VxLAN фабрика часть 4. Multipod11.11.2020 09:32

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

id1upt2_ppza9r6d9zlp_vndyny.png


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

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


  1. Multipod
  2. Multisite

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

u8iwn2jjijolhijgtuovaxbxjnm.jpeg

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

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

rfwf2gba3weuej4n00xg9di4gjs.jpeg

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

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


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

И снова есть два варианта настройки 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:

xoa4ayhkt1-qsneyskvtr5yi58m.jpeg

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

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

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

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

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

route-map NH_UNCHANGED
 set ip next-hop unchanged

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

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

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

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

fschhmjmfxj47bjc1ozcpnmlelw.jpeg

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

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

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

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

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

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

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

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

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

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

2az8xk2so48hq9b2ejyf3sjidzg.png

© Habrahabr.ru