VPWS, VPLS и EVPN: лабораторная

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

Лабораторная: сравнение VPWS, VPLS и EVPN вместе с L2 OAM. Инженер поднимает параллельные L2VPN и проверяет, как каждый ведёт себя при отказе. Используются три уровня проверки: 1. VCCV (RFC 5085) проверяет сам псевдопровод: тест идёт внутри PW по тому же пути, что и данные (LSP ping для PW, ping mpls pseudowire). 2. IEEE 802.1ag CFM: Maintenance Domain (MD), Maintenance Association (MA), Maintenance Endpoint (MEP); Continuity Check Messages (CCM) отправляются с интервалом от 3,33 мс до 10 минут, отказ фиксируется после потери 3,5 интервалов. 3. ITU-T Y.1731 добавляет измерения задержки (DM), вариации задержки и потерь кадров (LM). Время переключения при отказе определяется интервалом CCM, способом обнаружения и платформой; цель 50 мс достижима только при быстром обнаружении и аппаратной поддержке.

Зачем нужна OAM в L2VPN

Pseudowire, VPLS и EVPN скрывают от клиента весь путь через MPLS: клиент видит провод или коммутатор, а провайдер обязан отвечать за него. Если ping клиента не проходит, причина может быть в AC, во внешней транспортной метке, в PW-метке, в MTU или в сигнализации. OAM (Operations, Administration, Maintenance) даёт инструменты, которые проверяют каждый уровень по отдельности, и в лабораторной вы пройдёте их по слоям: AC, транспорт LDP, PW, клиентский L2.

Уровни OAM и кто за что отвечает

Транспортный LSP: LSP Ping и Traceroute (RFC 4379) отправляют MPLS Echo Request (UDP 3503, адрес 127.0.0.0/8 с Router Alert) по тому же стеку меток, что и данные, и проверяют, что FEC привязан к LSP на всём пути. Pseudowire: VCCV (RFC 5085) - канал в самом PW, позволяющий отправить проверочное сообщение так, чтобы оно шло тем же путём, что и данные клиента. Ethernet-сегмент: IEEE 802.1ag CFM и ITU-T Y.1731 работают между клиентскими портами (UNI) или между PE, проверяя именно L2-связность. Физический линк: 802.3ah (EFM OAM) для одного физического линка.

VCCV: типы канала и проверки

VCCV определяет два параметра, согласуемых при установке PW в Interface Parameters (sub-TLV 0x0C, ограничения по битам). Control Channel (CC) тип 1: PWE3 control word, у которого первый ниббл равен 0001 (в обычном данных кадре 0000), поэтому PE отличает OAM-пакет и обрабатывает его, а не отправляет в AC; тип 2: Router Alert label (метка 1) между транспортной и PW меткой; тип 3: TTL-expiry - PW label с TTL=1, пакет доходит до PE через истечение TTL (используется для traceroute по сегментам MS-PW). Connectivity Verification (CV): ICMP Ping, LSP Ping (с PW FEC: sub-TLV FEC 128 type 10, содержит peer, PW ID и PW Type) и BFD (RFC 5885). Команды ping mpls pseudowire и ping mpls l2circuit используют LSP Ping с PW FEC: ответ приходит только если на удалённом PE существует PW с тем же ID и меткой, что делает проверку куда надёжнее обычного ping клиента.

BFD для PW

BFD (RFC 5880) даёт обнаружение отказа за сотни миллисекунд вместо секунд LDP. Для PW применяется VCCV-BFD (RFC 5885): BFD-пакеты передаются в канале PW (CC тип 1 или 3), интервалы min-tx/min-rx 300 мс и multiplier 3 дают время обнаружения около 900 мс. Статус BFD может сигнализироваться в PW Status TLV (BFD status signaling), и тогда падение PW на одном конце отражается на AC другого PE. Важно: интервалы ниже 100 мс нужны только при аппаратной поддержке BFD, иначе сессии флапают при нагрузке на CPU.

PW Status и сходимость

При отказе AC на PE2 PE2 отправляет Notification с PW Status TLV (бит 0x4 или 0x2: Local AC fault), PE1 переводит PW в Down (Remote AC fault), не дожидаясь истечения LDP keepalive (60 с, hold 180 с по умолчанию у Cisco). Если Status TLV не согласован, остаётся только отзыв метки при удалении PW, а при выходе PE целиком из строя - таймаут LDP-сессии. Поэтому BFD на IGP (или на LDP) и PW Status вместе определяют время восстановления. Для VPLS и EVPN аналог: LDP MAC Address Withdraw (RFC 4762) и mass withdraw через Type 1 A-D route.

