Open vSwitch

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

Какое-то время в средах виртуализации на базе KVM и Xen для решения данной задачи использовался встроенный в ядро Linux коммутатор второго уровня — Linux Bridge (мост, он же разновидность коммутатора). В принципе, он и сейчас используется по умолчанию в некоторых дистрибутивах как наиболее простое решение. Linux-мост позволяет создавать виртуальные интерфейсы для ВМ, а также коммутировать их между собой и внешним миров через физические интерфейсы узла. Также возможны некоторые методы фильтрации трафика на канальном уровне. Но даже этот скромный функционал едва ли применим в крупных инфраструктурах из-за еще одной особенности виртуализации — высокой мобильности объектов(VM). К сожалению Linux-мост не подходит для динамичных сред с большим количеством узлов и миграцией VM по причине отсутствия централизованности и взаимодействия между узлами. Связанность состояний и правил, таких как правила маршрутизации, ACL, QoS, мониторинга, закрепленные за сетевым объектом (VM) при перемещении на другой физический узел — это основной список требований к коммутатору в виртуальной среде. Здесь нам на помощь и приходит распеределенный, управляемый, многоуровневый виртуальный коммутатор, каковым и является Open vSwitch(далее OVS).

OVS — это свободный аналог коммерческих VMware Dis­trib­uted vSwitch и Cisco Nexus 1000v, изначально развиваемый компанией Cit­rix, а теперь уже и многочисленным сообществом, включающим специалистов из Red Hat, Canon­i­cal, Ora­cle и других компаний. Он базируется на некоторых уже имеющихся в ядре компонентах, например, том же Linux Bridge и штатном стеке QoS, плюс собственных разработках, реализующих дополнительный функционал.

С помощью OVS можно создавать VLAN’ы, фильтровать трафик на сетевом уровне, агрегировать каналы, зеркалировать трафик, ограничивать ширину канала для конкретных ВМ.
OVS значительно упрощает администрирование виртуализированных сред, так как вся сетевая конфигурация ВМ и статистика остаются связанными, даже если ВМ мигрирует с одного физического узла на другой. Управление коммутаторами, создание правил и их перемещение на каждом из узлов осуществляется централизованно с помощью протокола Open­Flow.
Поддержка NetFlow и sFlow позволяет мониторить и анализировать состояние сети по множеству аспектов, учитывать трафик ВМ.

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

Кроме всего, OVS может работать с логическими тегами так же как и его коммерческие конкуренты. Поддержка логического контекста в сети достигается посредством добавления тегов или управления ими в сетевых пакетах. Это может использоваться, например чтобы однозначно определить ВМ (способ, стойкий к аппаратному спуфингу).
Так же имеется реализация GRE-туннелирования, способная обрабатывать тысячи одновременных GRE-туннелей. Это, например, может использоваться, для объединения частных сетей ВМ в различных центрах обработки данных.

2. РАЗВЕРТЫВАНИЕ

OVS поддерживается ядром Linux начиная с версии 2.6.18 а по состоянию на версию 3.3 включен в основную ветку.

На сегодняшней день, OVS используется по умолчанию в таких платформах виртуализации как Cit­rix XenServer, Xen Cloud Plat­form, а также поддерживается QEMU-KVM/libvirt и Vir­tu­al­Box. Кроме этого, продукт интегрирован в такие системы управления виртуальной инфраструктурой, как Open­Stack, open­QRM, Open­Neb­ula, oVirt и при ручной настройке работает в CloudStack.

Уже подготовленный OVS точно есть в репозиториях Ubuntu, Debian, Fedora, а так же в портах FreeBSD и, возможно, в предпочитаемом вами дистрибутиве. Инструкцию по установке из пакетов или сборке из исходников можно легко найти с помощью поисковика.

3. АРХИТЕКТУРА

Архитектура OVS состоит из трех основных компонентов: базы данных, непосредственно программного коммутатора и управляющего контроллера. На каждом из физических узлов, вместе с гипервизором располагаются собственные БД и коммутатор. По сути, эти два компонента образуют самостоятельный, отдельно стоящий коммутатор, ничего не знающий о других таких же на соседних узлах. БД обеспечивает хранение всей конфигурации своего узла: настройки интерфейсов, портов, различные правила и прочее. Коммутатор, собственно, передает пакеты. Распределенность дизайна OVS достигается с помощью контроллера. Этот компонент обычно разворачивается на отдельный сервер или ВМ.

