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

TRILL и FabricPath

TRILL (Transparent Interconnection of Lots of Links) — технология, работающая на канальном уровне модели OSI и обеспечивающая передачу пакетов внутри ЦОД по уникальным идентификаторам. Под словом «пакет» на канальном уровне мы, конечно же, подразумеваем кадр.

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

Для того чтобы коммутаторы TRILL знали, как добраться до того или иного коммутатора в сети TRILL, они используют протокол динамической маршрутизации. Но вместо привычных нам префиксов (адресов подсетей), обмен осуществляется собственными уникальными идентификаторами. Это позволяет получить дерево кратчайших путей к каждому из коммутаторов TRILL.
Что же нам даёт такая замысловатая обработка пакетов в сети? Так как теперь наш пакет коммутируется внутри сети TRILL по новым правилам (используется маршрутизация на канальном уровне), мы получаем плюсы L3, но на канальном уровне:

• отсутствие каких-либо L2-петель, а значит протоколы STP нам уже не нужны, все каналы активные;
• равномерную утилизацию каналов для одинаковых маршрутов;
• снижение нагрузки на MAC-таблицы части коммутаторов, так как внутри сети мы используем идентификаторы коммутаторов TRILL, а не MAC адреса (только для тех устройств, за которыми нет хостов, в нашем случае для коммутаторов B, С и D).

А так как рекомендованной для работы сети TRILL является архитектура Сlos, мы получаем все её плюсы (о чём мы говорили в предыдущей статье).

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

Различные производители сетевого оборудования имеют свои реализации TRILL. В частности, компания Cisco реализовала концепцию TRILL в своей технологии FabricPath. Стоит отметить, что хоть FabricPath и является реализацией стандарта TRILL IETF, в их работе есть определённые отличия. О некоторых из них я приведу информацию ниже.

Как я отметил ранее, TRILL и FabricPath в своей работе для построения кратчайших маршрутов используют протокол динамической маршрутизации. Для этой задачи был выбран протокол IS-IS. Данный протокол, разработанный в далёких 80-х, можно сказать, обрёл вторую жизнь. Почему IS-IS? Он работает поверх канального уровня.

Поддерживает передачу любых данных внутри своих сообщений. Другими словами, в рамках пакетов IS-IS мы можем передавать, например, какие-то имена, метки или любую другую информацию. Т.е. IS-IS очень просто адаптируется для обеспечения работы других сетевых протоколов. Расчёт кратчайшего маршрута происходит по алгоритму Дейкстры (так же как в протоколе OSPF).

Предлагаю чуточку подробнее остановится на вопросе заполнения MAC-таблицы, где содержатся соответствия MAC-адресов хостов и идентификаторов устройств TRILL/FabricPath.

Для технологии FabricPath этот процесс выглядит следующим образом. После «включения» сети, данная таблица на всех коммутаторах пуста. Её заполнение на каждом устройстве происходит по мере прохождения через него пакетов. MAC-адреса локальных устройств запоминаются также, как в обычной сети Ethernet (когда они попадают на порт коммутатора). Для пакетов, пришедших со стороны сети FabricPath, запись вида «MAC-адрес — идентификатор устройства» добавляется только в том случае, если коммутатор уже знает о получателе данного пакета (т.е. у него есть запись о MAC адресе получателя). Если данных о получателе нет, коммутатор ничего не запоминает. Пока нужная запись «MAC-адрес — идентификатор устройства» отсутствует, коммутатор рассылает такие пакеты на все устройства в сети FabricPath.
Такой механизм позволяет минимизировать MAC-таблицу, занося данные только о тех MAC-адресах удалённых хостов (имеются ввиду хосты, которые находятся за другими устройствами FabricPath), которые обмениваются данными с локальными. В такой схеме адреса хостов, полученные в широковещательных пакетах (broadcast), в MAC-таблицу никогда не заносятся. Конечно, это приводит к росту флудинга в начале взаимодействия хостов. Однако экономятся ресурсы коммутаторов в плане MAC-таблицы.

Для TRILL (IETF) описаны несколько вариантов заполнения MAC-таблицы. Самый простой – схема работы обычной сети Ethernet. Как только пришёл пакет, мы заносим соответствие «MAC-адрес – порт» для локальных хостов и «MAC-адрес — идентификатор устройства» для пакетов, пришедших со стороны сети TRILL. Также есть вариант обмена данными о MAC-адресах через специализированный протокол End Station Address Distribution Information (ESADI). В этом случае каждый коммутатор TRILL сообщает всем остальным о MAC-адресах локальных хостов.

Как было отмечено ранее, хоть TRILL (IETF) и FabricPath (Cisco) имеют общие схемы работы, при этом присутствуют существенные различия. Отличаются идентификаторы устройств, заголовки протоколов, схемы «изучения» MAC адресов, а также процесс передачи пакетов внутри сети TRILL/FabricPath.