Ethernet CFM (802.1ag, Y.1731)

Модель: Maintenance Domain (MD) с уровнем 0-7 (клиент обычно 5-7, оператор 3-4, линк 0-1), внутри него Maintenance Association (MA), у каждого устройства своя MEP (Maintenance End Point), между ними MIP (промежуточные точки). Пакеты: CCM (Continuity Check Message, мультикаст, интервалы 3.33 мс, 10 мс, 100 мс, 1 с, 10 с, 1 мин, 10 мин; отказ фиксируется при потере 3.5 интервалов), LBM/LBR (Loopback, L2-эквивалент ping), LTM/LTR (Linktrace, L2-traceroute). Y.1731 добавляет измерение задержки (DMM/DMR), потерь (LMM/LMR), AIS. Сообщения CFM пересылаются через PW прозрачно (клиентский CFM) либо терминируются на PE (оператор).

MTU - главная причина PW "Up, но не работает"

Метод проверки: ping по ядру между loopback с размером 1526 байт и DF-битом, затем клиентский ping с DF. Если PW Up, а большие кадры теряются, значит MTU какого-то интерфейса меньше размера кадра с метками. LSP Ping может сообщить о MTU через Echo Reply с кодом Return Code (в том числе с Downstream Mapping, где указан MTU следующего интерфейса).

Алгоритм диагностики

1. AC: интерфейс Up, нужный VLAN принимается. 2) IGP/LDP: loopback PE2 доступен, есть метка (LDP bindings), targeted-сессия Operational. 3) PW: VC Up, метки local и remote ненулевые, MTU local = remote, control word согласован. 4) Данные: ping mpls pseudowire успешен, затем клиентский ping с размером 1500 и DF. 5) Быстрое обнаружение: BFD Up, интервал и multiplier соответствуют плану. Отладка снизу вверх позволяет локализовать неисправность и не гадать по симптому на уровне клиента.

Что нужно знать про сбои и их внесение в лабораторной

В лабораторной вы намеренно ломаете сервис: меняете VC ID, MTU, shutdown AC на PE2, убираете loopback из LDP. По каждому сбою заранее запишите, что покажут команды. Это учит видеть признаки: DOWN/MM/EM/CM в Junos и Cisco, Remote AC fault, пустой Outgoing label, ping mpls с ошибкой "no label entry", потеря BFD Up.

Схема архитектуры и топология

+--------+   PW (VC ID 100)   +--------+
|  PE1   | ================== |  PE2   |
+--------+   [transport | PW label | PW ACH | IP/UDP LSP ping]   +--------+
  VCCV: Echo Request -->  inside the PW, same path as the customer data
        <-- Echo Reply (in-band or via IP path, depending on the reply mode)
  CFM:  MEP-1 on the AC of PE1 <---- CCM every N ms ----> MEP-2 on the AC of PE2

Схема прохождения трафика и стек меток

VCCV (RFC 5085) packet, control channel type 1 (PW ACH):
[Transport label] [PW label] [PW ACH: 0001 | version 0 | reserved | channel type 0x0021 (IPv4)] [IP/UDP dst 3503: MPLS LSP Ping Echo Request]
Type 2: [Transport label] [Router Alert label (1)] [PW label] [IP/UDP LSP ping]
Type 3: [Transport label] [PW label with TTL=1] [IP/UDP LSP ping]

Таблица состояний и параметров

Архитектурная модель и принцип работы

В реальных сетях оператора MPLS объединяет оборудование различных производителей. Ниже представлены практические примеры конфигурации и вывода команд Data Plane / Control Plane для четырёх платформ: Cisco IOS-XE/XR, Huawei VRP, Juniper Junos и MikroTik RouterOS v7. Обратите внимание на различия в синтаксисе и механизмах распределения меток.

Практическая конфигурация (Cisco, Huawei, Juniper, MikroTik)

Cisco (IOS-XE/XR)

bfd-template single-hop PW-BFD
 interval min-tx 300 min-rx 300 multiplier 3
pseudowire-class PW-ETH-OAM
 encapsulation mpls
 control-word
 vccv bfd template PW-BFD udp
 vccv bfd status signaling
l2vpn xconnect context VPWS100
 member GigabitEthernet2 service-instance 100
 member 10.255.0.2 100 encapsulation mpls pw-class PW-ETH-OAM