Современные облачные центры обработки данных и периферийные VPN-инфраструктуры высокой доступности требуют неблокирующей пропускной способности и восстановления после аварий за доли секунды. Исторически сетевые инженеры использовали агрегацию каналов между несколькими шасси (MLAG) или закрытые механизмы стекирования для резервированного подключения серверов к коммутаторам leaf.

Однако технология MLAG связывает плоскости управления двух коммутаторов через закрытый межузловой канал (ISL), что приводит к расхождению конфигураций, состоянию разделенного мозга (split-brain) и жестким пределам масштабирования. Инженерный совет интернета (IETF) устранил эти архитектурные барьеры, стандартизировав Ethernet Virtual Private Network (EVPN) multi-homing в спецификациях RFC 7432 и RFC 8365.

Отделяя избыточность каналов от физических соединений между коммутаторами, EVPN формирует открытую плоскость управления на основе Multiprotocol BGP (MP-BGP). Использование идентификаторов сегментов Ethernet (ESI), режима all-active, процедур выбора Designated Forwarder (DF) и симметричных anycast-шлюзов обеспечивает надежное активное перенаправление трафика на уровнях 2 и 3 в современных фабриках.

Тупик проприетарного MLAG: почему избыточность каналов уровня 2 не масштабируется

На протяжении двух десятилетий многошассийная агрегация каналов служила основным методом резервирования подключений хостов без блокировки портов протоколом Spanning Tree (STP). MLAG объединяет два физических коммутатора, формируя для подключенного сервера единый агрегированный транк LACP стандарта IEEE 802.1AX.

Несмотря на широкое применение, архитектура MLAG имеет фундаментальные недостатки:

  1. Проприетарная синхронизация плоскости управления: MLAG требует закрытых служебных протоколов синхронизации через выделенный межузловой канал (ISL). Операторы не могут объединять в единую пару коммутаторы разных производителей.
  2. Риски разделенного мозга (Split-Brain): При отказе соединения ISL и потере контрольных пакетов оба коммутатора активируют одинаковые виртуальные адреса IP и MAC. Это вызывает дублирование пакетов, искажение таблиц ARP на узлах и потерю трафика.
  3. Ограничение двумя шасси: Топологии MLAG принципиально не поддерживают объединение более двух коммутаторов, что исключает одновременное подключение сервера к трем или четырем узлам leaf из разных аппаратных стоек.

EVPN заменяет эту закрытую конструкцию, переводя координацию между шасси в стандартные сигнальные сообщения MP-BGP.

Архитектура BGP EVPN Multi-Homing: плоскость управления по стандарту RFC 7432

Спецификация RFC 7432 определяет EVPN как плоскость управления на базе протокола BGP для служб Ethernet поверх фабрик IP и MPLS. В архитектуре EVPN multi-homing резервные коммутаторы leaf работают с полностью независимыми плоскостями управления, не требуя выделенных межузловых линий связи.

Синхронизация осуществляется исключительно через маршрутные анонсы MP-BGP AFI 25 (L2VPN) и SAFI 70 (EVPN), передаваемые поверх опорной IP-сети.

Идентификаторы сегментов Ethernet (ESI): отделение каналов от аппаратных платформ

Сегмент Ethernet (Ethernet Segment, ES) представляет собой совокупность резервных физических каналов, связывающих подключенное устройство с несколькими коммутаторами leaf (узлами Provider Edge, PE). Каждому сегменту присваивается уникальный 10-байтный идентификатор Ethernet Segment Identifier (ESI).

В RFC 7432 стандартизированы различные типы ESI. В оверлейных сетях ЦОД чаще всего применяются Type 0 (ручная конфигурация) и Type 1 (автогенерация на основе MAC-адреса и ключа порта LACP IEEE 802.1AX):

+--------------------+---------------------------------------+
| Тип ESI (1 байт)   | Значение (9 байт)                     |
+--------------------+---------------------------------------+
| Type 0x00          | Произвольный 9-байтный идентификатор  |
| Type 0x01          | MAC-адрес (6B) + Port Key (2B) + 0    |
+--------------------+---------------------------------------+

Когда независимые коммутаторы leaf фиксируют одинаковый ненулевой ESI на своих нисходящих портах, они автоматически распознают общее подключение к одному физическому сегменту и запускают процедуры координации.

Маршруты EVPN на практике: автообнаружение и атрибуты сегментов Ethernet

Стандарт RFC 7432 вводит специализированные типы маршрутов BGP NLRI для управления многоузловым подключением:

  • Маршрут типа 1 (Ethernet Auto-Discovery Route): Анонсируется для каждого ESI для подтверждения поддержки режима all-active и передачи меток фильтрации split-horizon. Этот тип маршрута также обеспечивает мгновенный массовый отзыв при обрыве линии.
  • Маршрут типа 2 (MAC/IP Advertisement Route): Передает MAC-адреса хостов и обнаруженные привязки ARP/ND на сегменте ESI вместе с метками VNI уровня 2.
  • Маршрут типа 4 (Ethernet Segment Route): Обнаруживает соседние коммутаторы leaf, подключенные к тому же сегменту ESI, обмениваясь IP-адресами для последующих выборов Designated Forwarder.

