О настройке Open vSwitch непростым языком04.04.2017 10:18

1ee15842f09640e5a3a79c7818a82741.png

От переводчика
SDN — программно определяемые сети — прочно вошли в нашу жизнь, однако материалов о низкоуровневой их работе на русском языке не так уж много. Предлагаю вашему вниманию перевод обучающей статьи, в которой показан пример создания автономного виртуального коммутатора с поддержкой VLAN. Такой коммутатор в своем базовом функционале может работать и без контроллера сети. Предполагается. что читатель знаком с основами и терминологией построения сетей в целом, а также имеет общее представление о программно-определяемых сетях.

Используемые термины:
OpenFlow — протокол управления передачей данных в сети. Описывает процесс взаимодействия контроллера и коммутатора, а также формат загружаемых в коммутатор правил.
Open vSwitch — программная реализация коммутатора, совместимого с протоколом OpenFlow. Используется для управления трафиком в системах виртуализации, например, OpenStack и oVirt (экспериментально).
802.1Q (VLAN) — механизм разграничения трафика как в пределах одного коммутатора, так и в локальной сети. Основан на внедрении в пакет данных тега (номера) VLAN
802.1p (QoS) — механизм управления приоритезацией трафика. Часть стандарта 802.1Q
Порт агрегации (trunk port) — порт коммутатора, соединенный с вышестоящим коммутатором. Порт агрегации разрешает отправку пакетов с любым номером VLAN
Порт доступа (access port) — порт коммутатора, разрешающий работу с пакетами только определенных VLAN.


Введение

В Сети есть много руководств по основам OpenFlow, но эта статья о другом. Тем не менее, для понимания данной статьи базовые знания об OpenFlow обязательны. Если вы не до конца понимаете, как работают правила OpenFlow, изучите пожалуйста основы, а затем возвращайтесь к этой статье.
Также вам потребуются знания основ Open vSwitch. Если вы никогда не использовали утилиты управления ovs-vsctl или ovs-ofctl, вам следует немного почитать про них перед тем, как мы продолжим.
Большая часть возможностей, описанных в этом руководстве, относятся к расширенной версии протокола OpenFlow, реализованной в Open vSwitch.Если вы используйте аппаратную реализацию в виде коммутатора на базе ASIC-чипа, это руководство вряд ли вам поможет.
Мы не будем подробно рассматривать всю подноготную технологий, о которых пойдет речь. За подробностями вы можете обратиться к документации Open vSwitch, в особенности — к файлам справки ovs-vsctl, а также к комментариям в файлах include/openflow/nicira-ext.h и include/openvswitch/meta-flow.h.

Приступая к работе

Будем считать, что в вашей системе уже установлены исполняемые файлы Open vSwitch. Какое-либо специализированное аппаратное обеспечение, кроме собственно компьютера, вам не потребуется. Вместо этого мы будем использовать скрипт ovs-sandbox, который можно найти здесь. Данный скрипт нужен для создания программно-определяемой сетевой среды на базе Open vSwitch.

Вы можете использовать ovs-sandbox тремя способами:

  • Если вы уже установили Open vSwitch на вашу систему, вы можете просто запустить скрипт ovs-sandbox, без указания каких-либо параметров.
  • Если Open vSwitch у вас не установлен (и вы не хотите устанавливать его), то можете собрать Open vSwitch без установки в соответствии с инструкциями для Linux, FreeBSD и NetSBD. Затем запустите ovs-sandbox и укажите ему каталог с Open vSwitch ./ovs-sandbox -b <каталог>
  • Как вариант, вы можете запустить команду make sandbox из каталога, в котором собран Open vSwitch

Скрипт делает следующее:

  1. ВНИМАНИЕ: удаляет все подкаталоги из подкаталога с именем sandbox текущего каталога и все файлы в этом подкаталоге
  2. Создает новый каталог «sandbox» в текущем каталоге.
  3. Устанавливает переменные среды, чтобы утилиты Open vSwitch использовали в качестве текущего каталога «sandbox», а не каталог установки Open vSwitch
  4. Если вы собирали Open vSwitch, но не устанавливали его, копирует файлы справки в подкаталог «sandbox» и записывает имя этого подкаталога в переменную среды MANPATH. Это означает, что когда вы будете использовать, например, команду man ovs-vsctl, вы увидите справку именно для той версии Open vSwitch, которую вы собирали.
  5. Создает пустую базу данных конфигурации Open vSwitch в каталоге «sandbox»
  6. Запускает ovsdb-server в каталоге «sandbox»
  7. Запускает ovs-vswitchd в каталоге «sandbox» и передает ему параметры для специального тестового режима работы.
  8. Запускает сеанс интерактивной оболочки из каталога «sandbox»

