Сетевые оверлейные технологии: OTV, LISP и итоги. Часть 3
В предыдущих частях (первая, вторая) данной статьи мы рассмотрели общую классификацию сетевых оверлейных технологий для ЦОДов, а также более детально разобрали, что такое TRILL, FabricPath и VXLAN. Осталось дело за OTV и LISP. Плюс, нужно подвести итоги.
OTV
Технология OTV (Overlay Transport Virtualization) была придумана компанией Cisco для обеспечения связи распределённых сегментов L2-сети через обычную IP-сеть. С помощью OTV мы можем «растянуть» широковещательный домен между двумя и более ЦОДами. Можно сказать, что это одна из реализаций L2 VPN, работающая поверх IP-сети.
OTV реализует концепцию маршрутизации по MAС-адресам. Выглядит это следующим образом. Устройства, на которых запущена технология OTV (далее устройства OTV), используя протокол динамической маршрутизации IS-IS, обмениваются данными о MAC-адресах хостов, которые находятся за ними. Это позволяет каждому устройству OTV иметь общую таблицу маршрутизации MAC-адресов. Далее получив пакет, у которого в качестве получателя указан MAC-адрес хоста, находящегося где-то далеко (я имею ввиду в удалённом сегменте L2-сети), устройство OTV по таблице определяет, куда нужно переслать этот пакет. Пакету добавляется заголовок, и он пересылается сначала на удалённое устройство OTV, и далее уже на хост получателя. При передаче Ethernet-пакетов между устройствами OTV они инкапсулируются в UDP дейтаграммы.
Я думаю, многие уже отметили, что в общем случае OTV очень напоминает логику работы VXLAN. Но в отличии от VXLAN технология OTV рассчитана в первую очередь на связь L2-сетей между ЦОДам. Второй момент – мы снова говорим про IS-IS. Так же, как и в TRILL/FabricPath для control-plane (реализации логики работы) используется это протокол динамической маршрутизации.
Давайте посмотрим, каким образом устройства OTV находят друг друга, для обеспечения дальнейшей связи между собой. Для этого OTV поддерживает два режима работы.
В первом случае для связи устройств OTV между собой используется multicast трафик. Все устройства OTV сообщают сети о том, что они хотят получать multicast трафик, адресованный определённой группе (посредствам протокола IGMP). Далее сообщения для установления и поддержания связи между собой (Hello-пакеты), а также данные о MAC-адресах передаются через multicast-сообщения. Эти сообщения передаются сетью на все устройства OTV. Такое поведение очень похоже на работу обычного протокола динамической маршрутизации. Только OTV устройства могут находится в разных подсетях. Чтобы всё это работало, наша сеть должна поддерживать передачу multicast-трафика, в том числе его маршрутизацию. Как было отмечено в предыдущей статье, обеспечить выполнение этого условия не всегда просто (например, если между ЦОДами используется сеть интернет). Поэтому есть второй режим работы, в котором используется unicast трафик.
В случае использования unicast трафика для взаимодействия между OTV устройствами, одно из них настраивается как сервер соседственных связей (Adjacency Server). Далее на всех остальных OTV устройствах указывается его адрес (это делается «ручками» при настройке). Все OTV устройства устанавливают с ним соединение. Таким образом сервер соседственных связей собирает данные обо всех OTV устройствах (в частности, узнаёт их IP-адреса) и распространяет их на все устройства. Получив эту информацию, каждое OTV устройство теперь может устанавливать связь с другими, используя unicast пакеты, так как теперь есть данные об их IP-адресах. После установления соседственных связей между OTV устройствами, начинается обмен таблицами MAC-адресов. Безусловно такой режим работы создаёт большую нагрузку на устройства OTV, чем в случае использования multicast-трафика. Так как в ряде случаев (например, для широковещательного трафика) придётся вместо одного пакета, отправлять сразу несколько (на каждое устройство OTV).
Для уменьшения взаимного влияния распределённых L2-сегментов друг на друга и оптимизации передаваемого трафика между ними, OTV обеспечивает их частичную изоляцию:
- Между устройствами OTV не передаются BPDU-пакеты протоколов STP. Каждый сегмент строит свою независимую STP-топологию.
- Между устройствами OTV не передаётся unknown unicast трафик. Такая логика работы исходит из предположения, что любое устройство рано или поздно передаст какие-то данные и мы узнаем его MAC-адрес.
- Оптимизируется передача ARP-сообщений. На OTV устройствах кешируют все ответы ARP, пришедшие с удалённых хостов. Таким образом, локальное устройство OTV может ответить на ARP запрос, если ранее кто-то уже посылал аналогичный.
Как было отмечено ранее, OTV в отличии от VXLAN обеспечивает связь только между ЦОДами. По факту VXLAN более универсальный протокол. Однако требования к «железу» у OTV несколько ниже. OTV достаточно часто рекомендуется Cisco в дизайнах между ЦОДами, где внутри в свою очередь используется FabricPath.
OTV поддерживается на следующем оборудовании Cisco: Nexus 7K, ASR 1K, ISR 4451-X.
LISP
Протокол LISP (Cisco Locator/ID Separation Protocol) в отличии от ранее озвученных имеет другое назначение. Всем известна проблема корректной маршрутизации трафика, в случае, если виртуальная машина переехала, например, из одного ЦОДа в другой. И хорошо, если в другом ЦОДе используется такое же адресное пространство. А если там совсем другие подсети, как сообщить клиентскому оборудованию, что теперь трафик нужно слать не в ЦОД1, а в ЦОД2, да ещё и может быть на другой адрес? Одним из вариантов решения данной задачи стало разделение идентификатора сервера на две части: непосредственно адрес сервера (Endpoint Identifier (EID) address) и адрес устройства, через которое доступен сервер (Route Locator (RLOC) address). Таким образом, при переезде виртуальный машины в другой ЦОД, адрес EID всегда будет оставаться неизменным, при этом адрес RLOC поменяется.
В общих словах работу LISP можно описать следующим образом. После «включения» сети устройства, где настроен LISP (в терминах LISP — xTR), сообщают выделенному серверу (Map-Server) информацию о сетях, которые ими обслуживаются, т.е. для которых они является шлюзом по умолчанию. Далее, например, устройство ROUTER2, получив трафик от клиента к серверу (на адрес EID=1.1.1.2), делает запрос на выделенное устройство (Map-Resolver), который в свою очередь обращается к Map-Server. Map-Server, определив по своей базе адрес RLOC1 (адрес ROUTER1) для запрашиваемого адреса EID, просит ROUTER1 напрямую ответить клиентскому xTR (ROUTER2) о своем адресе RLOC1. После этого ROUTER2 инкапсулирует все клиентские пакеты и отправляет их на адрес RLOC1. Далее ROUTER1, получив эти пакеты, деинкапсулирует их и отправляет уже непосредственно серверу (1.1.1.2).
Но что будет, если виртуальная машина (ВМ) переедет? В этом случае после осуществления миграции на другой хост, виртуальный коммутатор (работающий на хосте, куда переехала ВМ) отправит в сеть сообщение RARP или GARP (в зависимости от типа гипервизора). Задача данного сообщения «рассказать» сети, что ВМ находится теперь на новом хосте. Перехватив такой трафик (по факту подойдёт любой трафик от ВМ, но обычно первым мы видим именно RARP/GARP), ближайший xTR отправит сообщение об этом (что ВМ теперь находится за ним) на Map-Server. Map-Server в свою очередь обновит базу (для адреса виртуальной машины EID заменит адрес RLOC, через который она доступна). Также Map-Server проинформирует старый RLOC (в нашем случае ROUTER1) о том, что виртуальная машина уехала и теперь она находится за новым адресом RLOC (например, RLOC3, на рисунке не изображено). Это нужно, чтобы сообщить о миграции ВМ всем xTR, которые до этого к ней обращались и имеют у себя в локальной базе привязку EID к старому RLOC1.
Для инкапсуляции трафика используется протокол UDP, что обеспечивает прозрачное прохождение пакетов через обычную IP-сеть.
LISP поддерживается достаточно на большом перечне оборудования Cisco, например: ISR G1 и G2, ASR, CRS, Nexus 7K, Catalyst 6K.
Общий итог
Попробуем подвести общие итоги по всем трём частям моей статьи. В следующей таблице представлена краткая информация по тем технологиям, которых мы коснулись в данном материале.
| Тип оверлея | Где используется | Транспорт | |
|---|---|---|---|
| FabricPath | Network-based | Внутри ЦОД | FabricPath* |
| TRILL | Network-based | Внутри ЦОД | TRILL* |
| VXLAN | Host-based или Network-based | Как внутри ЦОД, так и между ЦОДами | UDP |
| OTV | Network-based | Между ЦОДами | UDP |
| LISP | Network-based | Передачи трафика к ВМ, которые мигрируют | UDP |
* используется свой протокол на канальном уровне.
На оборудовании Cisco, на мой взгляд, достаточно большое распространение получила связка технологий FabricPath (внутри ЦОДа) и OTV (между ЦОДами). Эти технологии хорошо отработаны, просты в настройке и именно на них опирается большинство дизайнов Cisco. Есть примеры ЦОДов, где это используется. Правда стоит заметить, что для их использования требуется не совсем простое и дешевое «железо». Но что поделаешь.
Что можно сказать про VXLAN? Это довольно перспективная технология:
- постоянно дорабатывается;
- поддерживается и развивается многими вендорами;
- появляется поддержка на более дешевых классах устройств;
- достаточно гибкая: Host-based или Network-based, работа как внутри ЦОДа, так и между;
- поддержка более 16 млн. логических сегментов (VXLAN сетей);
- используется в сетях SDN (на мой взгляд, очень мощный драйвер).
Безусловно, есть ряд вопросов, которые требуют ещё доработки. Например, если мы говорим, про Cisco, хотелось бы видеть поддержку MP-BGP EVPN для режима передачи unicast на более простом «железе» или возможность работы в режиме unicast между несколькими VSM для решения Cisco Nexus 1000V.
Но технология постоянно развивается. Ещё не так давно рассматривать VXLAN для реализации связи между ЦОДами было сложно. Сейчас же возможность использования MP-BGP EVPN для реализации control-plane VXLAN сделало это возможным. Благодаря MP-BGP EVPN решается вопрос минимизации флудинга и изоляции распределённых сегментов при использовании VXLAN. Хотя хотелось бы конечно, чтобы не было вообще никакого флудинга и штормов.
Вообще стоит сказать, что судя по документам Cisco, вендор возлагает большие надежды на реализацию MP-BGP EVPN. Cisco предлагая его как некий стандарт SDN архитектур для реализации связи по средствам VXLAN в противовес Open vSwitch Database Management Protocol (OVSDB). Ну это не ново для Cisco, посмотрим, что получится.
Стоит обратить внимание, что VXLAN никак не участвует в работе транспортной сети. Т.е. транспортная сеть должна настраиваться отдельно, плюс если её плохо настроить, передача VXLAN трафика будет происходить не оптимально. Правда, «кривизна» рук опасна для любых технологий.
Технология LISP стоит чуточку особняком, решая задачу оптимальной передачи трафика в сторону сервера, а в некоторых задачах и клиента. Поэтому LISP рекомендуется использовать независимо от оверлейных технологий внутри ЦОД или между ними. LISP не самый простой (с точки зрения реализации) вариант решения проблемы неоптимальной передачи трафика и далеко не на все случаи в жизни. Например, чтобы полностью решить вопрос неоптимального движения трафика от клиента к серверу в ЦОДе (т.е. WAN-to-DC), LISP должен быть настроен у каждого удалённого клиента (что для интернет сети представляется достаточно сложной задачей).
И напоследок, хотелось бы отметить ещё несколько моментов:
- Описанные технологии являются оверлейными. А значит добавляют к исходному пакету свой заголовок. Следовательн, необходимо крайне внимательно следить за таким параметром, как максимальный размер кадра (MTU).
- Как я уже писал, нет супер технологии, которая решает все проблемы. У любой озвученной технологии есть свои плюсы и минусы.
- Для упрощения восприятия материала я специально упустил ряд технических деталей. Поэтому, если что-то вызывает вопросы, постараюсь ответить.
