Русский
Русский
English
Статистика
Реклама

Vxlan

Way to Geneve

10.04.2021 22:12:11 | Автор: admin

Хабр, привет.

Меня зовут Аркадий и я сетевой инженер в одном из сервис провайдеров. Кому интересны основные отличия VXLAN от Geneve добро пожаловать под кат. Избегая выстрела в ногу, хочу отметить, что основа статьи это выжимки из RFC и открытой информации WMware.

В NSX-T VMware уходит от Overlay на базе VXLAN в пользу Geneve. Внедрение Geneve лоббируется помимо VMWare такими компаниями как : Intel, Microsoft, Red Hat. Маркетинг называет следующую причину к Geneve : "Geneve сочетает в себе лучшее от протоколов VXLAN (Virtual Extensible LAN), NVGRE(Network Virtualization using Generic Routing Encapsulation), and STT(Stateless Transport Tunneling)." Разберем отличия нового Overlay протокола и почему ему отдано предпочтение ведущими вендорами виртуализации.

Теперь по порядку:

Geneve - туннельный протокол работающий поверх UDP (port number) для построения туннелей между NVEs (Network Virtualization Edge) через IP underlay. Описан в RFC8926, который в свою очередь заменил предшествующий драфт draft-gross-geneve 2020-11-06.

Протокол разрабатывался рабочей группой IETF с целью унификации и агрегации преимуществ протоколов VXLAN, NVGRE и STT. Недостатками которых являлись гибкость и ограниченность масштабирования в условиях стремительного развития виртуализации и сервисов на базе глобальных облачных провайдеров.

Основной задачей технологии (протокола) является виртуализация L2 домена работающего поверх базовой IP сети. Широко применяется в облачных средах, в связи с ограничениями по размеру поля VLAN Tag 802.1q в 2 ^ 12 = 4094.

Geneve

Минимальный размер заголовка Geneve составляет 8 байт.

Geneve headerGeneve header

Ver (2 bits) Версия протокола. Текущее значение 0.

Opt Len (6 bits) указание размера поля Variable Length Options. Минимальный размер заголовка + значение Opt Len = полный размер заголовка.

O (1bit) Control packet. Интерпретируется TEPs (tunnel end points). Может использоваться для передачи пакета на обработку выше по стеку.

C (1bit) Critical options present. Установленный бит указывает на необходимость парсинга опций на TEPах. На TEPах поддерживающих парсинг опций пакет должен быть отброшен.

Rsvd.(6 bits) Reserved. Значение поля должно быть = 0 при передаче пакета и игнорируемо на конечных хостах.

Protocol type (16 bits) - 0x6558 Transparent Ethernet Bridging.

VNI (24 bits) Virtual Network Identifier уникальный идентификатор сегмента виртуальной сети. Идентифицирует L2 домен которому принадлежит оригинальный Ethernet фрейм. NSX-T использует диапазон VNI от 5000 до 16777216.

Reserved (8 bits). Значение поля должно быть = 0 при передаче пакета и игнорируемо на конечных хостах.

За базовым заголовком Geneve следует поле опций в TLV формате. Каждая опция состоит из заголовка в 4 байта и данных интерпретируемых в соответствии с полем Type опции. В базовом заголовке предусмотрено поле для идентификации типа опции по организации, технологии, или вендору. Определенный блок IANA зарегистрировала для тестов и оптимизации протокола. Поле опций в заголовке Geneve по тексту RFC в большей степени предусмотрено для масштабирования протокола и возможностей оптимизации протокола разработчиками. В поле тип определено место контрольного бита (C) Critical являющегося глобальным по отношению ко всем TEPs. При обработке TEP пакета при выставленном бите C и не определенным типом опции пакет должен быть отброшен.

Хотя опции предназначены для обработки на конечных TEP, они также могут быть интерпретированы транзитными устройствами. Если обработка опций на транзитных устройствах не предусмотрена, то транзитные устройства выполняют обработку по аналогии с обычным UDP пакетом.

В сравнении с VXLAN (RFC7348)

VXLAN Header (8 bytes)VXLAN Header (8 bytes)

VXLAN Flags (8 bits) Набор флагов, в котором I должен быть выставлен в 1 для валидного VNI, R зарезервированные флаги выставленные в 0 при передаче и игнорируемы на приеме

Reserved (24 bits) - Зарезервированные флаги выставленные в 0 при передаче и игнорируемы на приеме

VNI (24 bits) - уникальный идентификатор сегмента виртуальной сети. Идентифицирует L2 домен. Размер поля такой же как у Geneve (порядка 16М номеров).

Reserved (8 bits) - Зарезервированные флаги выставленные в 0 при передаче и игнорируемы на приеме.

Ссылка на vxlan.pcap

Summary по заголовкам пакетов VXLAN и GENEVE:

Одинаковый минимальный размер заголовка 8 байт с возможность расширения Geneve за счет поля опций разной длины. Geneve обладает следующими преимуществами:

  • Поддерживает проприетарные* значения полей type, length, value;

  • Обладает гибкостью в отношении включения дополнительных метаданных в заголовок;

* ИМХО это кажется основной причиной описания нового стандарта и активного его внедения ведущими вендорами, а не маркетинговый булщит на тему сочетания в себе преимуществ предшественников.

Целиком пакет Geneve over IPv4 выглядит так:

Ссылка на Geneve.pcap

Требования к IP Underlay сетевой инфраструктуры следующие:

  • IP связность между TEP

  • Отсутствие на пути трафика блокировок UDP6081 Geneve или UDP4789 VXLAN

  • Минимальный MTU 1600 байт

Итого

Существенных различий между VXLAN и Geneve на уровне заголовков нет, равно как и на этапе инкапсуляции пакета.

Получилось достаточно кратко. В будущем планирую рассмотреть процесс построения таблиц соответствия (которых три) и этапы передачи Geneve пакета между TEP примере NSX-T.

Подробнее..

VxLAN фабрика. Часть 2.5

08.09.2020 14:23:50 | Автор: admin

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



Многие тут вещи будут скорее базового уровня в понятиях VxLAN и не должны вызывать трудностей.



I. как VxLAN фабрика узнает о MAC адресах?


Да мы уже разобрали, что MAC и IP адреса передаются через EVPN route-type 2. Но как EVPN узнает о них?


Все довольно просто и работает аналогично логике обычного VLAN:


  • Кадр от источника попадает на порт коммутатора (VTEP)
  • Коммутатор, если не знает MAC источника записывает его в свою таблицу TCAM
  • Так как коммутатор выполняет роль VTEP, то информацию о MAC и IP адресах источника он передает через EVPN route-type 2 (каким именно образом зависит от настройки фабрики. В нашем случае используется Route-reflector(RR), поэтому информация отправляется к RR и от него к остальном VTEP)


С источником все понятно, а что делать с Destination? Ведь Host-источник скорее всего не знает MAC адрес назначения и пошлет ARP запрос.
Появляется два варианта:


  1. не использовать функцию Suppress-ARP
  2. использовать функцию Suppress-ARP

В первом случае все довольно просто, но не оптимально. При получении Broadcast запроса VTEP отправит его дальше в рамках того VNI, от куда пришел запрос. То есть по всей фабрики разойдется этот запрос в виде Unicast сообщений.



Во втором случае, при получении ARP запроса VTEP сам отвечает ARP reply, а ARP REQ дальше не отправляется.



Однако такая логика работает только если VTEP уже знает Destination MAC. Если адрес не известен, то пойдем по первому пути. Более подробно работу и настройку Suppress-ARP я касался в первой части цикла.


II. Зачем используется UDP?


Вопрос не менее интересный и ответить довольно просто. Для этого вспомним логику работы VxLAN фабрики.


К кадру, прилетающему на порт VTEP, добавляется VxLAN метка с номером VNI. Далее получившийся кадр запаковывается в UDP, инкапсулируется в новый IP пакет и передается поверх Underlay сети.


Так почему же нельзя оригинальный кадр с меткой VxLAN запаковать в IP и необходимо использовать UDP?


А все из-за одного поля в заголовке протокола IP Protocol, который указывает, какой именно протокол находится выше. Примеры протоколов и их номера (wiki):


ICMP - 1TCP - 6UDP - 17GRE - 47

И в этом кроется весь секрет VxLAN не имеет такой номер, а значит протокол IP не сможет о нем рассказать и уважающая себя сеть такой пакет не пропустит, поэтому инженеры обошли эту проблему с использованием протокола UDP.



И тут может возникнуть второй вопрос почему не TCP, ведь он такой надежный и хороший? А все потому, что TCP такой надежный и хороший гарантирует доставку и для такой гарантии использует жутко долгие таймеры, проверки, регулирование полосы пропускания и т.д. В итоге TCP дает большую задержку, которая, особенно сильно, будет заметна, когда клиент VxLAN фабрики тоже будет использовать TCP.


III. Разница между ingress-replication и Multicast


Тема довольно объемная и в качестве краткого пояснения ответ дать не получится. Поэтому работа Multicast будет рассмотрена в рамках одной из следующей статьи цикла. Однако я попробую дать краткое описание различий двух технологий.


Для начала рассмотрим как передаются пакеты в обоих случаях.


при использовании ingress-replication при получения широковещательного трафика (например ARP запрос) запрос инкапсулируется внутрь VxLAN и передается каждому VTEP в VxLAN через Unicast сообщения (для примера откажемся от RR). Так как VTEP будет больше 1, то широковещательный трафик будет дублироваться:



В случае использования Multicast, каждый VTEP для каждого VNI подписывается на определенную Multicast группу. И теперь, при получении широковещательного трафика, VTEP инкапсулирует ARP запрос в IP пакет. В заголовках IP пакета в качестве адреса назначения используется multicast адрес группы для этого VNI, а адрес источника IP адрес интерфейса NVE. Например, VNI 10000 ассоциируем c multicast группой 225.1.10.10



