Привет, Хабр! Все еще заканчиваю цикл статей, посвященных запуску курса "Архитектор сетей" от OTUS, по технологии VxLAN EVPN. И сегодня обсудим реализацию подключений машинных залов или ЦОД в одну VxLAN фабрику  Предыдущие части цикла можно найти по ссылкам: Для начала определимся какие варианты подключения существуют: Да, вариантов не так много, однако их достаточно для решения поставленной задачи. Разберемся подробнее в каждом из способов. К уже знакомой ранее схеме, добавим второе подключение(второй ЦОД или второй машинный зал), в результате чего мы не можем подключить 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 адресах: И снова есть два варианта настройки 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: Значит и VxLAN тоннель будет строиться до этого же адреса. Но в сети появилась eBGP сессия, в которой адрес Next-Hop меняется при покидании update локальной AS. Поэтому нам потребуется дополнительная настройка на Spine и SS, которая будет запрещать смену NH адреса. Однако если мы говорим про Nexus, то данная настройка не так очевидна, как хотелось бы. Для начала потребуется создать route-map, который запрещает смену Next_hop адреса: Далее устанавливает route-map в сторону eBGP соседей: Как вы могли заметить 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 выглядела следующим образом: Route-target формируется автоматически на основе номер AS:VNI. В результате RT export для левой стороны — 65000:10000. Для правой — 65010:10000.
Так как правила import работают так же в автоматическом режиме — коммутатор не добавит маршрут с неизвестным RT в таблицу маршрутизации. Тут можно поступить следующим образом. Вместо автоматического режима настроить RT вручную: То же самое касается и l3 VNI(если необходимо): В результате на всех Leaf коммутаторах используется одинаковый RT, по которому маршрут будет добавлен в таблицу маршрутизации и появится связанность между конечными устройствами  Сетевой администратор