Мультисервисные сети2

Время (4 октета) – время в секундах, по истечении которого маршрути- затор-сосед, не посылающий сообщения Hello, считается отключенным.

Идентификатор выделенного маршрутизатора (4 октета) – с

точки зрения маршрутизатора, посылающего сообщение (0, если выделенный маршрутизатор еще не выбран).

Идентификатор запасного выделенного маршрутизатора (4 ок-

тета) – с точки зрения маршрутизатора, посылающего сообщение (0, если запасной выделенный маршрутизатор еще не выбран).

Список идентификаторов соседей, от которых получены Hello-со-

общения за последние Dead Interval секунд; число полей «Neighbor» определяется из общей длины сообщения, указанной в OSPF-заго- ловке. Длина одного поля – 4 октета.

После того, как пара маршрутизаторов начинает обмениваться Hello-сообщениями с каким-то соседом, этот процесс проходит через несколько стадий:

DOWN – сосед не обнаружен или отключился;

INIT – послано Hello-сообщение или получено от маршрутизатора, еще не зачисленного в список соседей;

2-WAY (двусторонняя связь) – получено Hello-сообщение, в котором данный маршрутизатор-получатель перечислен в списке соседей, а отправитель этого сообщения также зачислен в список соседей данного маршрутизатора;

WAIT – ожидание в течение Dead Interval секунд для обнаружения всех соседей; в это время маршрутизатор передает Hello-сообщения, но не участвует в выборах выделенного маршрутизатора и в синхронизации баз данных;

EXSTART – установление ролей главный/подчиненный и инициализация структур данных для обмена описаниями баз данных (протокол обмена);

EXCHANGE – обмен описаниями баз данных (протокол обмена); LOADING – синхронизация баз данных, пересылка сообщений-

запросов о состояниях связей и ответов на них (протокол обмена); FULL – базы данных синхронизированы.

Каждый маршрутизатор самостоятельно производит выборы выделенного и запасного выделенного маршрутизаторов на основании имеющихся у него данных о соседях и о том, кого каждый из соседей назначил на эту роль. Фактически процесс выборов происходит постоянно, после получения каждого Hello-сообщения, но алгоритм гарантирует, что при стабильном состоянии сети всеми маршрутизаторами будут выбираться одни и те же идентификаторы выделенного маршрутизатора (Designated Router, DR) и идентификаторы запасного выделенного маршрутизатора (Backup Designated Router, BDR).

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

493

поле своих Hello-сообщений. Иначе он может поместить туда адреса других маршрутизаторов, если он считает их занимающими соответствующие роли. Если маршрутизатор не определился с выбором DR и (или) BDR (например, после включения), он заполняет соответствующие поля нулями.

Выбор проводится только среди соседей, с которыми установлена двусторонняя связь и приоритет которых не равен нулю; в этот список маршрутизатор включает и себя, если его приоритет не нулевой.

Итак, после получения очередного Hello-сообщения маршрутизатор приступает к выбору DR и BDR. Он помнит мнения своих соседей по поводу того, кто является DR и BDR, которые он узнал из получаемых Hello-сообщений, а также свой собственный предыдущий выбор.

1.Сначала выбирается BDR, на эту должность назначается маршрутизатор с наивысшим приоритетом из всех, объявивших себя в качестве BDR, при этом маршрутизаторы, объявившие себя в качестве DR, не рассматриваются. Если никто не объявил себя в качестве BDR, выбирается маршрутизатор с высшим приоритетом из тех, кто не объявил себя в качестве DR. В случае равных приоритетов выбирается маршрутизатор с бóльшим идентификатором.

2.На должность DR выбирается маршрутизатор с наивысшим приоритетом из всех, объявивших себя в качестве DR. В случае равных приоритетов выбирается маршрутизатор с бóльшим идентификатором.

3.Если никто не предложил себя в качестве DR, в поле «Designated Router» заносится идентификатор BDR.

4.Если маршрутизатор только что выбрал себя на роль DR или BDR или только что потерял статус DR или BDR, шаги 1–3 повторяются. Термин «только что» означает «в результате выполнения непосредственно предшествующих шагов 1–3, а не предыдущих итераций алгоритма».

