Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Часть 5. VxLAN. EVPN L2

Цель

  • Настроить Overlay на основе VxLAN EVPN для L2 связанности между клиентами

Ожидаемый результат

  • Настроен BGP peering между Leaf и Spine в AF l2vpn evepn.

  • Настроена и проверена IP связанность между клиентами в первой зоне.

  • В документации зафиксирован план работ, адресное пространство, схема сети и конфигурация устройств.

Небольшое введение

Перед началом работы на этим Д/З немного меняем топологию сети. Делаем задел на будущее - масштабирование в пределах одного ДЦ, масштабирование в 2 и более ДЦ с растягиваением L2 (чего делать очень не рекомендуют), включение в схему с l2vni файрволов.

IP-адресация
Общая схема

Представляем, что у нас:

  • 2 Spine-коммутатора в разных сетевых стойках

  • 2 стойки и в каждой по 2 Leaf-коммутатора и 1 гипервизор на базе VMware ESXi 8.x

  • 1 стойка с парой border-leaf и/или service-leaf. Всего в схеме теперь 8 коммутаторов и 2 гипервизора.

Идем в свой выдуманный ДЦ в Netbox и смотрим на расположение оборудования:

Мы же в самом начале этого увлекательного путешествия решили, что:

  1. Spine-коммутаторы расположены в разных серверных стойках

  2. Leaf-коммутаторы сгруппированы по 2 в качестве Top of Rack устройств (пока это standalone устройства, дальше будем пробовать их в m-lag).

Из-за добавившихся устройств возникла необходимость в обновлении BGP сессий внутри Netbox. Проблема с автоматизацией или генерацией все еще актуальна и не решена, но для минимизации ошибок воспользуемся Excel'ем.

bgp_session.xlsx
15KB
Open

В файле нет рокет сайнс. На первом листе справочники устройств, AS и адресов. На втором листе их можно выбрать из drop-down меню:

А потом скопировать и вставить в поле импорта Netbox:

В результате получается вполне годный список сессий для последующего использования в Netbox Provisioning -> Config Templates

Здесь стоит сделать паузу. Куратор курса дал направление в сторону динамических соседей. Это нужно обдумать, так как инфо в Netbox нужно будет отдавать с устройств. Подумаем позже над этим.

Достижение результата

Шаблон конфигурации

Как и прежде, конфигурация устройств генерируется внутри Netbox на основе его данных через шаблоны. Методом проб и ошибок я пришел к тому, что шаблон нужно разделить для групп устройств. Теперь их два - один для Spine'ов hw5_netbox_spine_bgp_template.jinja2, второй - для Leaf'ов hw5_netbox_leaf_bgp_template.jinja2.

hw5_netbox_leaf_bgp_template.jinja2
4KB
Open
hw5_netbox_spine_bgp_template.jinja2
3KB
Open

Тут, пожалуй, стоит подробнее остановиться на том, как шаблоны работают.

SPINE

Этот шаблон Jinja2 генерирует конфигурацию сетевого устройства (под управлением Arista EOS), используя данные из NetBox и связанных контекстов. Его цель — автоматически сформировать готовый к применению конфиг на основе инвентаря устройства, его интерфейсов, IP-адресов, BGP-сессий, VRF, VLAN, параметров STP и маршрутов.