Где же использовать данные технологии? TRILL и FabricPath работают на канальном уровне (L2). Поэтому, в частности, FabricPath рекомендуется вендором именно для построения сети внутри ЦОД. Технология FabricPath поддерживается на коммутаторах семейства Cisco Nexus (5500, 6000, 7000, 9000).

VXLAN

VXLAN (Virtual Extensible LAN) ещё одна оверлейная технология, в первую очередь рассчитанная на мир виртуализации. Над её разработкой трудятся целый ряд компаний (Cisco, Vmware, Citrix и пр.).
Посмотрев на название, сразу приходят мысли, что это что-то близкое к привычным нам VLAN’ам. Так оно и есть. VXLAN, на мой взгляд, можно сравнить с продвинутым VLAN. По факту это его замена. Что же там продвинутого? VXLAN поддерживает до 16 млн. подсетей, против 4096 для VLAN (речь идёт про уникальные идентификаторы). Также VXLAN позволяет обеспечить связность распределённых L2-сегментов через IP-сеть. Как это реализовано и, что это нам даёт, рассмотрим далее.

Работу VXLAN можно частично сравнить с ранее описанными технологиями TRILL/FabricPath. Передача пакета при его коммутации разбивается на этапы. После того как пакет попал на устройство, где запущена технологий VXLAN (далее устройство VXLAN), для данного пакета определяется удалённое устройство VXLAN, через которое подключен получатель. Пакету добавляется заголовок, и он пересылается сначала на интересующее нас устройство VXLAN, а далее уже на хост получателя. На этом сходство заканчивается. VXLAN инкапсулирует изначальный Ethernet-пакет в обычную UDP дейтаграмму. А значит при передаче пакетов между устройствами VXLAN, обработка такого пакета происходит по стандартным правилам маршрутизации и коммутации. Т.е. транспортная сеть (сеть между устройствами VXLAN) может быть полностью маршрутизируемой, и поддержка в ней технологии VXLAN не требуется. А значит нет петель (нет необходимости использоваться STP), можно использовать одновременную передачу пакетов по нескольких путям и т.д. Получаем все блага полноценной маршрутизации для пакетов, которые должны коммутироваться.
Инкапсуляция в UDP позволяет использовать VXLAN в том числе в сети интернет. С помощью VXLAN мы можем соединить распределённые L2-сегменты между двумя и более ЦОДами.

Очень важный момент, на чём мы запускаем VXLAN. Так как изначально VXLAN был рассчитан на виртуализацию, данная технология может быть настроена на виртуальном коммутаторе (Host-based) внутри сервера. Это очень здорово, так как в этом случае к «железкам» в сети вообще нет никаких требований. Также VXLAN может быть запущен на коммутационном оборудовании (Network-based). А в купе с тем, что VXLAN мы можем использовать как внутри ЦОДа, так и между ними, получаем идеальную технологию. Но, как обычно, дьявол кроется в деталях.


В целом идея работы VXLAN достаточно проста. Получили пакет, посмотрели в таблицу MAC-адресов, нашли куда переслать, инкапсулировали в UDP и передали. Уверен, что у многих уже возник вопрос, а как же заполняется таблица MAC-адресов? Как каждое устройство VXLAN узнаёт, где находится нужный MAC-адрес?

И вот тут появляются нюансы работы VXLAN. Самый первый вариант реализации – это использование multicast пакетов. Вспоминаем, что multicast даёт нам возможность передать пакет по сети сразу на несколько получателей (объединённых группу). В VXLAN это решили использовать. Все устройства VXLAN сообщают сети о том, что они хотят получать multicast трафик, адресованный определённой multicast-группе (это делает посредствам протокола IGMP). Далее любое устройство VXLAN, чтобы послать пакет на другие устройства VXLAN, в качестве адреса получателя указывает адрес multicast-групп. А дальше всё просто. Пока таблица MAC-адресов пуста, пакеты просто передаются сразу всем устройствам VXLAN (используем multicast). Получив такой пакет, устройство VXLAN заносит себе в таблицу соответствие MAC-адреса отправителя и IP-адреса устройства VXLAN, передавшего данный пакет. Таким образом, через некоторое время все устройства VXLAN будут знать, где находится тот или иной MAC-адрес. Соответственно, пакеты, адресованные уже на известный MAC-адрес передаются в виде unicast трафика.

Ах незадача, ведь вся сеть должна поддерживать multicast. Более того, если устройства VXLAN находятся в разных подсетях, необходимо поддерживать маршрутизацию multicast трафика. Вот мы и пришли к первой заковырке. Если для внутренней сети мы это можем реализовать, то для сети интернет сложновато. Какой может быть выход? Отказаться от multicast и использовать только unicast трафик.