После выбора DR и BDR маршрутизатор сообщает их идентификаторы в своих Hello-сообщениях. Если в результате процедуры выбора DR или BDR изменились по сравнению с предыдущим выбором данного маршрутизатора, он устанавливает необходимые отношения смежности, если они еще не были установлены, и разрывает ненужные больше отношения смежности, если таковые имеются.

Когда маршрутизатор подключается к сети, сначала он достигает состояния 2-WAY со всеми своими соседями, а потом, прежде чем приступать к выборам, ожидает время WAIT. В течение этого времени он передает Hello-сообщения с обнуленными полями DR и BDR. После истечения периода WAIT вновь подключившийся маршрутизатор может предлагать себя на роль BDR, производить выборы и формировать отношения смежности.

Протокол обмена. После установления отношений смежности для каждой пары смежных маршрутизаторов происходит синхронизация их баз данных. Эта же операция происходит при восстановлении ранее разорванного соединения, поскольку в образовавшихся после аварии двух изолированных подсистемах базы данных развивались независимо друг от друга. Синхронизация баз данных происходит с помощью протокола обмена (Exchange protocol). Сначала маршрутизаторы обмениваются только описаниями своих баз данных (Database Description), содержащими идентификаторы записей и номера их версий, это позволяет избежать пересылки всего содержимого базы данных, если требуется синхронизировать только несколько записей. Во время этого обмена каждый маршрутизатор формирует список записей, содержимое которых он должен запросить (то есть эти записи в его базе данных устарели либо отсутствуют), и соответственно отправляет пакеты запросов о состоянии связей. В ответ он получает содержимое последних версий нужных ему записей в пакетах типа

«Обновление состояния связей (Link State Update)». После синхрони-

зации баз данных производится построение маршрутов, как описано в предыдущем разделе.

Протокол лавинной маршрутизации. Каждый маршрутизатор от-

вечает за те и только те записи в базе данных состояния связей, которые описывают связи, исходящие от данного маршрутизатора. Это значит, что при образовании новой связи, изменении в состоянии связи или ее исчезновении (обрыве), маршрутизатор, ответственный за эту связь, должен соответственно изменить свою копию базы данных и немедленно известить все остальные маршрутизаторы OSPFсистемы о произошедших изменениях, чтобы они также внесли исправления в свои копии базы данных. Подпротокол OSPF, выпол-

няющий эту задачу, называется протоколом лавинной маршрутиза-

ции (Flooding protocol). При работе этого протокола пересылаются сообщения типа «Обновление состояния связей (Link State Update)»,

получение которых подтверждается сообщениями типа «Link State Acknowledgment». Каждая запись о состоянии связей имеет свой номер (номер версии), который также хранится в базе данных. Каждая новая версия записи имеет больший номер. При рассылке сообщений об обновлении записи в базе данных номер записи также включается в сообщение для предотвращения попадания в базу данных устаревших версий. Маршрутизатор, ответственный за запись об изменившейся связи, рассылает сообщение «Обновление состояния связи» по всем интерфейсам. Однако новые версии состояния одной и той же связи должны появляться не чаще, чем оговорено определенной константой.

Далее на всех маршрутизаторах OSPF-системы действует следующий алгоритм.

495

1.Получить сообщение. Найти соответствующую запись в базе данных.

2.Если запись не найдена, добавить ее в базу данных, передать сообщение по всем интерфейсам.

3.Если номер записи в базе данных меньше номера пришедшего сообщения, заменить запись в базе данных, передать сообщение по всем интерфейсам.

4.Если номер записи в базе данных больше номера пришедшего сообщения и эта запись не была недавно разослана, разослать содержимое записи из базы данных через тот интерфейс, откуда пришло сообщение. Понятие «недавно» определяется значением константы.

5.В случае равных номеров сообщение игнорировать.

Протокол OSPF устанавливает также такую характеристику записи в базе данных, как возраст. Возраст равен нулю при создании записи. При «заливке» OSPF-системы сообщениями с данной записью каждый маршрутизатор, который ретранслирует сообщение, увеличивает возраст записи на определенную величину. Кроме этого, возраст увеличивается на единицу каждую секунду. Из-за разницы во времени пересылки, в количестве промежуточных маршрутизаторов и по другим причинам возраст одной и той же записи в базах данных на разных маршрутизаторах может несколько различаться (это нормальное явление). При достижении возрастом максимального значения (60 минут), соответствующая запись расценивается маршрутизатором как просроченная и непригодная для вычисления маршрутов. Такая запись должна быть удалена из базы данных.

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

