Опубликовано Minorioo 7 Март , 2014

OTV является одной из технологий, которая помогает прокинуть L2-сеть через L3 облако, главное чтобы была IP-связность (нет привязки к конкретному транспорту).

На рисунке снизу показана типовая ситуация, в которой может потребоваться внедрение OTV.

 

Терминология и основные принципы

Прежде чем изучать поведение Control и Data plane, необходимо познакомиться с некоторыми понятиями:

• OTV Edge. Устройство, которое берет на себя все OTV функции. Оно получает L2 ethernet фреймы, инкапсулирует их и передает по L3. Рекомендуется помещать Edge на Distribution уровне дата-центра.
• Внутренний интерфейс OTV (OTV internal interface). Это интерфейс, который смотрит в сторону локального сайта и переносит на себе самые обыкновенные VLAN’ы, которые надо «расширить» на несколько сайтов.
• OTV join interface. Это аплинк в сторону L3 сети. Представляет собой p2p маршрутизируемый интерфейс, который используется для OTV- передачи трафика.
• OTV Overlay interface. Логический виртуальный интерфейс, на котором настраивается почти вся OTV конфигурация. Используется для инкапсуляции интересного трафика (эдакий interface Tunnel).
• OTV site VLAN. Используется OTV Edge коммутаторами для обнаружения соседей в случае multihoming подключения. По этой VLAN устройства устанавливают отношения соседства и выбирают Authorative Edge Device (AED), которое и передает трафик в облако (выбора происходят per vlan).
• OTV site-id. Должен быть уникальным для сайта в пределах одного Overlay облака (аналог FabricPath ID).

OTV Control plane

Корневой концепцией в OTV является объявление МАС адресов через Control Plane (вместо классического MAC address learning на уровне Data Plane). Т.е. когда OTV Edge видит какие-либо изменения в локальной МАС таблице (напр., появилась новая рабочая станция в сети), то об этом сразу же сообщается всем остальным OTV Edge соседям (с которыми предварительно устанавливаются отношения соседства). При этом апдейт передается в виде связки MAC+Site-ID (т.е. удаленные Edge знают за каким Site-ID какой МАС находится). Собственно сам механизм установления соседства между коммутаторами может проходить 2мя путями, в зависимости от того, к какой транспортной сети подключены устройства:

• Multicast режим. Если L3 облако является multicast aware (т.е., например, ISP согласен маршрутизировать ваш мультикаст-трафик), то соседство устанавливается путем многоадресной рассылки.
• Unicast режим. В противном случае вводится понятие сервера регистрации, который ответственен за коммуникации между всеми Edge коммутаторами.

Рассмотрим, что происходит при наличии L3 multicast aware сети.

В этом случае все OTV Edge являются одновременно multicast клиентами и серверами. Серверная роль заключается в отсылке служебных OTV сообщений на заранее определенный адрес рассылки. Клиентская роль заключается собственно в приеме таких сообщений от других устройств. Соответственно, чтобы мультикаст трафик дошел до коммутатора, L3 облако должно знать о наличии заинтересованных клиентов. Для этого Edge высылает IGMP join через свой Join Interface. Обычно, в качестве протокола многоадресной рассылки используется протокол PIM в режиме Source Specific Multicast (SSM), который не требует наличия в сети точки рандеву (Rendezvous Point, RP). Однако, никто Вам не запрещает использовать классический PIM-SM.

Прим. Основы мультикаста можете прочитать в этой статье: http://www.anticisco.ru/blogs/?p=1883

На рисунке выше представлена последовательность операций установления соседства:

• OTV Edge высылает IGMP Join на определенный мультикастный адрес для присоединения коммутатора к дереву рассылки
• Control protocol генерирует OTV Hello пакет, который необходимо доставить остальным устройствам для успешного установления соседства.
• Пакет подвергается OTV инкапсуляции, в процессе которой добавляется новый IP заголовок, в котором SIP=IP адресу Join интерфейса, DIP=Multicast IP.
• Пакет передается по L3 облаку и деинкапсулируется на удаленных площадках.
• Такой же процесс происходит в обратном направлении.

