Customizing SDN Control. Part 2 (rus)

Добро пожаловать обратно.
Мы продолжаем изучение плоскости управления и, в частности, продолжаем
урок, на котором мы изучали, как
использовать контроллеры SDN для настройки управления сетью.
В предыдущей части этого урока мы рассмотрели, как
используйте контроллер POX для реализации простого переключателя обучения второго уровня.
В этой части урока мы расширим этот переключатель обучения второго уровня.
принимать решения о переадресации на основе простых
правила брандмауэра, которые мы устанавливаем на контроллере.
Цель этого урока двояка.
Во-первых, показать, как легко сделать
фундаментальные изменения в поведении сети с
очень простые изменения в контроллере.
Во-вторых, дать вам больше информации о контроллере POX.
Итак, чтобы повторить то, что мы сделали на прошлом уроке, мы
использовал контроллер POX для установки правил простой таблицы потоков в
коммутатор, совпавший с MAC-адресом назначения, и взял
конкретное действие по пересылке пакета из определенного порта.
Возможна и более сложная коммутация.
Мы можем, например, установить правила потоковой таблицы, которые
совпадают по многим другим конкретным полям в заголовке пакета.
Это позволяет коммутатору принимать конкретные решения о переадресации для разных потоков.
Мы также можем использовать правила потока для реализации брандмауэра.
Например, мы могли бы заставить коммутатор выполнять переадресацию или
решения об отбрасывании на основе значения исходного MAC-адреса.
В этом уроке мы рассмотрим, как вносить простые изменения
к переключателю обучения второго уровня, чтобы реализовать этот пример брандмауэра.
Давайте вернемся к топологии, с которой мы работали на последних уроках.
Снова у нас есть переключатель, который соединяет три
hosts, и мы подключим контроллер к этому коммутатору.
Но вместо подключения контроллера, который выполняет просто второй уровень
коммутируя, мы увеличим функции, выполняемые тем
контроллер, чтобы он проверял исходный MAC-адрес входящих пакетов.
И решает, пересылать или отбрасывать пакет,
на основе значения исходного MAC-адреса.
Если контроллер решает, что пакет следует переслать, то
он продолжает выполнять функции переключения второго уровня, как и раньше.
Давайте вернемся к алгоритму переключения обучения POX из прошлого урока.
Это то же самое, что мы смотрели в прошлый раз.
За исключением того, что мы собираемся добавить дополнительный шаг, где контроллер
проверяет исходный MAC-адрес на соответствие определенным правилам брандмауэра, которые
проверить исходный MAC-адрес на соответствие решениям о пересылке или удалении.
Эта дополнительная функция требует лишь нескольких простых дополнений к контроллеру.
Во-первых, нам нужна хеш-таблица, в которой хранятся пары ключ-значение.
В частности, эта хеш-таблица должна отображать идентификатор коммутатора.
и исходный MAC-адрес пакета в значение true/false
указывает, должен ли пакет быть перенаправлен или отброшен.
Контроллер решит отбросить пакет, если есть запись брандмауэра,
сопоставляется с ложью или если для этого исходного MAC-адреса нет записи брандмауэра.
Контроллер решит перенаправить трафик, если
есть запись брандмауэра, которая соответствует истине.
Давайте быстро взглянем на эти изменения в самом коде POX.
Таким образом, вы можете распознать до первого шага переключения
алгоритм, который сопоставляет MAC-адрес источника пакета с
входящий порт и последующие шаги, которые выполняет коммутатор.
Мы просто добавили правило, которое проверяет, есть ли
запись брандмауэра для этого MAC-адреса источника на этом коммутаторе.
Если запись возвращает false, коммутатор отбрасывает пакет.
В противном случае он продолжается, как и прежде.
Давайте кратко рассмотрим, что нам нужно было сделать, чтобы реализовать правило проверки.
Здесь мы внесли простое изменение, добавив хеш-таблицу.
В хеш-таблице хранятся сопоставления для конкретных исходных MAC-адресов.
Мы можем манипулировать хеш-таблицей с помощью метода добавления правила, который принимает
в качестве входных данных идентификатор коммутатора, исходный MAC-адрес и истинный или ложный
значение, указывающее, следует ли пересылать пакет.
Функция правила проверки просто проверяет,
хеш-таблица имеет запись для этого конкретного идентификатора коммутатора и
исходный MAC-адрес, и если у него есть запись,
он проверяет, является ли запись истинной или ложной.
Функция возвращает значение true только в том случае, если хеш-таблица брандмауэра содержит
запись для этого исходного MAC-адреса, который соответствует истине.
Помимо определения методов управления брандмауэром, я
также добавил пару правил в наш брандмауэр для этого конкретного коммутатора.
Которые эффективно разрешают пакеты от хостов с
MAC-адрес одного или двух для пересылки пакетов через этот коммутатор.
Весь остальной трафик будет отброшен.
Давайте теперь посмотрим на наш новый контроллер в действии.
Сначала я начну топологию Mininet с тремя хостами и
коммутатор, а затем я подключу наш новый контроллер к этому коммутатору.
Теперь мы видим, как контроллер прослушивает брандмауэр.
И вот, брандмауэр подключается.
И контроллер добавляет два правила.
Тот, который позволяет хостам с MAC-адресом один пересылать трафик.
И второй, который позволяет хостам с MAC-адресом два пересылать трафик.
Мы можем видеть, c 