Начиная с этого момента, вы можете запускать все привычные команды Open vSwitch из сеанса оболочки. Например, вы можете запустить ovs-vsctl и создать виртуальный коммутатор: 

$ ovs-vsctl add-br br0

С точки зрения Open vSwitch, созданный вами коммутатор так же реален, как и любой другой. Например, вы можете подключить его к OpenFlow-контроллеру или использовать ovs-ofctl для проверки и изменения правил управления трафиком. С другой стороны, коммутатор не отображается в сетевой конфигурации хоста, так что утилиты ifconfig и ip не могут работать с ним. Кроме того, не будут работать и утилиты ping и tcpdump. Но у этого есть и хорошая сторона — вы не сможете сбить сетевые настройки хоста, изменяя настройки коммутатора в «песочнице».

Когда вам потребуется завершить работу с Open vSwitch, просто наберите в оболочке команду «exit» или нажмите Ctrl+D. Это завершит процессы, запущенные скриптом ovs-sandbox, но оставит на месте сам каталог «sandbox» со всем его содержимым.
Каталог «sandbox» содержит файлы журналов для всех служб Open vSwitch, так что вы можете просмотреть их и после того, как завершили работу с Open vSwitch.

Использование отладчика GDB


Этот обучающий материал не требует применения отладчика GDB в обязательном порядке, тем не менее вы можете использовать GDB, чтобы разобраться во внутреннем устройстве утилит Open vSwitch.

GDB можно применять для отладки любого уже запущенного процесса при помощи команды gdb .

Скрипт ovs-sandbox имеет параметр -g для запуска ovs-vswitchd под GDB. Параметр можно использовать в случае, если требуется поставить точки останова перед выполнением ovs-vswitchd или чтобы отладить сбой на раннем этапе запуска службы. Кроме того, существует параметр -d, который запускает под GDB службу ovsdb-server. Оба параметра можно использовать одновременно.

Имеется также параметр -e, который тоже запускает под GDB службу ovs-vswitchd, но не отображает приглашение gdb> и не ждет ввода команд, а сразу приступает к исполнению службы. Параметр -r заставляет службу ovsdb-server запускаться под GDB сразу же, подобно ovs-vswitchd.

Чтобы избежать некорректного поведения терминала при запуске GDB, скрипт ovs-sandbox открывает новый сеанс xterm для каждой сессии GDB. Для систем без графического сервера X Windows поддержка GDB отключена.

При запуске тестовой среды из make-файла скрипту можно передать параметр -g через переменную среды SANDBOXFLAGS. Таким образом, команда make sandbox SANDBOXFLAGS=-g запустит тестовую среду со службой ovs-vswitchd под отладчиком GDB в отдельном X-терминале.

Постановка задачи


Основная цель этого руководства — демонстрация обширных возможностей Open vSwitch по управлению трафиком. В ходе работы мы построим коммутатор, способный запоминать MAC-адреса и имеющий разделенные VLAN«ами порты доступа и агрегации. Если не рассматривать функции Open vSwitch, о которых мы поговорми чуть ниже, OpenFlow предлагает как минимум два пути для реализации такого коммутатора.
  • Использование контроллера OpenFlow для запоминания MAC-адресов в режиме постобработки трафика. Каждое новое соединение сначала анализируется контроллером, который формирует для него разрешающие правила. Всякий раз, когда новый MAC-адрес появляется на порту или «переезжает» из одного порта в другой, контроллер должен изменить соответствующую таблицу правил коммутатора.
  • «Обычное» (NORMAL) поведение. OpenFlow определяет такое поведение, как «работу обычного коммутатора без OpenFlow». Если правило предусматривает такое поведение, то пакет проходит через коммутатор так, как будто на коммутаторе не настроен OpenFlow.