Чтобы записи в базе данных не устаревали, маршрутизаторы, ответственные за них, должны через каждые 30 минут обеспечивать систему сообщениями об обновлении записей, даже если состояние связей не изменилось. Содержимое записей в этих сообщениях неизменно, но номер версии больше, а возраст равен нулю.

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

В протоколе OSPF может быть применена аутентификация сообщений, например, защита их с помощью пароля.

Приложение 2. Программно-конфигурируемые сети

П2.1. Общие положения

С каждым годом, начиная с 2006 г., появляется все больше и больше работ, посвященных программно-конфигурированным сетям (ПКС) или SDN (Soft Difined Networks), предлагаются программные продукты, техника, позволяющие реализовать эти сети. В этом разделе мы попытаемся, используя известные публикации [1–14], рассказать, что такое ПКС, почему вдруг появилась необходимость в новой технологии построения компьютерных сетей, каковы перспективы внедрения этой технологии в мире, место России в продвижении этой технологии.

Что не так в современных IР-сетях? Появление интернета было революционным событием, изменившим нашу экономическую, технологическую и социальную жизнь. Не смотря на то, что его общая архитектура, несомненно, является успешной, современный интернет достаточно дорогой и сложный в управлении, слишком завязанный на вендеров и не гибкий для развития. В такой сети при появлении оборудования нового поставщика (вендора) оператору необходимо модернизировать всю систему управления сетью.

Основные сетевые протоколы ТСР/IР были разработаны в 70-е годы прошлого века на заре Интернета. С тех пор по мере необходимости предоставления все новых и новых услуг к этим протоколам добавлялись все новые и новые протоколы. Сегодня количество протоколов превышает 600 и продолжает расти. Сеть становится все сложнее и соответственно усложняется управление этой сетью.

Всети традиционной архитектуры технологии виртуализации вычислительного окружения и хранилищ данных прочно закрепились в Дата-Центрах, отлажены и хорошо работают. Но в сетевом окружении, как раньше, так и сейчас существуют разные трудности [1]:

статическое или ручное выделение и перераспределение сетевых ресурсов;

отдельная настройка каждого сетевого устройства при большом их количестве;

сложность и ресурсоемкость при внедрении и изменении сетевых политик, конфигураций, новых сервисов;

многовендорность и проприетарность некоторых функций.

Вклассической IР-сети маршрутизатор содержит две плоскости – плоскость управления (control plane) и плоскость данных (data plane). Плоскость управления в маршрутизаторе обрабатывает пакет и принимает решение, куда его передавать дальше (операция routing). В плоскости передачи данных решается проблема продвижения па-

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

Многие крупные вендоры, в том числе IBM, видят решение вышеописанных задач в использовании программно-конфигурируемых сетей, которые полностью изменят экономику и опыт внедрения IT сис-

тем [1].

Что предлагает технология ПКС:

Отделить в маршрутизаторе управление сетевым оборудованием от управления передачей данных. Управление вынести на отдельный компьютер, который будет находиться под контролем администратора сети.

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

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

Еще раз напомним, что в классической сети задача построения маршрута (control plane) и реализация маршрута (data plane) объединены в сетевом устройстве. В SDN предусматривается передача управляющих функций так называемому контроллеру, что приводит к замене традиционной распределенной модели маршрутизации централизованной моделью. Таким образом, процесс управления сетью, включающий создание маршрутов, становится программированием сети в целом.

На рис. П2.1 представлена классическая сетевая архитектура, состоящая из маршрутизаторов, каждый из которых имеет в своем составе уровень управления (App и OS) и уровень данных (Forwarding).

На рис. П2.2 представлена ПКС (SDN), в которой управление централизовано. Здесь связь контроллера (Controller) с переключателем Switch осуществляется при помощи протокола OpenFlow. Приложения (Application, App) и контроллер общаются через графический интер-

фейс пользователя (Graphical User Interface, GUI).

