Сетевые технологии (16). Программно-конфигурируемые (Software-Defined) коммутаторы

SDN-контроллер

Протоколы TRILL и SPB, рассмотренные в предыдущих публикациях, представляют собой ОДИН ИЗ путей решения проблемы масштабирования сетей с топологией Spanning Tree.

Другой путь – использование технологии программно-конфигурируемых сетей SDN (Software-Defined Networking). Это подход получил гораздо большее распространение, чем TRILL и SPB.

Основная идея SDN состоит в замене механизма «форвардинга» пакетов в каждом коммутаторе, на управление от централизованного контроллера, который программируется пользователем относительно того, как выдавать инструкции на передачу («форвардинг») пакетов в каждом коммутаторе. Как и в TRILL/SPB, такой подход позволяет сосуществовать как основному маршруту форвардинга, так и резервному. Контроллер может быть как отдельным узлом, так и распределённым набором узлов.

При запуске, и затем периодически при работе, контроллер опрашивает коммутаторы сети, чтобы определить их состояние, а также внутренние параметры. Затем, на основе этой информации, контроллер строит соответствующее дерево Spanning Tree. После этого, коммутаторы будут передавать пакеты только по линкам, определённым в конфигурации сети от контроллера. Звенья, которые не являются частью созданного дерева Spanning Tree также можно использовать для передачи пакетов по известным направлениям, как и в традиционных коммутаторах, с алгоритмом Spanning Tree. Если на коммутатор приходит пакет с неизвестным адресом назначения, то коммутатор сообщает об этом контроллеру, который затем решает, что делать дальше.

Коммутаторы часто конфигурируются так, чтобы сообщать новые адреса источников контроллеру, поэтому контроллер может сообщить всем другим коммутаторам наилучший маршрут трафика от этого нового источника.

SDN-контроллер может быть сконфигурирован как обычный файрволл, не разрешающий передачу между определёнными парами узлов по соображениям безопасности. Например, если в дата центре есть клиент А и клиент В, и у каждого несколько подключённых к дата-центру узлов, то сеть можно программно сконфигурировать так, что ни один пакет с узла клиента А не попадёт через дата-центр ни на один узел клиента В, и наоборот.

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

Реализация OpenFlow

Основа технологии SDN – это способность контроллера сообщать коммутаторам информацию о том, как форвардить пакеты.

Рассмотрим архитектуру коммутатора с протоколом OpenFlow, который является стандартом SDN, созданным организацией ONF (Open Networking Foundation), основанной разработчиками технологии SDN.

Форвардинг в OpenFlow делается по одной или нескольким таблицам потока (flow table). Во flow-table содержатся т.н. «поля соответствия» (match field), а также набор инструкций, выдаваемых по получению тех или иных пакетов, и действий в случае установки соответствия в match field.

Обычно это такие действия:

  • Сброс пакета
  • Форвардинг пакета на один определённый интерфейс
  • Рассылка (flooding) пакета на набор интерфейсов
  • Форвардинг пакета на контроллер
  • Обработка пакета на другой (с более высоким номером) таблице Flow Table.

Соответствие (Matching) может быть найдено, например, когда IP-адрес источника в пакете соответствует значению IP-адреса назначения в таблице. В этом случае, форвардинг может быть сделан полностью или частично по IP-адресу, а не по Ethernet-адресу. Таким образом, коммутатор OpenFlow может действовать как коммутатор уровня L3, то есть, почти как IP-маршрутизатор.

Таблицы Flow Table немного похожи на таблицы передачи пакетов в коммутаторе (forwarding tables), в которых тоже прописаны соответствия между адресами источника и назначения, и то, какие действия нужно предпринимать в случае установления соответствия при передаче пакета на следующей маршрутизатор.

Обычно, коммутаторы OpenFlow обрабатывают пакеты рассылки, делая их форвардинг на определённые выходные интерфейсы (flooding). При помощи контроллера SDN, можно установить на определённые выходные интерфейсы атрибут NO_FLOOD, что означает, что те пакеты для рассылки (flooding или broadcast, или что ещё) не будут восприниматься этими интерфейсами. Примерно так организуются сети Spanning Tree.

