Часть 7. VxLAN. Multihoming

Цель

  • Настроить отказоустойчивое подключение клиентов с использованием EVPN Multihoming

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

  • Клиент подключен двумя линками к различным Leaf

  • Со стороны клиента настроен агрегированный канал (LACP)

  • Настроен multihoming для работы в Overlay сети. В нашем случае - ESI LAG.

  • Зафиксирован в документации - план работы, адресное пространство, схема сети, конфигурацию устройств.

  • Протестирована отказоустойчивость. Необходимо убедиться, что связнность не теряется при отключении одного из линков.

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

Введение

В качестве технического долга имеем:

  • zero touch provisioning устройств

  • раскатывание конфигурации в автоматическом режиме

Вводятся новые понятия, а именно:

  • ES - ethernet segment. An Ethernet segment is associated with an access-facing interface of a VTEP and represents the connection with a host device. Each Ethernet segment is assigned a unique value known as Ethernet segment identifier (ESI). When a host device is connected to more than one VTEPs, then the ESI for these connections remains the same. Источникarrow-up-right

  • ESI - Ethernet Segment Identifier. An EVPN LAG is identified using an Ethernet segment identifier (ESI). An ESI is a mandatory attribute that is required to enable EVPN LAG server multihoming. Источникarrow-up-right

    В EVPN-сетях — это ключ, по которому несколько PE-маршрутизаторов/коммутаторов идентифицируют общий Ethernet-сегмент (Multi-Homing). Он позволяет:

    1. Обнаруживать и управлять мультихомингом (Active/Active или Active/Standby).

    2. Избегать петель и дублирования кадров через split-horizon.

    3. Корректно маршрутизировать/рассылать трафик в сценариях отказоустойчивости и балансировки нагрузки.

Без ESI протокол EVPN не мог бы грамотно различать отдельные физические сегменты и обеспечивать мультихоминг с сохранением изоляции и согласованности маршрутов/кадров.

Схема сети

За основу принимается всё та же топология из задания Часть 5. VxLAN. EVPN L2

В нее добавлена еще одна пара leaf'ов. Заодно проверим на надежность "конфигуратор" из Netbox и задокументируем процесс онбоардинга новых устройств xD

Для упрощения и экономии ресурсов будем работать внутри Rack 3 и Rack 4 согласно схемы

  • Внутри Rack 4 будет работать устройство на базе RHEL 8.4 с агрегированным (Bond0) интерфейсом, состоящим из двух подключений: первое - в сторону no-osl-dc1-f1-r03k04-lf01, второе - в сторону no-osl-dc1-f1-r03k04-lf02.

Это эмуляция подключения конечного сервера в двум ToR коммутаторам в пределах серверной стойки.

адресация
общая, немного сокращённая схема

Тут мне попадается офигенная композиция в Яндекс.Музыке Valhalla Callingarrow-up-right и еще один трек Ghost Riders in the Skyarrow-up-right. Фак, чистый кайф!

VXLAN thunders in twilight’s dome,

ESI’s banner guides the roaming band.

Multihome stands as bonds of home,

Valhalla calls—EVPN at hand!

Тут мы останавливаемся думать за генерацию ESI - он же Ethernet Segment Identifier. Самый распространённый формат — тип 0x00 (Manual), где 9 байт могут быть заданы вручную (часто встречается тип 00:aa:bb:cc:dd:...).

Предполагается, что ESI сегмент не распространяется за пределы серверной стойки. В таком случае мы можем привязаться к физической стойке (Rack)

В Netbox вводятся два новых поля в Customization -> Custom Fields для документирования значений полей:

  • ESI ID - идентификатор Ethernet сегмента с проверкой по Regex ^[0-9A-Fa-f]{4}(:[0-9A-Fa-f]{4}){4}$

  • LACP System-id - идентификатор LACP для коммутаторов с проверкой по Regex ^[0-9A-Fa-f]{4}(.[0-9A-Fa-f]{4}){2}$