К сожалению, оба подхода не лишены недостатков. В первом случае использование контроллера приводит к существенному уменьшению полосы пропускания и увеличению задержек. Кроме того, контроллер плохо масштабируется для обслуживания большого количества коммутаторов, что особенно важно в среде с тысячами гипервизоров, на каждом из которых работает собственный OpenFlow-коммутатор. Естественно, запоминание MAC-адресов с использованием контроллера не будет работать, если контроллер вышел из строя, медленно обрабатывает запросы или недоступен вследствие сетевых проблем.

Во втором случае (NORMAL) мы имеем дело с проблемами иного рода. Во-первых, лишь небольшая часть «обычного» поведения стандартизирована и по-разному работает на оборудовании различных производителей. Доступные функции и способы их конфигурирования (как правило, не через OpenFlow) у разных производителей тоже отличаются. Во-вторых, режим NORMAL не очень хорошо работает совместно с другими правилами OpenFlow. NORMAL реализует концепцию «все или ничего» и имеет весьма узкий потенциал для настройки своего поведения или взаимодействия с другими функциями.

Сценарий тестирования


Мы построим OpenFlow-коммутатор и настроим его таблицы для запоминания MAC-адресов и работы с VLAN-ами. Коммутатор будет иметь 4 порта:
  • p1 — порт агрегации для всех VLAN на порте 1 коммутатора
  • p2 — порт доступа для нетегированного VLAN 20 на порте 2 коммутатора
  • p3, p4 — порты доступа для нетегированного VLAN 30 на портах 2 и 3 коммутатора, соответственно

Имена портов не имеют значения, вы можете назвать их eth1-eth4 или другим образом по вашему желанию.
Коммутатор OpenFlow также имеет один порт, видимый на хосте как локальный интерфейс. Наш сценарий не предусматривает его использование.

Наш коммутатор будет включать 5 таблиц с правилами, каждая из которых реализует свою часть конвейера по обработке трафика.
  • Таблица 0: Входной контроль
  • Таблица 1: Обработка VLAN на входе
  • Таблица 2: Запоминание MAC и VLAN для входного порта
  • Таблица 3: Поиск порта для выходного MAC и VLAN
  • Таблица 4: Обработка пакета на выходе

Ниже будет показано, как создать такой коммутатор таблица за таблицей.

Вы можете копировать команды ovs-vsctl и ovs-ofctl с параметрами из примеров ниже и вставлять их в командную оболочку, созданную ovs-sandbox. Команда ovs-appctl с параметрами предназначена для тестов и ее не следует использовать отдельно от остальных примеров.

Установка


Запустим ovs-sandbox и в открывшейся интерактивной оболочке введем следующую команду: 
$ ovs-vsctl add-br br0 -- set Bridge br0 fail-mode=secure

Эта команда создает новый виртуальный коммутатор br0 и переводит его в так называемый режим fail-secure. Для нас пока это будет значить только то, что коммутатор запустится с пустыми таблицами.
Если мы не сделаем этого, коммутатор запустится с единственным правилом, которое отрабатывает поведение NORMAL. Мы можем использовать эту возможность для построения такого же коммутатора, как и наш, но с ограничениями, описанными выше в разделе «Постановка задачи»

Новый коммутатор пока имеет только один порт — локальный br0. Нам нужно добавить порты p1, p2, p3 и p4. Команда for оболочки — один из способов сделать это: 
$ for i in 1 2 3 4; do
    ovs-vsctl add-port br0 p$i -- set Interface p$i ofport_request=$i
    ovs-ofctl mod-port br0 p$i up
done

Команды не просто добавляют порты, но и устанавливают атрибут ofport_request, чтобы порт p1 соответствовал порту 1 OpenFlow, порт 2 — порту 2 OpenFlow и так далее.

Мы можем пропустить установку атрибута ofport_request и позволить OpenFlow самому выбирать порты, но в целях обучения мы присвоим номера портов самостоятельно, чтобы говорить, например, о порте 1 OpenFlow и знать, что он ссылается на порт p1.

Команда ovs-ofctl, используя запрос к OpenFlow, запускает интерфейсы, которые при создании выключены. К такому же эффекту приводит запуска команды ifconfig up, но интерфейсы тестовой среды не отображаются в хостовой ОС и ifconfig не может ими управлять.

Мы пока еще не настраивали VLAN«ы и запоминание MAC-адресов, поскольку планируем сделать это ниже при помощи таблиц управления трафиком.