Таким образом у нас пропадает дублирование широковещательного трафика. Плюс, при должной оптимизации трафика, работа через Multicast будет более масштабируема. Единственная сложность underlay сеть должна поддерживать Multicast трафик.


Если у вас возникает вопрос Зачем вообще понадобился EVPN, если все может отлично работать через Multicast, ведь это более масштабируемое решение?


Ответ тут дать довольно затруднительно и вам придется решить самостоятельно какую технологию использовать. На данный момент, Multicast действительно является более масштабируемым решением. Но EVPN постоянно дорабатывается и в нем появляются новые route-type для передачи все большей информации о сети для более гибкой настройки. Дополнительно, EVPN строится на основе BGP, а значит есть возможность использовать все методы оптимизации, что есть и в самом BGP (например в моем стенде уже используется RR, для уменьшения BUM трафика и оптимизации анонсируемой информации).


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




OSPF ipv6. Практические навыки



Подробнее..

VxLAN фабрика. Часть 3

16.09.2020 14:04:44 | Автор: admin

Привет, Хабр. Заканчиваю цикл статей, посвященных запуску курса "Сетевой инженер" от OTUS, по технологии VxLAN EVPN по маршрутизации внутри фабрики и использовании Firewall для ограничения доступа между внутренними сервисами



Предыдущие части цикла можно найти по ссылкам:



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


Рассмотрим два варианта маршрутизации между VRF:


  1. Маршрутизация, не выходя из VxLAN фабрики;
  2. Маршрутизация на внешнем оборудовании.

Начнем с логики маршрутизации между VRF. Есть определенное количество VRF. Чтобы маршрутизировать между VRF, необходимо выделить устройство в сети, которое будет знать обо всех VRF (или части, между которыми нужна маршрутизация).Таким устройством может стать, например, один из Leaf коммутаторов (или все сразу). Выглядеть такая топология будет следующим образом:



Какие недостатки в такой топологии?


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


Однако рассмотрим такой способ подробнее, так как для небольших сетей такой вариант вполне подойдет (если нет каких-либо специфичных требований бизнеса)


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


И ответ кроется в таких функциях как export и import маршрутной информации (настройку данной технологии рассматривали во второй части цикла). Кратко повторю:


При задании VRF в AF необходимо указать route-target для import и export маршрутной информации. Указать его можно в автоматическом режиме. Тогда в значение попадет ASN BGP и L3 VNI, привязанный к VRF. Это удобно, когда у вас в фабрике используется только одна ASN:


vrf context PROD20  address-family ipv4 unicast    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000    route-target import auto

Однако если у вас больше одной ASN и необходимо передавать маршруты между ними, то более удобным и масштабируемым вариантом будет ручная настройка route-target. Рекомендация в ручной настройке первое число, использовать удобное Вам, например, 9999.
Второе следует сделать равным VNI для этого VRF.


Настроим следующим образом:


vrf context PROD10  address-family ipv4 unicast    route-target export 9999:99000              route-target import 9999:99000    route-target import 9999:77000         ! Пример 1 import из другого VRF    route-target import 9999:77000         ! Пример 2 import из другого VRF

Как выглядит в таблице маршрутизации:


Leaf11# sh ip route vrf prod<.....>192.168.20.0/24, ubest/mbest: 1/0    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Рассмотрим второй вариант маршрутизации между VRF через внешнее оборудование, например Firewall.


Можно предположить несколько вариантов работы через внешнее устройство:


  1. Устройство знает, что такое VxLAN и мы можем добавить его в часть фабрики;
  2. Устройство ничего не знает об VxLAN.

На первом варианте останавливаться не будем, так как логика будет практически такая же, как показано выше доводим все VRF до Firewall и на нем настраивает маршрутизацию между VRF.


Рассмотрим второй вариант, когда наш Firewall ничего не знает о VxLAN (сейчас, конечно, появляется оборудование с поддержкой VxLAN. Например, Checkpoint анонсировал его поддержку в версии R81. Почитать об этом можно тут, однако это все на стадии тестирования и нет уверенности в стабильности работы).


При подключении внешнего устройства у нас получается следующая схема:



Как видно по схеме появляется узкое место на стыке с Firewall. Необходимо это учитывать в дальнейшем при планировании сети и оптимизации сетевого трафика.


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


В результате схема с Firewall:



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


Хорошо. Подключили Firewall, добавили его во все VRF. Но как теперь заставить трафик с каждого Leaf идти через этот Firewall?


На Leaf, подключенному к Firewall, никаких проблем не возникнет, так как все маршруты локальные:


0.0.0.0/0, ubest/mbest: 1/0    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Однако как быть с удаленными Leaf? Как передать им внешний маршрут по-умолчанию?


Верно, через EVPN route-type 5, как и любой другой префикс по VxLAN фабрике. Однако с этим не все так просто (если мы говорим про cisco, как у других вендоров не проверял)


Анонсировать маршрут по-умолчанию необходимо с Leaf, к которому подключен Firewall. Однако для передачи маршрута, Leaf должен сам его знать. И тут возникает некоторая проблема (возможно только у меня), маршрут необходимо прописать статикой в том VRF, где вы хотите анонсировать такой маршрут:


vrf context PROD10    ip route 0.0.0.0/0 10.254.13.55

Далее в настройке BGP задать этот маршрут в AF IPv4:


router bgp 65001    vrf prod        address-family ipv4 unicast            network 0.0.0.0/0

Однако это не все. Таки образом маршрут по-умолчанию не попадет в семейство l2vpn evpn. Дополнительно к этому необходимо настроить редистрибуцию:


router bgp 65001    vrf prod        address-family ipv4 unicast            network 0.0.0.0/0            redistribute static route-map COMMON_OUT

Указываем какие именно префиксы попадут в BGP через редистрибуцию


route-map COMMON_OUT permit 10  match ip address prefix-list COMMON_OUTip prefix-list COMMON_OUT_GATE seq 10 permit 0.0.0.0/0

Теперь префикс 0.0.0.0/0 попадает в EVPN route-type 5 и передается остальным Leaf:


0.0.0.0/0, ubest/mbest: 1/0    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

В таблице BGP так же можем наблюдать полученный route-type 5 с маршрутом по-умолчанию через 10.255.1.5:


* i[5]:[0]:[0]:[0]:[0.0.0.0]/224                      10.255.1.5                        100          0 i*>i                   10.255.1.5                        100          0 i

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


Если же у вас остались вопросы/предложения на тему, рассмотреть какой-либо функционал EVPN напишите, рассмотрим дополнительно.

Подробнее..

VxLAN фабрика часть 4. Multipod

10.11.2020 18:17:06 | Автор: admin

Привет, Хабр! Все еще заканчиваю цикл статей, посвященных запуску курса "Архитектор сетей" от OTUS, по технологии VxLAN EVPN. И сегодня обсудим реализацию подключений машинных залов или ЦОД в одну VxLAN фабрику





Предыдущие части цикла можно найти по ссылкам:



Для начала определимся какие варианты подключения существуют:


  1. Multipod
  2. Multisite

Да, вариантов не так много, однако их достаточно для решения поставленной задачи. Разберемся подробнее в каждом из способов. К уже знакомой ранее схеме, добавим второе подключение(второй ЦОД или второй машинный зал), в результате чего мы не можем подключить Leaf к уже существующему Spine. Возможно расстояние слишком большое или не хватка портов. Для простоты схемы я оставлю по одну Spine и одному Leaf коммутатору. В итоге добавляем еще один уровень в underlay сети SuperSpine(SS):



Далее нам надо построить связанность между конечными узлами. И тут довольно много вариантов развития событий. Для начала предположим, что с одной стороны у нас есть VNI 10000 и IP адрес устройства находится в сети 10.0.0.0/24 и с другой стороны так же необходимо использовать сеть 10.0.0.0/24, предоставив один L2 домен между различными машинными залами или ЦОД.


В результате такой работы Leaf'ам необходимо поднять тоннель, по которому они будут обмениваться информацией о MAC и IP адресах:



Хорошо. С основной задачей определились. Остается понять как же построить тоннель между Leaf. А точнее как именно Leaf узнают друг о друге. Как мы помним из предыдущих частей Leaf регистрируются в сети с помощью EVPN route-type 3.


Появляется два способа передать информации EVPN о самих коммутаторах и MAC/IP адресах:


  1. Поднять BGP сессию между Spine:
  2. Поднять BGP сессию между Spine и SS

И снова есть два варианта настройки BGP сессии. C обеих сторон мы можем использовать одну и туже AS, тогда VNI будут иметь вид 65000:10000, где 65000 номер AS, 10000 номер VNI (номера взяты из прошлых частей).


При одной AS проблем в целом не возникнет. Но, при увеличении сети, управлять одной AS может быть проблематично. Так как в iBGP требуется Full-Mesh, либо настройка Route-reflector.


Исходя из всего этого, мы будем настраивать каждую часть независимо друг от друга. То есть левый Spine находится в AS 65000. Правый Spine в AS 65010.


Остается вопрос, что делать с SS. Исходя из первого варианта SS можно использовать чисто как Underlay сеть. В целом вариант рабочий, но только до тех пор, пока в вашей сети не появится 3,4,5 и более подключенных к нему Spine. Так как между Spine придется поднимать Full-Mesh, для передачи маршрутной информации.


Второй вариант кажется более удобным поднимать BGP сессию на SS с каждым Spine. Тогда не требуется Full-Mesh между отдельными Spine, что удобно в плане настройки и управления, но приводит к единой точке отказа (не забывайте, что каждое устройство должно дублироваться).


Так как мы ранее отнесли все Spine к разным AS, то к какой же отнести SS? Все просто SS имеет свою AS:



Теперь у нас появился eBGP соседство и такое отношение приводит к следующей неприятной ситуации, но для начала вспомним как именно Leaf строят тоннели между собой. У Leaf есть информация о Next-hop(NH), за которым находится MAC/IP и тоннель строится до этого самого Next-Hop.


Например, есть следующая запись в таблице BGP о MAC адресе 00c1.6487.dbd1, который доступен через NH 10.255.0.3:


*> i[2]:[0]:[0]:[48]:[00c1.6487.dbd1]:[0]:[0.0.0.0]/216 *>i 10.255.0.3 100 0 64600 i

Значит и VxLAN тоннель будет строиться до этого же адреса. Но в сети появилась eBGP сессия, в которой адрес Next-Hop меняется при покидании update локальной AS. Поэтому нам потребуется дополнительная настройка на Spine и SS, которая будет запрещать смену NH адреса. Однако если мы говорим про Nexus, то данная настройка не так очевидна, как хотелось бы.


Для начала потребуется создать route-map, который запрещает смену Next_hop адреса:


route-map NH_UNCHANGED set ip next-hop unchanged

Далее устанавливает route-map в сторону eBGP соседей:


router bgp 65000  template peer SuperSpine    remote-as 65005    update-source loopback0    address-family l2vpn evpn      send-community      send-community extended      route-map NH_UNCHANGED out  neighbor 10.255.1.101    inherit peer SPINE  

Как вы могли заметить route-map устанавливается в адресном семействе l2vpn evpn и вы верно подумали SS так же должен понимать evpn адресное семейство, чтобы передавать информацию различных типов EVPN. По сути включение SS мало чем отличается от подключения обычного Spine в плане настройки BGP сессии.


Хорошо, на этом можно считать, что задача выполнена, но как только мы начинаем проверять, что вся информация о MAC и IP адресах доходит до Leaf понимаем, что все не так хорошо и update так и не дошел до Leaf, а застрял на SS.



То есть вся информация дошла до SS, но он ее не отправляет дальше. Все дело в том, что тут работает обычная логика BGP и все эти маршруты не проходят проверку на Next-Hop, так как SS ничего не знает о том как добраться до Leaf (мы ведь запустили только BGP в адресном семействе l2vpn evpn). Чтобы поправить эту ситуации запускаем OSPF между Spine и SS. То есть теперь вся сеть является единым IGP доменом. SS узнает обо всех NH и спокойно передает маршрутную информацию дальше.


Теперь радостно мы проверяем что все EVPN route-type 2 и 3 и 5 дошли до Leaf, но скорее всего нас снова постигнет разочарование. В таблице маршрутизации мы ничего не знаем об удаленных устройствах от удаленного Leaf.


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


evpn  vni 10000 l2    route-target import auto       route-target export auto

Route-target формируется автоматически на основе номер AS:VNI. В результате RT export для левой стороны 65000:10000. Для правой 65010:10000.
Так как правила import работают так же в автоматическом режиме коммутатор не добавит маршрут с неизвестным RT в таблицу маршрутизации.


Тут можно поступить следующим образом. Вместо автоматического режима настроить RT вручную:


evpn  vni 10000 l2    route-target import 999:10000       route-target export 999:10000

То же самое касается и l3 VNI(если необходимо):


vrf context PROD  address-family ipv4 unicast    route-target both 999:99999 

В результате на всех Leaf коммутаторах используется одинаковый RT, по которому маршрут будет добавлен в таблицу маршрутизации и появится связанность между конечными устройствами


Подробнее..

Из ничего к ЦОД с VXLANEVPN или как готовить Cumulus Linux. Часть 2

13.11.2020 04:15:27 | Автор: admin

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

Выбираем дизайн Underlay

Предисловие

Первое, с чем приходится сталкиваться при строительстве фабрики, это проработка дизайна Underlay - как мы хотим строить наши VXLAN туннели (точнее организовать поиск VTEP)?

Варианта у нас 3:

1.Статические туннели, в которых мы задаем каждый VTEP руками - это сразу не наш вариант, но, скажу по секрету, все еще есть провайдеры, которые ручками строят RSVP-TE туннели под каждый сервис. Так что не удивлюсь, если есть такие реализации в промышленном масштабе. Ну и никто не отменял SDN.

2.Multicast - в целом, простая реализация, но для нас вариант отпал сразу, т.к. Cumulus не умеет в подобную реализацию, да и Juniper в своих материалах говорит о его resourse-intensive и медленной сходимости.

3.BGP или BGP, или все-таки BGP? Как обычно, в случае когда нам нужен какой-нибудь широкий функционал, который был бы гибким, мы приходим к BGP, точнее в нашем случае к EVPN с сигнализацией по BGP. На нем и остановимся подробней. Так как бывает iBGP и eBGP, то и реализации underlay могут быть с каждым из них.

iBGP

При использовании iBGP у нас сразу же появляется потребность в IGP, будь то OSPF или IS-IS (хоть статика), т.к. строить мы будем до Loopback, а сообщать маршруты о том, как дойти до них, нам кто-то должен. Так же не забываем о том, как iBGP распространяет маршруты, что вынуждает нас строить full-mesh (в такой реализации Spine совсем ничего не знает о существовании BGP).

Или можем сделать Spine в роли Route-Reflector.

По итогу мы получаем как минимум 2 протокола маршрутизации и плюсом к этому full-mesh или RR. Это, конечно, не самое худшее что могло бы быть, но следующий вариант мне нравится больше.

eBGP

Данная реализация, на мой взгляд, самая понятная и надежная, и в итоге мы остановились на ней. Как только мы переходим к eBGP, потребность в Route-Reflector отпадает (надеюсь, все понимают почему), и продолжать использовать IGP тоже не имеет большого смысла, т.к. мы можем начинать строить соседства с p2p адресов. Так же в данном дизайне MLAG имеют более понятную реализацию. Про нее бы я остановился подробней. Оба MLAG свича помещаются в одну AS, т.к. при правильной реализации для всего остального VXLAN/EVPN домена они будут казаться одним устройством, что делает логичным их помещение в одну AS. Само соседство мы строим на peerlink'e, и это действительно необходимо, т.к. в случае, если у одного коммутатора упадут линки в сторону Spine, то он начнет дропать весь входящий трафик из-за того, что не будет маршрутов.

Единственное, что может кого-то спугнуть, это то, что нужно вести адресный план с номерами AS. Но счастливые обладатели Cumulus с версией 4.2(т.к. именно в ней это вышло) могут пойти другим путем, т.к. он теперь умеет автоматическое назначение AS, основываясь на MACе, что гарантирует вам уникальность (берет он из приватного пула 32-bit AS).
Так же стоит затронуть почему оба Spine находятся в одной AS. Т.к. каждый Spine имеет прямой линк к каждому Leaf, то трафик через него не может пройти дважды. Следовательно, мы можем использовать одинаковый номер AS на всех Spine, что собственно и советует Cumulus.
P.S. при использовании коротких AS можно все грамотно и красиво разделить, чтобы по номеру AS было понятно где был создан префикс. Так что использовать 32-bit AS совсем необязательно.

BGP Unnumbered

Думаю, многие не очень любят сталкиваться с адресным планированием p2p сетей, и как бы хотелось иметь только loopback и больше ничего. Если такие мысли вас когда-либо посещали, то стоит присмотреться к использованию Unnumbered. Реализация данного функционала в Cumulus отличается от Cisco, где у вас происходит заимствование адреса с интерфейса. Вместо этого у Cumulus выделен отдельный пул IPv6 адресов, которые динамически назначаются на интерфейс и по факту на них строится eBGP соседство. Так же на самом соседстве обязательно должен быть настроен extended-nexthop (для того, чтобы вы могли маршрутизировать IPv4 Family поверх IPv6 сессии).

P.S. Если на интерфейсах уже назначен какой-либо IPv4 /30 или /31 адрес, то BGP пиринг будет с них. Так же он не может работать в broadcast сетях, только p2p.

BGP+BFD

Как бы вы не хотели, но в любом случае таймеры самого BGP всегда будут измеряться секундами. И с учетом того, что сейчас появляются iSCSI, VSAN и т.д. такие задержки никто не может себе позволить. Как и во всех других протоколах маршрутизации нас спасает BFD. У Cumulus минимальные значения это 2x50 мс, насколько я знаю Cisco уже умеет 2х33 мс, так что данный функционал нам обязателен.

Что имеем в итоге?
1.Маршрутизация на eBGP с автоназначением AS + iBGP для MLAG пары
2.Из адресации нужны только loopback, все остальное нам заменяет Unnumbered
3.BFD

Настало время все настроить и посмотреть как оно работает

1.Как выглядит автоназначение AS у Cumulus

#Вариации у Cumulus при выборе AS#P.S. Для всех Spine мы можем использовать одну AS, т.к. тут не будет возникать петли по AS-pathcumulus@Switch1:mgmt:~$ net add bgp autonomous-system    <1-4294967295>  :  An integer from 1 to 4294967295    leaf            :  Auto configure a leaf ASN in the 4-byte private range 4200000000 - 4294967294 based on the switch                       MAC    spine           :  Auto configure a spine AS-number in the 4-byte private ASN range. The value 4200000000 is always                       used#Что по факту происходит при выборе "net add bgp autonomous-system leaf"cumulus@Switch1:mgmt:~$ net add bgp autonomous-system leafcumulus@Switch1:mgmt:~$ net pending+router bgp 4252968529 #Процесс BGP с автоматически сгенерированным AS+end

2.Конфигурация BGP+Unnumbered