Шаблон для генерации конфигурации для leaf'ов претерпел значительные изменения и заставил потратить на себя кучу времени. Основные изменения коснулись секций для интерфейсов. Теперь по каждому типу интерфейсов собственный цикл обработки.

Ниже приведен пример для секции Port-Channel и кастомных полей:

Пока не ясно как и откуда генерировать ESI и LACP System-ID. В лабораторных условиях принимаем за истину, что LACP System-ID - это mac-адрес mgmt порта первого устройства в паре. Для Rack 4 это будет 5001.000D.0000

Файлы конфигураций устройств

Сегодня будут приложены только файлы spin'ов и leaf'ов (Rack 3, Rack 4)

Вот тут показаны дополнительные поля:

Конфигурационные файлы устройств. Напоминаю, что это выгрузка из Netbox без ручных правок:

Тестирование на отказ

Сценарий 1. Как оказалось, он же "единственный"

Пробую отключить левое плечо у сервера и вижу, что трафик не бежит. Смотрю в табличку маршрутизации на лифе стойки 3 и вижу маршрут только через одну AS - 4200131337. Вот они бенефиты отдельных AS для лифов!

А проблема заключалась в том, что в Netbox для одного лифа Po1 был настроен в access vlan 10, а для второго - нет! После правки в Netbox и заливки нового конфига результат на лифе следующий:

Вывод команды sh bgp evpn route-type auto-discovery

Вывод команды show bgp evpn route-type mac-ip

Как проходит трафик для пингования сервера

Вместо скриншотов видео на Youtube

ESI LAG. Тестыarrow-up-right

Что-то вместо выводов

  1. Конфигуратор в Netbox работает очень даже сносно :-) Что прям радует.

  2. Отдельная AS для leaf'ов удобна в плане восприятия информации о маршрутах и в траблшутинге

  3. Документирование через Netbox не всегда можно решить "в лоб". Я попался на Port-Channel, ESI и LACP SID. А также, нужно думать между разными вендорами и платформами.

  4. ESI LAG кажется удобнее, чем MC-LAG. Коллеги добились использования >2 устройств для подключения серверов, нет необходимости сопровождать peerlink и синхронизировать какие-то части конфигурации, можно использовать мультивендорную среду.

Bonus

Доставка конфигурации на устройства из Netbox

Так получилось, что в процессе чтения и рефлексии набрел на плагин Netbox netbox-config-diffarrow-up-right , который все время обходил стороной. Но это же то, что мне было нужно все это время!

Что умеет плагин:

  • Config Diff - сравнение конфигурации устройства из Render Config и реальным состоянием с помощью подключения через драйвер

  • Config Managemenet - доставка конфигурации на устройства и приведение его в эталонное состояние

Настройка плагина хорошо описана в документацииarrow-up-right.

После установки необходимо настроить платформу на вкладке Config Diff Plugin -> Compliance -> Platform Settings

Список поддерживаемых платформ:

  • arista_eos

  • cisco_iosxe

  • cisco_iosxr

  • cisco_nxos

  • juniper_junos

После этого можно запустить скрипт для проверки состояния устройств из вкладки Customization -> Scripts -> ConfigDiffScript

Результат работы скрипта:

После того, как скрипт отработает, можно провалиться в устройство и посмотреть Config Diff на вкладке Config Compliance

И самое интересное! Доставка конфигурации на устройства

На вкладке Config Diff Plugin -> Config Managemenet -> Configuration Requests создается новый запрос на изменение конфигурации и следующий порядок действий:

  1. Collect Diffs - сбор информации о разности конфигураций.

  2. Approve - разрешение на применение конфигурации

  3. Schedule - планирование конфигурации к применению

В джобах можно посмотреть историю:

И там же посмотреть, что получилось:

Лог выполнения джоба в JSON

chevron-rightЛогhashtag

}

Last updated