Теоретические основы и архитектура

В центрах обработки данных плоскость данных EVPN чаще строится на VXLAN, а не на MPLS: фабрика leaf-spine даёт IP-подложку с ECMP, а MPLS-метки не нужны. RFC 8365 описывает, как те же маршруты EVPN (Type 1-5) обслуживают VXLAN: идентификатор сервиса переносится как VNI, туннельные концы называются VTEP, а BUM-трафик доставляется через ingress replication или multicast в underlay. Для оператора важен стык двух миров: ЦОД с VXLAN и WAN с EVPN-MPLS. DCI (Data Center Interconnect) можно построить растяжкой VXLAN через WAN или на gateway, который завершает один домен и заново объявляет маршруты в другом (RFC 9014). Урок разбирает VXLAN-заголовок (RFC 7348), накладные расходы 50 байт и их влияние на MTU, сравнивает EVPN-VXLAN и EVPN-MPLS и показывает варианты gateway/stitching на границе ЦОД. Предполагается знание Type 2/3/5, ESI и IRB из предыдущих уроков модуля.

Почему VXLAN в ЦОД

Фабрика leaf-spine состоит из коммутаторов с маршрутизируемыми линками (часто eBGP в подложке, RFC 7938), любой leaf связан со всеми spine, а между двумя leaf существует несколько равноценных путей. MPLS-ядро в такой фабрике избыточно: ему нужны LDP или SR, метки, а оборудование ЦОД часто их не поддерживает. VXLAN (RFC 7348) инкапсулирует Ethernet-кадр в UDP/IP, и для подложки достаточно IP-маршрутизации с ECMP; равномерность по путям даёт хэш внутренних заголовков, который VTEP записывает в UDP source port.

Заголовок VXLAN, VTEP и VNI

После внешних Ethernet, IP и UDP (порт назначения 4789) идёт 8-байтовый заголовок VXLAN: флаги (бит I = 1 означает валидный VNI), резерв, 24-битный VNI и ещё один резервный байт. VNI делит сеть на до 16 млн сегментов (против 4094 у VLAN). VTEP (VXLAN Tunnel Endpoint) - устройство, которое инкапсулирует и декапсулирует кадры; его IP-адрес (обычно loopback) используется как source и next hop. Устройство, где VNI связан с VLAN и локальными портами, называется L2-шлюзом, где VNI связан с VRF - L3-шлюзом (L3 VNI для симметричного IRB).

EVPN для VXLAN (RFC 8365)

Сама по себе VXLAN использует flood-and-learn: неизвестные MAC заливаются в multicast-группу, и MAC изучаются по трафику. EVPN убирает этот механизм: Type 2 объявляет MAC и IP, Type 3 строит список VTEP для VNI, Type 5 несёт префиксы, Type 1 и Type 4 обеспечивают multihoming. Отличия от EVPN-MPLS: в поле метки передаётся VNI (24 бита) вместо MPLS-метки; extended community BGP Encapsulation указывает тип туннеля VXLAN; next hop - адрес VTEP; RT и RD часто формируются автоматически из номера AS и VNI (RFC 8365 допускает автогенерацию, поведение зависит от платформы). Для L3 VNI используется Router's MAC: внутренний destination MAC в пакете между VTEP равен MAC принимающего VTEP.

BUM-трафик

Есть два способа доставки. Ingress replication (head-end replication): Type 3 несёт PMSI Tunnel attribute с типом 6, и каждый VTEP формирует список соседей для VNI и отправляет N-1 unicast-копий. Подложке достаточно unicast-маршрутизации, но нагрузка ложится на ingress и растёт с числом VTEP. Multicast в подложке: VNI отображается на группу, подложка строит дерево PIM (Sparse Mode или Bidir), а репликацию выполняют spine. Это экономит ресурсы leaf, но подложка должна поддерживать PIM и распределение групп, а число групп ограничено ресурсами устройств. Подавление ARP/ND и ограничение unknown unicast снижают объём BUM в обоих вариантах.

Накладные расходы и MTU

Внешние заголовки добавляют 14 байт Ethernet, 20 байт IPv4, 8 байт UDP и 8 байт VXLAN: всего 50 байт для IPv4 в подложке (70 для IPv6, ещё +4 при внешнем 802.1Q-теге). Внутренний кадр сохраняет свой Ethernet-заголовок, поэтому для IP-пакета 1500 байт IP MTU подложки должен быть не меньше 1550. Фрагментировать VXLAN-пакеты нельзя, потому что VTEP обычно ставит DF-бит и отбрасывает такие пакеты; правильное решение - jumbo (9000-9216) на всех линках фабрики и gateway. При MPLS накладные расходы составляют 4 байта на метку, обычно 8-12 байт (транспортная метка, метка EVI, иногда ESI label), поэтому проблема с MTU там менее острая.

Split horizon: local bias вместо ESI label

В EVPN-MPLS BUM-кадр защищён ESI label. В VXLAN метки нет, поэтому применяется local bias (RFC 8365, раздел 8.3.1): ingress VTEP копирует BUM-кадр от CE всем остальным VTEP, включая другой VTEP того же ES, но получатель не отправляет такой кадр на локальный интерфейс этого ES, если IP-адрес источника входит в список VTEP сегмента (по маршрутам Type 4). Поэтому для multihoming в VXLAN критичны корректные Type 4 и актуальный список соседей.

DCI: растяжка VXLAN и gateway

Первый вариант - растянуть VXLAN между ЦОД поверх IP-подложки WAN: единый VNI и единый BGP-домен EVPN. Просто, но домен отказа становится общим: ошибка в одном ЦОД (например, шторм BUM или лавина MAC) влияет на оба. Второй вариант - DCI gateway на границе каждого ЦОД (RFC 9014): gateway завершает VXLAN и переобъявляет маршруты в WAN как EVPN-MPLS (или как EVPN-VXLAN с другим VNI), изменяя метку или VNI, RT и next hop. Для WAN с MPLS-ядром поверх SR или LDP это естественно: gateway работает как PE и VTEP одновременно. Gateway объединяют в ES для резервирования; DF определяет, кто пересылает BUM между доменами. Для L3 DCI обычно достаточно маршрутов Type 5 или стыка IP-VRF с L3VPN (VPNv4) на границе; точный механизм определяется платформой.

Практические проблемы