The Control Plane (rus)

by Sasha Shkrebets last modified Mar 06, 2023 01:01 PM
Сейчас мы начинаем новый модуль, в котором мы будем исследовать гайки и болты плоскости управления сетью. Этот модуль состоит из трех уроков. Первый будет посвящен основам управления самолетом. Мы поговорим о деталях OpenFlow версии 1.0 а также последние изменения в протоколе OpenFlow. Затем мы поговорим о примерах различных SDN-контроллеров. И, наконец, мы рассмотрим, как используйте контроллеры SDN для настройки управления сетью.

Сейчас мы начинаем новый модуль, в котором мы будем
исследовать гайки и болты плоскости управления сетью.
Этот модуль состоит из трех уроков.
Первый будет посвящен основам управления самолетом.
Мы поговорим о деталях OpenFlow версии 1.0
а также последние изменения в протоколе OpenFlow.
Затем мы поговорим о примерах различных SDN-контроллеров.
И, наконец, мы рассмотрим, как
используйте контроллеры SDN для настройки управления сетью.
Будет задание по программированию и викторина на основе
задание, а также викторина по понятиям в этом модуле.
Давайте теперь перейдем к изучению некоторых основ плоскости управления.
Начнем с основ спецификации протокола OpenFlow.
Короче говоря, OpenFlow разделяет данные и
плоскости управления следующим образом, как мы обсуждали.
Контроллер общается с коммутатором OpenFlow по защищенному
канал и протокол эффективно инструктируют OpenFlow
переключиться на обновление записей в таблице потоков, чтобы они принимали разные
действия над различными потоками трафика, которые проходят через коммутатор.
Назначение канала управления
эффективно обновлять эту таблицу потоков и все
логики относительно того, как таблица потоков
записи обновляются, содержатся в контроллере.
Все смарты сети
резидент на контроллере и работа переключателей
просто сводится к пересылке трафика на основе
записи таблицы потоков, которые устанавливает контроллер.
Спецификация протокола OpenFlow определяет число
вещей, включая комплектующие переключателя,
формат сообщения и какие типы действий
таблица потоков должна быть способна работать.
Давайте подробнее рассмотрим
некоторые аспекты спецификации протокола OpenFlow.
Спецификация протокола определяет два компонента коммутатора.
Первая — это таблица потоков, таблица потоков выполняет поиск пакетов.
Функция поиска сравнивает поля в каждом пакете с
таблица потоков, которая находится в коммутаторе и ищет совпадения.
Другими словами, он проверяет, соответствуют ли заголовки пакетов, которые
проходящие через коммутатор, соответствуют любой записи в таблице потоков коммутатора.
Действия, предпринимаемые коммутатором, зависят от того, как пакеты
проходящие через этот переключатель, соответствуют любой из этих конкретных записей таблицы потоков.
Если совпадения нет, трафик отправляется на контроллер.
Другим аспектом коммутатора SDN является безопасный канал, который
как коммутатор взаимодействует с внешним контроллером.
Давайте кратко рассмотрим, как работает OpenFlow.
сопоставление с использованием записей таблицы потоков в конкретном коммутаторе.
Эта конкретная блок-схема, взятая из OpenFlow версии 1.0
Спецификация указывает, как коммутатор должен обрабатывать пакет по мере его поступления.
Когда пакет поступает на коммутатор, он анализирует поля заголовка и
на основе значений этих полей заголовка он попытается сопоставить это
package против записей таблицы потоков в любой из нескольких таблиц потоков.
Если нет совпадения ни в одном из
эти таблицы, трафик отправляется на контроллер.
В противном случае действия выполняются на основе действий
которые указаны в соответствующих записях таблицы потоков.
Таким образом, поля заголовка пакета сопоставляются с одним из N
таблицы, и если нет совпадения, пакет отправляется на контроллер.
Из соображений масштабируемости имеет смысл попытаться сопоставить как можно больше пакетов в
переключателя, чтобы избежать перенаправления слишком большого количества трафика на контроллер.
Смотрим матч поближе
поля, которые являются частью спецификации OpenFlow 1.0.
Спецификация определяет 12-кортеж.
Другими словами, 12 разных полей в пакете
заголовок, по которому может совпадать запись таблицы потоков.
В дополнение к десяти, которые показаны
на этом рисунке есть еще две лишние.
Другие поля, с которыми может сопоставляться коммутатор, включают входящие
коммутатор, MAC-адрес источника и получателя,
тип Ethernet, идентификатор VLAN, исходный и целевой IP-адреса
адрес, тип протокола, например, является ли
пакет является пакетом TCP или UDP, и если это пакет TCP, источник и
порт назначения.
Как только коммутатор идентифицирует соответствующую запись таблицы потоков, он выполнит
действие, указанное в этой записи таблицы потоков.
Два обязательных действия в протоколе OpenFlow
Спецификация пересылает пакет и отбрасывает его.
Теперь переадресация может включать в себя несколько возможностей.
Во-первых, это пересылка пакета из всех
интерфейсы, не включая интерфейс, на который прибыл пакет.
Другой способ — просто инкапсулировать пакет и отправить его контроллеру.
Другой вариант — направить пакет в локальный сетевой стек коммутатора.
Другой способ — просто выполнять действия в таблице потоков.
Наконец, коммутатор может отправить пакет обратно через входной порт.
Спецификация OpenFlow 1.0 также определяет некоторые необязательные
такие действия, как пересылка пакета, как обычно
бы и пересылка пакета в соответствии с связующим деревом.

