lab05-VxLAN-L2
Задание VxLAN. L2 VNI
Цель: Настроить Overlay на основе VxLAN EVPN для L2 связанности между клиентами.
Описание/Пошаговая инструкция выполнения домашнего задания: В этой самостоятельной работе мы ожидаем, что вы самостоятельно:
Настроите BGP peering между Leaf и Spine в AF l2vpn evpn Настроите связанность между клиентами в первой зоне и убедитесь в её наличии Зафиксируете в документации - план работы, адресное пространство, схему сети, конфигурацию устройств
Схема стенда
Стенд делаем по принципу - хосты linux, leaf - frr, spine - eos (arista)
Распределение адресного пространства для Underlay
План составлен с учетом 10.x.y.z, где x - номер DC, y - номер spine, z - по очереди для подключения leaf Адреса для хостов - 172.16.x.z/24, где x - номер leaf, z - по порядку адрес хоста, на leaf ip .1 Адреса loopback 192.168.a.b/32, где a - 1 для spine, 2 - для leaf, b - номер spine, leaf по порядку Адресацию 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-2
Eth2
10.1.2.0/31
fd00::10:2:1:0/127
Leaf-1
Eth2
10.1.2.1/31
fd00::10:2:1:1/127
Spine-2
Eth2
10.1.2.2/31
fd00::10:2:1:2/127
Leaf-2
Eth2
10.1.2.3/31
fd00::10:2:1:3/127
Spine-2
Eth3
10.1.2.4/31
fd00::10:2:1:4/127
Leaf-3
Eth2
10.1.2.5/31
fd00::10:2:1:5/127
Host-1
Eth1
172.16.1.11/24
fd00::172:16:1:b/116
Leaf-1
Eth3
access vlan red
access vlan red
Host-2
Eth1
172.16.2.12/24
fd00::172:16:2:c/116
Leaf-2
Eth3
access vlan blue
access vlan blue
Host-3
Eth1
172.16.1.13/24
fd00::172:16:3:e/116
Leaf-3
Eth3
access vlan red
access vlan red
Host-4
Eth1
172.16.2.14/24
fd00::172:16:4:d/116
Leaf-3
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-3
192.168.2.3
fd00::192:168:2:3
Собираем топологию на базе ospf+ibgp. Area ospf 0, bgp as 65500
Запуск лабараторной в среде netlab
Казалось бы все просто, но очень долго мучался с работой access на frr. Оказалось что если назначать подключаемые интерфейсы не по порядку, то происходит mismatching и с точки зрения frr настраиваются не те интерфейсы которые настраиваются в бриджинг со стороны linux alpine внутри которого этот frr крутится. Так же меня не очень устроило что по умолчанию создается сессия между spine выступающими route reflector, которая не совсем понятно зачем нужна в случае отсутсвия прямого линка между ними. Поэтому лезем в код, а именно покурив /usr/local/lib/python3.10/dist-packages/netsim/modules/bgp.py узнаем что при создании сессий в случае присутсвия роут рефлектора, строится не full mesh а сессии только от RR, но не обрабатываются ситуация сессий с другими RR, добавив условие проверки, получаем что netlab работать перестает. Немного вспомнив курсы по python понимаю, что накосячил с отступами, все поправил - netlab запустился. Вроде все хорошо, но понял что данное изменение безоговорочно убирает сессию, хотя опрос всех знакомых сетевых инженеров так и не принес ответа зачем может понадобится такая сессия, решил что может кому и понадобится, а значит добавляем в обработчик /usr/local/lib/python3.10/dist-packages/netsim/modules/bgp.yml параметр который поможет управлять этим процессом. По умолчанию выставил False. Пару раз пришлось все перезапускать чтобы проверить корректность работы. Измененные файлы прилагаю если вдруг кто то найдет их здесь раньше, чем я доберусь до того чтобы законтрибьютить это в проект netlaba. bgp.py bgp.yml
Конфиг-файл или под катом
Проверка работы
Какой конечный результат мы хотели? связность между h1 и h3, h2 и h4 соответственно. И чтобы через vxlan. Стартуем и смотрим на пинги
Пинги между хостами побежали, значит можно посмотреть что происходит у нас на leaf и spine, какие есть маршруты и прочее. Учитывая что у нас поднялся evpn и по ipv4 и по ipv6 будет весело но для понимания введем таблицу mac для устройств
h1
aa:c1:ab:0d:85:f0
172.16.1.11/24
fd00::172:16:1:b/116
fe80::a8c1:abff:fe0d:85f0/64
red
101000
h2
aa:c1:ab:a5:c3:48
172.16.2.12/24
fd00::172:16:2:c/116
fe80::a8c1:abff:fea5:c348/64
blue
101001
h3
aa:c1:ab:cb:d4:25
172.16.1.13/24
fd00::172:16:1:d/116
fe80::a8c1:abff:fecb:d425/64
red
101000
h4
aa:c1:ab:60:b1:45
172.16.2.14/24
fd00::172:16:2:e/116
fe80::a8c1:abff:fe60:b145/64
blue
101001
Вот что показывает spine-1 о наших evpn
Как видим распространяются link-local еще и vlan-if которые прибиты внутри frr, ниже выдержка ip a c leaf-3
А вот и вывод по evpn маршрутам с leaf-3
Если заглянуть в wireshark то можно увидеть как на leaf происходит обмен маршрутами второго типа.
Самым интересным открытием стало что при передаче второго типа маршрутов передаются так же и link-local для ipv6
Конфигурационные файлы, забыл сначала приложить, но удобно что можно ввести команду neltab collect и забрать их в директории config. Конфигурационные файлы устройств:
Последнее обновление