Пересылка All-Active: симметричная балансировка нагрузки между коммутаторами

Технология EVPN поддерживает два режима резервирования: Single-Active и All-Active. В режиме Single-Active трафик передает только один выбранный коммутатор, а остальные каналы находятся в ожидании. В режиме All-Active все подключенные коммутаторы одновременно пересылают одноадресные кадры от сервера и к нему.

Поскольку сервер настраивает стандартный транк LACP по всем физическим линиям, исходящий трафик симметрично распределяется между коммутаторами leaf. Коммутаторы инкапсулируют пакеты в туннели VXLAN и передают их через фабрику без возникновения сетевых петель.

Архитектура предотвращения петель: фильтрация Split-Horizon с помощью ESI-меток

В топологии all-active, когда хост отправляет широковещательный, неизвестный одноадресный или многоадресный (BUM) пакет на коммутатор Leaf-1, этот коммутатор тиражирует кадр через фабрику VXLAN на коммутатор Leaf-2. Однако Leaf-2 также подключен напрямую к тому же серверу через общий сегмент ESI.

Если бы Leaf-2 направил этот пакет обратно на сервер, возникло бы зацикливание трафика уровня 2. EVPN предотвращает такую ситуацию с помощью механизма фильтрации split-horizon:

  1. Коммутаторы leaf передают метку ESI Label в маршрутах типа 1 (Route Type 1 per-ES).
  2. При инкапсуляции пакета BUM в заголовок VXLAN коммутатор Leaf-1 добавляет исходную метку туннеля ESI.
  3. Получая инкапсулированный пакет из фабрики, Leaf-2 проверяет внутреннюю метку ESI источника. Если пакет поступил из локального сегмента ESI, Leaf-2 сбрасывает кадр на порту этого сегмента, продолжая пересылку на все остальные интерфейсы.

Аппаратная фильтрация полностью исключает эхо-пакеты без необходимости программной блокировки физических портов.

Выборы Designated Forwarder (DF): подавление дублирования широковещательного трафика

Хотя режим all-active позволяет всем подключенным коммутаторам одновременно пересылать известный одноадресный трафик, широковещательные данные BUM из ядра сети должны передаваться клиенту только одним устройством в пределах каждого широковещательного домена. Если бы оба коммутатора пересылали широковещательный трафик серверу, сегмент был бы перегружен дубликатами.

EVPN решает эту задачу с помощью выборов назначенного пересыльщика (Designated Forwarder, DF) для каждого виртуального сегмента VLAN.

Алгоритм выборов по модулю: вычислительный механизм и риски неравномерности

Спецификация RFC 7432 описывает стандартный алгоритм выборов DF на основе деления по модулю. Коммутаторы собирают анонсы маршрутов типа 4 для целевого ESI, формируют отсортированный список IP-адресов кандидатов и присваивают им порядковые индексы i (от 0 до N - 1).

Коммутатор, выбранный в качестве Designated Forwarder для сегмента V, определяется равенством:

DF Index = V mod N

Здесь V представляет собой идентификатор VLAN, а N — общее число участвующих коммутаторов PE. Этот простой метод может приводить к дисбалансу распределения нагрузки, если диапазон номеров VLAN распределен неравномерно.

Выборы DF на основе приоритетов: детерминированное управление по стандарту RFC 8584

Для устранения недостатков алгоритма по модулю стандарт RFC 8584 вводит расширяемую процедуру выборов DF. В ней используется расширенное сообщество BGP DF Election Extended Community:

+-----------------------------------------------------------+
| Приоритет DF (2 байта)   | Флаги выборов DF (2 байта)     |
+-----------------------------------------------------------+

Инженеры задают числовой приоритет (от 0 до 65535) для каждого коммутатора. Устройство с максимальным приоритетом назначается основным DF. Стандарт RFC 8584 также поддерживает плавные таймеры упреждения и бит Don't Preempt Me (DP), что исключает колебания трафика при перезагрузке и повторном вводе узла в строй.

Распределенные Anycast-шлюзы: симметричная маршрутизация IRB на коммутаторах Leaf

Многоузловое подключение EVPN напрямую взаимодействует со службами интегрированной маршрутизации и мостового соединения (IRB) для передачи данных между подсетями. Традиционные протоколы резервирования шлюза первого перехода (FHRP, такие как VRRP) неэффективно направляют весь трафик через единственный активный маршрутизатор.

