Open vSwitch реализует внутриполосное управление как скрытые потоки, то есть потоки, которые не видны через OpenFlow, и с более высоким приоритетом, чем потоки с подстановочными знаками, которые могут быть настроены через OpenFlow. Это сделано для того, чтобы контроллер OpenFlow не мог мешать им и, возможно, нарушать связь со своими коммутаторами. Посмотреть все потоки, в том числе внутриполосные, можно с помощью команды ovs-appctl bridge/dump-flows.
(...)
Следующие правила (с действием OFPP_NORMAL) устанавливаются на любом мосту, имеющем какие-либо удаленные устройства:
(a) Запросы DHCP, отправленные с локального порта.
(b) ARP отвечает на MAC-адрес локального порта.
(c) ARP-запросы с MAC-адреса локального порта.
In-band также устанавливает следующие правила для каждого уникального MAC-адреса следующего прыжка для IP-адресов удаленных устройств (следующим узлом является либо сам удаленный узел, если он находится в локальной подсети, либо шлюз для доступа к удаленному устройству):
(d) ARP отвечает на MAC-адрес следующего перехода.
(e) ARP-запросы с MAC-адреса следующего перехода.
In-band также устанавливает следующие правила для каждого уникального удаленного IP-адреса:
(f) Ответы ARP, содержащие IP-адрес удаленного устройства в качестве цели.
(g) Запросы ARP, содержащие IP-адрес удаленного устройства в качестве источника.
In-band также устанавливает следующие правила для каждой уникальной удаленной пары (IP, порт):
(h) TCP-трафик на IP-адрес и порт удаленного устройства.
(i) TCP-трафик с удаленного IP-адреса и порта.
Цель этих правил — сделать их как можно более узкими, чтобы позволить коммутатору присоединиться к сети и иметь возможность взаимодействовать с удаленными устройствами. Как упоминалось ранее, эти правила имеют более высокий приоритет, чем правила контроллера, поэтому, если они слишком широкие, они могут помешать контроллеру реализовать свою политику. Таким образом, внутриполосный режим активно отслеживает некоторые аспекты обработки потоков и пакетов, чтобы правила могли быть более точными.
Внутриполосное управление отслеживает попытки добавить потоки в тракт данных, которые могут помешать выполнению его функций. Путь данных допускает только записи с точным соответствием, поэтому внутриполосное управление может быть очень точным в отношении потоков, которые оно предотвращает. Потоки, пропущенные в пути данных, отправляются в пространство пользователя для обработки, поэтому предотвращение кэширования этих потоков в быстром пути не влияет на правильность. Единственный тип потока, который в настоящее время запрещен, — это поток, который не позволяет локальным портам видеть ответы DHCP. Например, правило, которое перенаправляет весь DHCP-трафик на контроллер, не будет разрешено, а правило, которое перенаправляется на все порты (включая локальный порт), будет разрешено.
Документ также содержит дополнительную информацию об особых случаях и возможных проблемах, но он довольно длинный, поэтому я его здесь не привожу.