При рассылке типа broadcast (на все интерфейсы, кроме входного), в отличие от flooding (на некоторые интерфейсы), обращение к таблице Flow Table не требуется.

При назначении соответствий (Match field) может назначаться также величина приоритета. В случае соответствия пакета двум и более полям Flow Table, выбирается поле с наивысшим приоритетом.

Команды OpenFlow для Flow Table также могут включать модификацию (“mangling”) пакетов.

Кроме того, во Flow Table могут быть счётчики, флаги, а также значение времени последнего использования поля (last_used). 

Также коммутатор OpenFlow может вводить ограничения на качество услуг Quality-of-Service, например, ограничение полосы пропускания (bandwidth).

Логический коммутатор OpenFlow

Логический коммутатор OpenFlow (OpenFlow Logical Switch, т.е., встроенное в коммутатор программное обеспечение, после чего он становится коммутатором OpenFlow) состоит из таблиц потоков (Flow Table) и таблиц группировки (Group Table), которые производят просмотр соответствий и форвардинг на основе этих соответствий.

Коммутатор обменивается сообщениями с SDN-контроллером, который управляет коммутатором через протокол OpenFlow. При помощи протокола OpenFlow, контроллер может добавлять, модифицировать, и удалять записи в таблицах потока и группировки, как в реактивном режиме (в ответ на пришедшие пакеты), так и проактивно.

Каждая таблица в коммутаторе содержит набор записей по управлению потоками (Flow), каждая из которых состоит из полей соответствия (match fields), счётчиков, а также набор инструкций для того, как поступать с пакетами, у которых есть соответствия. Просмотр соответствий начинается с первой таблицы потока в магистрали потока (Pipeline), и затем продолжается на последующих. Найденные соответствия имеют приоритет в зависимости от положения таблицы в магистрали. Используется первое найденное соответствие. При этом выполняются команды, ассоциированные с данной записью в таблице потока. Если соответствий не найдено, то выполняются команды записи таблицы для отсутствия потока (miss flow). При этом, пакет может быть направлен на контроллер канала OpenFlow, сброшен, или направлен в следующую таблицу потока.

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

Команды обработки в магистрали потока (Pipeline) дают возможность посылать пакеты на следующую таблицу в магистрали, и позволяет обмен информации в форме метаданных между таблицами магистрали.

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

Записи в таблице потока могут сами делать форвардинг пакет на физический порт коммутатора. Однако, это может быть и логический порт, определённый в коммутаторе, а также резервный порт, определённый в SDN.

Резервные порты могут предписывать основные действия форвардинга, такие, как посылка на контроллер, рассылка по набору выходных портов (flooding), а также форвардинг без использования методов OpenFlow, т.е. методами обработки в обычном коммутаторе.

Логические порты, сконфигурированные в коммутаторе, могут определять группы агрегации линков, туннели или интерфейсы петель (loopback interfaces).

(О типах портов OpenFlow — следующая публикация)

Действия, ассоциированные с записями в таблицах flow table, могут также направлять пакеты в группы, которые сконфигурированы для дополнительной обработки. Группа представляет собой набор действий по рассылке flooding, а также более сложную семантику, например, многомаршрутность (multipath), быструю перемаршрутизацию (fast reroute), а также агрегацию линков.

Представляя собой общий уровень абстрагирования, таблицы групп могут использовать много записей в таблицах Flow Table для форвардинга одиночного идентификатора (например, форвардинга IP-адреса на общий интерфейс next hop).

Таблицы группировки Group Table содержат записи групп (group entries), каждая запись групповой таблицы содержит список наборов действий (action bucket) с определённой семантикой, зависящей от типа группы. Действия в одном или нескольких наборов action bucket применяются к пакетам, посылаемым в группу.

Продолжение — здесь.

Об авторе Алексей Шалагинов

Независимый эксперт
Запись опубликована в рубрике Ликбез, Сетевые технологии с метками , , , . Добавьте в закладки постоянную ссылку.

1 отзыв на “Сетевые технологии (16). Программно-конфигурируемые (Software-Defined) коммутаторы

  1. Уведомление: Сетевые технологии (16-1). Программно-конфигурируемые (Software-Defined) коммутаторы — Порты OpenFlow | Telecom & IT

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.