Прим. В качестве CP протокола используется ISIS, у которого есть TLV для переноса информации о таблице МАС адресов. Отдельная настройка ISIS не требуется.

После того, как OTV Adjacency установлены, коммутаторы переходят к фазе обмена МАС адресами. Делается это так:

• OTV Edge в дата-центре Edge узнает новые МАС адреса на локальном сайте (MAC A,B,C в VLAN 100). Это традиционный learning.
• Генерируется сообщение OTV Update, которое содержит информацию о новых МАС адресах. Сообщение инкапсулируется в OTV и передается на удаленные площадки.
• В дата-центрах East/South-East происходит деинкаспуляция пакета и полезная информация добавляется в МАС таблицу. В качестве параметра Next-Hop ставится IP адреса OTV соседа, от которого пришел Update.

OTV Data Plane

После заполнения Control Plane устройства способны корректно передавать трафик. Что же конкретно происходит?

• OTV Edge получает L2 фрейм через свой Ethernet интерфейс. Производится L2 lookup, в результате которого выясняется, что Destination MAC доступен через IP адрес B (адрес East Side).
• OTV Edge производит инкапсуляцию фрейма: SIP ставится адресом Join интерфейса, DIP=B.
• Пакет передается по L3 облаку и в конце концов прилетает на удаленный Edge.
• East Side Edge деинкапсулирует пакет, производит L2 lookup и отправляет фрейм через Ethernet.

Прим. OTV инкапсуляция представляет собой добавление дополнительных 42 байт к заголовку. Если быть совсем точным, то производится инкапсуляция вида Ethernet over MPLS over GRE. Т.е. OTV по сути – GRE туннель между коммутаторами.

 

 

OTV и Broadcast/Unknown Unicast трафик

Думаю, Вы заметили, что я рассмотрел ситуацию с передачей трафика для случая, когда МАС адреса хостов во взаимодействии уже известны. Но это ведь не всегда так! Например, появилась новая виртуалка и ее МАС пока неизвестен на Edge устройствах. Что же происходит в данной ситуации? Тут всё довольно просто: если OTV Edge получает фрейм с неизвестным ему DMAC, то такой фрейм рассылается только через Ethernet, но не через OTV Overlay! Также не передаются в OTV: CDP, LACP, IGMP, VTP и STP BPDU.

Особняком стоит взаимодействие OTV и ARP.

• Некий хост в ДЦ West генерирует ARP Request чтобы узнать МАС IP адреса А, который находится в ДЦ East.
• Этот запрос инкапсулируется и передается по OTV облаку на все удаленные сайты. В конце концов он долетает до нужного хоста, который отвечает с помощью ARP Reply. Ответ долетает до первоначального хоста.
• Теперь OTV Edge в ДЦ West имеет возможность снупить (ARP snooping) все последующие запросы, которые будут отправляться на хост А и отвечать на них локально, не передавая через OTV.

Multihoming OTV

Все-таки ситуации, когда ДЦ сайт смотрит во внешний мир всего одним коммутатором – скорее исключение. Чаще всего их два! Соответственно оба подключаются к OTV. Далее происходит выбор AED (per-vlan, повлиять на процесс нельзя), один коммутатор становится active для четных vlan, другой для нечетных, и они постоянно друг друга мониторят через site vlan. Главное – не передавайте site vlan через OTV!

Также встает вопрос с предотвращением петель для ARP запросов, которые широковещательно распространяются по всему ДЦ. Ответ на данную проблему достаточно полно показан на рисунке ниже.

 

Конфигурация и верификация

Прежде всего хочу отметить, что OTV доступен только на Nexus7000 и ASR1000. Для Nexus нужна Enhanced L3 лицензия, для ASR – Enterprise. Также существенно важным являются следующие ограничения:

• OTV не может находится на одном VDC с SVI-интерфейсами (N7K)
• OTV не может находится на одном маршрутизаторе, на котором уже запущен MPLS (ASR1000)
• Для работы на N7K необходима M-плата