Чтобы посмотреть результат нашей работы, можно воспользоваться командами ovs-vsctl show или ovs-ofctl show br0.

Создаем таблицу 0: Входной контроль


В таблицу 0 попадают пакеты, которые только пришли на коммутатор. Мы будем использовать ее для отбраковки пакетов по тем или иным причинам. Например, пакет с широковещательным адресом отправителя — неправильный, так что мы можем отбросить его на входе в коммутатор.
$ ovs-ofctl add-flow br0 "table=0, dl_src=01:00:00:00:00:00/01:00:00:00:00:00, actions=drop"

Коммутатор также не должен пересылать дальше пакеты протокола IEEE 802.1D Spanning Tree Protocol (STP), так что мы добавим правило для отбрасывания таких пакетов и пакетов других зарезервированных многоадресных протоколов: 
$ ovs-ofctl add-flow br0 "table=0, dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0, actions=drop"

Мы можем добавить правила для выбраковки пакетов других протоколов по принципу, показанному выше.

Нам нужно еще одно правило с приоритетом ниже приоритета по-умолчанию, чтобы пакеты, которые не были отброшены вышестоящими правилами, отправились на следующую стадию — в таблицу 1 OpenFlow.

$ ovs-ofctl add-flow br0 "table=0, priority=0, actions=resubmit(,1)"

Действие resubmit — это часть расширения Open vSwitch для OpenFlow.

Проверяем таблицу 0


Если мы используем Open vSwitch для настройки физического или виртуального коммутатора, нам нужно тестировать его путем отправки пакетов разными путями, например, с помощью всем известных утилит ping и tcpdump или более специализированных средств типа Scapy. Для нашего виртуального коммутатора это затруднительно, поскольку он невидим для операционной системы.

Однако виртуальный коммутатор имеет несколько специальных инструментов для тестирования. Наиболее широкий функционал предлагает ofproto/trace. Принимая на вход имя коммутатора и описание трафика, ofproto/trace пошагово демонстрирует, какие правила будут им затронуты.

Пример 1


Попробуйте выполнить команду: 
$ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=01:80:c2:00:00:05

Вывод будет примерно таким: 
Bridge: br0
Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=01:80:c2:00:00:05,dl_type=0x0000

Rule: table=0 cookie=0 dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0
OpenFlow actions=drop

Final flow: unchanged
Megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
Datapath actions: drop

Первая строка показывает параметры обрабатываемого пакета в более детализированном виде, чем мы пишем в командной строке.

Вторые несколько строк показывают путь пакета внутри коммутатора br0. Мы видим, что в таблице 0 было найдено соответствующее правило с определенным приоритетом и заданным действием. Если пакет подпадает под несколько правил, таких строк будет несколько.

Последняя группа строк отображает результат. который мы не будем здесь подробно рассматривать.

Пример 2

Попробуем выполнить команду

$ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=01:80:c2:00:00:10

Вывод ее будет таким: 
Bridge: br0
Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=01:80:c2:00:00:10,dl_type=0x0000

Rule: table=0 cookie=0 priority=0
OpenFlow actions=resubmit(,1)

        Resubmitted flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=01:80:c2:00:00:10,dl_type=0x0000
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=01:80:c2:00:00:10/ff:ff:ff:ff:ff:f0,dl_type=0x0000
        Rule: table=254 cookie=0 priority=0,reg0=0x2
        OpenFlow actions=drop

Final flow: unchanged
Megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=01:80:c2:00:00:10/ff:ff:ff:ff:ff:f0,dl_type=0x0000
Datapath actions: drop

В этом случае пакет не соответствует какому-либо правилу с действием «drop» в таблице 0, так что он попадает под правило с действием resubmit. Действие resubmit перенаправляет пакет в таблицу 1, что показано в строке
OpenFlow actions=resubmit(,1)

Мы пока еще не добавили какие-либо правила в таблицу 1 OpenFlow, так что пакет не будет соответствовать ни одному правилу. Таким образом, пакет будет отброшен, так что со стороны результат будет таким же, как и в первом примере.

Создаем таблицу 1: Обработка VLAN на входе


