lab07-VxLAN&M-LAG
Задание VXLAN. Multihoming
Цель: Настроить отказоустойчивое подключение клиентов с использованием EVPN Multihoming.
Описание/Пошаговая инструкция выполнения домашнего задания: В этой самостоятельной работе мы ожидаем, что вы самостоятельно:
Подключите клиентов 2-я линками к различным Leaf Настроите агрегированный канал со стороны клиента Настроите multihoming для работы в Overlay сети. Если используете Cisco NXOS - vPC, если иной вендор - то ESI LAG (либо MC-LAG с поддержкой VXLAN) Зафиксируете в документации - план работы, адресное пространство, схему сети, конфигурацию устройств Опционально - протестировать отказоустойчивость - убедиться, что связнность не теряется при отключении одного из линков
Схема стенда
В силу ограничений функционала frr меняем "вендора" leaf на arista, все же frr это роутер, функционал свитчей в них выполняется через средства linux. И mlag запустить на нем не получилось. В качестве клиента оставляем 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 по порядку Адресацию 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-3
Eth3
10.0.1.2/31
fd00::10:0:1:2/127
Leaf-4
Eth3
10.0.1.3/31
fd00::10:0:1:3/127
Leaf-1
Eth4
------------
------------
Leaf-2
Eth4
------------
------------
Leaf-3
Eth4
------------
------------
Leaf-4
Eth4
------------
------------
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-3
Eth5
access vlan red
access vlan red
Host-2
Eth2
172.16.1.12/24
fd00::172:16:1:с/116
Leaf-4
Eth5
access vlan red
access vlan red
Host-3
Eth1
172.16.2.13/24
fd00::172:16:2:d/116
Leaf-1
Eth6
access vlan blue
access vlan blue
Host-3
Eth2
172.16.2.13/24
fd00::172:16:2:d/116
Leaf-2
Eth6
access vlan blue
access vlan blue
Host-4
Eth1
172.16.2.14/24
fd00::172:16:2:e/116
Leaf-3
Eth6
access vlan blue
access vlan blue
Host-4
Eth2
172.16.2.14/24
fd00::172:16:2:e/116
Leaf-4
Eth6
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
Leaf-4
192.168.2.4
fd00::192:168:2:4
Собираем топологию на базе ospf+ibgp. Area ospf 0, bgp as 65500
Запуск лабараторной в среде netlab
Особенностей в запуске не было, для того чтобы не мешать в одну кучу сервисы и транспорт, ввел vrf - user в который поместил оба vlan-if что позволит хостам общаться между собой. Так же так как в основном я работаю с решением centralized gateway, когда l3 приземляется на border-leaf, решил попробовать distributed gateway, чтобы посмотреть как оно настраивается и forwadит. Единственное модуль gateway, обеспечивающий работу протоколов fhrp растягивает только ipv4 адрес между оборудованием, попытки подружить его с ipv6 не очень получились.
Конфиг-файл или под катом
Проверка работы
Первым делом убеждаемся что есть пинги, пожалуй пришло время вписывать автотесты. Для этого в файл топологии добавляем блок validate
И после ввода netlab validate получаем:
Ну красота же, иногда мне кажется что это какое то читерство, ибо лаба сама себя собирает, сама себя проверяет, единственное над чем приходится корпеть так это правильно написанный yml. Смотрим что у нас знает spine-2 о наших хостах.
Учитывая что у нас поднялся evpn и по ipv4 и по ipv6 будет весело но для понимания введем таблицу mac для устройств
h1
aa:c1:ab:31:a1:6f
172.16.1.11/24
fd00::172:16:1:b/116
fe80::a8c1:abff:fe0d:85f0/64
red
101000
h2
aa:c1:ab:82:c9:3c
172.16.2.12/24
fd00::172:16:2:c/116
fe80::a8c1:abff:fea5:c348/64
red
101000
h3
aa:c1:ab:e6:14:53
172.16.1.13/24
fd00::172:16:1:d/116
fe80::a8c1:abff:fecb:d425/64
blue
101001
h4
aa:c1:ab:a6:ff:af
172.16.2.14/24
fd00::172:16:2:e/116
fe80::a8c1:abff:fe60:b145/64
blue
101001
В целом l2 vni мы отработали в 5й лабороторной, поэтому смотрим на наши mlag
Вот для leaf-3 leaf-4
Со всех сторон хорошо. Теперь нужно понять спасает ли нас эта технология от выхода из строя оборудования или линков. Предлагается следующий сценарий отказов:
Допустим мы проводили работы по обновлению и leaf-1 упал. 1 на картинке
Работы проводили не только мы, но и кто то в кроссе и в результате повредили все аплинки для leaf-3. 2-3 на картинке
День несчастий продолжался и на leaf-4 сгорела интерфейсная плата в сторону серверов. 4-5 на картинке
Все падения будем эмулировать путем перевода в shutdown интерфейсов. Написал сценарий и самому страшно от такого развития событий, представляю в каком шоке был бы мониторинг хД).
Состояние интерфейсов под катом
Прибегаем к чудной команде netlab validate и
Тесты успешно пройдены, несмотря на все наши старания. Конечно при определенной сноровке еще парой shutdown мы могли бы дошатать этот стенд, но проявим сочувствие и соберем конфигурацию. Делается это кстати командой netlab collect. Все файлы конфигурации ложатся в папку /config в директории лабы. Для любителей wireshark вот информация с leaf-4, путем нескольких стартов валидации. На них наглядно видно что трафик ходит в обе стороны при отказах.
l4 выбран как тот на котором можно увидеть как трафик будет перетекать в peer-link пытаясь попасть на хосты. Где видим что трафик ходит в eth3 и eth4 которые связывают leaf3 и leaf4. eth3 выступает по факту дополнительным путем для evpn, т.к. у нас ibgp то evpn соседство между leaf-3 и spine не упало, просто установился запасной маршрут, и он отлично вещает и принимает маршруты от всех остальных leaf. eth4 выступает peerlink для работы mlag.
Видим, что линки mlag у нас в состоянии Active-partial, ну у соседа то они лежат. И evpn соседство у нас не упало. Вот кстати и ospf route со spine-1
Видим что у нас loopback leaf-3 (192.168.2.3) c ценой маршрута 30. leaf-1(192.168.2.1) вообще не отсвечивает.
Конфигурационные файлы устройств(с поднятыми интерфейсами) :
Последнее обновление