Что делать и куда бежать, если тебе нужно построить сеть на несколько ЦОД, с 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 shutdown

BGW-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 shutdown

LEAF-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.1

LEAF-01

router ospf UNDERLAY
  router-id 10.0.0.101

BGW-02

router ospf UNDERLAY
  router-id 10.0.0.2

LEAF-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 extended

BGW-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 extended

LEAF-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/2

MAC адрес хоста с 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 1

BGW-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/32

BGW-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-replication

Cisco (да и насколько я знаю все остальные) для 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-asn

BGW-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 для сетевых инженеров

Строим VXLAN/EVPN на несколько ЦОД