Пакеты, которые приходит в таблицу 1, уже прошли все основные проверки в таблице 0. Таблица 1 предназначена для прикрепления пакетов к VLAN«ам. Проверка основана на сопоставлении VLAN«а и порта, через который пакеты попадают в коммутатор. Мы также будем использовать таблицу для прикрепления заголовка VLAN к пакету, который уходит в порт агрегации, что позволит отложить стадии обработка, относящиеся к VLAN, поскольку номер VLAN всегда будет частью заголовка (за исключением особых случаев).

Начнем с добавления правила с низким приоритетом, которое будет отбрасывать все пакеты. Перед ним мы добавим правила, пропускающие нужные нам пакеты. Пусть это будет правило типа «отбрасывать по-умолчанию»

$ ovs-ofctl add-flow br0 "table=1, priority=0, actions=drop"

Порт агрегации p1 (или OpenFlow порт 1, что проще) принимает любые пакеты вне зависимости, имеют ли они или нет заголовок VLAN и каков этот заголовок. Таким образом, мы можем добавить правило, которое перенаправляет весь трафик с порта 1 в следующую таблицу: 
$ ovs-ofctl add-flow br0 "table=1, priority=99, in_port=1, actions=resubmit(,2)"

На портах доступа мы можем принимать любые пакеты без заголовка VLAN, присваивать им соответствующий VLAN и передавать на следующую ступень.
$ ovs-ofctl add-flows br0 - <<'EOF'
table=1, priority=99, in_port=2, vlan_tci=0, actions=mod_vlan_vid:20, resubmit(,2)
table=1, priority=99, in_port=3, vlan_tci=0, actions=mod_vlan_vid:30, resubmit(,2)
table=1, priority=99, in_port=4, vlan_tci=0, actions=mod_vlan_vid:30, resubmit(,2)
EOF

Мы не будем писать правил. обрабатывающих пакеты с уже имеющимися метками VLAN (802.1Q), которые приходят на порты доступа, так что эти пакеты будут отброшены правилом по-умолчанию. Именно такое поведение мы и ожидаем от портов доступа.

В других случаях порты доступа пропускают пакеты, принадлежащие VLAN 0 (т.е. пакеты, отмеченные в соответствии с механизмом приоритезации трафика 802.1p). Чтобы разрешить такие пакеты, замените vlan_tci=0 на vlan_tci=0/0xfff в правиле выше.

Тестируем таблицу 1


Утилита ofproto/trace позволяет нам проверить добавленные правила для управления VLAN«ами на входе в коммутатор.

Пример 1. Пакет на порте агрегации


Проверяем пакет, который пришел в коммутатор с порта агрегации: 
$ ovs-appctl ofproto/trace br0 in_port=1,vlan_tci=5

Из вывода команду следует, что пакет проходит таблицу 0, пересылается в таблицу 1, а затем — в таблицу 2 (в которой пока еще нет правил).
Bridge: br0
Flow: in_port=1,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000

Rule: table=0 cookie=0 priority=0
OpenFlow actions=resubmit(,1)

        Resubmitted flow: in_port=1,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
        Rule: table=1 cookie=0 priority=99,in_port=1
        OpenFlow actions=resubmit(,2)

                Resubmitted flow: unchanged
                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                Resubmitted  odp: drop
                Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                Rule: table=254 cookie=0 priority=0,reg0=0x2
                OpenFlow actions=drop

Final flow: unchanged
Megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
Datapath actions: drop

Пример 2. Корректный пакет на порте доступа


Тестируем корректный пакет (т.е. пакет без заголовка 802.1Q), приходящий на порт p2: 
$ ovs-appctl ofproto/trace br0 in_port=2

Вывод этой команды похож на вывод предыдущей за исключением того, что пакету перед отправкой в таблицу 2 присваивается метка VLAN 20.
Bridge: br0
Flow: in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000

Rule: table=0 cookie=0 priority=0
OpenFlow actions=resubmit(,1)

        Resubmitted flow: in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
        Rule: table=1 cookie=0 priority=99,in_port=2,vlan_tci=0x0000
        OpenFlow actions=mod_vlan_vid:20,resubmit(,2)

                Resubmitted flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                Resubmitted  odp: drop
                Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                Rule: table=254 cookie=0 priority=0,reg0=0x2
                OpenFlow actions=drop

Final flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
Datapath actions: drop

Пример 3. Некорректный пакет (с заголовком 801.2Q) на порте p2