#loopbacknet add loopback lo clag vxlan-anycast-ip 10.223.250.30 #При MLAG добавляется общий для пары IP (Он как раз и будет светится в маршрутахnet add loopback lo ip address 10.223.250.1/32#AS+Router IDnet add bgp autonomous-system leafnet add bgp router-id 10.223.250.1#Создаем стандартную конфигу для соседей через peer-groupnet add bgp neighbor fabric peer-group #Создаем саму peer группуnet add bgp neighbor fabric remote-as external #Обозначаем что это eBGPnet add bgp neighbor fabric bfd 3 50 50 #Классический BFDnet add bgp neighbor fabric capability extended-nexthop # IPv4 over IPv6#Задаем соседей через интерфейсы(Unnumbered)net add bgp neighbor swp2 interface peer-group fabric net add bgp neighbor peerlink.4094 interface remote-as internal #iBGP через Peerlinknet add bgp ipv4 unicast neighbor peerlink.4094 next-hop-self #Не забываем про next-hop для iBGPnet add bgp ipv4 unicast redistribute connected #Отдаем в BGP все свои сетки#EVPNnet add bgp l2vpn evpn neighbor fabric activate #Активируем family для eBGPnet add bgp l2vpn evpn neighbor peerlink.4094 activate #Активируем family для iBGPnet add bgp l2vpn evpn advertise-all-vni #Сообщаем BGP соседям о своих VNI 

3.BGP Summary

cumulus@Switch1:mgmt:~$ net show bgp summary#IPv4show bgp ipv4 unicast summary=============================BGP router identifier 10.223.250.1, local AS number 4252968145 vrf-id 0BGP table version 84RIB entries 29, using 5568 bytes of memoryPeers 3, using 64 KiB of memoryPeer groups 1, using 64 bytes of memoryNeighbor                       V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcdSwitch3(swp2)              4 4252424337    504396    484776        0    0    0 02w0d23h            3Switch4(swp49)             4 4208128255    458840    485146        0    0    0 3d12h03m            9Switch2(peerlink.4094) 4 4252968145    460895    456318        0    0    0 02w0d23h           14Total number of neighbors 3#EVPNshow bgp l2vpn evpn summary===========================BGP router identifier 10.223.250.1, local AS number 4252968145 vrf-id 0BGP table version 0RIB entries 243, using 46 KiB of memoryPeers 3, using 64 KiB of memoryPeer groups 1, using 64 bytes of memoryNeighbor                       V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcdSwitch3(swp2)              4 4252424337    504396    484776        0    0    0 02w0d23h          237Switch4(swp49)             4 4208128255    458840    485146        0    0    0 3d12h03m          563Switch2(peerlink.4094) 4 4252968145    460895    456318        0    0    0 02w0d23h          807Total number of neighbors 3

4.net show route

cumulus@Switch1:mgmt:~$ net show routeshow ip route=============Codes: K - kernel route, C - connected, S - static, R - RIP,       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,       F - PBR, f - OpenFabric,       > - selected route, * - FIB route, q - queued route, r - rejected route#Как видим все IPv4 адреса доступны через IPv6 (И да у Cumulus есть weight, аналогичный Cisco)C>* 10.223.250.1/32 is directly connected, lo, 02w0d23h #LoopbackB>* 10.223.250.2/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d23hB>* 10.223.250.6/32 [20/0] via fe80::ba59:9fff:fe70:e5c, swp49, weight 1, 3d12h19mB>* 10.223.250.7/32 [20/0] via fe80::ba59:9fff:fe70:e5c, swp49, weight 1, 3d12h19mB>* 10.223.250.9/32 [20/0] via fe80::ba59:9fff:fe70:e5c, swp49, weight 1, 3d12h19mC>* 10.223.250.30/32 is directly connected, lo, 02w0d23h #MLAG LoopbackB>* 10.223.250.101/32 [20/0] via fe80::1e34:daff:fe9e:67ec, swp2, weight 1, 02w0d23hB>* 10.223.250.102/32 [20/0] via fe80::1e34:daff:fe9e:67ec, swp2, weight 1, 02w0d23hB>* 10.223.250.103/32 [20/0] via fe80::1e34:daff:fe9e:67ec, swp2, weight 1, 02w0d23hB>* 10.223.252.11/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.12/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.20/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.101/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.102/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06hB>* 10.223.252.103/32 [200/0] via fe80::ba59:9fff:fe70:e50, peerlink.4094, weight 1, 02w0d06h

5.traceroute + BFD

#traceroute полностью линуксовый (при желании можно пускать трассировку по TCP порту)cumulus@Switch1:mgmt:~$ traceroute -s 10.223.250.1 10.223.250.6vrf-wrapper.sh: switching to vrf "default"; use '--no-vrf-switch' to disabletraceroute to 10.223.250.6 (10.223.250.6), 30 hops max, 60 byte packets 1  10.223.250.7 (10.223.250.7)  1.002 ms  1.010 ms  0.981 ms # Все ответы идут с loopback интерфейсов 2  10.223.250.6 (10.223.250.6)  0.933 ms  0.917 ms  1.018 ms#Проверяем BFDcumulus@Switch1:mgmt:~$ net show bfd------------------------------------------------------------------------------------------port   peer                       state  local                      type       diag  vrf------------------------------------------------------------------------------------------swp2   fe80::1e34:daff:fe9e:67ec  Up     fe80::1e34:daff:fea6:b53d  singlehop  N/A   N/Aswp49  fe80::ba59:9fff:fe70:e5c   Up     fe80::1e34:daff:fea6:b510  singlehop  N/A   N/A

На данном этапе Underlay уже полностью готов к использованию, теперь можем перейти к Overlay.

Выбираем дизайн Overlay

Как понятно из названия статьи, Overlay у нас на VXLAN с поиском VTEP через EVPN. Но и тут не все так просто. Существуют 3 основных дизайна маршрутизации трафика между SVI, на них как раз и остановимся.

Centralized IRB

В данной реализации у нас появляется единая точка выхода из подсети, это centralized switch. Зачастую это несколько отдельных коммутаторов (active-active пара), которые занимаются только L3 форвардингом, а все остальные Leaf коммутаторы занимаются только L2. Дополнительно ко всему в такой реализации сentralized switch должен анонсировать EVPN type-2 маршрут (MAC+IP) c расширенным Default Gateway community(0x03). Так же не забываем что на centralized switch должны присутствовать VNI со всей фабрики.

*Все Leaf коммутаторы в MLAG паре*Все Leaf коммутаторы в MLAG паре

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

Asymmetric IRB

Очень схожая по настройке реализация с Symmetric IRB (о которой ниже), но с одним исключением. Вся маршрутизация происходит на первом же VTEP, и последующим устройствам остаётся только отдать пакет по L2. При такой реализации необходимо, чтобы на каждом Leaf были все VNI+Vlan, что является платой за отказ от L3VNI.

P.S. На самом деле, средствами автоматизации можно прийти к тому, что конфигурация у всех устройств фабрики всегда одинаковая (следовательно есть все VNI). При таких условиях данный дизайн может быть очень даже не плох, с учетом избавления от необходимости выделения VLAN под каждый VRF. Но в условиях того, что на текущий момент автоматизация у нас только в зачаточном состоянии, вероятноcть человеческой ошибки слишком высока.

Symmetric IRB

При симметричной модели для всех L3 коммуникаций у нас создается отдельная сущность L3VNI, с которой ассоциируется VLAN. Именно данный функционал избавляет нас от необходимости иметь все VNI на каждом VTEP.

Для того, чтобы было понятно что происходит, давайте рассмотрим то, как пойдет пакет с VM2 на VM3. При попадании пакета на Leaf03/04, он делает route-lookup, в котором видит что VM3 доступна через Leaf05/06, а nexthop является L3VNI интерфейс. Далее уже Leaf05/06 получает данный пакет, снимает VXLAN заголовок и передает уже чистый пакет в SVI20. То есть помещение в нужный SVI идет именно на конечном устройстве, что как раз и избавляет нас от необходимости иметь его на всех устройствах, но L3VNI у нас должен быть везде.

Как итог мы выбирали именно этот дизайн для Overlay.

Заканчиваем с настройкой фабрики

Пора настроить уже сам Overlay и посмотреть, как у нас будет работать поиск VTEP и распространение маршрутов.

1.Создаем L3VNI

#VRF+VNInet add vrf Test vrf-table auto #Cоздаем VRF и автоматически назначаем RD+RTnet add vrf Test vni 200000 #Добавляем VNI к VRFnet add vxlan vniTest vxlan id 200000 #Создаем L3VNInet add vxlan vniTest bridge learning off #Отключаем изучение Маков, т.к. используется EVPNnet add vxlan vniTest vxlan local-tunnelip 10.223.250.1 #Адрес откуда строим туннель#VLANnet add vlan 2000 hwaddress 44:38:39:BE:EF:AC #Делается только для MLAG, что бы у Active-Active пары был один MACnet add vlan 2000 vlan-id 2000 #Номер вланаnet add vlan 2000 vlan-raw-device bridge #Добавление в bridgenet add vlan 2000 vrf vniTest #Ассоциация с VRFnet add vxlan vniTest bridge access 2000 #Ассоциируем VLAN с L3VNI

2.Создаем VNI

#VNInet add vxlan vni-20999 vxlan id 20999 net add vxlan vni-20999 bridge arp-nd-suppress on #Включаем функционал ARP-supress - уменьшаем BUM трафикnet add vxlan vni-20999 bridge learning off #Отключаем изучение Маков, т.к. используется EVPNnet add vxlan vni-20999 stp bpduguard # Включаем bpduguardnet add vxlan vni-20999 stp portbpdufilter # Включаем bpdufilternet add vxlan vni-20999 vxlan local-tunnelip 10.223.250.1 #Адрес откуда строим туннель#Создаем VLANnet add vlan 999 ip address 10.223.255.253/24 # IP на VLANnet add vlan 999 ip address-virtual 44:39:39:ff:01:01 10.223.255.254/24 #Виртуальный адрес (Для единого gateway на всех Leaf)net add vlan 999 vlan-id 999 #Номер вланаnet add vlan 999 vlan-raw-device bridge #Добавление в bridgenet add vlan 999 vrf Test #Ассоциация с VRFnet add vxlan vni-20999 bridge access 999 #Ассоциируем VLAN с VNI#P.S. Это конфига если нам нужен L2 only vlan (Конфигурация VNI не меняется)net add vlan 999 ip forward offnet add vlan 999 vlan-id 999net add vlan 999 vlan-raw-device bridge