Используя протокол Open­Flow, OVS-контроллер способен централизованно управлять множеством OVS-коммутаторов, а так же другими устройствами, поддерживающими этот протокол. Таким образом, создается иллюзия, что мы работаем с распределенным по множеству узлов коммутатором. Такая модель кажется мне вполне прозрачной, простой и понятной. Есть множество самостоятельных коммутаторов. Хочешь — используй их как отдельные сущности, а хочешь — подключай к контроллеру и оркестрируй всеми одновременно. В рамках данной статьи будет рассмотрены возможности отдельно стоящего коммутатора без использования контроллера.

4. СОЗДАЕМ КОММУТАТОР И ДОБАВЛЯЕМ ПОРТЫ

После установки OVS никаких коммутаторов автоматически не создается. Это необходимо проделать самостоятельно.

# ovs-vsctl add-br <имя_коммутатора>

Пример создания коммутатора:

ovs-vsctl add-br ovs-sw0

Пример создания порта на коммутаторе:

# ovs-vsctl add-port <имя_комутатора> <имя_физ.Интерфейса>

Посмотреть текущую конфигурацию всех имеющихся коммутаторов в виде наглядного дерева из портов можно с помощью следующей команды:

# ovs-vsctl show

Вывести имена всех коммутаторов:

# ovs-vsctl list-br

Посмотреть текущий список портов конкретного коммутатора:

# ovs-vsctl list-ports <имя_коммутатора>

Удалить порт:

# ovs-vsctl del-port <имя_коммутатора> <имя_порта>

Удалить коммутатор целиком:

# ovs-vsctl del-br <имя_коммутатора>

5. ТОНКОСТИ КОНФИГУРИРОВАНИЯ

Конфигурация всех Open vSwitch коммутаторов, портов, настройки поддерживаемых протоколов хранятся в собственной базе данных OVS. Утилита ovs-vsctl предоставляет интерфейс для внесения изменений в эту БД. Для некоторых типичных задач существуют вполне понятные, говорящие сами за себя параметры, подобные представленным в предыдущем разделе. Но как только появится необходимость в каком либо продвинутом функционале, например, создании GRE-туннеля, необходимо будет на прямую править записи БД(в формате JSON) с помощью специального синтаксиса. В общем случае синтаксис для внесения изменений в БД выглядит так:

# ovs-vsctl <команда> <таблица> <запись> <ключ=значение>

Например разрешим порту eth0 пропускать во внешний мир трафик из определенных VLAN-ов:

# ovs-vsctl set port eth0 trunks=10,20,30,40,50

Вместо команды set, могут также использоваться:

list <таблица> <запись>
find <таблица> <условие>
get <таблица> <запись> <ключ=значение>
add <таблица> <запись> <ключ=значение>
remove <таблица> <запись> <ключ=значение>
clear <таблица> <запись> <ключ>
cre­ate <таблица> <запись> <ключ=значение>
destroy <таблица> <запись>
wait-until <таблица> <запись> <ключ=значение>

Думаю, что по началу команд, понятно их предназначение без пояснения. Единственный вопрос вызывает wait-until. Но к сожалению, я так и не понял как она работает.

В стандартной конфигурации в OVSDB существуют следующие таблицы:

* Open_vSwitch — Cхема
* Bridge
* Port
* Inter­face
* Flow_Table – конфигурация Open­Flow
* QoS
* Mir­ror
* Con­troller — параметры подключения к контроллеру Open­Flow
* Man­ager – конфигурация OVSDB
* Net­Flow
* SSL
* sFlow
* IPFIX
* Flow_Sample_Collector_Set

Содержание большинства таблиц понятно из их названия. Изначально почти все они пусты, так как конфигурация отсутствует.

Например, просмотреть, какие записи присутствуют в таблице описывающей порты можно следующим образом:

# ovs-vsctl list port

а конфигурацию (запись) конкретно для eth0:

# ovs-vsctl list port eth0

так же можно пользоваться поиском оперируя различными параметрами
например, вывести все порты включенные в конкретный VLAN:

# ovs-vsctl find port tag=10

6. ОРГАНИЗОВЫВАЕМ ВИРТУАЛЬНЫЕ СЕТИ (VLAN)

Это пожалуй одна из самых актуальных функций коммутатора, как физического, так и виртуального. Я думаю, что объяснять их функциональное предназначение будет лишним, поэтому просто покажу как это реализуется в Open vSwitch.
В скудной документации это предложено делать следующим способом:
Берется конкретный, уже существующий порт и ему, путем внесения изменений в базу, присваивается тег (tag) с номером желаемого VLAN-а (VLAN ID)