$ ovs-appctl ofproto/trace br0 in_port=2,vlan_tci=5

Вывод команды показывает, что пакет поступает в таблицу 1 и отбрасывается правилом по-умолчанию.
Bridge: br0
Flow: in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000

Rule: table=0 cookie=0 priority=0
OpenFlow actions=resubmit(,1)

        Resubmitted flow: in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
        Rule: table=1 cookie=0 priority=0
        OpenFlow actions=drop

Final flow: unchanged
Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
Datapath actions: drop

Создаем таблицу 2: запоминаем пару MAC+VLAN на входящем порте


Таблица 2 позволяет коммутатору запомнить, какой MAC-адрес отправителя соответствует указанному порту и VLAN-метке пакета.
Эта таблица — хорошая иллюстрация того, почему VLAN-метки добавляются к пакетам, пришедшим в коммутатор через порт доступа, именно в таблице 1. Мы хотим сопоставлять пару VLAN+MAC с портом вне зависимости от того, принадлежал ли уже пакет к VLAN, когда пришел в коммутатор, или же метка VLAN была проставлена в пакете самим коммутатором.
Потребуется всего одно правило, чтобы реализовать нашу задумку. Вот оно: 
$ ovs-ofctl add-flow br0 \
    "table=2 actions=learn(table=10, NXM_OF_VLAN_TCI[0..11], \
                           NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
                           load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]), \
                     resubmit(,3)"

Действие «learn» изменяет таблицу с правилами на основании содержимого пакета, который обрабатывается в данный момент. Это действие является расширением протокола OpenFlow, реализованного в Open vSwitch.
Параметры действия «learn» можно описать следующим образом: 
table=10
Изменять таблицу 10. В этой таблице мы будем запоминать MAC-адреса
NXM_OF_VLAN_TCI[0..11]
Создать правило в таблице 10, которому будут соответствовать все пакеты с VLAN, равным VLAN текущего пакета. Это позволит сопоставить MAC с единственным номером VLAN, как это обычно делают коммутаторы с поддержкой VLAN
NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[]
Добавляет в созданное правило параметр «MAC-адрес получателя», который будет равен MAC-адресу отправителя текущего пакета.
load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]
Предыдущие команды задавали параметры пакета, обрабатываемого новым правилом, а данная команда определяет действие над пакетом. Это действие загружает номер порта, с которого пришел пакет, в регистр 0 (специальное поле, определенное в Open vSwitch расширении протокола OpenFlow)
В реальном процессе запоминания MAC-адресов могут участвовать еще два параметра. Во-первых, действие «learn» должно задавать параметр hard_timeout для нового типа трафика, чтобы позволить коммутатору «забывать» MAC-адреса, если с данного адреса не поступает пакетов в течение некоторого разумного времени. Во-вторых, следует ограничить потребление ресурсов, ограничив число строк в таблице 10 при помощи таблицы Flow_Table в базе данных конфигурации Open vSwitch.

Определенно, для понимания работы правила нам нужны примеры

Тестируем таблицу 2


Пример 1


Для начала выполним команду: 
$ ovs-appctl ofproto/trace br0 in_port=1,vlan_tci=20,dl_src=50:00:00:00:00:01 -generate

Вывод команды покажет нам, что действие «learn» выполнено и в таблицу 10 добавлено новое правило.
Bridge: br0
Flow: in_port=1,vlan_tci=0x0014,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000

Rule: table=0 cookie=0 priority=0
OpenFlow actions=resubmit(,1)

        Resubmitted flow: in_port=1,vlan_tci=0x0014,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
        Rule: table=1 cookie=0 priority=99,in_port=1
        OpenFlow actions=resubmit(,2)

                Resubmitted flow: unchanged
                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                Resubmitted  odp: drop
                Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                Rule: table=2 cookie=0
                OpenFlow actions=learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]),resubmit(,3)

                        Resubmitted flow: unchanged
                        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                        Resubmitted  odp: drop
                        Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                        Rule: table=254 cookie=0 priority=0,reg0=0x2
                        OpenFlow actions=drop

Final flow: unchanged
Megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x1fff,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
Datapath actions: drop

