lab08-VxLAN&M-Routing
Задание VxLAN. Routing.
Цель: Реализовать передачу суммарных префиксов через EVPN route-type 5.
Описание/Пошаговая инструкция выполнения домашнего задания:
В этой самостоятельной работе мы ожидаем, что вы самостоятельно:
Разместите двух "клиентов" в разных VRF в рамках одной фабрики. Настроите маршрутизацию между клиентами через внешнее устройство (граничный роутер\фаерволл\etc) Зафиксируете в документации - план работы, адресное пространство, схему сети, настройки сетевого оборудования
Схема стенда
Оставляем leaf на arista, чтобы можно было оставить кусочек m-lag на l1-l2, l4 выступает border leaf, frr делаем внешним роутером В качестве клиента оставляем linux c bond. Стенд делаем по принципу - хосты linux, leaf - eos, spine - eos (arista)
Распределение адресного пространства
План составлен с учетом 10.x.y.z, где x - номер DC, y - номер spine, z - по очереди для подключения leaf Адреса для хостов - 172.16.x.z/24, где x - номер leaf, z - по порядку адрес хоста, на leaf ip . Сеть для построения peerlink 10.0.x.z где x - номер DC, z - по очереди для пары leaf. Адреса loopback 192.168.a.b/32, где a - 1 для spine, 2 - для leaf, b - номер spine, leaf по порядку. VRF red 172.16.1.0/24 blue 172.16.2.0/24 anycast gw 172.16.x.254/24 Interconnect vrf с external router 10.0.5.0/30 Адресацию ipv6 делаем по прицнипу из fd00::[IPv4]
Interconnect ipv4 ipv6
Spine-1
Eth1
10.1.1.0/31
fd00::10:1:1:0/127
Leaf-1
Eth1
10.1.1.1/31
fd00::10:1:1:1/127
Spine-1
Eth2
10.1.1.2/31
fd00::10:1:1:2/127
Leaf-2
Eth1
10.1.1.3/31
fd00::10:1:1:3/127
Spine-1
Eth3
10.1.1.4/31
fd00::10:1:1:4/127
Leaf-3
Eth1
10.1.1.5/31
fd00::10:1:1:5/127
Spine-1
Eth4
10.1.1.6/31
fd00::10:1:1:6/127
Leaf-4
Eth1
10.1.1.7/31
fd00::10:1:1:7/127
Spine-2
Eth1
10.1.2.0/31
fd00::10:1:2:0/127
Leaf-1
Eth2
10.1.2.1/31
fd00::10:1:2:1/127
Spine-2
Eth2
10.1.2.2/31
fd00::10:1:2:2/127
Leaf-2
Eth2
10.1.2.3/31
fd00::10:1:2:3/127
Spine-2
Eth3
10.1.2.4/31
fd00::10:1:2:4/127
Leaf-3
Eth2
10.1.2.5/31
fd00::10:1:2:5/127
Spine-2
Eth4
10.1.2.6/31
fd00::10:1:2:6/127
Leaf-4
Eth2
10.1.2.7/31
fd00::10:1:2:7/127
Leaf-1
Eth3
10.0.1.0/31
fd00::10:0:1:0/127
Leaf-2
Eth3
10.0.1.1/31
fd00::10:0:1:1/127
Leaf-1
Eth4
------------
------------
Leaf-2
Eth4
------------
------------
Leaf-4
Eth5 vrf-red
10.0.5.0/31
fd00::10:0:5:0/127
R-1
Eth1
10.0.5.1/31
fd00::10:0:5:1/127
Leaf-4
Eth6 vrf-blue
10.0.5.2/31
fd00::10:0:5:2/127
R-1
Eth2
10.0.5.3/31
fd00::10:0:5:3/127
Host-1
Eth1
172.16.1.11/24
fd00::172:16:1:b/116
Leaf-1
Eth5
access vlan red
access vlan red
Host-1
Eth2
172.16.1.11/24
fd00::172:16:1:b/116
Leaf-2
Eth5
access vlan red
access vlan red
Host-2
Eth1
172.16.1.12/24
fd00::172:16:1:c/116
Leaf-1
Eth6
access vlan blue
access vlan blue
Host-2
Eth2
172.16.1.12/24
fd00::172:16:1:с/116
Leaf-2
Eth6
access vlan blue
access vlan blue
Host-3
Eth1
172.16.2.13/24
fd00::172:16:2:d/116
Leaf-3
Eth3
access vlan red
access vlan red
Host-4
Eth1
172.16.2.14/24
fd00::172:16:2:e/116
Leaf-3
Eth4
access vlan blue
access vlan blue
Host-5
Eth1
172.16.2.15/24
fd00::172:16:2:f/116
Leaf-4
Eth3
access vlan red
access vlan red
Host-6
Eth1
172.16.2.16/24
fd00::172:16:2:10/116
Leaf-4
Eth4
access vlan blue
access vlan blue
loopback
Spine-1
192.168.1.1
fd00::192:168:1:1
Spine-2
192.168.1.2
fd00::192:168:1:2
Leaf-1
192.168.2.1
fd00::192:168:2:1
Leaf-2
192.168.2.2
fd00::192:168:2:2
Leaf-1
192.168.2.0
fd00::192:168:2:0
Leaf-2
192.168.2.0
fd00::192:168:2:0
Leaf-3
192.168.2.3
fd00::192:168:2:3
Leaf-4
192.168.2.4
fd00::192:168:2:4
R-1
192.168.3.1
fd00::192:168:3:1
Собираем топологию на базе ospf+ibgp. Area ospf 0, bgp as 65500, external bgp as 65100
Запуск лабараторной в среде netlab(l2 mode)
Так как задание надо читать вдумчиво то по ходу выполнения сделалось 2 лабараторные. 1-я попытка была построена на l2, маршрутизация между хостами работала, r1 был включен по схеме чупа-чупса router-on-stick, если что схема
Конфиг-файл или под катом
И это прекрасно работало, смущало правда отсутствие type-5 route, но откуда им было браться, если ни один leaf не замешан в маршрутизации между vrf, и вообще про эти самые vrf знать не знает. Понимая что сделал не то, пошел делать то.
Запуск лабараторной в среде netlab(l3 mode)
Правильная схема к заданию. Было решено освоить distributed gateway, когда шлюз для каждого домена находится на каждом leaf. Возникли нюансы с обменом маршрутной информацией между vrf leaf-4 и r-1, но об этом позже, выстраданый конфиг-файл или ниже схемы под катом
Проверка работы
Связность проверяем автотестом через neltab validate , если все хорошо сошлось, то все и запингуется, вывод
А теперь о нюансах обмена маршрутами через R-1. Если просто запустить стенд, то оба vrf получат маршрут loopback интерфейса от r-1, r-1 будет знать о всех сетях, а вот vrf не будут знать друг о друге, потому что оба vrf имеют одну и ту же BGP AS, и не должны устанавливать в свою таблицу маршруты полученные по ebgp со своей BGP AS. Здесь у нас несколько вариантов решения этой проблемы:
bgp allow as in для пиров, что разрешит роутеру принимать маршруты со своей AS, почему то не зароботало у меня на arista, хотя на frr запустилось, возможно где то не дожал;
route-map c удалением BGP AS полученных от leaf-4, прекрасно работает;
создавать VRF на R-1 и связывать их через другой IGP протокол, что по факту приведет к тому же удалению всех атрибутов BGP и приведет к усложненному варианту пункта 2;
самый легкий в реализации, но почему то не сразу пришедший на ум - default originate, получится что то похожее на hvpn(hierarchy vpn) в терминологии huawei;
bgp override-as тоже почему то не стартанул на arista, frr запустил;
использовать разные AS для разных vrf, можно, но привычка говорит что vrf должен быть той же as как и роутер на котором он находится. От мысли сделать leaf-4 на frr при остальной фабрике на arista отказался, так как начинали некоректно мапиться vxlan vni. Потратил много сил чтобы попробовать это все склеить, но с такими костылями сдавать лабу не хотелось.
Теперь о том как это все заставить красиво работать. Изначально остановился на варианте с вещанием маршрута по умолчанию, так как он хорошо работал в netlab, в одну строку bgp.default_originate: True и маршрут летит в сессии. После понял что возникают проблемы с работой m-lag на leaf-1 leaf-2, а именно проскакивающие dup пакеты в результатах пинга. А все потому что leaf-1 и leaf-2 работая в фабрике должны слать update с одинакового адреса, для чего нужно создать одинаковый loopback с одинаковым адресом на обоих. Т.к. глубинной целью обучения определено сделать все лабы без ввода configure terminal, то нужно включить дополнительную конфигурацию при инициализации устройств. По хорошему нужно бы дописать дополнительный модуль, но сейчас совсем не успеваю, поэтому срежем угол воспользовавшись опцией config при составлении файла топологии, это позволяет добавить дополнительную конфигурацию на устройства после инициализации стенда. Раз уж мы делаем дополнительную конфигурацию для leaf leaf1/2, то можно и вставить дополнения для R-1 c route-map. r1-route-map
Так же важная пометка, почему то в мою голову закралась мысль о том что один и в тот же vni можно засовывать и l2 и l3, что на практике оказалось совсем не так. От этого я долго мучался в поисках маршрутов, которые никак не хотели лететь.
Теперь смотрим в таблицы:
Обратим внимание на то что маршруты приходящие с пары leaf-1 leaf-2 приходят с адреса 192.168.2.0/32 общего между leaf-1 и leaf-2
Таблицы маршрутизации для vrf
loopback c r-1 не приходит потому что мы его не пропускаем route-mapой. Но у нас есть суммированные маршруты к сети другого vrf анонсируемые leaf-4
вот какие таблицы у него
Кстати забыл рассказать о замечательной дополнительной tool netlab которая позволяет не путаться в том что и как соединено - graphite. Она отражает как соединены интерфейсы, а также позволяет подключаться на устройства по ssh, причем можно одновременно висеть на нескольких устройствах, что на мой взгляд очень удобно, если не любишь tmux.
Теперь немного поснифаем трафик, чтобы посмотреть что происходит на leaf-4
Маршруты типа 5 отдаваемые на spine
Маршруты типа 3
Посмотрим в icmp на l4 видим что пакет пришел из фабрики по vni 10000(vrf red type 5) а ответ ушел по vni 10000 (vlan 1000 type 3) Что то я немного приплутал.
Проще всего посмотреть круговорот трафика в фабрике оказалось на l3 пропинговав хосты подключенные к нему в разных vrf Так на 1 запрос от h3 улетает в фабрику, на 2 этот же запрос возвращается из фабрики, на 3 ответ от h4 улетает в фабрику, на 4 ответ прилетает от фабрики. В обратную сторону по ipv6
А если мы посмотрим в l2 связность то пинги в фабрике бегают по своим изолированным vxlan
1,2 красный vrf 3,4 синий. На этом пожалуй все
Конфигурационные файлы устройств :
Последнее обновление