Ниже — более детальный разбор того, что делает шаблон:

  1. Базовые настройки безопасности и управления:

  • no aaa root: Выключает определённые AAA настройки по умолчанию.

  • Настройка пользователя admin с ролью network-admin и заданным секретом.

  • transceiver qsfp default-mode 4x10G: Определяет режим работы QSFP-трансиверов.

  • service routing protocols model multi-agent: Переключение модели протоколов маршрутизации на «multi-agent» (особенность Arista EOS).

  1. Hostname и VRF для управления:

  • hostname {{ device.name }}: Устанавливает имя устройства согласно данным из NetBox.

  • vrf instance {{ vrfs.mgmt }}: Создаёт VRF для управления (management VRF), имя которого берётся из шаблона vrfs.mgmt.

  1. Управление через API и VRF:

  • В блоке: Настраивается management api http-commands, включается no shutdown для default VRF и управленческого VRF, что позволяет управлять устройством по API из правильного VRF.

  1. Маршрутизация:

  • Включается 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 }}), указывая на шлюз по умолчанию для управления.

  1. Spanning-tree режим:

  • Перебираются настройки STP, заданные в stp_mode, и устанавливается режим spanning-tree.

  1. Настройка интерфейсов:

  • Перебираются все интерфейсы устройства (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 для управления.

  • Добавление описания, если есть.

  1. Настройка 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-маршрутами.

  1. Команда end: Завершение конфигурационного файла.

Итог: Шаблон берёт данные о устройстве, его интерфейсах, IP-адресах, BGP-сеансах, VRF, STP-режиме и т.д. из NetBox (и связанных переменных device, vrfs, stp_mode, bgp_peer_groups, mgmt_default_gw) и формирует полный конфигурационный скрипт для сетевого устройства. Он автоматизирует процесс конфигурации, устраняет необходимость ручной настройки и снижает риск ошибок.

LEAF

Этот шаблон Jinja2 автоматически генерирует конфигурацию сетевого коммутатора (под управлением Arista EOS) на основе данных, полученных из NetBox или других контекстных переменных. Рассмотрим основные аспекты, которые он реализует:

  1. Начальные настройки устройства:

  • no aaa root: Отключение некоторых настроек AAA по умолчанию.

  • Создание пользователя admin с заданной ролью и секретом.

  • Настройка трансиверов QSFP в режим 4x10G.

  • Переключение модели протоколов маршрутизации на multi-agent.

  • Установка hostname устройства (hostname {{ device.name }}).

  1. Настройка VRF и управления:

  • Создаёт VRF для управления (vrf instance {{ vrfs.mgmt }}).

  • В блоке management api http-commands включается доступ к API и отключение shutdown для default и management VRF.

  1. Маршрутизация:

  • Включается 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-маршрутов.

  1. Spanning-Tree и VLAN:

  • Настраивает режимы spanning-tree, используя данные из stp_mode.

  • Генерирует конфигурацию для всех VLAN, связанных с сайтом устройства: vlan <vid> с name <vlan.name>.

  1. Настройка интерфейсов:

  • Перебирает все интерфейсы устройства:

  • Ethernet интерфейсы:

  • Если есть IP-адрес: задаётся MTU, L3-режим (no switchport), BFD, IP-адрес. Интерфейс поднимается или выключается по флагу enabled, добавляется description при наличии.

  • Если IP-адресов нет: интерфейс становится L2 (access или trunk), назначаются VLAN согласно mode и untagged/tagged VLAN.

  • Loopback интерфейсы: Назначаются IP-адреса, описание при наличии.

  • Management интерфейсы: Назначаются IP-адреса, привязываются к управленческому VRF, описание при наличии.

  1. VXLAN конфигурация:

  • Создаётся интерфейс Vxlan1.

  • Указывается vxlan source-interface Loopback10, vxlan udp-port 4789.

  • Перебираются VLAN сайта и для каждого создаётся сопоставление vxlan vlan <vid> vni <100000 + vid> — таким образом, каждому VLAN назначается свой VNI.

  1. 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 сгенерируется следующий конфиг

no-osl-dc1-f1-r03k01-lf01.conf

Конфигурационные файлы

Сгенерированные в Netbox файлы подложены как start-up config в лабе EVE-NG как есть без ручных изменений:

6_no-osl-dc1-f1-r01k01-spn01.txt
3KB
Open
no-osl-dc1-f1-r01k01-spn01
6_no-osl-dc1-f1-r02k01-spn01.txt
3KB
Open
no-osl-dc1-f1-r02k01-spn01
6_no-osl-dc1-f1-r03k01-lf01.txt
3KB
Open
no-osl-dc1-f1-r03k01-lf01
6_no-osl-dc1-f1-r03k01-lf02.txt
3KB
Open
no-osl-dc1-f1-r03k01-lf02
6_no-osl-dc1-f1-r03k02-lf01.txt
3KB
Open
no-osl-dc1-f1-r03k02-lf01
6_no-osl-dc1-f1-r03k02-lf02.txt
3KB
Open
no-osl-dc1-f1-r03k02-lf02
6_no-osl-dc1-f1-r03k03-lf01.txt
3KB
Open
no-osl-dc1-f1-r03k03-lf01
6_no-osl-dc1-f1-r03k03-lf02.txt
3KB
Open
no-osl-dc1-f1-r03k03-lf02

Проверка настроек

Ниже приложены скриншоты с устройства 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

PreviousЧасть 4. Underlay. BGP
NextЧасть 6. VxLAN. EVPN L3

Last updated