# ovs-vsctl set port <имя_порта> tag=10

Все вроде бы просто и логично. Но, у этого способа есть как минимум три серьезных проблемы, делающие его фактически неприменимым.
Во-первых, необходимо знать какие порты принадлежат ВМ. Какого-то штатного способа сделать это я не нашел. Во-вторых, после выключения ВМ, ее порт и соответствующие ему настройки автоматически удаляются. И в третьих, даже если мы создадим для каждой ВМ статический порт и присвоим нужные теги, способа подключить ВМ к существующему порту при использовании KVM и lib­virt, нет.
По большему счету, это проблема lib­virt. Судя по списку изменений [1], до версии 0.10.0 он не умел работать с VLAN’ами. Точнее, он мог автоматически создавать интерфейсы при запуске ВМ, но не позволял помещать их в нужные VLAN’ы, тогда как, например, XenServer, тесно интегрированный с OVS, позволяет указать номер VLAN при настройке сетевого интерфейса ВМ. В дистрибутивах с долгосрочной поддержкой версия lib­virt отстает (например, Ubuntu 12.04 LTS это 0.9.8), так что приходится использовать другой путь.
Мы можем включить в нужный VLAN не отдельный порт а целый коммутатор целиком. По умолчанию коммутатор создается в VLAN-е 0. Наш главный, родительский(ovs-sw0) мы так и оставим. А вот несколько других, дочерних, мы создадим в нужных нам VLAN-ах и подключим их к главному как порты.

Синтаксис:

# ovs-vsctl add-br <новый_дочерний_мост> <родительский_мост>

Пример:

# ovs-vsctl add-br sw0-vlan10 ovs-sw0 10

Данная команда создает виртуальный коммутатор sw0-vlan10, подключает к основному как порт и помещает его в VLAN с номером 10.
Таким путем, можно создать сколько угодно VLAN-ов. А чтоб поместить ВМ в нужный VLAN, необходимо вместо общего устройства ovs-sw0 указать например sw0-vlan10.
Теперь, команда ovs-vsctl show дополнительно будет показывать теги каждого порта, определяя тем самым его принадлежность к VLAN.

Посмотреть в каком VLAN-е находится конкретный коммутатор:

# ovs-vsctl br-to-vlan <имя_коммутатора>

Посмотреть имя родительского коммутатора:

# ovs-vsctl br-to-parent <имя_коммутатора>

7. АГРЕГИРУЕМ ФИЗИЧЕСКИЕ ИНТЕРФЕЙСЫ

ля повышения пропускной способности и уровня отказоустойчивости в Open vSwitch коммутатор могут быть включены несколько физических интерфейсов с задействованной на них агрегацией по протоколу LACP (Link Aggre­ga­tion Con­trol Pro­to­col). Выполняется это на канальном уровне, прозрачно для высокоуровневых протоколов, путем создания специального связующего-интерфейса (Bonding).

Создадим bond-интерфейс:

# ovs-vsctl add-bond <имя_коммутатора> <имя_нового_bonda> <список_физ.интерфейсов>

Пример:

# ovs-vsctl add-bond ovs-sw0 bond0 eth0 eth1

Включаем lacp на созданном bond-интерфейсе

# ovs-vsctl set port bond0 lacp=active

Информация о бонд-интерфейсе:

# ovs-appctl lacp/show <bond-интерфейс>

8. ИНТЕРФЕЙС УПРАВЛЕНИЯ ХОСТ-СИТЕМОЙ

Не исключена ситуация когда в хост-ситеме нет свободного физического интерфейса для управления гипервизором. Например если все сетевые контроллеры включены в bond-интерфейс или задействованы в разных Open vSwitch коммутаторах.
В таком случае, нужно создать постоянный виртуальный интерфейс\порт в коммутаторе и назначить ему статический IP-адрес и использовать для управления хостом.Создадим новый порт mgmt0:

# ovs-vsctl add-port ovs-sw0 mgmt0

Укажем что это внутренний интерфейс. Внутренний интерфейсы OVS могут быть сконфигурированы как физические:

# ovs-vsctl set inter­face mgmt0 type=internal

Помещаем при необходимости в нужный VLAN:

# ovs-vsctl set port mgmt0 tag=100

Далее, способом принятым в вашем дистрибутиве устанавливаем для mgmt0 статический IP-адрес и прочие сетевые реквизиты и используем как обычный физический интерфейс.

9. ЗЕРКАЛИРОВАНИЕ ПОРТОВ