Если будет использоваться только unicast трафик, как мы сможем заполнить таблицу MAC-адресов? Самый логичный вариант, должна быть какая-то база, где будут храниться данные о всех VXLAN устройствах (их IP-адреса). В этом случае устройства VXLAN смогут работать по тому же принципу, что и в режиме multicast. Единственно, когда нужно будет отправить пакет всем устройствам (например, когда нет ещё данных о MAC-адресе) придётся заглянуть в таблицу и отправить не один multicast-пакет, а несколько unicast-пактов (на каждое VXLAN устройство). Так и было сделано.

Основной минус такой реализации — повышенная нагрузка на устройство VXLAN в случае отправки broadcast, multicast и unknown unicast трафика (т.е. когда нет точного получателя трафика, или мы ещё не знаем, где находится MAC-адрес). Если у нас в сети, например, 20 устройств VXLAN, то нужно будет из одного такого пакета сгенерировать 20 одинаковых VXLAN пакетов и разослать их по сети. Поэтому режим unicast дополнили надстройкой, при которой в базу заносится дополнительно информация о MAC-адресах. Что это нам даёт? Теперь, устройство VXLAN может посмотреть в такую базу и сразу определить, где находится нужный MAC-адрес. Уже не требуется рассылать трафик сразу на все устройства VXLAN.
И снова возник вопрос. Ок, всё здорово, но кто и как будет заполнять базу? Вот тут-то и появляются различные вендорные реализации. Рассмотрим на примере того, что предлагает Cisco.

Первая реализация VXLAN в режиме unicast доступна на виртуальном коммутаторе Cisco Nexus 1000V. В этом случае управляющий модуль (Virtual Supervisor Module — VSM) собирает со всех виртуальных коммутаторов Cisco информацию о MAC-адресах, находящимся за ними. Таким образом, формируется база соответствий устройств VXLAN (виртуальных коммутаторов) и MAC-адресов.

Второй вариант реализации VXLAN в режиме unicast доступен уже на «железе». В этом режиме устройства VXLAN через специализированный протокол обмениваются между собой данными о MAC-адресах. Т.е. база соответствий в этом случае будет хранится отдельно на каждом устройстве VXLAN. В качестве такого протокола был выбран Multiprotocol Border Gateway Protocol Ethernet Virtual Private Network (MP-BGP EVPN). Это расширение протокола BGP, которое позволяет нам в сообщениях BGP передавать нужные нам данные: MAC-адрес хоста, его IP-адрес и IP-адрес VXLAN устройства, через который данный хост доступен.



Я думаю, вы уже обратили внимание на то, что вместе с MAC-адресом передаётся ещё и IP-адрес хоста. Это сделано для оптимизации протокола ARP (чтобы лишний раз не гонять между VXLAN устройствами ARP трафик).

Последний вариант (он правда чуточку вырожденный) – это статическое указание адреса удалённого VXLAN устройства. Причём указать можно всего одно такое устройство, т.е. сделать связь точка-точка.

Поддержка режимов VXLAN на оборудовании Cisco:

	Multicast	Unicast
Nexus 1000V	Да	Да, база MAC-адресов на VSM
Nexus 7000, 9000, ASR 9000	Да	Да, MP-BGP EVPN
ASA	Да	Да, статически задаётся адрес одного VXLAN устройства
ASR 1000	Да	Да, статически задаётся адрес одного VXLAN устройства
CSR	Да	Нет
ISR 4000	Да	н/д

Локальные итоги

Как небольшое резюме хотел бы ещё раз отметить основные моменты. TRILL и FabricPath работают на канальном уровне модели OSI. Все оборудование в сети начинает по-новому обрабатывать пакеты. Используется маршрутизация на канальном уровне. Эти технологии рекомендуется использовать для построения сети внутри ЦОД. Технология VXLAN инкапсулирует Ethernet-пакеты в дейтаграммы UDP. Тем самым данная технология позволяет оставить транспортную сеть без изменения, в том числе использовать сеть интернет. Между VXLAN устройствами строятся виртуальные туннели, по которым бегают пакеты между распределёнными сегментами одной L2 сети. VXLAN можно использовать как внутри, так и между ЦОДами.

На этом общее рассмотрение TRILL, FabricPath и VXLAN завершено. Хотелось бы отметить, что для упрощения понимания часть моментов были опущены. В частности, в таблицах MAC-адресов я сознательно опустил поле принадлежности MAC адреса/порта коммутатора тому или иному VLAN (VXLAN). Также не рассмотрел вопросы стыка обычной сети и сети VXLAN, вопросы отказоустойчивого подключения к сети FabricPath (vPC+ и HSRP) и т.д. Всё это нужно, как мне кажется, для более глубокого погружения. А мы тут всё-таки плаваем на небольших глубинах. Подчеркиваю, плаваем на глубинах, а не на поверхности.

В следующей статье мы рассмотрим технологии OTV и LISP, а также подведём общие итоги.