Что делать и куда бежать, если тебе нужно построить сеть на несколько ЦОД, с L2 связностью между площадками, отказоустойчивостью и масштабированием. В этой статье предлагаю рассмотреть некоторые из возможных подходов к организации больших сетей с использованием VXLAN/EVPN.
В рамках данной статьи будут рассматриваться именно подходы к построению DCI (Data Center Interconnect). Поэтому предполагается, что читатель знаком с основными принципами работы сетей с VXLAN/EVPN.
В контексте VXLAN DCI на сегодня можно выделить три основных подхода для соединения ЦОД между собой:
Multipod - наиболее простой и понятный подход: имеем единый VXLAN домен, в котором туннели могут строиться между любыми VTEP. VXLAN туннель строится end-to-end.
VLAN Hand-off - более масштабируемый подход с парадигмой один ЦОД один VXLAN домен, но накладывает большие требования к сети DCI, т.к. устройства DCI так же изучают всю маршрутную информацию. Используется несколько VXLAN туннелей(но не обязательно VXLAN и не обязательно туннели) для транспортировки трафика.
Multisite - большая масштабируемость, требования к DCI аналогичны подходу с multipod, но получаем vendor lock-in, т.к. реализации отличаются от вендора к вендору. Используется несколько VXLAN туннелей для транспортировки трафика.
Предлагаю подробней остановиться на каждом из них и далее собрать их в лабе.
Multipod
Архитектура Multipod - это способ разделения VXLAN-фабрики на несколько POD 'ов (Point of delivery). Обычно под PODом подразумевают отдельный ЦОД, но это может быть и просто обособленная часть сети, в которой большинство трафика не выходит за ее пределы (в рамках статьи считаем ЦОД=POD).
Если мы заглянем внутрь POD-а, то в каждом из них может быть своя Underlay сеть. Например, в одном ЦОД у вас eBGP, а в другом OSPF. Но вот что касается Overlay сети, то она у вас единая, соответственно, каждое устройство в сети имеет полную таблицу нужных ему маршрутов BGP EVPN.
Благодаря такому распространению маршрутов мы получаем все плюшки от использования EVPN с VXLAN, как оно изначально и задумывалось. Каждый VTEP знает о всех других VTEP и их MAC/IP маршрутах. Это позволяет без проблем простроить VXLAN туннель между конечными точками. Благодаря этому схема прохождения трафика от точки А до точки В становится максимально понятной.
Если взглянуть на схему, то видим что LEAF1, к которому подключен SRV1, строит туннель сразу до LEAF2 в другом ЦОД, т.к. он обладает всеми EVPN маршрутами и знает, что MAC SRV2 живет за LEAF2.
Пока мы не ушли далеко: чтобы не прыгать между разными формулировками пограничных устройств в архитектурах (Border Leaf / Border Gateway), я буду везде использовать термин из Multisite — BGW (Border Gateway).
Варианты соединения ЦОД
Используя Multipod, у нас нет каких-то жестких ограничений по соединению ЦОД друг с другом, но давайте рассмотрим самые часто используемые.
Прямое соединение ЦОД
Самый простой и часто используемый вариант - прямой стык на одном из уровней Super Spine/Spine/Leaf, без каких-либо промежуточных L3 устройств. Тут может быть множество вариантов DWDM/ Прямые оптические линки / L2 через какую либо транспортную сеть / Pseudo-wire и т.д.
Как правило, в такой схеме каждый ЦОД живет в своей AS. Это удобно, т.к. позволяет развязывать IGP процессы, настраивать политики маршрутизации, фильтровать маршруты на стыках и т.д. Но стоит уточнить, что это не обязательное требование, тут все зависит от вашей фантазии. На стыке через DCI может быть и ISIS/OSPF, и пириться вы можете с Loopback по Multihop. А может, захочется загнать все ЦОД в одну AS и упражняться с Full-Mesh или несколькими кластерами RR.
Каким бы ни было решение, его главная задача - выполнить 2 пункта: каждый Leaf должен знать все EVPN маршруты и как добраться до Next-Hop, которые в них фигурируют.
Важное замечание: при передаче маршрутов в схеме с Multipod, Next-Hop EVPN маршрутов не изменяется, поэтому underlay маршруты должны до нас долетать в каком-то виде, будь то IGP или BGP.
Использование вышестоящей транспортной сети
Данное соединение может вам понадобиться, если у вас есть какое-либо ядро сети, в котором может быть как MPLS, так и чистый IP, которое соединяет ЦОДы между собой.
При использовании данной схемы у нас начинается разделение того, как мы получаем ту или иную маршрутную информацию, т.к. промежуточная транспортная сеть зачастую ничего не знает, да и не хочет знать о ваших VXLAN, и передать через нее EVPN маршруты не всегда получится. Единственное, что нам нужно от транспортной сети, это доставить наши underlay адреса, которые нам необходимы для 2 вещей:
Возможность установить Multihop BGP EVPN соседство между пограничными устройствами
Возможность добраться до всех Next-Hop, которые нам прилетели в EVPN маршрутах
Так же важно не забыть про MTU на всем пути прохождения трафика, в том числе через транспортную сеть, потому что далеко не все вендора могут собрать обратно фрагментированные VXLAN пакеты.
Резюме
Использование Multipod - хороший способ собрать несколько ЦОД в одну VXLAN фабрику:
Каждый ЦОД может жить в своей AS и использовать свою underlay-сеть.
Единая Overlay сеть, благодаря чему все Leaf'ы получают полную таблицу маршрутов и знают как дойти до всех VTEP.
Стыки между ЦОД могут быть выполнены в любом количестве и на любых устройствах VXLAN фабрики.
Но данный подход хорошо работает на сети размером до 100 Leaf. Если вы на моменте планирования понимаете, что ваша цифра сильно выше, то нужно начинать задумываться о других подходах к решению, так как есть множество свичей с ограничением в <=128 VTEP Peers (у большинства популярных моделей Cisco N9K это 256, что является тоже вполне достижимым числом). Также появляются вопросы по количеству BUM трафика, который в случае Ingress Replication будет уже сильно ощутимым.
VLAN Hand-off
Теперь я предлагаю остановиться на более масштабируемой архитектуре - VLAN Hand-off. Если вернуться к нашим POD из прошлого раздела, то данная архитектура подразумевает передачу чистых L2 пакетов на стыках между POD. Это значит, что передача пакетов с инкапсуляцией в VXLAN у нас будет происходить только внутри PODа, а на выходе мы имеем обычный L2 Trunk. Как видно на схеме ниже, у нас появляется несколько VXLAN туннелей, но они не выходят за переделы ЦОД, а заканчиваются на Border Leaf.
Благодаря такому разграничению, мы получаем изолированные таблицы BGP EVPN в каждом из ЦОД, что радикально снижает количество маршрутов. Что касается DCI - это может быть все что угодно (VXLAN,MPLS,etc), его главная цель обеспечить L2 связность между всеми Border Leaf. И далее Border Leaf, используя классический механизм Flood and Learn, будет учить MAC адреса из других ЦОД через классический L2 порт.
Соответственно, мы получаем следующий путь пакета от SRV1 до SRV2. Пакет приходит на LEAF1, дальше строится VXLAN туннель до BGW1. BGW1 передает пакет без дополнительных заголовков в L2 транк до BGW2. BGW2, получив пакет, строит свой VXLAN туннель и отправляет пакет в LEAF2.
DCI и VLAN Hand-off
Давайте подробней рассмотрим роль DCI в данной схеме. Если в схеме с Multipod, DCI должен был просто доставить маршруты Loopback, то здесь на него ложится совсем другая нагрузка. Для эффективной передачи пакетов он должен держать в своих таблицах всю L2 информацию всех ЦОД. Следующим важным пунктом становится отказоустойчивость стыка с DCI. Как только мы ушли от механизмов защиты от петель VXLAN и перешли к чистому L2 у нас появляется вопрос: "А как это соединить, чтобы и резерв был, и чтобы шторма не было?". И тут сразу к нам приходят схемы с Multihoming или MLAG со стороны ЦОД, эти решения понятны, обкатаны и позволяют легко сделать Active/Active, но не факт что это возможно со стороны DCI и может так случиться, что со стороны ЦОД вы соберете отказоустойчивую и балансируемую схему, а со стороны DCI у вас будет VPLS c Active/Standby или какие-нибудь Standalone L2 устройства.
L3 информация
Пункт с передачей L3 может быть и необязательным, если у вас нет терминации сетей на VXLAN-фабрике, а все терминируется на каком-нибудь фаерволе, и фабрика работает в чистом L2 режиме. При такой схеме VLAN Hand-off получается наиболее простым.
В случае если какая-то маршрутизация все-таки нужна, то нужно будет поднимать маршрутизацию на SVI/SUB между Border Leaf во всех ЦОД, или маршрутизироваться через DCI. Зачастую маршрутизация требуется если какие-то из сетей у вас живут в нерастянутом виде и существую только в одном или нескольких ЦОД. Еще можно будет сэкономить на маршрутной информации, передавая префиксы вместо хостовых маршрутов, которые передаются в EVPN Route Type 2.
Резюме
По итогу при использовании VLAN Hand-off мы уходим от проблем масштабируемости, которые у нас были при использовании Multipod, т.к. домен, где передается какая-либо маршрутная информация по EVPN, ограничивается одним ЦОД, а DCI для нас это просто еще какой-то линк, с которого летят маки, и нам уже без разницы сколько там устройств, нам даже не нужна никакая информация об Underlay другого ЦОД. Единственным ограничителем для коммутаторов ставится размер MAC таблицы.
Так же данная архитектура дает нам соединять ЦОД с любыми технологиями внутри, т.к. на стыках у нас чистый L2 пакет. В ЦОД1 у вас может быть Legacy L2 архитектура, в ЦОД2 Cisco ACI , а в ЦОД3 VXLAN на Huawei и все это будет прекрасно работать.
Еще моменты, на которые стоит обратить внимание:
В случае если сравнивать VLAN Hand-off с Ingress Replication и Multipod с Ingress Replication, мы сильно уменьшим количество BUM на DCI, т.к. нам не нужно реплицировать пакеты на множество Leaf в других ЦОД, а отправить только один пакет в Trunk.
И снова MTU. В данной схеме даже некому будет фрагментировать пакеты, поэтому MTU должен быть согласован на всем пути.
Multisite
Основное название прижилось от Cisco, но есть аналоги у Arista (EVPN Multi-Domain VXLAN), Huawei (Segment VXLAN) и других больших вендоров, сама история с использованием Multisite достаточно вендор-зависимая, но теоретически может получиться вполне себе рабочая история если добавить пару костылей.
При использовании данной архитектуры мы получаем что-то среднее между Multipod и VLAN Hand-off. Внутри одного ЦОД, как и в других решениях, у нас нет каких-либо изменений, вся магия данного подхода кроется в работе BGW коммутаторов, на которые теперь возлагается больший функционал, чем это было в Multipod или VLAN Hand-off.
Основная задача BGW состоит в следующем:
Получение EVPN маршрутов (Type 2/5) из своего ЦОД.
Выполнение re-originate этих маршрутов от себя и анонс к BGW в других ЦОД. На данном этапе происходит изменение Next-Hop и другие ЦОД видят как VTEP уже BGW, а не изначальный LEAF.
Аналогично работает получение маршрутов из других ЦОД, и передача в свой ЦОД с Next-Hop себя.
Соответственно, мы получаем некоторое разделение доменов VXLAN. Leaf1 знает о VTEP только своего ЦОД и ничего не знает о существовании ЦОД2, т.к. BGW пересоздает маршруты от себя. В свою очередь у BGW есть маршруты до всех LEAF в своем ЦОД и маршруты, до всех BGW других ЦОД (BGW не видят LEAF коммутаторы других ЦОД, все маршруты указывают на другие BGW, которые сделали re-originate маршрутов от себя). В итоге если взглянуть на схему мы получаем 3 VXLAN туннеля:
Туннель LEAF1 к BGW1 внутри ЦОД
Туннель BGW1 к BGW2 через DCI
Туннель BGW2 к LEAF2 в ЦОД2
Соответственно, у нас на всех этапах прохождения трафика будут VXLAN туннели. Важным обязательным условием в Multisite является eBGP Full Mesh связность между BGW (или схема с Route Server в DCI), т.к. тут начинает работать правило Multisite Split Horizon, полученное от BGW, другим BGW не отдавай, что защищает от петель. Все соседства между BGW зачастую строятся с Loopback, но это не является обязательным условием.
Еще несколько моментов, которые хотел бы упомянуть:
В зависимости от вендора, помимо переписания Next-Hop, BGW еще могут переписывать RT при получении маршрутов из других ЦОД или использовать на DCI другие VXLAN VNI.
Передача маршрутов 1 и 4 в другие ЦОД не производится, т.к. в этом нет смысла, все спрятано за BGW. Маршруты типа 3 BGW создает свои.
Решения по отказоустойчивости BGW так же могут отличаться между вендорами, кто-то умеет в Anycast, а кто-то в MLAG.
Резюме
Оба подхода и Multisite, и VLAN Hand-off сильно увеличивают масштабируемость растянутых VXLAN сетей на большое количество ЦОД благодаря уменьшению устройств в одном BGP EVPN домене. Если в случае c VLAN Hand-off вы разрываете весь Overlay, то в Multisite маршрутная информация Overlay остается в полном виде, но BGW изменяет ее, подставляя себя как Next-Hop, таким образом, маскируя весь свой/чужой ЦОД на себя.
Также стоит выделить что Multisite не налагает никаких специфичных ограничений на DCI, если в VLAN Hand-off нам нужно было думать как соединить ЦОД между собой и DCI должен был учить MAC адреса, то в случае с Multisite нам просто нужна IP связность между BGW.
Нужно немного добавить ложки дегтя: все решения Multisite это vendor lock-in в том или ином виде. Иногда, добавив некоторое количество костылей, можно будет скрестить Huawei Segment VXLAN с Cisco Multisite. Но чтобы все работало нативно и стабильно, нужны все BGW коммутаторы одного вендора, хотя стандартные LEAF могут быть и мультивендорными.
Собираем Лабу
Давайте теперь посмотрим на все это вживую, настроим каждое из решений и посмотрим на то, как будет распространятся маршрутная информация и ходить трафик.
Первым мы начнем с Multipod, лаба у нас будет состоять из 4 x Nexus 9300v 10.5.1F и 2 машинок, на которых будут просто навешены IP для запуска пингов, настроим стандартный VXLAN, на DCI у нас будет простая темная оптика.
Все, что касается настроек LEAF1 и LEAF2, они практически никак не будут меняться между схемами, все изменения будут только на BGW устройствах, поэтому основные настройки по типу iBGP внутри ЦОД и IGP протоколов мы сделаем только один раз и в следующих схемах будем уже только изменять текущие настройки.
Настройки внутри ЦОД
Включаем весь необходимый функционал NXOS
Настраивается на всех коммутаторах
feature bgp
feature nv overlay
feature vn-segment-vlan-based
feature interface-vlan
feature ospf
nv overlay evpn Настраиваем Lo и P2P интерфейсы
BGW-01
interface loopback0
description Router_ID
ip address 10.0.0.1/32
interface Ethernet 1/1
description to_LEAF01
no switchport
mtu 9216
ip address 10.1.0.1/31
no shutdown
interface Ethernet 1/2
description to_BGW02
no switchport
mtu 9216
ip address 10.1.0.2/31
no shutdown
LEAF-01
interface loopback0
description Router_ID
ip address 10.0.0.101/32
interface Ethernet 1/1
description to_BGW01
no switchport
mtu 9216
ip address 10.1.0.0/31
no shutdownBGW-02
interface loopback0
description Router_ID
ip address 10.0.0.2/32
interface Ethernet 1/1
description to_LEAF02
no switchport
mtu 9216
ip address 10.1.0.5/31
no shutdown
interface Ethernet 1/2
description to_BGW01
no switchport
mtu 9216
ip address 10.1.0.3/31
no shutdownLEAF-02
interface loopback0
description Router_ID
ip address 10.0.0.102/32
interface Ethernet 1/1
description to_BGW02
no switchport
mtu 9216
ip address 10.1.0.4/31
no shutdownНастраиваем OSPF для Underlay
BGW-01
router ospf UNDERLAY
router-id 10.0.0.1LEAF-01
router ospf UNDERLAY
router-id 10.0.0.101BGW-02
router ospf UNDERLAY
router-id 10.0.0.2LEAF-02
router ospf UNDERLAY
router-id 10.0.0.102На всех устройствах включаем OSPF на Eth1/1 и Lo0
interface Ethernet 1/1
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
interface loopback0
ip router ospf UNDERLAY area 0.0.0.0Проверяем что нам прилетели Loopback адреса соседа
LEAF-01# show ip route ospf-UNDERLAY
10.0.0.1/32 [BGW-01 Lo0], ubest/mbest: 1/0
*via 10.1.0.1, Eth1/1, 110/41, 00:02:59, ospf-UNDERLAY, intra
BGW-01# show ip route ospf-UNDERLAY
10.0.0.101/32 [Leaf-01 Lo0], ubest/mbest: 1/0
*via 10.1.0.0, Eth1/1, 110/41, 00:03:13, ospf-UNDERLAY, intra
LEAF-02# show ip route ospf-UNDERLAY
10.0.0.2/32 [BGW-02 Lo0], ubest/mbest: 1/0
*via 10.1.0.5, Eth1/1, 110/41, 00:00:51, ospf-UNDERLAY, intra
BGW-02# show ip route ospf-UNDERLAY
10.0.0.102/32 [Leaf-02 Lo0], ubest/mbest: 1/0
*via 10.1.0.4, Eth1/1, 110/41, 00:01:07, ospf-UNDERLAY, intraНастраиваем iBGP
BGW-01
router bgp 100
router-id 10.0.0.1
log-neighbor-changes
address-family ipv4 unicast
network 10.0.0.1/32
neighbor 10.0.0.101
description LEAF_01_Lo0
remote-as 100
update-source loopback0
address-family ipv4 unicast
next-hop-self
address-family l2vpn evpn
send-community extendedДавайте немного остановимся на конфигурации. Строкиaddress-family ipv4 unicast и network 10.0.0.101/32 нам нужны, т.к. между ЦОД у нас eBGP и нам нужно доставлять Loopback адреса между ЦОД, так же для iBGP соседа прописали next-hop-self.
LEAF-01
router bgp 100
router-id 10.0.0.101
log-neighbor-changes
address-family ipv4 unicast
network 10.0.0.101/32
neighbor 10.0.0.1
description BGW_01_Lo0
remote-as 100
update-source loopback0
address-family ipv4 unicast
next-hop-self
address-family l2vpn evpn
send-community extendedBGW-02
router bgp 200
router-id 10.0.0.2
log-neighbor-changes
address-family ipv4 unicast
network 10.0.0.2/32
neighbor 10.0.0.102
description LEAF_02_Lo0
remote-as 200
update-source loopback0
address-family ipv4 unicast
next-hop-self
address-family l2vpn evpn
send-community extendedLEAF-02
router bgp 200
router-id 10.0.0.102
log-neighbor-changes
address-family ipv4 unicast
network 10.0.0.102/32
neighbor 10.0.0.2
description BGW_02_Lo0
remote-as 200
update-source loopback0
address-family ipv4 unicast
next-hop-self
address-family l2vpn evpn
send-community extendedИ чтобы не выносить это отдельно, на всех устройствах настроим NVE интерфейс, который нам нужен для VXLAN
interface nve1
no shutdown
source-interface loopback0
host-reachability protocol bgpВсе, что мы настроили выше, это все Underlay и Overlay внутри ЦОД и эти настройки меняться уже не будут, т.к. все архитектуры по большей части меняют только настройки BGW. Далее давайте пока создадим наш L2 VNI и VRF (L3 VNI), а соседство между BGW поднимем в самом конце.
Создание L2 VNI
Настраивается на всех коммутаторах
vlan 101
name L2-VNI
vn-segment 10101
interface nve1
member vni 10101
ingress-replication protocol bgp
evpn
vni 10101 l2
rd auto
route-target both 10101:10101Стоит сразу уточнить что RT мы указываем вручную, т.к. ЦОД у нас 2 и каждый в своей AS. Режим route-target auto от Cisco работать не будет, он создает RT формата [Номер AS]:[VNI], который к нам не применим. Но мы вернемся к auto когда будем рассматривать Multisite.
После того, как мы настроили все, то уже будут видны Type3 маршруты между BGW и LEAF. В момент создания VNI и настройки Ingress Replication наши коммутаторы стали заинтересованы в BUM трафике этого VNI, и для того чтобы его получать они отправляют EVPN Type 3 маршрут.
LEAF-02# show bgp l2vpn evpn vni-id 10101
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.0.0.102:32868 (L2VNI 10100)
*>i[3]:[0]:[32]:[10.0.0.2]/88 10.0.0.2 100 0 i
*>l[3]:[0]:[32]:[10.0.0.102]/88 10.0.0.102 100 32768 iСоздание VRF (L3 VNI)
Настраивается на всех коммутаторах
Создаем сам VRF и вручную назначаем RT
vrf context MAIN
vni 100200
rd auto
address-family ipv4 unicast
route-target both 12:100200
route-target both 12:100200 evpnСоздаем VLAN и SVI для L3 VNI
vlan 3960
name L3-VNI-MAIN
vn-segment 100200
interface Vlan3960
description L3-VNI-MAIN
no shutdown
vrf member MAIN
no ip redirects
ip forwardАссоциируем VNI с VRF
interface nve1
member vni 100200 associate-vrfТеперь у нас все готово для подачи VLAN в хост и проверки доступности шлюза
Подключаем хосты
Т.к. мы хотим сделать одинаковый адрес шлюзов в разных ЦОД, то давайте пропишем на всем оборудовании Anycast MAC
fabric forwarding anycast-gateway-mac 0002.0002.0002Далее выполняем настройки на LEAF-01 & LEAF-02
Создаем SVI
interface Vlan101
description SRV
no shutdown
vrf member MAIN
ip address 192.168.0.1/24
fabric forwarding mode anycast-gatewayПодаем VLAN в порт
interface Ethernet 1/2
description SRV
switchport mode access
switchport access vlan 101Проверяем доступность шлюза с хоста
VPCS> show
NAME IP/MASK GATEWAY
VPCS1 192.168.0.100/24 192.168.0.1
VPCS> ping 192.168.0.1
84 bytes from 192.168.0.1 icmp_seq=1 ttl=255 time=20.270 ms
84 bytes from 192.168.0.1 icmp_seq=2 ttl=255 time=2.018 ms
84 bytes from 192.168.0.1 icmp_seq=3 ttl=255 time=1.546 ms
84 bytes from 192.168.0.1 icmp_seq=4 ttl=255 time=2.371 ms
84 bytes from 192.168.0.1 icmp_seq=5 ttl=255 time=4.551 ms
VPCS> Проверяем что в порту Eth 1/1 появился MAC и у нас есть ARP запись
LEAF-01# show mac address-table interface ethernet 1/2
---------+-----------------+--------+---------+------+----+------
* 101 0050.7966.6805 [SRV1 DC1] dynamic NA F F Eth 1/2
LEAF-01# show ip arp vrf MAIN
IP ARP Table for context MAIN
Total number of entries: 1
Address Age MAC Address Interface Flags
192.168.0.100 00:02:17 0050.7966.6805 Vlan101 И теперь мы должны увидеть EVPN Type 2 маршрут на BGW от LEAF
BGW-01# show bgp l2vpn evpn vni-id 10101 route-type 2
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.0.0.1:32868 (L2VNI 10101)
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6805]:[0]:[0.0.0.0]/216, version 14
Paths: (1 available, best #1)
Flags: (0x000212) (high32 00000000) on xmit-list, is in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop, in rib
Imported from 10.0.0.101:32868:[2]:[0]:[0]:[48]:[0050.7966.6805]:[0]:[0.0.0.0]/216
AS-Path: NONE, path sourced internal to AS
10.0.0.101 (metric 41) from 10.0.0.101 (10.0.0.101)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10101
Extcommunity: RT:10101:10101 ENCAP:8
Path-id 1 not advertised to any peer
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6805]:[32]:[192.168.0.100]/272, version 33
Paths: (1 available, best #1)
Flags: (0x000212) (high32 00000000) on xmit-list, is in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop, in rib
Imported from 10.0.0.101:32868:[2]:[0]:[0]:[48]:[0050.7966.6805]:[32]:[192.168.0.100]/272
AS-Path: NONE, path sourced internal to AS
10.0.0.101 (metric 41) from 10.0.0.101 (10.0.0.101)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10101 100200
Extcommunity: RT:12:100200 RT:10101:10101 ENCAP:8 Router MAC:5001.0000.1b08
Path-id 1 not advertised to any peerДавайте немного остановимся на этом выводе. В нем видно, что нам пришло 2 маршрута, один простой Type 2 MAC, второй Type 2 MAC+IP, т.к. мы настроили интерфейс как L3. Так же мы видим 2 RT12:100200и 10101:10101один от нашего L3 VNI и второй от L2 VNI.
На данном этапе у нас полностью настроен VXLAN внутри ЦОД, и если мы включим любой хост в BGW и настроим порт, то мы получим связь через VXLAN. Но статья у нас про несколько ЦОД, поэтому давайте поднимем связность между ЦОД и проверим, что хосты видят друг друга через DCI.
Настраиваем eBGP между BGW
Для начала нам на BGW нужно подготовить route-map, который будет сохранять неизменным Next-Hop при передаче его соседу. Это RM мы повесим на EVPN соседство.
route-map nh_unchanged permit 10
set ip next-hop unchangedА теперь поднимаем соседства
BGW-01
router bgp 100
neighbor 10.1.0.3
description BGW_02
remote-as 200
address-family ipv4 unicast
address-family l2vpn evpn
send-community extended
route-map nh_unchanged out Давайте немного остановимся на этой конфигурации, мы здесь поднимаем 2 семейства BGP: l2vpn для передачи EVPN маршрутов с route-map, которую мы создали ранее, и ipv4 для того чтобы доставить Loopback адреса LEAF коммутаторов. Давайте поднимем вторую сторону.
BGW-02
router bgp 200
neighbor 10.1.0.2
description BGW_01
remote-as 100
address-family ipv4 unicast
address-family l2vpn evpn
send-community extended
route-map nh_unchanged out Соседство должно было установится, давайте проверим маршруты на LEAF
LEAF-01# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i10.0.0.1/32 10.0.0.1 100 0 i
*>i10.0.0.2/32 10.0.0.1 100 0 200 i
*>l10.0.0.101/32 0.0.0.0 100 32768 i
*>i10.0.0.102/32 10.0.0.1 100 0 200 i
LEAF-02# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i10.0.0.1/32 10.0.0.2 100 0 100 i
*>i10.0.0.2/32 10.0.0.2 100 0 i
*>i10.0.0.101/32 10.0.0.2 100 0 100 i
*>l10.0.0.102/32 0.0.0.0 100 32768 iНу и проверим связность между Loopback
LEAF-02# ping 10.0.0.101 source 10.0.0.102
PING 10.0.0.101 (10.0.0.101) from 10.0.0.102: 56 data bytes
64 bytes from 10.0.0.101: icmp_seq=0 ttl=252 time=34.037 ms
64 bytes from 10.0.0.101: icmp_seq=1 ttl=252 time=12.728 ms
64 bytes from 10.0.0.101: icmp_seq=2 ttl=252 time=11.365 ms
64 bytes from 10.0.0.101: icmp_seq=3 ttl=252 time=11.574 ms
64 bytes from 10.0.0.101: icmp_seq=4 ttl=252 time=9.824 ms
--- 10.0.0.101 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 9.824/15.905/34.037 msОтлично! На этом этапе мы все полностью настроили, давайте теперь проверим связность между хостами и посмотрим в dump трафика
VPCS> show
NAME IP/MASK GATEWAY
VPCS1 192.168.0.100/24 192.168.0.1
VPCS> ping 192.168.0.200
84 bytes from 192.168.0.200 icmp_seq=1 ttl=64 time=21.974 ms
84 bytes from 192.168.0.200 icmp_seq=2 ttl=64 time=18.257 ms
84 bytes from 192.168.0.200 icmp_seq=3 ttl=64 time=40.663 ms
84 bytes from 192.168.0.200 icmp_seq=4 ttl=64 time=38.492 ms
84 bytes from 192.168.0.200 icmp_seq=5 ttl=64 time=22.457 msКак видим, пинги ходят, давайте посмотрим в таблицу MAC адресов на LEAF-01
LEAF-01# show mac address-table
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
* 101 0050.7966.6805 [SRV1 DC1] dynamic NA F F Eth1/2
C 101 0050.7966.6806 [SRV1 DC2] dynamic NA F F nve1(10.0.0.102) [LEAF-02]Оба мак адреса присутствуют, один локальный, второй доступен через nve интерфейс. Давайте посмотрим маршрут на LEAF-01 до 0050.7966.6806, который доступен через VXLAN
LEAF-01# show bgp l2vpn evpn 0050.7966.6806
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.0.0.101:32868 (L2VNI 10101)
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6806]:[0]:[0.0.0.0]/216, version 21
Paths: (1 available, best #1)
Flags: (0x000212) (high32 00000000) on xmit-list, is in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop, in rib
Imported from 10.0.0.102:32868:[2]:[0]:[0]:[48]:[0050.7966.6806]:[0]:[0.0.0.0]/216
AS-Path: 200 , path sourced external to AS
10.0.0.102 (metric 41) from 10.0.0.1 (10.0.0.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10101
Extcommunity: RT:10101:10101 ENCAP:8Как видим, advertise маршрута делает BGW-01, но Next-hop до которого мы будем строить туннель остается LEAF-02, давайте посмотрим на дамп трафика между LEAF-01 и BGW-01
В дампе мы можем увидеть, что верхний IP заголовок указывает на LEAF коммутаторы и туннель строится сразу end-to-end без каких-либо промежуточных перекладываний. И в случае если у вас Multipod архитектура, все взаимодействия будут идти именно таким образом. Давайте перейдем к следующей архитектуре.
VLAN Hand-off
Изменения, которые нам потребуются чтобы привести схему к VLAN Hand-off, будут минимальными, если взглянуть на схему, то у нас изменился всего один линк, это связность между BGW-01 и BGW-02, теперь это у нас транк порт, на котором разрешен VLAN 101
Перейдем к конфигурации, ломать конфигурацию BGP мы пока не будем, сделаем это дальше на Multisite, мы просто сбросим интерфейсы Eth1/2 на BGW и сделаем их транковыми, VLAN на BGW мы ранее уже создали.
Настраиваем Trunk на BGW
Перед тем как что-либо настроить, давайте посмотрим на текущую таблицу мак адресов BGW-01
BGW-01# show mac address-table
C 101 0050.7966.6805 [SRV1 DC1] dynamic NA F F nve1(10.0.0.101)
C 101 0050.7966.6806 [SRV2 DC2] dynamic NA F F nve1(10.0.0.102)Сейчас он видит оба наших хоста через VXLAN туннели, после настроек мы как раз увидим что только один из адресов у нас будет через туннель
Сбрасываем интерфейсы на BGW01 и BGW02
default interface ethernet 1/2И настраиваем их как транк
interface Ethernet 1/2
switchport mode trunk
switchport trunk allowed vlan 101
no shutdownНа этом мы закончили всю настройку, которая нам требуется для перехода на VLAN Hand-off, давайте проверим нашу связность между хостами
SRV1> ping 192.168.0.200
84 bytes from 192.168.0.200 icmp_seq=1 ttl=255 time=34.420 ms
84 bytes from 192.168.0.200 icmp_seq=2 ttl=255 time=11.630 ms
84 bytes from 192.168.0.200 icmp_seq=3 ttl=255 time=33.753 ms
84 bytes from 192.168.0.200 icmp_seq=4 ttl=255 time=19.235 ms
84 bytes from 192.168.0.200 icmp_seq=5 ttl=255 time=17.672 msВсе доступно, но теперь надо посмотреть на таблицу MAC адресов в BGW-01
BGW-01# show mac address-table vlan 101
---------+-----------------+--------+---------+------+----+------------------
C 101 0050.7966.6805 [SRV1 DC1] dynamic NA F F nve1(10.0.0.101) [LEAF-01]
* 101 0050.7966.6806 [SRV2 DC2] dynamic NA F F Eth1/2MAC адрес хоста с LEAF коммутатора своего ЦОД, как и ранее, доступен через VXLAN, а вот второй MAC у нас теперь просто виден через порт Eth1/2, если мы взглянем на таблицу MAC адресов на LEAF-01, то увидим следующее:
LEAF-01# show mac address-table
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan,
(NA)- Not Applicable A – ESI Active Path, S – ESI Standby Path
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
* 101 0050.7966.6805 [SRV1 DC1] dynamic NA F F Eth1/2
C 101 0050.7966.6806 [SRV2 DC2] dynamic NA F F nve1(10.0.0.1) [BGW-01]Теперь Next-Hop адресом, с которого доступен хост из второго ЦОД, стал адрес BGW-01, и можно подробней глянуть на сам маршрут
LEAF-01# show bgp l2vpn evpn 0050.7966.6806
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.0.0.1:32868
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6806]:[0]:[0.0.0.0]/216, version 58
Paths: (1 available, best #1)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop
Imported to 1 destination(s)
Imported paths list: L2-10101
AS-Path: NONE, path sourced internal to AS
10.0.0.1 (metric 41) from 10.0.0.1 (10.0.0.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10101
Extcommunity: RT:10101:10101 ENCAP:8Теперь у нас и advertiser, и Next-Hop равны BGW, т.к. фактически на нем заканчивается VXLAN туннель и у нас теперь всего 2 устройства в EVPN домене.
Для того чтобы увидеть все деталях, стоит собрать дампы в 3 точках:
Линк между LEAF-01 и BGW-01, на котором мы видим что трафик упаковался в VXLAN и идет до BGW-01 до LEAF-01
Линк между BGW-01 и BGW-02, на котором мы видим, что наш изначальный пакет между хостами идет в чистом виде, без каких-либо инкапсуляций (802.1Q мы тут не считаем)
Линк между LEAF-02 и BGW-02, на котором мы видим, что в ЦОД2 строится свой VXLAN туннель, VNI у нас совпадают, но все будет так же прекрасно работать даже если мы поменяем VNI во втором ЦОД, т.к. никакая информация по EVPN между ЦОД не передается
Посмотрев на прохождение трафика становится наглядным отличием VLAN Hand-off от Multipod, в котором у нас был один туннель, но мы в два раза уменьшили количество хостов, на который нужно бы было реплицировать трафик. Или второй ЦОД мог быть и вообще без VXLAN и срастить нашу сеть мы бы не смогли. На этом мы заканчиваем с VLAN Hand-off и переходим к нашей последний архитектуре.
Multisite
Как и говорилось ранее, все что касается Multisite в том или ином виде проприетарно, и тут мы будем рассматривать именно то, как это видит Cisco. Схема у нас практически не будет отличаться от Multipod
Как и в случае с VLAN Hand-off все основные изменения конфигурации у нас будут на BGW устройствах, давайте начнем.
Подготовка BGW для работы в Multisite
Первым делом нам нужно указать номера сайтов
BGW-01
evpn multisite border-gateway 1BGW-02
evpn multisite border-gateway 2Введя эту настройку мы обозначили, что устройство будет работать как Multisite BGW, без нее вы не сможете дать команды, относящиеся к Multisite в других разделах. Что касается самого номера, у каждого сайта он должен быть уникальным и он отвечает за следующие механизмы:
Выбор DF, который будет отвечать за BUM при использовании Anycast Multisite BGW
Генерация secondary RD, который будет использоваться при анонсах EVPN маршрутов другим BGW
Далее, если мы посмотрим на Cisco Best Practice, то для Multisite у нас должно быть 3 Loopback адреса:
Loopback0 - для BGP пирингов и RID
Loopback1 - VTEP для локально подключенных хостов, но в нашем случае мы его схлопываем вместе с Loopback 0, т.к. у нас только одно устройство.
Loopback100 - Multisite VTEP, для Multisite у нас поднимается отдельный интерфейс для туннелей
Давайте настроим наши Loopback100 на BGW. И, т.к. они должны быть доступны для построения туннелей, заанонсируем их по BGP
BGW-01
interface loopback100
description Multisite_VTEP
ip address 10.100.0.1/32
router bgp 100
address-family ipv4 unicast
network 10.100.0.1/32BGW-02
interface loopback100
description Multisite_VTEP
ip address 10.100.0.2/32
router bgp 200
address-family ipv4 unicast
network 10.100.0.2/32Следующим обязательным шагом в настройке мы должны обозначить внутренние интерфейсы как fabric-tracking и внешние как dci-tracking. Это все сделано в рамках защиты от блэкхолинга трафик, т.к. Loopback100 у вас одинаковый между BGW одного сайта, то в случае, когда у вас упали все линки в сторону внутреннего ЦОД, вам нужно перестать анонсировать этот Loopback. Постарался наглядно отобразить проблему на картинках в двух действиях.
В случае с Cisco при таком падении внутренних портов, у вас просто пропадет анонс Loopback 100, мы чуть позже посмотрим в лабе как это происходит. Раз теперь нам стало понятней зачем нам это нужно, давайте продолжим настройки.
Интерфейсы BGW
У нас будет по одному интерфейсу fabric-tracking и dci-tracking, также нам нужно вернуть IP на наши линки между BGW после VLAN Hand-off
BGW-01
default interface Ethernet 1/2
interface Ethernet 1/2
description to BGW-02
no shutdown
no switchport
ip address 10.1.0.2/31
evpn multisite dci-tracking
interface ethernet 1/1
description to LEAF-01
evpn multisite fabric-tracking BGW-02
default interface Ethernet 1/2
interface Ethernet 1/2
description to BGW-01
no shutdown
no switchport
ip address 10.1.0.3/31
evpn multisite dci-tracking
interface ethernet 1/1
description to LEAF-02
evpn multisite fabric-tracking Следующим шагом нам нужно настроить NVE для Multisite. И чтобы NVE уже не трогать, то сразу настроим Ingress Replication для нашего VNI
BGW-01 и BGW-02
interface nve1
multisite border-gateway interface loopback100
member vni 10101
multisite ingress-replicationCisco (да и насколько я знаю все остальные) для multisite поддерживают только Ingress Replication, но внутри ЦОД у вас все так же может быть multicast.
BGW и BGP
Ну и последним шагом у нас осталось наше соседство. В сетях, где у вас будет несколько BGW, эти соседства по хорошему строятся на Loopback с multihop eBGP, но у нас всего 1 линк и по одному устройству в каждом ЦОД, поэтому мы на p2p адресах и поднимемся.
Перед настройкой удалим текущую конфигурацию, которая осталась после Multipod
BGW-01
router bgp 100
no neighbor 10.1.0.3
neighbor 10.1.0.3
remote-as 200
peer-type fabric-external
address-family ipv4 unicast
address-family l2vpn evpn
send-community extended
rewrite-evpn-rt-asnBGW-02
no neighbor 10.1.0.3
neighbor 10.1.0.2
remote-as 100
peer-type fabric-external
address-family ipv4 unicast
address-family l2vpn evpn
send-community extended
rewrite-evpn-rt-asnДавайте теперь остановимся немного поподробней на конфигурации, а именно строчке peer-type fabric-external. Именно она и делает все основную работу в Multisite, добавив эту строчку BGW начинает отправлять соседу все EVPN маршруты своего ЦОД, как будто бы их создателем является сама BGW(В оригинале это звучит сильно лучше - route reorigination).
И у нас тут есть еще одна интересная строчка, это rewrite-evpn-rt-asn. Ранее в Multipod я уже говорил что мы вернемся к настройке route-target auto в l2 VNI, так вот, строчка rewrite-evpn-rt-asn позволяет переписывать RT на входе, навешивая свой auto RT для этого VNI.
Перенастроим наш VNI 10101 наroute-target autoна всех устройствах (чуть позже мы в дампах посмотрим как выглядят наши BGP Update)
evpn
vni 10101 l2
rd auto
no route-target import 10101:10101
no route-target export 10101:10101
route-target both autoНу вот и все, мы закончили все наши настройки, посмотрим что с нашей связностью
NAME IP/MASK GATEWAY
SRV1 192.168.0.100/24 192.168.0.1
SRV1> ping 192.168.0.200
84 bytes from 192.168.0.200 icmp_seq=1 ttl=255 time=43.716 ms
84 bytes from 192.168.0.200 icmp_seq=2 ttl=255 time=36.265 ms
84 bytes from 192.168.0.200 icmp_seq=3 ttl=255 time=19.733 ms
84 bytes from 192.168.0.200 icmp_seq=4 ttl=255 time=28.022 ms
84 bytes from 192.168.0.200 icmp_seq=5 ttl=255 time=13.947 msКак видим, все заработало, взглянем на MAC таблицу LEAF-01
LEAF-01# show mac address-table vlan 101
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
* 101 0050.7966.6805 [SRV1 DC1] dynamic NA F F Eth1/2
C 101 0050.7966.6806 [SRV2 DC2] dynamic NA F F nve1(10.100.0.1) [BGW-01 Lo100]Выглядит она почти так же как было и в схеме с VLAN Hand-off, но адреса теперь прилетают не с Loopback0 BGW, а с Loopback100, который мы подняли для Multisite. А самое главное отличие мы увидим если посмотрим на таблицу на BGW-01
BGW-01# show mac address-table vlan 101
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
C 101 0050.7966.6805 [SRV1 DC1] dynamic NA F F nve1(10.0.0.101) [LEAF-01]
C 101 0050.7966.6806 [SRV2 DC2] dynamic NA F F nve1(10.100.0.2) [BGW-02 Lo100]Если ранее 0050.7966.6806, был доступен через Trunk, то теперь это полноценный туннель до Loopback 100 BGW-02. Давайте теперь посмотрим наш Type 2 маршрут до 0050.7966.6805 на BGW-01:
BGW-01# show bgp l2vpn evpn 0050.7966.6805
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.0.0.1:32868 (L2VNI 10101)
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6805]:[0]:[0.0.0.0]/216, version 23
Paths: (1 available, best #1)
Flags: (0x000212) (high32 0x000400) on xmit-list, is in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop, in rib
Imported from 10.0.0.101:32868:[2]:[0]:[0]:[48]:[0050.7966.6805]:[0]:[0.0.0.0]/216
AS-Path: NONE, path sourced internal to AS
10.0.0.101 (metric 41) from 10.0.0.101 (10.0.0.101)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10101
Extcommunity: RT:100:10101 ENCAP:8
Path-id 1 (dual) advertised to peers:
10.1.0.3 Тут видно, что маршрут получен от LEAF-01, и что он передается дальше Multisite соседу. Обратите внимание на RT, оно у нас 100:10101, и теперь сравним это с тем, как видит этот же маршрут BGW-02
BGW-02# show bgp l2vpn evpn 0050.7966.6805
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 1:10101
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6805]:[0]:[0.0.0.0]/216, version 58
Paths: (1 available, best #1)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: external, path is valid, is best path, no labeled nexthop
Imported to 1 destination(s)
Imported paths list: L2-10101
AS-Path: 100 , path sourced external to AS
10.100.0.1 (metric 0) from 10.1.0.2 (10.0.0.1)
Origin IGP, MED 2000, localpref 100, weight 0
Received label 10101
Extcommunity: RT:200:10101 ENCAP:8 Тут мы видим, что маршрут получен по eBGP, а в роли Next-Hop указан Loopback100 BGW-01, и сразу замечаем, что RT стал 200:10101, за это как раз и отвечает команда rewrite-evpn-rt-asn. Чтобы было наглядней по тому, какие RT отправляются, давайте почистим наши маршруты и отловим как выглядит BGP Update от BGW-01 до BGW-02.
В апдейте мы видим что отправляется RT 100:10101, но при получении BGW-02 сам переписывает их на подходящие для своей AS. Работать это будет только с RT auto, если RT установлены в ручную, то он не будет пытаться их переписать.
Вот мы и подошли к основной части, давайте взглянем на дампы того, как у нас ходит пинги, поступим аналогично тому, как мы делали с VLAN Hand-off, будем смотреть в трех точках:
Линк между LEAF-01 и BGW-01, и тут, как я и писал выше, никаких отличий, кроме смены DST IP BGW на Loopback100.
Линк между BGW-01 и BGW-02, и вот он наш второй VXLAN туннель. Стоит обратить внимание на адрес, с которого отправляет пакет BGW-01, Loopback0 все так же и остается SRC для всех VXLAN туннелей. Loopback100 же у нас фактически используется только для получения трафика, а не его отправки.
Линк между BGW-02 и LEAF-02, и наш третий туннель. Тут снова видим что BGW как SRC берет Lo0.
И последним, что я бы хотел показать по теме Multisite, это то, как отрабатывает защита от блэкхолинга трафика. Перед тем, как выключить интерфейсы, взглянем на статус нашего Loopback100.
BGW-01# show interface loopback 100
loopback100 is up
admin state is up,
Hardware: Loopback
Description: Multisite_VTEP
Internet Address is 10.100.0.1/32Как видим, он в UP и с ним все хорошо, давайте выключим наш единственный внутренний линк и посмотрим состояние после этого.
BGW-01(config)# interface ethernet 1/1
BGW-01(config-if)# shutdown
BGW-01(config-if)# end
BGW-01# show interface loopback 100
loopback100 is down (Administratively down)
admin state is up,
Hardware: Loopback
Description: Multisite_VTEP
Internet Address is 10.100.0.1/32Несмотря на то, что мы выключили только Eth1/1, у нас так же теперь в режиме shutdown и Loopback100, можно так же глянуть логи.
2025 May 12 21:56:54 BGW-01 %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface Ethernet1/1 is down(Config change)
2025 May 12 21:56:54 BGW-01 %ETHPORT-5-IF_DOWN_ADMIN_DOWN: Interface loopback100 is down (Administratively down)
2025 May 12 21:56:55 BGW-01 %ETHPORT-5-IF_DOWN_ADMIN_DOWN: Interface Ethernet1/1 is down (Administratively down)
2025 May 12 21:56:55 BGW-01 %NVE-5-NVE_INTF_STATE: nve1: NVE Interface state changed to downКак видим в логах, он упал одновременно с интерфейсом Eth1/1, и еще интересная деталь, так же у нас и отключился nve1 интерфейс, если мы вернем наш Eth1/1 и выключим Eth1/2, который является DCI, то увидим главное отличие dci-tracking и fabric-tracking, при падении DCI линков у нас выключается только Loopback100.
2025 May 12 22:18:58 BGW-01 %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface Ethernet1/2 is down(Config change)
2025 May 12 22:18:58 BGW-01 %ETHPORT-5-IF_DOWN_ADMIN_DOWN: Interface loopback100 is down (Administratively down)
2025 May 12 22:18:58 BGW-01 %ETHPORT-5-IF_DOWN_ADMIN_DOWN: Interface Ethernet1/2 is down (Administratively down)Подразумевается что в BGW помимо линков к другим ЦОД может быть и локальная нагрузка в виде хостов, и чтобы их не ломать nve1 остается в работе. На этом мы завершаем с нашим разбором Multisite и наверное можем подвести какие-то итоги.
Финал
При построении сети нет единственно правильной архитектуры, тут все зависит от ваших предпочтений, потребностей в росте сети, наличии оборудования. В каких-то случаях можно строить все просто и удобно на Multipod, в котором отлично срастаются практически любые вендора, и все прохождение трафика получается прозрачным.
А может быть сборная солянка из технологий в ЦОДах и единственным возможным решением будет VLAN Hand-off.
Но бывает так, что у вас есть уверенность в доступности нужного оборудования с функционалом Multisite и вы готовы идти в эту историю, чтобы получить прозрачность маршрутной информации и масштабируемость.
Спасибо за внимание)
Так же оставлю ссылочки на Whitepaper по Multisite от вендоров, которые поддерживают данное решение.
Cisco https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-739942.html
Huawei https://support.huawei.com/enterprise/en/doc/EDOC1000039339/82982614/configuring-inter-as-segment-vxlan-to-implement-layer-3-interworking
Arista https://www.arista.com/assets/data/pdf/Whitepapers/EVPN-Data-Center-EVPN-Gateway-for-Hierarchical-Multi-Domain-EVPN-and-DCI-WP.pdf
P.S. Я недавно решил создать свой курс на Stepik, и если вдруг хотите разобраться с таким инструментом, как NetBox, по промокоду HABR действует скидка 25% на мой курс: Netbox для сетевых инженеров