3.Настройка соседства с внешней инфраструктурой

#Создаем самый обычный BGP процесс в VRFnet add bgp vrf Test autonomous-system 4252424337net add bgp vrf Test router-id 10.223.250.101net add bgp vrf Test neighbor 100.64.1.105 remote-as 35083net add bgp vrf Test ipv4 unicast redistribute connectednet add bgp vrf Test ipv4 unicast redistribute staticnet add bgp vrf Test ipv4 unicast neighbor 100.64.1.105 route-map Next-Hop-VRR_Vl997 out #Конфига для корректной работы MLAG+VSS через BGP+SVI, это стоило пару дней мучений для понимания#P.S. Стоит так же заметить что в инфру будут отдаваться /32 префиксы которые генерирует EVPN, в нашем случая я их фильтровал на принимающей стороне.net add bgp vrf Test l2vpn evpn  advertise ipv4 unicast #Отдаем полученные маршруты в EVPN

На данном этапе с конфигурацией мы закончили, теперь предлагаю посмотреть как это все выглядит:

#VNIcumulus@Switch1:mgmt:~$ net show evpn vniVNI     Type VxLAN IF      MACs   ARPs   Remote VTEPs  Tenant VRF20995   L2   vni-20995     5        3        1               default #VNI, если нет IP на SVI20999   L2   vni-20999     26       24       4               Test    #VNI200000  L3   vniTest        3        3        n/a             Test    #Сам L3VNI#VNI подробнейcumulus@Switch1:mgmt:~$ net show evpn vni 20999VNI: 20999 Type: L2 Tenant VRF: Test VxLAN interface: vni-20999 VxLAN ifIndex: 73 Local VTEP IP: 10.223.250.30 #При наличии MLAG, будет использоватся vxlan-anycast-ip Mcast group: 0.0.0.0 #Не используется Remote VTEPs for this VNI: #Те у кого так же есть данный VNI  10.223.250.9 flood: HER #Используем Head-end Replication (Так же известно как Ingress replication)  10.223.252.103 flood: HER  10.223.252.20 flood: HER  10.223.250.103 flood: HER Number of MACs (local and remote) known for this VNI: 26 Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 24 Advertise-gw-macip: No #Community при centralized IRB
#Таблица с тем откуда изучены макиcumulus@Switch3:mgmt:~$ net show evpn mac vni 20999Number of MACs (local and remote) known for this VNI: 28Flags: B=bypass N=sync-neighs, I=local-inactive, P=peer-active, X=peer-proxyMAC               Type   Flags Intf/Remote ES/VTEP            VLAN  Seq #'s0c:59:9c:b9:d8:dc remote       10.223.250.30                        0/00c:42:a1:95:79:7c remote       10.223.250.30                        0/0#Таблица MAC,где видим Interface VNIcumulus@Switch3:mgmt:~$ net show bridge macs vlan 999VLAN  Master  Interface  MAC                TunnelDest  State      Flags         LastSeen----  ------  ---------  -----------------  ----------  ---------  ------------  ----------------- 999  bridge  bridge     1c:34:da:9e:67:68              permanent                24 days, 04:35:13 999  bridge  bridge     44:39:39:ff:01:01              permanent                14:26:45 999  bridge  peerlink   1c:34:da:9e:67:48              permanent                31 days, 17:22:36 999  bridge  peerlink   1c:34:da:9e:67:e8              static     sticky        24 days, 04:14:16 999  bridge  vni-20999  00:16:9d:9e:dd:41                         extern_learn  19 days, 04:17:21 999  bridge  vni-20999  00:21:1c:2e:86:42                         extern_learn  19 days, 04:17:21 999  bridge  vni-20999  00:22:0c:de:30:42                         extern_learn  19 days, 04:17:21#Маки самих VTEPcumulus@Switch3:mgmt:~$ net show evpn rmac vni allVNI 200000 RMACs 3RMAC              Remote VTEP44:38:39:be:ef:ac 10.223.250.3044:39:39:ff:40:94 10.223.252.10344:38:39:be:ef:ae 10.223.250.9#Arp-cachecumulus@Switch3:mgmt:~$ net show evpn arp-cache vni 20999Number of ARPs (local and remote) known for this VNI: 28Flags: I=local-inactive, P=peer-active, X=peer-proxyNeighbor                  Type   Flags State    MAC               Remote ES/VTEP                 Seq #'s10.223.255.242            local        active   1c:34:da:9e:67:68                                0/010.223.255.13             remote       active   0c:42:a1:96:d2:44 10.223.250.30                  0/010.223.255.243            local        inactive 06:73:4a:02:27:8a                                0/010.223.255.7              remote       active   0c:59:9c:b9:f8:fa 10.223.250.30                  0/010.223.255.14             remote       active   0c:42:a1:95:79:7c 10.223.250.30                  0/0
#Таблица маршрутизацииcumulus@Switch1:mgmt:~$ net show route vrf Test | grep "10.3.53"//Как видим все next-hop vlan2000, который мы отдали раньше под L3VNIC * 10.223.255.0/24 [0/1024] is directly connected, vlan999-v0, 03w3d04hC>* 10.223.255.0/24 is directly connected, vlan999, 03w3d04hB>* 10.223.255.1/32 [20/0] via 10.223.250.30, vlan2000 onlink, weight 1, 02w5d04hB>* 10.223.255.2/32 [20/0] via 10.223.250.30, vlan2000 onlink, weight 1, 02w5d04hB>* 10.223.255.3/32 [20/0] via 10.223.250.30, vlan2000 onlink, weight 1, 02w5d04h#Пример вывода EVPN маршрутаcumulus@Switch3:mgmt:~$ net show bgp evpn route vni 20999BGP table version is 1366, local router ID is 10.223.250.101Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incompleteEVPN type-1 prefix: [1]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP]EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]   Network          Next Hop            Metric LocPrf Weight Path*> [2]:[0]:[48]:[00:16:9d:9e:dd:41]                    10.223.250.30                          0 4252968145 i                    RT:9425:20999 RT:9425:200000 ET:8 Rmac:44:38:39:be:ef:ac*> [2]:[0]:[48]:[00:22:56:ac:f3:42]:[32]:[10.223.255.1]                    10.223.250.30                          0 4252968145 i                    RT:9425:20999 RT:9425:200000 ET:8 Rmac:44:38:39:be:ef:ac

Заключение

Как итог, мы получили готовую VXLAN/EVPN фабрику. В Underlay у нас Unnumbered BGP и больше ничего, а в качестве Overlay мы имеем VXLAN/EVPN c Symmetric IRB, чего для решения наших задач в ЦОД более чем достаточно. Данный дизайн так же можно растянуть и на сами сервера, что бы строить туннели непосредственно с них.

Конечно, я не затронул всех возможных дизайнов по типу маршрутизации на Spine, но такой цели и не преследовалось. Надеюсь, статья кому-нибудь придётся по душе и будет полезна в планировании или эксплуатации собственного ЦОД. В случае, если есть идеи по улучшению или заметили критическую ошибку, прошу в комментарии.

Подробнее..

VxLAN фабрика часть 5. Multisite

12.04.2021 14:15:58 | Автор: admin

Привет, Хабр! Наконец заканчиваю цикл статей,посвященных запуску курса"Дизайнер сетей ЦОД"от OTUS, по технологии VxLAN EVPN. И сегодня обсудим реализацию подключений различных ЦОД или сайтов.

Предыдущие части цикла можно найти по ссылкам:

1 часть цикла - L2 связанность между серверами
2 часть цикла - Маршрутизация между VNI
2.5 часть цикла - Теоретическое отступление
3 часть цикла - Подключение внешнего маршрутизатора/firewall
4 часть цикла - Multipod



Сегодня рассмотрим второй способ подключение различных ЦОД - Multisite.

Для начала вспомним как строится Underlay при построении фабрики с помощью Multipod. И снова получаем несколько вариантов построения такой сети. То есть:

  1. Underlay сеть может быть единой и, например, использовать OSPF для IP связанности между всеми устройствами в фабрике.

  2. Underlay повторяет логику BGP для настройки EVPN и каждый POD находится в своей AS, как показано на рисунке ниже

Однако, вспоминая предыдущую часть, приходим к тому, что во всех случаях возникают свои проблемы. Так в 1 случае, при едином OSPF процессе, может появиться слишком большое количество устройств (например более 100-150 устройств) и динамическая маршрутизация станет работать заметно медленнее и больше нагружать сетевые устройства. Во 2-м случае возникает еще больше проблем (ниже указаны не все проблемы, а только основные):

  1. Смена Next-Hop. С использованием eBGP, при выходе update из AS, Next-hop меняется. То есть не забываем делать соответствующие настройки;

  2. Общая проблема для обоих случаев - значение Route-target в автоматическом режиме работать не будет. То есть необходимо использовать статическую настройку, однако это решается автоматизацией таких настроек и сети в целом;

  3. С увеличением количества клиентов, увеличивается и количество MAC/IP адресов и BUM трафик соответственно.

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

Для начала обсудим какие преимущества дает сегментация сети:

  1. Уменьшение домена рассылки Broadcast для поиска какого-либо клиента сети;

  2. Упрощается объединение различных подов через сеть интернет;

  3. Проблемы в одном сайте никак не влияют на другой сайт;

  4. Так как теперь каждый сайт независим от другого, то возможно использовать на одном сайте ingress replication, а на другом Multicast. То есть ЦОДы с различными технологиями объединяются без каких-либо проблем миграции.