На рис. П2.2 можно выделить три уровня: уровень приложений (Арр), уровень управления (Controller) и уровень инфраструктуры сети (Switch). Для управления инфраструктурой сети необходим сбор данных о состоянии сети. Объем этих данных чрезвычайно велик и их можно отнести к категории Big Data (большие данные).

Рис. П2.1. Классическая сетевая архитектура

Обработка этих данных является сложной задачей, относящейся к категории NP-Complit: необходимо оценить степень удовлетворенности услугами пользователей; измерить сетевые параметры, характеризующие QoS; определить топологию и междоменное взаимодействие; составить прогноз изменений в топологии и сетевых характеристик и т.д.

Рис. П2.2. Программно-конфигурируемая сеть

В этой связи в [2] предлагается в SDN добавить четвертый уровень или четвертую информационную плоскость (рис. П2.3).

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

Отметим, что разделение уровня управления и уровня передачи данных – это общая идея (кстати, далеко не новая – вспомним

Softswitch), имеющая множество способов реализации. Так можно использовать для управления один контроллер, а можно несколько. У каждого из этих вариантов есть свои плюсы и минусы. Можно полностью убрать функции управления из маршрутизации, оставив только функцию продвижения, а можно часть функций управления оставить за маршрутизатором. Понятно, что централизация управления (использование на всю сеть одного контроллера) скажется на структурной надежности сети. Децентрализованная система управления сложна с точки зрения реализации, но более живучая при отказах. Использование «тупых» и, следовательно, дешевых маршрутизаторов на сети может привести к полному параличу сети при выходе из строя контроллера.

Рис. П2.3. Четырех уровневая архитектура SDN

Технический директор Cisco в России и СНГ Андрей Кузьмич, говоря о характерных особенностях SDN, отмечает, что сила SDN не просто в вынесении таблицы коммутации/маршрутизации в некий контроллер, а в развитии дополнительных сервисов как отдельных программных продуктов, которые будут влиять на построение и изменение таблиц коммутации/маршрутизации. Например, исходя из важности конкретного приложения, контроллер сможет менять таблицу коммутации для его приоритетного обслуживания [3].

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

колами. Строить отдельную сеть было дорого, поэтому решили задействовать имеющуюся университетскую сеть, в которой с помощью прообраза SDN были выделены ресурсы для испытаний. Интерес к SDN со стороны неуниверситетских кругов первыми проявили крупные поставщики интернетсервисов, которым требовались высокопроизводительные инфраструктуры для организации взаимодействия между десятками и даже сотнями серверов в гигантских ЦОД.

П2.2. Протокол OpenFlow и OpenFlow коммутатор

Наиболее перспективным и активно развивающимся стандартом для SDN является OpenFlow – открытый стандарт, в котором описываются требования, предъявляемые к коммутатору, поддерживающему протокол OpenFlow для удаленного управления.

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

Как и следует из названия, протокол OpenFlow при идентификации трафика оперирует понятием «потока», то есть управление данными в OpenFlow осуществляется не на уровне отдельных пакетов, а на уровне их потоков. Правила в коммутаторе OpenFlow устанавливается с участием контроллера только для первого пакета, а затем все остальные пакеты потока его используют.

Ключевым элементом коммутатора, поддерживающего этот протокол, является таблица потоков (flow tables). Протокол используется для управления (программирования) таблиц потоков (flow tables) сетевых коммутаторов и маршрутизаторов с центрального устройства – контроллера сети (сервера или даже персонального компьютера). Коммутаторы с поддержкой OpenFlow могут быть двух типов: OpenFlow-only (работающий только под управлением OpenFlow) или OpenFlow-hybrid (гибридные, совмещающие OpenFlow и обычную обработку пакетов средствами микропрограммы устройства).

Протокол OpenFlow – открытый стандарт, поэтому использовать его в своих устройствах может любой производитель телекоммуникационного оборудования. Уже сейчас этот протокол поддерживают многие производители Ethernet-коммутаторов. Первыми это стали де-

лать NEC и BigSwitch, чуть позже – Pronto и Marvell. Затем к ним при-

соединились IBM, Brocade и HP, и только после этого о поддержке OpenFlow заявили лидеры рынка IP-коммутаторов – Cisco, Juniper и Extreme Networks [4].

В настоящий момент протокол имеет версию 2.5 (19 декабря 2014 г.).