Теоретические основы и архитектура
EVPN (Ethernet VPN, RFC 7432) - современная технология L2 и L3 VPN, которая решает слабые места VPLS. В VPLS MAC-адреса изучаются flood-and-learn в плоскости данных, что даёт избыточный BUM-трафик и медленную сходимость при переезде хоста. В EVPN MAC-адреса, изученные локально на порту PE, анонсируются через MP-BGP маршрутом Route Type 2 (MAC/IP Advertisement), а удалённые PE ставят их в таблицу из control plane. Ключевая функция - MAC Mobility: когда виртуальная машина переезжает (например, vMotion) на другой PE, новый PE изучает MAC локально и анонсирует Route Type 2 с расширенным community MAC Mobility и увеличенным sequence number. Остальные PE, в том числе прежний, выбирают маршрут с большим номером, и прежний PE отзывает свой. Время переключения определяется скоростью обнаружения и обработки BGP; кратковременные потери на переезде возможны.
Зачем EVPN, если есть VPLS
В VPLS MAC-адреса изучаются в плоскости данных (flood-and-learn): неизвестный unicast и BUM заливаются во все PW, а таблицы MAC на PE между собой не обмениваются. EVPN (RFC 7432, EVPN-MPLS) переносит обучение MAC в плоскость управления: PE, увидев MAC на своём AC, анонсирует его по BGP (адресное семейство AFI 25, SAFI 70, l2vpn evpn), остальные PE устанавливают маршрут и отправляют unicast точно по назначению без flooding. Дополнительно EVPN даёт active-active multihoming, быструю сходимость при отказе (mass withdraw), подавление ARP, ограничение BUM и единый механизм для L2 и L3 (RFC 9136 IP Prefix).
Элементы модели
EVI (EVPN Instance) - экземпляр сервиса на PE, аналог VFI, содержит один или несколько MAC-VRF (bridge domain). Для каждого EVI задаются RD (Route Distinguisher, делает маршруты уникальными) и RT (Route Target, определяет, какие PE импортируют маршруты). Типичная схема: RD уникален на PE и EVI (например 10.255.0.1:100 на PE1 и 10.255.0.2:100 на PE2), RT один на EVI (65000:100) - так все PE одного EVI импортируют общие маршруты. Если задать одинаковый RD на разных PE, маршруты одного MAC с разных PE отбросятся как дубликаты. Ethernet Tag ID идентифицирует VLAN внутри EVI (для VLAN-based сервиса равен 0). ESI (Ethernet Segment Identifier, 10 байт) идентифицирует сегмент, подключающий CE к одному или нескольким PE; ESI = 0 означает single-homed.
Service interface: VLAN-based (один EVI на VLAN, Ethernet Tag 0), VLAN-bundle (несколько VLAN в одном MAC-VRF) и VLAN-aware bundle (несколько bridge domain в одном EVI с Ethernet Tag ID).
Типы маршрутов
Тип 1, Ethernet Auto-Discovery (A-D): per-ES (ESI + Ethernet Tag 0xFFFFFFFF) используется для mass withdraw: при отказе линка к CE PE отзывает один маршрут, и все удалённые PE сбрасывают сразу все MAC этого сегмента, не дожидаясь отзыва каждого Type 2. Per-EVI A-D (с меткой) нужен для aliasing: удалённый PE балансирует трафик к MAC на все PE, подключённые к сегменту, даже если MAC анонсировал только один.
Тип 2, MAC/IP Advertisement: RD, ESI, Ethernet Tag ID, длина MAC (48), MAC, длина IP (0, 32 или 128) и IP, Label1 (метка MPLS для L2, нужна именно эта метка на дне стека), опционально Label2. Содержит MAC Mobility extended community при перемещениях.
Тип 3, Inclusive Multicast Ethernet Tag: каждый PE анонсирует для EVI свой адрес и PMSI Tunnel attribute (тип туннеля 6 - ingress replication, плюс метка, по которой получатель принимает BUM). Из этих маршрутов PE строит список для flooding: ingress replication - отправка копии BUM каждому удалённому PE по метке (P2MP LSP тоже возможны).
Тип 4, Ethernet Segment: анонсирует участие PE в ES; нужен для выбора Designated Forwarder (DF). DF по умолчанию определяется по алгоритму modulo: PE сортируются по IP, DF для VLAN = PE с индексом (Ethernet Tag mod N). DF отправляет BUM в сегмент, остальные PE (non-DF) блокируют BUM в сторону CE. Таймер ожидания анонсов 3 секунды (RFC 7432). Route Target для Type 4 - ES-Import RT (6 байт из ESI), поэтому импортируют такие маршруты только PE одного сегмента.
Тип 5 (RFC 9136) переносит IP-префиксы между EVI и используется в интеграции L2/L3 и в маршрутизации по IRB.
MAC mobility
Когда хост (например, виртуальная машина) переезжает с PE1 на PE2, PE2 видит MAC на своём AC (GARP/RARP) и анонсирует Type 2 с MAC Mobility extended community, sequence number которого равен предыдущему значению плюс один (первое появление обходится без community, то есть sequence 0). Все PE выбирают маршрут с наибольшим sequence number; при равенстве побеждает меньший IP-адрес PE. PE1, получив более новый маршрут для MAC, который он считал локальным, отзывает свой анонс и очищает локальную запись. Результат: трафик к MAC переключается за одну BGP-итерацию без ожидания aging. Sticky/static MAC помечаются флагом в community и не перемещаются (sequence не растёт).
Защита от петель и "флапающих" MAC: RFC 7432 рекомендует duplicate MAC detection: при M перемещениях за N секунд (по умолчанию M=5, N=180) MAC признаётся дубликатом, PE перестаёт его анонсировать и сигнализирует об этом оператору, возврат автоматически возможен через несколько минут. Без этого петля на CE приводила бы к бесконечному росту sequence number.