Осталось разобраться как работает данная технология. Для начала рассмотрим теоретическую часть.

При реализации Multisite в сети появляется еще одна роль устройства - BGW(Border Gateway), которая может быть присвоена Spine, а может стать отдельным устройством в сети. В логической схеме дополнительное устройство встраивается выше Spine, как показано на рисунке ниже:

Но на самом деле, поставить BGW возможно в любое место в сети, главное обеспечить IP связанность

Осталось разобраться как же это все работает. Однако, для начала вернемся к предыдущим частям и вспомним как все работает в рамках одного POD. В одном POD тоннель устанавливается напрямую между VTEP, как показано ниже и LEAF коммутаторы напрямую обмениваются информацией о MAC/IP адресах.

То есть каждый LEAF должен знать о всех VTEP находящихся в его сети.
Теперь, когда вспомнили как работает сеть в рамках одно пода или нескольких, можем перейти к логике Multisite. Для начала приведу общую схему с логикой работы сети. Объяснение происходящего приведу ниже.

Получается что в Multisite тоннель от Leaf строится до BGW, далее BGW строит совершенно другой тоннель до второго BGW, находящего на другом сайте, и далее строится еще один тоннель уже в рамках другого сайта. Именно такая логика работы, когда между сайтами строится отдельный тоннель, позволяет сегментировать сеть, упростить поиск и устранение неисправностей, так как удаленный сайт полностью скрывается за 1 устройством(но рекомендуется использовать как минимум 2 BGW на каждом сайте для отказоустойчивости). Далее перейдем к настройке BGW, так как все остальные устройства не меняют свою настройку и никакие изменения на них не совершаются. Для начала на BGW необходимо включить следующие feature:

feature ospf - для организации Underlay в своем сайте

Настройка самой Underlay сети в данном разделе рассматриваться не будет, так как ничем не отличается от обычной реализации пода. При этом для IP связанности так же можно использовать IP unnumbered или адреса на point-to-point линках с маской /30 или /31.

После настройки Uderlay сети на BGW необходимо указать интерфейс, который смотрит в локальный сайт:

Interface Ethernet1/50description SITE-INTERNALevpn multisite fabric-tracking - указываем где находится локальный сайт

Далее готовим настройки для Overlay сети. Выглядят они практически аналогично настройкам на Leaf коммутаторах. В целом это логично, так как BGW так же имеет роль VTEP.

feature bgpfeature nv overlaynv overlay evpn

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

evpn multisite border-gateway <site-id> номер сайта одинаковый у всех BGW в одном сайте

Продолжаем настройку BGW и создаем интерфейс NVE

interface nve1  host-reachability protocol bgp  source-interface loopback1 - как и на LEAF, интерфейс используется для построения тоннеля в рамках своего сайта  multisite border-gateway interface loopback100 - новая настройка, используется для построения тоннеля между сайтами

Если у вас есть несколько BGW(а их должно быть хотя бы 2), то loopback100 должен иметь одинаковый адрес на всех устройствах с этой ролью - anycast адрес для сайта

Далее настраиваем протокол BGP для работы в локальном сайте. Настройка ничем не отличается от настройки на других устройствах в сетевой фабрике:

router bgp 65501  neighbor 10.100.100.201    remote-as 65501    update-source loopback0    address-family l2vpn evpn      send-community      send-community extended   neighbor 10.100.100.202    remote-as 65501    update-source loopback0    address-family l2vpn evpn      send-community      send-community extended

На данном этапе мы произвели настройки необходимые для первого тоннеля между LEAF и BGW

Переходим ко второй части настройки - тоннель между сайтами. Сразу уточню, что этот тоннель всегда должен работать только в режиме ingress replication.

interface Ethernet1/1  evpn multisite dci-tracking - команда указания, что интерфейс является внешним локального сайта и смотрит в сторону второго сайта

Последнее, что осталось настроить - BGP соседство со вторым сайтом:

router bgp 65501  neighbor 10.52.52.52 - удаленный сосед    remote-as 65036    update-source loopback0 - устанавливаем так же с loopback    ebgp-multihop 5    peer-type fabric-external - указываем, что удаленный пир, относится к фабрике в другом сайте    address-family l2vpn evpn      send-community      send-community extended      rewrite-evpn-rt-asn - Так как можем использоваться автоматическая настройки RT, то его необходимо изменить на новое значение

Напомню, что RT - это route-target и в автоматическом режиме формируется из двух значений AS:VNI

Аналогично необходимо завести всех остальных соседей в других сайтах. При этом необходимо настроить Full-Mesh между всеми маршрутизаторами с ролью BGW во всех сайтах. Либо возможно использовать Route-reflector в eBGP. Настройка RR выглядит следующим образом:

router bgp 65036  address-family l2vpn evpn    retain route-target all - принимаем все анонсы с любом RT  template peer OVERLAY-PEERING    update-source loopback0    ebgp-multihop 5    address-family l2vpn evpn      send-community both      route-map UNCHANGED out - запрещаем менять значение атрибута Next-Hop neighbor 10.100.100.21 remote-as 65501    inherit peer OVERLAY-PEERING    address-family l2vpn evpn      rewrite-evpn-rt-asn - так же переписываем значение RT, при автоматическом режиме установки RTroute-map UNCHANGED permit 10 - route-map в котором указываем запрет смены NH  set ip next-hop unchanged 

Этап выше настраивает тоннель между сайтами, как показано на рисунке ниже:

Настройка Multisite, закончена, однако предлагаю рассмотреть варианты работы нескольких BGW в одном сайте. На сегодняшний день доступно 3 вида подключения BGW:

  1. Вариант, что рассмотрели выше, без каких-либо настроек;

  2. VPC BGW - до 2-х устройств;

  3. Anycast BGW - до 4-х устройств.

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

Далее рассмотрим оставшиеся 2 подхода к реализации BGW и начнем с VPC BGW:

  • только 2 устройства с физическим Peer-link и keepalive link(возможно использовать виртуальный, однако с точки зрения надежности я бы рекомендовал использовать прямой физический канал), что добавляет еще больше линков, нежели в 1 варианте подключения;

  • Используется для небольших внедрений

Настройка VPC ничем не отличается от настройки VPC на Leaf коммутаторах. Так же требуется на интерфейсе Loopback создать secondary адрес, до которого будет строится VxLAN тоннель.

Anycast BGW и тут может возникнуть вопрос, чем же Anycast лучше. Разберемся по порядку. :

  • до 6 устройств BGW в одном сайте;

  • простой сценарий отработки проблем в сети, то есть все устройства независимы друг от друга, в отличии от VPC(да-да, там тоже разный Controle-Plane, однако это не спасает от багов);

  • сеть любой сложности;

  • простое развертывание с нуля устройств BGW, не влияя на сеть в целом.

То есть все устройства BGW Anycast прячутся за одним виртуальным адресом, как показано на рисунке ниже

Настройка мало чем отличается от реализации рассмотренной в начале данного материала:

 interface loopback100 - интерфейс указанный как multisite border-gateway description MULTI-SITE INTERFACE  ip address 10.10.10.10/32 - одинаковый адрес на всех BGW  ip router ospf UNDERLAY area 0.0.0.0 - IP связанность в рамках локального сайта

На этом настройка связанности между сайтами закончена. На момент написания данного материала не получается реализовать mulisite в виртуальной среде. На железе все запускается без особых проблем. Возможно в новых виртуальных образах ситуация исправлена.

Ниже предлагаю пройти опрос, на какой стадии использования VxLAN EVPN вы сейчас находитесь.

Подробнее про работу технологии можно посмотреть в RFC-7432 и в draft-ietf-bess-evpn-overlay, draft-ietf-bess-evpn-prefix-advertisement, draft-ietf-bess-evpn-inter-subnet-forwarding


Современная IT инфраструктура все больше виртуализируется, уплывая в Облака. Модели "все как сервис"- SaaS, PaaS, IaaS используются повсеместно, но все эти решения, по-прежнему используют сети передачи данных и машинные ресурсы для их обработки. За последние 20 лет, сети ЦОД, претерпели множество изменений, с которыми попробуем познакомиться ближе и разобрать основные технологические этапы этой эволюции с присущими им технологиями и архитектурными решениями в рамках бесплатного демо-урока по теме: "Эволюция сетевых технологий в ЦОД".

Записаться на демо-урок

Подробнее..

Huawei настройка VXLAN фабрики

17.04.2021 20:18:06 | Автор: admin

Привет Хабр!

В данной статье хочу поделиться настройкой VXLAN фабрики на оборудовании Huawei. На Хабре, да и на других ресурсах довольно подробна описана технология, как работает control plan, data plane, архитектура и т.д., поэтому в этой статье будет приведена настройка коммутатора с некоторыми пояснениями. Любая критика приветствуется. Для тестирования конфигурации появилась возможность добавить в EVE-NG коммутатор Huawei CE12800. За подробностями сюда и сюда. Data plane к сожалению там работает плохо, но control plane хорошо и не поддерживается часть функционала (m-lag, L3VXLAN например).

Общее описание схемы и подготовка underlay

В фабрике будет использоваться 2 Spine и 4 Leaf (2 из которых объединены в m-lag пару). Между Spine и Leaf коммутаторами используются point to point подсети с 31 маской и увеличен MTU. Используется симметричный IRB. Spine коммутаторы так же будут выполнять роль BGP route reflector. Инкапсуляция и деинкапсуляция будет производиться на Leaf коммутаторах.

Начну с настройки m-lag пары leaf коммутаторов, для правильной работы нужен keepalive линк и peer линк. По peer линку может идти полезная нагрузка поэтому необходимо учитывать полосу пропускания этого линка. Так же следует учитывать, что m-lag в исполнении Huawei накладывает некоторые ограничения, например нельзя построить ospf соседство через агрегированный интерфейс (или можно но с костылями):

