Как мы тестируем MPLS и segment routing: label-пути под трафиком

MPLS – то место, где control plane и forwarding plane расходятся чаще всего. LSP в CLI поднят, а пакеты все равно идут куда-то не туда. Мы тестируем обе плоскости вместе: каждый label-путь на стенде несет трафик, и генератор докладывает, что вышло с дальнего конца, с какими метками и через сколько миллисекунд.

Стенд

DUT – это P- или PE-роутер, физический или виртуальный, на портах от 1G до 100G. Генератор эмулирует окружающее ядро: соседей LDP, head end и tail end RSVP-TE, IS-IS или OSPF с расширениями segment routing, BGP для сервисов VPNv4, VPNv6 и EVPN. Для SR-дизайна генератор проталкивает стеки меток нужной дизайну глубины, с adjacency SID и prefix SID, а где используются, с binding SID и flex-algo.

Сверху едут сервисы: L3VPN с сотнями VRF, псевдопровода L2VPN, EVPN поверх MPLS, у каждого свой трафик и своя маркировка QoS. Конфигурация берется из вашего шаблона.

Что проверяем

• Распределение меток: сессии LDP и RSVP-TE сотнями, время выделения и установки меток, поведение при рестарте сессии
• SR-MPLS: генератор проталкивает стеки из 3, 5 и больше меток, форвардинг проверяется по каждой метке на выходе; максимальную глубину SID у DUT измеряем, цифра из даташита не в счет
• Traffic engineering: явные пути, ограничения по полосе, вытеснение одних LSP другими и проверка, идут ли пакеты тем путем, который контроллер считает рабочим
• Сервисы: L3VPN с сотнями VRF и тысячами маршрутов на VRF, L2VPN с обучением MAC, маршруты EVPN каждого типа, у каждого трафик и проверка QoS на выходе
• Защита: TI-LFA, RSVP fast reroute и BGP PIC; разрыв в миллисекундах по каждому потоку при отказе линка или узла, с защитой и без
• Масштаб: сколько меток, LSP и VRF устройство держит, пока что-то не перестанет устанавливаться; ищем плавным наращиванием вместо чтения лимита
• MTU и QoS: большие кадры с полным стеком меток, маппинг DSCP в EXP, policing и shaping на каждый LSP

Что обычно ломается

Стеки меток. Устройство заявляет максимальную глубину SID 10 и корректно форвардит до 5; с 6 меток пакеты уходят на неверный next hop или дропаются на стадии хеширования, которая так глубоко не смотрит. SR-контроллер об этом не знает и продолжает считать пути из 7 меток.

Второй случай: fast reroute медленнее самого отказа. TI-LFA обещает 50 мс, измеренный разрыв на первом потоке 50 мс, на 400-м VRF уже 3 секунды, потому что резервный путь ставится по каждому префиксу и устройство делает это по очереди. В даташите указан первый поток.

Третий случай: QoS через границу меток. Биты EXP корректно копируются при push, теряются при penultimate hop pop в определенной комбинации функций, и голосовой класс едет последний хоп как best effort. Видно только тогда, когда сервис работает с реальным трафиком и маркировка читается на выходе.

Что в отчете

Время установки сессий и меток. Измеренная глубина SID. Таблица защиты по каждому сценарию и сервису: событие, затронутые потоки, разрыв по потоку, медиана и худший. Проверка сервисов по каждому VRF и псевдопроводу, с маркировкой на выходе. Кривая наращивания масштаба. Конфигурация устройства, эмулированное ядро, прошивка и скорости портов, чтобы вендор мог повторить любую строку.

С чего начать

Пришлите нам модель устройства, прошивку, которую планируете запускать, и топологию, в которой оно будет стоять. Мы ответим тест-планом: пункты проверки, схема стенда и сроки. План бесплатный, отчет остается у вас, его можно показать вендору. Напишите нам или посмотрите, что еще умеет стенд.