Open vSwitch позволяет, направлять копию потока трафика из одного или нескольких интерфейсов в другой. Так же, возможно перенаправление трафика из всего VLAN’a в конкретный порт или на оборот. Может зеркалироваться только входящий, исходящий или оба типа. Понадобиться это может, например, для прослушки трафика в целях информационной безопасности или диагностики.

Выполним зеркалирование трафика из интерфейса vnet2 принадлежащего одной из ВМ в специально созданный для прослушивания порт mirror0 с типом inter­nal.
Команда, реализующая эту функцию в отличии предыдущих, просто ломает мозг

# ovs-vsctl -- set Bridge ovs-sw0 mirrors=@m -- --id=@mirror0 get Port mirror0 -- --id=@vnet2 get Port vnet2 -- --id=@m cre­ate Mir­ror name=mymirror select-dst-port=@vnet2 select-src-port=@vnet2 output-port=@mirror0

В данной команде, как нетрудно заметить, во всю производится работа с БД, а также используются своего рода внутренние переменные — –id=@<имя_переменной>
set Bridge ovs-sw0 mirrors=@m — эта часть описывает создание зеркала, имя и параметры которого должна быть получена из переменной @m.
–id=@mirror0 get Port mirror0 — –id=@vnet2 get Port vnet2 — здесь в переменные @mirror0, @vnet2 записываются идентификаторы соответствующих портов.
–id=@m cre­ate Mir­ror name=mymirror select-dst-port=@vnet2 select-src-port=@vnet2 output-port=@mirror0 — а тут собственно в переменную @m записывается идентификатор моста mymir­ror, которая будет подставлена в первой команде в переменную @m.

Конечно, для такого простого действия можно было реализовать человеко-понятные параметры и обойтись без ручных правок БД. Но пока что реальность такова.

Теперь, например с помощью tcp­dump запущенного в хост-системе можно наблюдать весь трафик ВМ:

# tcp­dump -i mirror0

Кстати, подобное зеркалирование трафика наверняка возможно у таких облачных провайдеров как Ama­zon EC2, Rack­space, Dig­i­talo­cean и других. По этому не стоит забывать об использовании защищенных сетевых протоколов!

10. GRE ТУННЕЛИРОВАНИЕ

Туннель GRE (Generic Rout­ing Encap­su­la­tion) — это наиболее простой способ соединить несколько изолированных коммутаторов находящихся на разных узлах. Данное решение позволяет строить распределенную приватную сеть, «размазанную» по множеству физических узлов.
В самом простом виде это можно увидеть на рисунке ниже.

GRE туннелирование работает на канальном уровне и не имеет не каких средств шифрования трафика а так же проблематична работа через NAT.
Итак, у нас есть два физических узла, на каждом из которых будут по два коммутатора. Один из них будет обычным, с физическим интерфейсом, а другой будет изолированным.

Узел 1.

# ovs-vsctl add-br ovs-sw0
# ovs-vsctl add-port ovs-sw0 eth0
# ovs-vsctl add-port ovs-sw0 tun0
# ovs-vsctl set inter­face tun0 type=internal
# ifcon­fig tun0 192.168.1.151 net­mask 255.255.255.0

Здесь, мы создаем коммутатор, подключаем в качестве порта физический интерфейс eth0, создаем постоянный виртуальный интерфейс tun0 и присваиваем ему IP-адресс (должен быть постоянным). Через интерфейс tun0 в дальнейшем будет настроен тунель.

Узел 2.

На втором узле будет отличаться только присваиваемый IP-адрес

# ovs-vsctl add-br ovs-sw0
# ovs-vsctl add-port ovs-sw0 eth0
# ovs-vsctl add-port ovs-sw0 tun0
# ovs-vsctl set inter­face tun0 type=internal
# ifcon­fig tun0 192.168.1.152 net­mask 255.255.255.0

Теперь построим туннель.

Узел 1.

# ovs-vsctl add-port is-br0 gre0 -- set inter­face gre0 type=gre options:remote_ip=192.168.1.152

Узел 2.

# ovs-vsctl add-port is-br0 gre0 -- set inter­face gre0 type=gre options:remote_ip=192.168.1.151

Теперь ВМ включенные в изолированные коммутаторы is-br0, на обоих узлах, смогут взаимодействовать.

11. СОЕДИНЕНИЕ ДВУХ БРИДЖЕЙ ЧЕРЕЗ PATCH PORT

Создание патч порта очень простое, необходимо выполниить следующую группу комманд на обеих концах коммутаторов:

ovs-vsctl add-port ovs-vsctl set interface type=patch
ovs-vsctl set interface options:peer=

CITRIX DISTRIBUTED VSWITCH CONTROLLER. КОНЦЕПЦИЯ SDN

В цикле статей посвященных Open vSwitch (OVS) были рассмотрены основные возможности программного коммутатора, а так же некоторые особенности его настройки и функционирования. Так как данная тематика достаточно обширна, была освещена лишь работа с «отдельно стоящим» коммутатором. Но сегодня когда виртуальные инфраструктуры могут насчитывать десятки и сотни узлов, а соответственно, и коммутаторов, необходим механизм, позволяющий гибко управлять множеством хостов и учитывать динамичность виртуальной среды, избавляющий от ручной настройки каждого узла. Таким средством является протокол Open­Flow, о котором и пойдет речь в данной статье.

Немного про OpenFlow

Проект OpenFlow стартовал в 2008 году в стенах Стэнфордcкого и Калифорнийского (Беркли) университетов в рамках зародившейся немногим ранее (2002 г.) концепции SDN (Software-defined net­works) – программно-конфигурируемых сетей. Основными идеями концепции являются простота, гибкость, унификация и дешевизна конечных решений. Архитектуру SDN можно представить как множество достаточно простых программных и аппаратных коммутаторов, подключенных к единому, мощному, интеллектуальному контроллеру, реализованному в виде обычного сервера со специальным ПО.
В данной схеме, коммутаторы должны уметь лишь быстро переадресовывать трафик и больше ничего. Вся интеллектуальная логика и высокоуровневая маршрутизация ложится на плечи контроллера. За счет переноса интеллекта на центральный узел, коммутаторы разгружаются и могут боле эффективно использовать вычислительные мощности для выполнения низкоуровневых операций с трафиком.
Также, централизованное управление позволяет мониторить состояние всей сети и управлять множеством ее параметров из одной точки. Но самой главной идеей данной архитектуры является возможность программно управлять трафиком в такой сети. Иными словами, контроллер — это не просто ПО, способное отправлять определенный набор команд на подчиненные коммутаторы. Это своего рода фреймворк и API, позволяющие управлять потоками трафика из различных (зависит от контроллера) языков программирования. Это позволяет строить сети любой топологии, непохожие друг на друга и описывать различное поведение коммутаторов для тех или иных случаев.

Причем же тут OpenFlow?

Open­Flow — это стандартизированный, открытый протокол (распространенные версии — 1.1, 1.3), по которому происходит взаимодействие контроллера с подчиненными коммутаторами. Контроллер Open­Flow вносит изменения в таблицы потоков коммутаторов, на основании которых принимается решение о передаче принятого пакета на конкретный порт коммутатора.

К сожалению, концепция SDN развивается не так как предполагалось. Хотя программно реализованных контроллеров достаточно на любой вкус, оборудования с поддержкой Open­Flow не так много, как хотелось бы. Например, продукты, выпускаемые Cisco Sys­tems и Juniper Net­works проприетарны и несовместимы с прочими производителями. Поэтому, наверное, единственная область в которой SDN развиты наиболее хорошо — это виртуализация, и Open vSwitch — хороший тому пример. Он полностью соответствует SDN и использует открытую реализацию OpenFlow.

Как это работает в OVS

Архитектура OVS достаточно проста и прозрачна. Основными компонентами являются; модуль ядра, OVSDB-база данных с конфигурацией (в формате json) и служба, отслеживающая и применяющая все вносимые в БД изменения. В случае с множеством узлов, каждый из коммутаторов является отдельной сущностью, никак не связанной с другими такими же. Для централизованного управления несколькими коммутаторами в OVS реализована поддержка протокола Open­Flow, посредством которого контроллер вносит изменения в таблицы потоков коммутатора, тем самым управляя движением трафика.

Развертывание контроллера

К сожалению, нормально реализованного контроллера, для управления несколькими экземплярами OVS, готового к использованию без какого либо программирования, на сегодняшний день не существует.
Для иллюстрации работы распределенного коммутатора на базе OVS будет использоваться несколько серверов XenServer 6.2 и собственная реализация OpenFlow-контроллера от Cit­rix — Dis­trib­uted Vir­tual Switch Con­troller (DVSC).
Здесь надо сказать что текущие свободные версии Open vSwitch, кроме непосредственно коммутатора включают в себя и реализацию примитивного OpenFlow-контроллера. К сожалению, его возможности крайне ограничены. С его помощью можно управлять группой удаленных OVS, но их функциональность будет как у коммутаторов второго уровня (L2).
К сожалению, использование же сторонних, открытых реализаций контроллера, наиболее известные из которых NOX, Flood­Light и Bea­con, подразумевает программирование различных модулей и классов, описывающих желаемую функциональность.
По большому счету, OVS в составе XenServer и контроллер для него в исполнении Cit­rix — это наиболее полная и функциональная реализация концепции SDN.