Обратите внимание на параметр -generate. Как правило, ofproto/trace не влияет на систему: действие «output» на самом деле не отправляет пакеты, действие «learn» не изменяет таблицы и так далее. С параметром -generate утилита ofproto/trace вынуждает систему выполнять действие «learn». Это важно, поскольку мы хотим видеть применение действия «learn» в таблице 10. Выполним команду
$ ovs-ofctl dump-flows br0 table=10

которая покажет примерно следующее: 
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=4315.181s, table=10, n_packets=0, n_bytes=0, idle_age=4315, vlan_tci=0x0014/0x0fff,dl_dst=50:00:00:00:00:01 actions=load:0x1->NXM_NX_REG0[0..15]

Можно увидеть, что пакет с VLAN 20 и адресом отправителя 50:00:00:00:00:01 привел к созданию правила, которому соответствуют пакеты с VLAN 20 и адресом получателя 50:00:00:00:00:01. Правило загружает номер порта 1, с которого мы тестировали коммутатор, в регистр 0.

Пример 2


Выполним вторую команду: 
$ ovs-appctl ofproto/trace br0 in_port=2,dl_src=50:00:00:00:00:01 -generate

Bridge: br0
Flow: in_port=2,vlan_tci=0x0000,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000

Rule: table=0 cookie=0 priority=0
OpenFlow actions=resubmit(,1)

        Resubmitted flow: in_port=2,vlan_tci=0x0000,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
        Rule: table=1 cookie=0 priority=99,in_port=2,vlan_tci=0x0000
        OpenFlow actions=mod_vlan_vid:20,resubmit(,2)

                Resubmitted flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000
                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                Resubmitted  odp: drop
                Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                Rule: table=2 cookie=0
                OpenFlow actions=learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]),resubmit(,3)

                        Resubmitted flow: unchanged
                        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                        Resubmitted  odp: drop
                        Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                        Rule: table=254 cookie=0 priority=0,reg0=0x2
                        OpenFlow actions=drop

Final flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
Datapath actions: drop

Пакет, созданный этой командой, имеет те же VLAN и MAC, что и в предыдущем примере, хотя поступает с порта доступа и изначально не имеет метки VLAN. Пакет в предыдущем примере приходил с порта доступа и уже имел заголовок 802.1Q. Теперь выведем содержимое таблицы 10
$ ovs-ofctl dump-flows br0 table=10

NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=4355.977s, table=10, n_packets=0, n_bytes=0, idle_age=4355, hard_age=15, vlan_tci=0x0014/0x0fff,dl_dst=50:00:00:00:00:01 actions=load:0x2->NXM_NX_REG0[0..15]

Мы увидим, что правило изменилось, отражая тот факт, что пакет пришел с порта 2. Именно такого поведения мы и ожидали.

Создаем таблицу 3: поиск порта назначения


В этой таблице определяется порт назначения, куда коммутатор должен направить пакет, основываясь на MAC-адресе получателя и номере VLAN. Если в таблице 2 уже обрабатывались пакеты с такими же адресами отправителя и получателя, то у нас уже есть запомненный адрес получателя и мы сразу направим пакет туда.
В этом случае нам нужно только одно правило
$ ovs-ofctl add-flow br0 "table=3 priority=50 actions=resubmit(,10), resubmit(,4)"

Это правило сначала перенаправляет пакет в таблицу 10, в которой отрабатывает правило «learn». Как мы говорили ранее, номера портов запомненных пакетов записываются в регистр 0. Если порт назначения для нашего пакета не запомнен, ни одно правило в таблице 10 не сработает, и действие «resubmit» закончится ничем. Поскольку регистры инициализируются нулевым значением, мы можем использовать значение 0 регистра №0 как индикатор того, что пакет на следующих стадиях обработки требуется разослать по всем портам.

Второе действие — перенаправление пакета в таблицу 4, на следующую стадию обработки.

Мы можем добавить еще одно правило, чтобы пропустить поиск в таблице 10 для многоадресных и широковещательных пакетов, поскольку их всегда требуется рассылать по всем портам.

$ ovs-ofctl add-flow br0 "table=3 priority=99 dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,4)"

В указанном выше правиле нет большой необходимости, поскольку широковещательные пакеты никогда не отображаются в таблице 10, так как мы поместили в таблицу 0 правило, отбрасывающее пакеты многоадресных протоколов.

Тестируем таблицу 3


Пример