Другим обязательным действием является действие сброса, при котором запись потока без
указанное действие указывает, что все соответствующие пакеты
для этой записи таблицы потоков следует удалить.
Кроме того, есть несколько необязательных
действия, описанные в спецификации OpenFlow 1.0.
Одним из них является действие модификации, при котором коммутатор может изменять различные пакеты.
значения заголовка, такие как идентификатор VLAN или IP-адрес назначения.
Изменение IP-адреса назначения может быть полезно, например, для выполнения
операции более высокого уровня, такие как балансировка нагрузки глобальной сети.
Другим необязательным действием является отправка пакета через
очередь, которая прикреплена, чтобы сказать выходной порт.
Одним из возможных вариантов использования этого действия может быть
для применения качества обслуживания или формирования трафика.
Коммутатор OpenFlow по умолчанию прослушивает элемент управления.
порта и даже при отсутствии контроллера мы можем
поговорите с коммутатором, используя программу под названием dpctl.
Программы dpctl позволяют нам выполнять такие операции, как проверка потока
записи таблицы на коммутаторе, изменение записей таблицы потоков и так далее.
Давайте быстро взглянем на dpctl в действии, используя показанную здесь топологию.
Мы можем указать мининету начать единую сеть с
три хоста, все подключены к одному коммутатору, где
один переключатель управляется пультом дистанционного управления, как
можно увидеть здесь с опцией удаленного контроллера.
Теперь мы можем использовать dpctl для подключения к контроллеру.
Например, мы можем использовать команду show
чтобы сообщить нам больше информации о коммутаторе.
Теперь вы заметите, если мы попытаемся пропинговать между
два хоста в этой топологии, что нет возможности подключения.
Причиной этого является доказательство, если мы
посмотрите на записи таблицы потоков в контроллере.
Давайте быстро рассмотрим это с помощью команды dump-flows.
Как мы видим, у коммутатора нет записей в таблице потоков, и поэтому он
не знает, что делать с пинг-пакетом, пришедшим с первого хоста.
Попробуем исправить это, добавив несколько записей в таблицу потоков.
Мы снова можем использовать dpctl для добавления записи в таблицу потоков, которая говорит, что если пакет
поступает на входной порт один, отправьте его на второй порт.
Нам нужно аналогичное правило таблицы потоков для обратного направления, которое
говорит, что если пакеты приходят на входной порт два, отправьте их на порт один.
Мы можем снова сбросить потоки, и теперь мы видим
две записи таблицы потоков, которые мы только что установили с помощью dpctl.
Теперь мы можем вернуться в мининет, и мы видим
этот хост один теперь может пинговать хост два.
Более свежие спецификации протокола OpenFlow
такие как версия 1.3, определяют различные улучшения.
Одним из них является понятие набора действий, посредством которого
коммутатор может выполнять несколько действий над каждым пакетом.
Другое понятие — это группа, которая по существу представляет собой список наборов действий.
Группа эффективно позволяет переключателю ссылаться на общий
набор действий, которые могут быть выполнены с несколькими наборами совпадающих потоков.
В конвейере OpenFlow 1.3 каждая таблица в конвейере
может обновлять поля заголовка пакета и потенциально добавлять
совокупность действий, которые будут выполняться на
пакет перед его отправкой на выходной порт.
Существуют различные варианты указания действий в группе действий.
Один из вариантов — выполнить все наборы действий в определенной группе.
Эта опция полезна для реализации многоадресной рассылки, при которой один пакет
могут быть клонированы для каждого набора действий в группе.
Другим примером группового варианта является то, что называется непрямым.
группа, при которой выполняется одно действие, установленное в группе.
Это может быть полезно для выполнения
один и тот же набор операций над несколькими записями потока.
Например, если у коммутатора было несколько записей таблицы потоков
все из которых должны были быть отправлены на следующую вершину
IP-адрес, непрямые группы позволят коммутатору указать
все эти записи таблицы потоков в одну и ту же непрямую группу.
Различные примеры действий включают уменьшение TTL,
копирование TTL в различные части заголовка, применение MPLS
теги к пакету и применение действий по обеспечению качества обслуживания.
Есть много более подробной информации о спецификациях OpenFlow в OpenFlow.
Белые книги спецификации, которые доступны
на веб-странице Open Network Foundation.
Стоит отметить, что существуют и другие архитектуры управления SDN.
Мы уже рассмотрели несколько в курсе, что касается истории.
Например, RCP является одним из примеров
Архитектура управления SDN, которая очень специфична для протокола пограничного шлюза.
В последнее время различные поставщики разрабатывают собственные архитектуры управления.
Контроллер Contrail от Juniper использует XMPP в качестве плоскости управления и имеет механизмы
для создания экземпляров виртуальных сетей как на втором, так и на третьем уровне.
Большая часть ПО для Contrail Controller от Juniper будет
внес свой вклад в сообщество OpenDaylight, посвященное
поддержка реализации с открытым исходным кодом различных архитектур управления SDN.
Другой архитектурой управления SDN является архитектура Cisco.
Открытая сетевая среда, в которой указан централизованный
программный контроллер, программируемая плоскость данных,
и возможность предоставления виртуальных оверлеев.
Таким образом, в этой лекции мы рассмотрели 

различные основы плоскости управления.
Мы изучили различные компоненты OpenFlow.
коммутатор, включая защищенный канал, таблицы потоков, а также
а также более новые групповые таблицы, находящиеся под
разработка как часть более современных спецификаций протокола OpenFlow.
Стоит отметить, что протокол OpenFlow развивается.
И в этом курсе, когда мы получаем
руки испачканы конкретными коммутаторами OpenFlow, и в частности
Откройте vSwitch, эта конкретная реализация коммутатора не реализована
многие из опций, указанных в более поздних спецификациях протокола.
Большая часть того, с чем мы будем иметь дело в
этот курс относится к спецификации OpenFlow версии 1.0.
Мы кратко рассмотрели dpctl, который напрямую подключается к
переключатель и может использоваться для опроса и управления записями таблицы потоков.
На следующем уроке мы рассмотрим различные контроллеры SDN.
который можно использовать для более сложной логики управления сетью.

Navigation