Первым делом настраиваем Join-интерфейс. В моем случае это E1/1.

##### Join Interface #####

interface e1/1

ip igmp version 3

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

Следующий шаг это настройка Overlay интерфейса. Перед этим необходимо включить OTV командой feature otv. После этого создается interface overlay, внутри которого необходимо дать набор команд:

• Ø otv join-interface <JOIN INTERFACE> укажет с какого физического интерфейса строится OTV облако
• Ø otv control-group <IP ADDRESS> задает адрес многоадресной рассылки, на который будут слаться все служебные сообщения, этот же адрес прослушивается для приема аналогичных сообщений
• Ø otv data group <IP RANGE> необходима в случае, если Вы хотите передавать между ДЦ сайтами свой мультикаст трафик. IP RANGE указывает диапазон адресов для пересылки. Здесь нужно принять во внимание некоторые факты: если L3 канал не является вашим собственным, то необходимо, чтобы провайдер был готов маршрутизировать ваш мультикаст трафик.
• Ø otv extend-vlan <VLANs> укажет набор VLAN’ов, которые необходимо расширить на удаленные сайты

После этого настраиваем site vlan командой otv site-vlan <VLAN NUMBER>.

Site-ID задается командой otv site-identifier <IDENTIFIER>.

В целом, базовая настройка закончена. Переходим к верификации.

N7K1# show otv

OTV Overlay Information

Site Identifier 0000.0000.0101

Overlay interface Overlay1

VPN name : Overlay1

VPN state : UP

Extended vlans : 10 (Total:1)

Control group : 224.1.1.1

Data group range(s) : 232.1.1.0/24

Join interface(s) : Eth1/1 (169.254.0.71)

Site vlan : 999 (up)

AED-Capable : Yes

Capability : Multicast-Reachable

В выводе данной команды видна вся основная информация: состояния OTV облака (VPN state), extend vlan’ы, site vlan, выбран ли коммутатор AED’ом.

Посмотреть отношения соседства с удаленными сайтами можно командой

N7K1# show otv isis adjacency

OTV-IS-IS process: default VPN: Overlay1

OTV-IS-IS adjacency database:

System ID SNPA Level State Hold Time Interface Site-ID

N7K2 0026.980c.2141 1 UP 00:00:25 Overlay1 0000.0000.01

Можно посмотреть все МАС адреса, которые доступны через OTV.

N7K1# show otv route

OTV Unicast MAC Routing Table For Overlay1

VLAN MAC-Address Metric Uptime Owner Next-hop(s)

---- -------------- ------ -------- --------- -----------

10 000c.2922.167d 42 00:26:16 overlay N7K2

10 000c.29bc.5bea 1 00:26:17 site Ethernet2/3

Индикацией того, что DataPlane работает, может служить наличие ARP-кэша.

N7K1# show otv arp-nd-cache

OTV ARP/ND L3->L2 Address Mapping Cache

Overlay Interface Overlay1

VLAN MAC Address Layer-3 Address Age Expires In

10 000c.2922.167d 10.0.0.2 00:00:01 00:07:58

Здесь мы видим, что N7K1 знает о МАС Server2 с IP 10.0.0.2 через интерфейс Overlay1. Если Server1 отошлет ARP запрос на Server2, то ему ответит N7K1.

N7K1# debug otv arp-nd

otv: IPv4 ARP Request packet received from source 10.0.0.1 on interface Ethernet2/3

otv: Found ORIB mac route next hop Ethernet2/3 for target IP 10.0.0.2 with source MAC 0010-000c.29bc.5bea , hence sending ARP proxy here instead of incoming iod Ethernet2/3

otv: Send proxy ARP-Reply to 10.0.0.1 (0010-000c.29bc.5bea) for target IP 10.0.0.2 with target MAC 000c.2922.167d on interface Ethernet2/3

 

 

Метки: nexus, otv
Опубликовано: Unified Fabric