В отличие от них, EVPN развертывает распределенный Anycast-шлюз на всех коммутаторах leaf:

  • Каждый коммутатор настраивается с идентичным виртуальным IP-адресом и виртуальным MAC-адресом шлюза по умолчанию (например, IP 10.100.1.1/24, MAC 00:00:5E:00:01:01).
  • При поступлении запроса ARP от сервера локальный коммутатор leaf мгновенно обрабатывает его на месте.
  • Маршрутизация между подсетями выполняется непосредственно на первом коммутаторе leaf по архитектуре Symmetric IRB (RFC 9135). Пакеты передаются через фабрику с инкапсуляцией в VNI уровня 3 (например, VNI 50000), минуя избыточные транзитные петли через центральные маршрутизаторы.

Быстрая сходимость и массовый отзыв: предотвращение потери пакетов при авариях

В крупных центрах обработки данных на одном сегменте Ethernet могут размещаться десятки тысяч MAC-адресов. При обрыве физического кабеля между Leaf-1 и сервером отзыв каждого отдельного маршрута типа 2 (анонса MAC) через протокол BGP занял бы несколько секунд, приводя к образованию черных дыр в передаче данных.

EVPN устраняет эту задержку за счет механизма псевдонимов и массового отзыва (Mass Withdrawal):

MAC-адрес (00:1A:2B:3C:4D:5E) ---> Анонсирован с ESI-123 (Маршрут типа 2)
Leaf-1 и Leaf-2               ---> Анонсируют доступ к ESI-123 (Маршрут типа 1)

Удаленные коммутаторы создают записи ECMP для балансировки нагрузки в сторону обоих узлов Leaf-1 и Leaf-2 для всех адресов, связанных с ESI-123. При фиксации локального обрыва линии:

  1. Коммутатор Leaf-1 немедленно отзывает только один маршрут типа 1 для сегмента ESI-123.
  2. Удаленные коммутаторы мгновенно исключают Leaf-1 из списков следующего перехода ECMP для всех MAC-адресов данного ESI, переключая весь поток данных на Leaf-2 за считанные миллисекунды.
  3. Очистку отдельных анонсов типа 2 узел Leaf-1 выполняет в фоновом режиме без сбоев активных сессий.

Для анализа параметров маршрутизации и проверки характеристик внешних каналов инженеры могут протестировать сетевые маршруты через инструмент проверки IP.

Инфраструктура RiceGuard Edge Fabric: отказоустойчивые сети Anycast-шлюзов

В архитектуре VPNRice опорная сеть высокой доступности RiceGuard использует BGP EVPN all-active multi-homing по стандарту RFC 7432 на всех региональных периферийных узлах присутствия. Отказ от закрытых кластеров MLAG обеспечивает стабильность операторского уровня:

  • Бесшовное обслуживание периферии: Периферийные шлюзы могут обновлять системное ядро без разрыва соединений. Изменение приоритета RFC 8584 позволяет плавно перенаправлять входящий трафик на соседние узлы перед началом регламентных работ.
  • Симметричная балансировка ECMP на входе: Потоки данных от различных магистральных провайдеров равномерно распределяются между вычислительными узлами all-active, предотвращая асимметричные перегрузки. Пользователи, загружающие сборки через клиентское приложение, получают стабильную пропускную способность.
  • Интеграция с телеметрией опорной сети: Состояния виртуальных оверлеев уровней 2 и 3 согласуются с данными сетевого мониторинга, развивая подходы, рассмотренные в статьях про программирование сетей SRv6 и хэширование ECMP для GRE-in-UDP и GENEVE.

Практическая реализация: настройка EVPN Multi-Homing в стеке Linux FRRouting

Открытые сетевые стеки, такие как FRRouting (FRR), поддерживают спецификацию EVPN multi-homing RFC 7432 в среде Linux. Ниже приведен пример конфигурации сегмента Ethernet в режиме all-active и шлюза Anycast в FRRouting:

! /etc/frr/frr.conf
router bgp 65001
 bgp router-id 192.0.2.11
 no bgp default ipv4-unicast
 neighbor FABRIC peer-group
 neighbor FABRIC remote-as 65000
 neighbor 192.0.2.1 peer-group FABRIC
 !
 address-family l2vpn evpn
  neighbor FABRIC activate
  advertise-all-vni
  advertise-default-gw
  autort rfc8365-compatible
 exit-address-family
!
interface bond0
 description Dual-Homed CE Link
 evpn multihoming es-id 00:11:22:33:44:55:66:77:88:99
 evpn multihoming es-sys-mac 00:11:22:33:44:55
 evpn multihoming df-preference 50000
!
interface vlan100
 description Anycast Gateway Subnet
 ip address 10.100.1.1/24
 ip gateway-address 10.100.1.1

Переход от проприетарных комплексов MLAG к открытому стандарту BGP EVPN all-active multi-homing дает инфраструктурным командам предсказуемую изоляцию сбоев, совместимость с оборудованием различных поставщиков и горизонтальное масштабирование.