наш, что есть
нет правила, позволяющего узлу 3 пересылать трафик.
Теперь давайте попробуем поэкспериментировать с ping all.
Мы видим, что хост один и хост два могут общаться с одним
другой, но любой трафик с участием третьего хоста блокируется.
Мы также можем видеть из отладки
сообщения, которые контроллер решил переслать или
отбрасывать разные пакеты в зависимости от значения
MAC-адрес источника входящего пакета.
Также интересно отметить, что
когда контроллер решает переслать пакет,
он также устанавливает в коммутаторе правило, позволяющее пересылать этот пакет.
Пока эта запись таблицы потоков остается в коммутаторе, все
пакеты, соответствующие этому потоку, могут продолжать пересылаться на коммутаторе.
Чтобы увидеть эффект, который это поведение имеет
по производительности пусть хост один пингует хост два.
Итак, мы видим, что изначально первый пакет имеет очень большую задержку.
Это потому, что этот пакет перенаправляется на контроллер.
Однако, как только контроллер решит, что хост можно
отправлять трафик на хост два и наоборот, а те
в коммутаторе установлены правила, пакеты пересылаются
непосредственно коммутатором, пока не истечет срок действия этой записи в таблице потоков.
И вы можете видеть, что примерно через 30 секунд запись таблицы потоков
истекает снова, и мы видим относительно более высокую задержку между двумя
конечные хосты, потому что трафик перенаправляется на контроллер.
Здесь мы видим важность кэширования
перенаправление решений, которые контроллер принимает на коммутаторе.
Очень важно ограничить трафик данных, который отправляется на контроллер.
Как мы видим, трафик, который отправляется на контроллер, испытывает
намного более высокая задержка, чем трафик, который может быть перенаправлен непосредственно через коммутатор.
Поэтому, когда контроллер решает перенаправить или
отбросить трафик, таблица потоков коммутатора будет изменена.
Затем эти модификации предотвращают трафик данных.
от перенаправления на контроллер,
до тех пор, пока эта запись таблицы потоков остается в коммутаторе.
Таким образом, мы увидели, что настроить управление с помощью SDN очень просто.
Мы внесли несколько небольших изменений в
переключатель второго уровня для включения возможностей брандмауэра.
Мы рассмотрели, как можно реализовать этот тип альтернативного управления.
И мы превратили коммутатор в брандмауэр менее чем за 40 строк кода Python.
Мы также продемонстрировали преимущества производительности
связанных с кэшированием решений о пересылке на
переключаться, чтобы не отправлять
трафик данных к контроллеру, когда это возможно.