dfs-group 1 priority 150 source ip 192.168.1.1 # IP адрес keepalive линка#stp bridge-address 0039-0039-0039 #для правильной работы STP задаем одинаковый bridge id#lacp m-lag system-id 0010-0011-0012 #задаем system id для LACP#interface Eth-Trunk0 #создаем peer линк trunkport INTERFACE #добавляем интерфейс в LAG  stp disable mode lacp-static peer-link 1#interface Eth-Trunk1 #пример агрегированного интерфейса в сторону сервера например  mode lacp-static dfs-group 1 m-lag 1

Проверяем, что m-lag пара собралась:

<Leaf11>disp dfs-group 1 m-lag*                : Local nodeHeart beat state : OKNode 1 *  Dfs-Group ID   : 1  Priority       : 150  Address        : ip address 192.168.1.1  State          : Master  Causation      : -  System ID      : fa1b-d35c-a834  SysName        : Leaf11  Version        : V200R005C10SPC800  Device Type    : CE8861EINode 2  Dfs-Group ID   : 1  Priority       : 120  Address        : ip address 192.168.1.2  State          : Backup  Causation      : -  System ID      : fa1b-d35c-a235  SysName        : Leaf12  Version        : V200R005C10SPC800  Device Type    : CE8861EI  <Leaf11>disp dfs-group 1 node 1 m-lag brief* - Local nodeM-Lag ID     Interface      Port State    Status                Consistency-check       1     Eth-Trunk 1    Up            active(*)-active      --

Пример настройки интерфейса внутри фабрики:

interface GE1/0/0undo portswitch  #переводим интерфейс в режим L3undo shutdown  #административно включаем интерфейсip address 192.168.0.1 31ospf network-type p2p #меняем тип OSPF интерфейса на point-to-point mtu 9200 #увеличиваем MTU интерфейса

В качестве underlay протокола маршрутизации используется OSPF:

ospf 1 router-id 10.1.1.11area 0.0.0.0 network 10.1.1.1 0.0.0.0 #анонсируем anycast lo только с m-lag пары  network 10.1.1.11 0.0.0.0 network 192.168.0.0 0.0.255.255

Так же в качестве протокола маршрутизации можно использовать два BGP процесса, один для underlay маршрутизации и второй для overlay маршрутизации.

bgp AS_UNDERLAY #процесс для underlay маршрутизации <settings>bgp AS_OVERLAY instance EVPN_NAME #процесс для overlay маршрутизации <settings>

С базовыми настройками закончили, проверим, что OSPF собрался и маршруты балансируются между Spine коммутаторами.

<Leaf11>disp ospf peer briefOSPF Process 1 with Router ID 10.1.1.11                   Peer Statistic InformationTotal number of peer(s): 2 Peer(s) in full state: 2----------------------------------------------------------------------------- Area Id         Interface                  Neighbor id          State 0.0.0.0         GE1/0/0                    10.1.1.100           Full 0.0.0.0         GE1/0/1                    10.1.1.101           Full-----------------------------------------------------------------------------

Соседство собралось, проверим маршрутную информацию:

<Leaf11>disp ip routing-table protocol ospfProto: Protocol        Pre: PreferenceRoute Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route------------------------------------------------------------------------------_public_ Routing Table : OSPF         Destinations : 11       Routes : 13OSPF routing table status : <Active>         Destinations : 8        Routes : 10Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface       10.1.1.2/32  OSPF    10   2             D   192.168.0.8     GE1/0/1                    OSPF    10   2             D   192.168.0.0     GE1/0/0       10.1.1.3/32  OSPF    10   2             D   192.168.0.8     GE1/0/1                    OSPF    10   2             D   192.168.0.0     GE1/0/0      10.1.1.12/32  OSPF    10   2             D   192.168.0.8     GE1/0/1                    OSPF    10   2             D   192.168.0.0     GE1/0/0     10.1.1.100/32  OSPF    10   1             D   192.168.0.0     GE1/0/0     10.1.1.101/32  OSPF    10   1             D   192.168.0.8     GE1/0/1

Подготовка overlay

Для начала необходимо глобально включить поддержку EVPN на коммутаторе:

evpn-overlay enable

Spine коммутаторы выполняют роль Route-reflector. Плюс нужно добавить строку undo policy vpn-target в соответствующей address family, чтобы Spine смог принять все маршруты и переслать их клиентам. Соседство строим на loopback адресах.

bgp 65000 group leafs internal peer leafs connect-interface LoopBack0 peer 10.1.1.11 as-number 65000 peer 10.1.1.11 group leafs peer 10.1.1.12 as-number 65000 peer 10.1.1.12 group leafs peer 10.1.1.2 as-number 65000 peer 10.1.1.2 group leafs peer 10.1.1.3 as-number 65000 peer 10.1.1.3 group leafs # ipv4-family unicast  undo peer leafs enable  undo peer 10.1.1.11 enable  undo peer 10.1.1.12 enable  undo peer 10.1.1.2 enable  undo peer 10.1.1.3 enable # l2vpn-family evpn  undo policy vpn-target  peer leafs enable  peer leafs reflect-client  peer 10.1.1.11 enable  peer 10.1.1.11 group leafs  peer 10.1.1.12 enable  peer 10.1.1.12 group leafs  peer 10.1.1.2 enable  peer 10.1.1.2 group leafs  peer 10.1.1.3 enable  peer 10.1.1.3 group leafs

На Leaf коммутаторах настраиваем нужный address family. Для m-lag пары хочется сделать политику подменяющую next-hop на anycast loopback ip адрес, но без такой политики все работает. Huawei подменяет next-hop адрес на адрес который указан в качестве source ip адреса интерфейса NVE. Но если вдруг возникнут проблемы с автоматической подменой всегда можно навесить политику руками:

bgp 65000 group rr internal peer rr connect-interface LoopBack0 peer 10.1.1.100 as-number 65000 peer 10.1.1.100 group rr peer 10.1.1.101 as-number 65000 peer 10.1.1.101 group rr # ipv4-family unicast  undo peer rr enable  undo peer 10.1.1.100 enable  undo peer 10.1.1.101 enable # l2vpn-family evpn  policy vpn-target  peer rr enable  peer 10.1.1.100 enable  peer 10.1.1.100 group rr  peer 10.1.1.101 enable  peer 10.1.1.101 group rr

Проверяем, что overlay control plane собрался:

<Leaf11>disp bgp evpn peer BGP local router ID        : 10.1.1.11 Local AS number            : 65000 Total number of peers      : 2 Peers in established state : 2  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State  PrefRcv  10.1.1.100      4       65000    12829    12811     0 0186h15m Established        0  10.1.1.101      4       65000    12844    12822     0 0186h15m Established        0  <Leaf11>disp bgp evpn peer 10.1.1.100 verbose #лишние строки удалены для сокращения вывода BGP Peer is 10.1.1.100,  remote AS 65000 Type: IBGP link Update-group ID: 2 Peer optional capabilities:  Peer supports bgp multi-protocol extension  Peer supports bgp route refresh capability  Peer supports bgp 4-byte-as capability  Address family L2VPN EVPN: advertised and received

Подготовка L2 VXLAN

Сперва создадим NVE интерфейс отвечающий за инкапсуляцию/деинкапсуляцию пакетиков:

interface Nve1 #создаем NVE интерфейс source 10.1.1.1 #для m-lag пары используем anycast ip адрес mac-address 0000-5e00-0199 #обязательно для m-lag пары на обоих коммутаторах настраиваем одинаковый MAC адрес, это необходимо для работы L3 VXLAN

Для организации L2 VXLAN необходимо создать bridge-domain и примапить к нему vlan, l2 подинтефейс или интерфейс целиком. К одному bridge-domain могут быть примаплены разные VLANs.

bridge-domain 150 #создаем bridge-domainvlan 150 access-port interface Eth-Trunk12 #можно мапить vlan в конфигурации bridge-domain, а можно в создавать l2 подинтерфейс vxlan vni 22150 #определяем vni evpn #создаем evpn instance  route-distinguisher 10.1.1.11:22150  vpn-target 65000:22150 export-extcommunity  vpn-target 65000:23500 export-extcommunity #этот rt нужен в будущем для L3 VXLAN  vpn-target 65000:22150 import-extcommunity#interface GE1/0/9.150 mode l2 #создаем подинтерфейс encapsulation [default,dot1q,untag,qinq] #выбираем тип инкапсуляции bridge-domain 150 #мапим к нужному bridge-domain#interface Nve1  vni 22150 head-end peer-list protocol bgp #определяем, что для BUM трафика будет использоваться ingress replication list с автообнаружением по BGP

Проделываем такую же работу на остальных коммутаторах и проверяем работу. На коммутаторах должны появиться EVPN маршруты типа 3:

<Leaf11>disp evpn vpn-instance name 150 verbose VPN-Instance Name and ID : 150, 1  Address family evpn  Route Distinguisher : 10.1.1.11:22150  Label Policy        : label per instance  Per-Instance Label  : 16,17  Export VPN Targets  : 65000:22150 65000:23500  Import VPN Targets  : 65000:22150#<Leaf11>disp bgp evpn vpn-instance 150 routing-table inclusive-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,               h - history,  i - internal, s - suppressed, S - Stale               Origin : i - IGP, e - EGP, ? - incomplete   EVPN-Instance 150: Number of Inclusive Multicast Routes: 3       Network(EthTagId/IpAddrLen/OriginalIp)                 NextHop *>    0:32:10.1.1.1                                          0.0.0.0 *>i   0:32:10.1.1.2                                          10.1.1.2 * i                                                          10.1.1.2

Посмотрим попристальнее на анонс полученный от соседа:

<Leaf11>disp bgp evpn vpn-instance 150 routing-table inclusive-route 0:32:10.1.1.2 BGP local router ID : 10.1.1.11 Local AS number : 65000   EVPN-Instance 150: Number of Inclusive Multicast Routes: 2 BGP routing table entry information of 0:32:10.1.1.2: Route Distinguisher: 10.1.1.2:22150 Remote-Cross route Label information (Received/Applied): 22150/NULL #видим нужный нам vni From: 10.1.1.100 (10.1.1.100) Route Duration: 7d19h17m35s Relay Tunnel Out-Interface: VXLAN Original nexthop: 10.1.1.2 Qos information : 0x0 Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>, Tunnel Type <VxLan> AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Originator: 10.1.1.2 PMSI: Flags 0, Ingress Replication, Label 0:0:0(22150), Tunnel Identifier:10.1.1.2 Cluster list: 10.1.1.100 Route Type: 3 (Inclusive Multicast Route) Ethernet Tag ID: 0, Originator IP:10.1.1.2/32 Not advertised to any peer yet

BUM трафик должен ходить, можно приступать к проверке связности между хостами. Для этого с хоста VM1 пропингуем хост VM2:

ubuntu@test-vxlan-01:~$ ping 192.168.50.3PING 192.168.50.3 (192.168.50.3) 56(84) bytes of data.64 bytes from 192.168.50.3: icmp_seq=1 ttl=64 time=0.291 ms--- 192.168.50.3 ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.291/0.291/0.291/0.000 ms#ubuntu@test-vxlan-01:~$ ip neigh192.168.50.3 dev eth0 lladdr 00:15:5d:65:87:26 REACHABLE

В это время на сети должны появиться анонсы 2 типа. Проверим:

<Leaf11>disp bgp evpn vpn-instance 150 routing-table mac-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,               h - history,  i - internal, s - suppressed, S - Stale               Origin : i - IGP, e - EGP, ? - incomplete EVN-Instance 150: Number of Mac Routes: 3       Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)  NextHop*>i   0:48:0015-5d65-8726:0:0.0.0.0                          10.1.1.2 * i                                                          10.1.1.2 *>    0:48:0015-5df0-ed07:0:0.0.0.0                          0.0.0.0

Посмотрим анонс пристальнее:

<Leaf11>disp bgp evpn vpn-instance 150 routing-table mac-route 0:48:0015-5d65-8726:0:0.0.0.0 BGP local router ID : 10.1.1.11 Local AS number : 65000 EVN-Instance 150: Number of Mac Routes: 2 #два маршрута, потому что приходит от двух RR BGP routing table entry information of 0:48:0015-5d65-8726:0:0.0.0.0: Route Distinguisher: 10.1.1.2:22150 Remote-Cross route Label information (Received/Applied): 22150/NULL From: 10.1.1.100 (10.1.1.100) Route Duration: 0d00h07m19s Relay Tunnel Out-Interface: VXLAN Original nexthop: 10.1.1.2 Qos information : 0x0 Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>, Tunnel Type <VxLan> AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Route Type: 2 (MAC Advertisement Route) Ethernet Tag ID: 0, MAC Address/Len: 0015-5d65-8726/48, IP Address/Len: 0.0.0.0/0, ESI:0000.0000.0000.0000.0000 Not advertised to any peer yet

Проверяем CAM таблицу коммутатора:

<Leaf11>disp mac-add bridge-domain 150Flags: * - Backup       # - forwarding logical interface, operations cannot be performed based           on the interface.BD   : bridge-domain   Age : dynamic MAC learned time in seconds-------------------------------------------------------------------------------MAC Address    VLAN/VSI/BD   Learned-From        Type                Age-------------------------------------------------------------------------------0015-5d65-8726 -/-/150       10.1.1.2      evn                   -0015-5df0-ed07 -/-/150       Eth-Trunk1.150      dynamic             450-------------------------------------------------------------------------------Total items: 2

Подготовка L3 VXLAN

Настало время выпустить хосты за пределы своей подсети, для этого будем использовать distributed gateway.

Для начала создадим нужный VRF:

ip vpn-instance EVPN ipv4-family  route-distinguisher 10.1.1.11:23500  vpn-target 65000: 23500 export-extcommunity evpn  vpn-target 65000: 23500 import-extcommunity evpn vxlan vni 23500

В конфигурацию BGP Leaf коммутаторов добавляем анонс IRB:

bgp 65000l2vpn-family evpn  peer rr advertise irb

Создаем L3 интерфейс для маршрутизации в нужном VRF:

interface Vbdif150 #номер должен совпадать с номером bridge-domain ip binding vpn-instance EVPN ip address 192.168.50.254 24 mac-address 0000-5e00-0101 vxlan anycast-gateway enable arp collect host enable #генерация маршрута второго типа на основании arp записи

Повторяем конфигурации на других Leaf коммутаторах и проверяем:

<Leaf11>disp ip vpn-instance SDC-EVPN  VPN-Instance Name               RD                    Address-family  EVPN                        10.1.1.11:23500            IPv4<Leaf11>disp evpn vpn-instance name __RD_1_10.1.1.11_23500__ verbose VPN-Instance Name and ID : __RD_1_10.1.1.11_23500__, 2  Address family evpn  Route Distinguisher : 10.1.1.11:23500  Label Policy        : label per instance  Per-Instance Label  : 17,18  Export VPN Targets  : 65000 : 23500  Import VPN Targets  : 65000 : 23500

На некоторых моделях коммутаторов (лучше свериться с официальной документацией) необходимо создание специального сервисного интерфейса для продвижения L3 VXLAN трафика. Полоса этого интерфейса должна быть в два раза больше пиковой полосы для L3 VXLAN трафика. При наличии большого количества Vbdif интерфейсов (более 2 тысяч) требуется создание дополнительных сервисных интерфейсов.

interface Eth-TrunkXXX service type tunnel trunkport 40GE1/1/1

На этом настройка L3 VXLAN завершена. Проверим доступность между хостами из разных подсетей:

ubuntu@test-vxlan-01:~$ ping 192.168.51.1PING 192.168.51.1 (192.168.51.1) 56(84) bytes of data.64 bytes from 192.168.51.1: icmp_seq=1 ttl=63 time=0.508 ms--- 192.168.51.1 ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.508/0.508/0.508/0.000 ms

Связность есть, теперь проверим маршрутную информацию:

<Leaf11>disp arp interface Vbdif 150ARP timeout:1200sARP Entry Types: D - Dynamic, S - Static, I - Interface, O - OpenFlowEXP: Expire-time  src: Source ip   dst: Destination ipIP ADDRESS      MAC ADDRESS    EXP(M) TYPE/VLAN/CEVLAN   INTERFACE----------------------------------------------------------------------------------------192.168.50.254  0000-5e00-0101        I                  Vbdif150192.168.50.1    0015-5df0-ed07   15   D/150/-            Eth-Trunk1.150----------------------------------------------------------------------------------------Total:2         Dynamic:1       Static:0    Interface:1    OpenFlow:0Redirect:0#<Leaf1>disp bgp evpn vpn-instance 150 routing-table mac-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,               h - history,  i - internal, s - suppressed, S - Stale               Origin : i - IGP, e - EGP, ? - incomplete EVN-Instance 150: Number of Mac Routes: 7       Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)  NextHop *>    0:48:0000-5e00-0101:0:0.0.0.0                          0.0.0.0 * i                                                          10.1.1.2 * i                                                          10.1.1.2 *>i   0:48:0015-5d65-8726:32:192.168.50.3                    10.1.1.2 * i                                                          10.1.1.2 *>    0:48:0015-5df0-ed07:0:0.0.0.0                          0.0.0.0 *>    0:48:0015-5df0-ed07:32:192.168.50.1                    0.0.0.0

Появились маршруты второго типа включающие в себя IP адреса. Теперь проверим перетекли ли маршруты в нужный VRF:

<Leaf11>disp bgp evpn vpn-instance __RD_1_10.1.1.11_23500__ routing-table mac-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,               h - history,  i - internal, s - suppressed, S - Stale               Origin : i - IGP, e - EGP, ? - incomplete EVN-Instance __RD_1_10.1.1.11_23500__: Number of Mac Routes:        Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)  NextHop*>i   0:48:0015-5d65-8726:32:192.168.50.3                    10.1.1.2 * i                                                          10.1.1.2*>i   0:48:0015-5df0-ed08:32:192.168.51.2                    10.1.1.3 * i                                                          10.1.1.3#<leaf11>disp bgp evpn vpn-instance __RD_1_10.1.1.11_23500__ routing-table mac-route 0:48:0015-5d65-8726:32:192.168.50.3 BGP local router ID : 10.1.1.11 Local AS number : 65000 EVN-Instance __RD_1_10.1.1.11_23500__: Number of Mac Routes: 2 BGP routing table entry information of 0:48:0015-5d65-8726:32:192.168.50.3: Route Distinguisher: 10.1.1.2:23500 Remote-Cross route Label information (Received/Applied): 22150 23500/NULL #добавился L3 VNI From: From: 10.1.1.100 (10.1.1.100) Route Duration: 7d08h48m44s Relay Tunnel Out-Interface: VXLAN Original nexthop: 10.1.1.2 Qos information : 0x0 Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>Tunnel Type <VxLan>, Router's MAC <3864-0111-1200> #в качестве MAC адреса используется MAC адрес NVE интерфейса VTEPа AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Route Type: 2 (MAC Advertisement Route) Ethernet Tag ID: 0, MAC Address/Len: 0015-5d65-8726/48, IP Address/Len: 192.168.50.3/32, ESI:0000.0000.0000.0000.0000 Not advertised to any peer yet

Заключение

В данной статье я попытался описать процесс настройки EVPN VXLAN фабрики на базе оборудования Huawei и привести некоторые команды необходимые в процессе отладки.

Спасибо за внимание!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru