Часть 5. VxLAN. EVPN L2
Цель
Настроить Overlay на основе VxLAN EVPN для L2 связанности между клиентами
Ожидаемый результат
Настроен BGP peering между Leaf и Spine в AF l2vpn evepn.
Настроена и проверена IP связанность между клиентами в первой зоне.
В документации зафиксирован план работ, адресное пространство, схема сети и конфигурация устройств.
Небольшое введение
Перед началом работы на этим Д/З немного меняем топологию сети. Делаем задел на будущее - масштабирование в пределах одного ДЦ, масштабирование в 2 и более ДЦ с растягиваением L2 (чего делать очень не рекомендуют), включение в схему с l2vni файрволов.
Представляем, что у нас:
2 Spine-коммутатора в разных сетевых стойках
2 стойки и в каждой по 2 Leaf-коммутатора и 1 гипервизор на базе VMware ESXi 8.x
1 стойка с парой border-leaf и/или service-leaf. Всего в схеме теперь 8 коммутаторов и 2 гипервизора.
Идем в свой выдуманный ДЦ в Netbox и смотрим на расположение оборудования:
Мы же в самом начале этого увлекательного путешествия решили, что:
Spine-коммутаторы расположены в разных серверных стойках
Leaf-коммутаторы сгруппированы по 2 в качестве Top of Rack устройств (пока это standalone устройства, дальше будем пробовать их в m-lag).
Из-за добавившихся устройств возникла необходимость в обновлении BGP сессий внутри Netbox. Проблема с автоматизацией или генерацией все еще актуальна и не решена, но для минимизации ошибок воспользуемся Excel'ем.
В файле нет рокет сайнс. На первом листе справочники устройств, AS и адресов. На втором листе их можно выбрать из drop-down меню:
А потом скопировать и вставить в поле импорта Netbox:
В результате получается вполне годный список сессий для последующего использования в Netbox Provisioning -> Config Templates
Здесь стоит сделать паузу. Куратор курса дал направление в сторону динамических соседей. Это нужно обдумать, так как инфо в Netbox нужно будет отдавать с устройств. Подумаем позже над этим.
Достижение результата
Шаблон конфигурации
Как и прежде, конфигурация устройств генерируется внутри Netbox на основе его данных через шаблоны. Методом проб и ошибок я пришел к тому, что шаблон нужно разделить для групп устройств. Теперь их два - один для Spine'ов hw5_netbox_spine_bgp_template.jinja2, второй - для Leaf'ов hw5_netbox_leaf_bgp_template.jinja2.
Тут, пожалуй, стоит подробнее остановиться на том, как шаблоны работают.
SPINE
Этот шаблон Jinja2 генерирует конфигурацию сетевого устройства (под управлением Arista EOS), используя данные из NetBox и связанных контекстов. Его цель — автоматически сформировать готовый к применению конфиг на основе инвентаря устройства, его интерфейсов, IP-адресов, BGP-сессий, VRF, VLAN, параметров STP и маршрутов.
Ниже — более детальный разбор того, что делает шаблон:
Базовые настройки безопасности и управления:
no aaa root: Выключает определённые AAA настройки по умолчанию.
Настройка пользователя admin с ролью network-admin и заданным секретом.
transceiver qsfp default-mode 4x10G: Определяет режим работы QSFP-трансиверов.
service routing protocols model multi-agent: Переключение модели протоколов маршрутизации на «multi-agent» (особенность Arista EOS).
Hostname и VRF для управления:
hostname {{ device.name }}: Устанавливает имя устройства согласно данным из NetBox.
vrf instance {{ vrfs.mgmt }}: Создаёт VRF для управления (management VRF), имя которого берётся из шаблона vrfs.mgmt.
Управление через API и VRF:
В блоке: Настраивается management api http-commands, включается no shutdown для default VRF и управленческого VRF, что позволяет управлять устройством по API из правильного VRF.
Маршрутизация:
Включается IP-маршрутизация (ip routing).
no ip routing vrf {{ vrfs.mgmt }} — отключение маршрутизации в этом VRF.
Настройка статического маршрута по умолчанию в management VRF (ip route vrf {{ vrfs.mgmt }} 0.0.0.0/0 {{ mgmt_default_gw }}), указывая на шлюз по умолчанию для управления.
Spanning-tree режим:
Перебираются настройки STP, заданные в stp_mode, и устанавливается режим spanning-tree.
Настройка интерфейсов:
Перебираются все интерфейсы устройства (device.interfaces.all()).
Для Ethernet-интерфейсов:
Если есть IP-адрес: интерфейс переводится в L3-режим (no switchport), задаётся MTU, настраивается BFD и назначается IP. Включается или выключается исходя из флага enabled.
Если IP-адреса нет: интерфейс остаётся L2 (switchport), выбирается access или trunk режим, VLANы, native VLAN для trunk при необходимости.
Описание интерфейса, если указано.
Для Loopback-интерфейсов:
Назначение IP-адресов.
Добавление описания, если оно есть.
Для Management-интерфейсов:
Назначение IP-адресов и привязка к VRF для управления.
Добавление описания, если есть.
Настройка BGP EVPN:
Цикл по BGP-сессиям, сгруппированным по local_as.
Устанавливается router bgp <local_asn> с router-id, взятым из IP Loopback0.
maximum-paths 2: Разрешает множественные пути.
Настраивается peer-group (leaf_peers), bfd, отправка расширенных сообществ (send-community extended).
Перебираются BGP-сессии (sessions): для каждого соседа устанавливается neighbor ... remote-as ... и назначение в peer-group.
Включается address-family evpn с neighbor ... activate для обмена EVPN-маршрутами.
Команда end: Завершение конфигурационного файла.
Итог: Шаблон берёт данные о устройстве, его интерфейсах, IP-адресах, BGP-сеансах, VRF, STP-режиме и т.д. из NetBox (и связанных переменных device, vrfs, stp_mode, bgp_peer_groups, mgmt_default_gw) и формирует полный конфигурационный скрипт для сетевого устройства. Он автоматизирует процесс конфигурации, устраняет необходимость ручной настройки и снижает риск ошибок.
LEAF
Этот шаблон Jinja2 автоматически генерирует конфигурацию сетевого коммутатора (под управлением Arista EOS) на основе данных, полученных из NetBox или других контекстных переменных. Рассмотрим основные аспекты, которые он реализует:
Начальные настройки устройства:
no aaa root: Отключение некоторых настроек AAA по умолчанию.
Создание пользователя admin с заданной ролью и секретом.
Настройка трансиверов QSFP в режим 4x10G.
Переключение модели протоколов маршрутизации на multi-agent.
Установка hostname устройства (hostname {{ device.name }}).
Настройка VRF и управления:
Создаёт VRF для управления (vrf instance {{ vrfs.mgmt }}).
В блоке management api http-commands включается доступ к API и отключение shutdown для default и management VRF.
Маршрутизация:
Включается IP-маршрутизация (ip routing).
no ip routing vrf {{ vrfs.mgmt }} — специфическое отключение маршрутизации в mgmt VRF.
Настройка prefix-list для loopback10 (ip prefix-list loopback-list).
Добавление статического маршрута по умолчанию в management VRF (ip route vrf {{ vrfs.mgmt }} 0.0.0.0/0 {{ mgmt_default_gw }}).
route-map loopback-map для фильтрации и распространения loopback-маршрутов.
Spanning-Tree и VLAN:
Настраивает режимы spanning-tree, используя данные из stp_mode.
Генерирует конфигурацию для всех VLAN, связанных с сайтом устройства: vlan
<vid>с name<vlan.name>.
Настройка интерфейсов:
Перебирает все интерфейсы устройства:
Ethernet интерфейсы:
Если есть IP-адрес: задаётся MTU, L3-режим (no switchport), BFD, IP-адрес. Интерфейс поднимается или выключается по флагу enabled, добавляется description при наличии.
Если IP-адресов нет: интерфейс становится L2 (access или trunk), назначаются VLAN согласно mode и untagged/tagged VLAN.
Loopback интерфейсы: Назначаются IP-адреса, описание при наличии.
Management интерфейсы: Назначаются IP-адреса, привязываются к управленческому VRF, описание при наличии.
VXLAN конфигурация:
Создаётся интерфейс Vxlan1.
Указывается vxlan source-interface Loopback10, vxlan udp-port 4789.
Перебираются VLAN сайта и для каждого создаётся сопоставление
vxlan vlan <vid> vni <100000 + vid>— таким образом, каждому VLAN назначается свой VNI.
BGP EVPN конфигурация:
Перебираются BGP-сессии, сгруппированные по локальному AS.
Настраивается router bgp <local_asn> с router-id, равным адресу Loopback0.
Задаётся peer-group для leaf (spine_peers), включается BFD, send-community extended.
Добавляются соседи (neighbor) из sessions с указанием remote-as.
redistribute connected route-map loopback-map позволяет распространить локальные loopback маршруты через BGP.
Настройка EVPN address-family: активируется соседи из peer-group для EVPN. Дополнительно, для каждого VLAN генерируется EVPN-секция:
vlan <vid> rd auto route-target both <vid>:<100000+vid> redistribute learned
Это добавляет L2VPN EVPN параметры для каждого VLAN, определяя RD и RT, необходимые для обмена EVPN-маршрутами (MAC/IP) между участниками EVPN-фабрики.
Итог: Шаблон собирает вместе множество данных о устройстве и его окружении (имя, интерфейсы, IP-адреса, VRF, VLAN, BGP, EVPN) и генерирует полноценную конфигурацию, готовую к применению. Он автоматически настраивает базовые параметры безопасности и управления, линейные и петлевые интерфейсы, L2/L3 параметры, VXLAN/EVPN для мульти-тенантной сети, а также объявляет маршруты и параметры BGP для обмена маршрутами (включая EVPN).
Например, для устройства no-osl-dc1-f1-r03k01-lf01 на основании настроек интерфейсов в Netbox сгенерируется следующий конфиг
Конфигурационные файлы
Сгенерированные в Netbox файлы подложены как start-up config в лабе EVE-NG как есть без ручных изменений:
Проверка настроек
Ниже приложены скриншоты с устройства no-osl-dc1-f1-r03k03-lf02, к которому подключен тестовый PC на Ubuntu. С этого PC запушены ping до всех гипервизиров: 192.168.10.1, 192.168.10.2, 192.168.10.3
Вывод команды show interfaces vxlan 1
show interfaces vxlan 1Вывод команды show vxlan vtep
show vxlan vtepВывод команд show mac address-table и show vxlan address-table
show mac address-table и show vxlan address-tableВывод команды show bgp evpn route-type mac-ip
show bgp evpn route-type mac-ipТестирование на отказ
Сценарий 1. Перезагрузка одного из Spine-коммутаторов
В данном сценарии перезапускаем no-osl-dc1-f1-r01k01-spn01
Проверяем устройство no-osl-dc1-f1-r03k03-lf02
Видим в логе сообщения
Dec 13 07:08:14 no-osl-dc1-f1-r03k03-lf02 Bgp: %BGP-3-NOTIFICATION: sent to neighbor 10.16.2.10 (VRF default AS 4200131329) 6/10 (Cease/BFD down <Hard Reset>) 0 bytes
И проверяем доступность гипервизоров с тестового PC
Сценарий 2. Перезагрузка одного из Leaf-коммутаторов в паре Rack 1
В данном сценарии перезапускаем no-osl-dc1-f1-r03k01-lf01
Проверяем доступность гипервизора и он не доступен xD
Пробуем Suspend Link в EVE-NG
Убеждаемся, что гипервизор доступен через Leaf no-osl-dc1-f1-r03k01-lf02
В данном случае обращаем внимание на вывод:
Это значит, что mac-адрес 0050.5666.b8eb стал доступен через leaf no-osl-dc1-f1-r03k01-lf02
А вывод команды show vxlan address-table:
Говорит о том, что mac-адрес переезжал и был получен через другой VTEP
Послесловие
Отличное задание!
Хочу выразить благодарность кураторам курса за наводящие ответы и неравнодушным однопоточникам за подсказку при траблшутинге. Особенно за команду neighbor SPINE-PEERS send-community extended, без которой не работало вообще ничего :xD
Last updated