Данная команда приводит к тому, что Open vSwitch запоминает адрес f0:00:00:00:00:01 на порте p1 VLAN«а 20: 
$ ovs-appctl ofproto/trace br0  in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01 -generate

Вывод команды показывает, что получатель пакета неизвестен, поскольку в таблице 10 не было найдено соответствующей строки.
Bridge: br0
Flow: in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000

Rule: table=0 cookie=0 priority=0
OpenFlow actions=resubmit(,1)

        Resubmitted flow: in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=90:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
        Rule: table=1 cookie=0 priority=99,in_port=1
        OpenFlow actions=resubmit(,2)

                Resubmitted flow: unchanged
                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                Resubmitted  odp: drop
                Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=90:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                Rule: table=2 cookie=0
                OpenFlow actions=learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]),resubmit(,3)

                        Resubmitted flow: unchanged
                        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                        Resubmitted  odp: drop
                        Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                        Rule: table=3 cookie=0 priority=50
                        OpenFlow actions=resubmit(,10),resubmit(,4)

                                Resubmitted flow: unchanged
                                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                                Resubmitted  odp: drop
                                Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000
                                Rule: table=254 cookie=0 priority=0,reg0=0x2
                                OpenFlow actions=drop

                                Resubmitted flow: unchanged
                                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                                Resubmitted  odp: drop
                                Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000
                                Rule: table=254 cookie=0 priority=0,reg0=0x2
                                OpenFlow actions=drop

Final flow: unchanged
Megaflow: recirc_id=0,in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000
Datapath actions: drop

Если два способа убедиться, что адрес отправителя был запомнен. Наиболее простой — вывести содержимое таблицы 10 с помощью команды: 
$ ovs-ofctl dump-flows br0 table=10

которая покажет примерно следующее: 
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=54.661s, table=10, n_packets=0, n_bytes=0, idle_age=54, vlan_tci=0x0014/0x0fff,dl_dst=f0:00:00:00:00:01 actions=load:0x1->NXM_NX_REG0[0..15]

Если вы запускали предыдущие примеры, или пробовали выполнить свои собственные команды, в выводе вы можете увидеть дополнительные строки. Эти строки не должны влиять на выполнение наших команд, Если они вас смущают, вы можете удалить их с помощью команды ovs-ofctl del-flows br0 table=10

Второй способ — это сгенерировать пакет, который задействует правило запоминания адресов. Например, мы можем сгенерировать пакет на порту p2, чей адрес назначения мы только что запомнили на порте p1. 
$ ovs-appctl ofproto/trace br0 in_port=2,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01 -generate

Вывод команды приведен ниже. Обратите внимание на строки, которые отображают работу действия «resubmit (,10)». По указанным строкам можно сделать вывод, что пакет соответствует правилу, созданному на основе первого MAC-адреса, который мы использовали, и это правило загружает номер порта p1 в регистр 0.
Bridge: br0
Flow: in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000

Rule: table=0 cookie=0 priority=0
OpenFlow actions=resubmit(,1)

        Resubmitted flow: in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
        Resubmitted  odp: drop
        Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=f0:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
        Rule: table=1 cookie=0 priority=99,in_port=2,vlan_tci=0x0000
        OpenFlow actions=mod_vlan_vid:20,resubmit(,2)

                Resubmitted flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                Resubmitted  odp: drop
                Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=f0:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                Rule: table=2 cookie=0
                OpenFlow actions=learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]),resubmit(,3)

                        Resubmitted flow: unchanged
                        Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                        Resubmitted  odp: drop
                        Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000
                        Rule: table=3 cookie=0 priority=50
                        OpenFlow actions=resubmit(,10),resubmit(,4)

                                Resubmitted flow: unchanged
                                Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                                Resubmitted  odp: drop
                                Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
                                Rule: table=10 cookie=0 vlan_tci=0x0014/0x0fff,dl_dst=f0:00:00:00:00:01
                                OpenFlow actions=load:0x1->NXM_NX_REG0[0..15]

                                Resubmitted flow: reg0=0x1,in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
                                Resubmitted regs: reg0=0x1 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0
                                Resubmitted  odp: drop
                                Resubmitted megaflow: recirc_id=0,reg0=0/0xffff,in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
                                Rule: table=254 cookie=0 priority=0,reg0=0x2
                                OpenFlow actions=drop

Final flow: reg0=0x1,in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=90:00:
    
            
© Habrahabr.ru