Развертывание контроллера состоит из одного простого действия — импорта ВМ(в формате xva) на один из серверов XenServer. Для входа в локальную консоль ВМ используется логин admin и такой же пароль.
После успешного импорта и запуска ВМ необходимо сконфигурировать сетевой интерфейс управления. Чтобы задать статический ip-адрес используется следующая команда:

# set con­troller management-interface con­fig sta­tic <net­mask> [ ]

Параметры, указанные в квадратных скобках, не обязательны.

Теерь когда сетевой интерфейс ВМ сконфигурирован можно заходить браузером в веб-консоль управления DVSC по адресу указанному в команде выше.
Используя те же учетные данные что при входе в локальную консоль, мы попадаем на страницу с общей информацией (Sta­tus). Здесь же, необходимо добавить пул ресурсов.

Пул ресурсов, в терминологии Cit­rix — это кластер серверов XenServer с одним или несколькими общими сетевыми хранилищами. При добавлении пула ресурсов в DVSC, указывается адрес или сетевое имя мастера пула и учетные данные для подключения.
Когда пул добавлен, коммутаторы на каждом из узлов XenServer автоматически переходят под управление контроллера DVSC. Это можно увидеть выполнив на любом из узлов XenServer следующую команду:

# ovs-vsctl show

На текущий момент, DVSC от Cit­rix поддерживает не всю функциональность OVS. Точнее не все реализуется из веб-консоли. Например, создать GRE-туннель между несколькими ВМ на разных узлах возможно только из командной строки. Сейчас, в графическом режиме доступны просмотр сетевой статистики по различным фильтрам, ограничение пропускной способности, а также зеркалирование трафика. Но самое главная возможность, которая, пожалуй, позволяет реализовать любые фантазии — это удобное описание потоков Open­Flow по принципу, очень напоминающему создание правил межсетевого экрана. Впрочем, давайте обо всем по порядку.

Описание потоков OpenFlow

Это пожалуй самая главная и интересная пункт из возможностей DVSC.
На вкладке Access Con­trol можно гибко описывать различные правила фильтрации трафика. Как и в случае с QoS и RSPAN, здесь действует та же система иерархии правил. То есть, существуют глобальные правила (Global Pol­icy) действие которых применимо ко всем виртуальным машинам на любых хостах во всех управляемых ресурсных пулах. Данные правила обычно общего характера. Например, тут по умолчанию описаны правила, разрешающие передачу трафика DNS и DHCP.
Ниже следуют правила налагаемые на конкретный пул ресурсов (Pol­icy for pool). Здесь могут быть учтены особенности пула и заданны особые правила или переопределены глобальные.
Следующий уровень иерархии — это правила для конкретного физического интерфейса (Pol­icy for Net­work). Данные правила применяются ко всем ВМ, работающим через указанный интерфейс. Ну и на самом низком уровне, они могут быть заданны для конкретной ВМ (Pol­icy for VM) или для ее отдельного интерфейса.
Как выглядят составленные правила и параметры, из которых они состоят, можно увидеть на рисунке №2. А в каком виде они хранятся в OVSDB конкретного коммутатора можем посмотреть следующим образом:

# ovs-ofctl dump-flows xenbr0

Утилита ovs-ofctl предназначена для управления OpenFlow-потоками OVS. С помощью нее можно описать любое правило.
Например, запретить ICMP на конкретном коммутаторе:

#ovs-ofctl add-flow xenbr0 idle_timeout=0,icmp,action=drop

здесь idle_timeout=0 означает, что это правило постоянное. Если нужно временное правило, то можно указать количество секунд.
А вот более сложное правило, запрещающее весь трафик из конкретного порта в ip-подсеть:

# ovs-ofctl add-flow xenbr0 "in_port=1 ip idle_timeout=0 nw_dst=192.168.14.0/24 priority=40000 action=drop"

in_port=1, это номер порта источника в коммутаторе. Узнать какие интерфейсы включены в какие порты можно следующей командой:

# ovs-dpctl show xenbr0