Как мы тестируем BGP: 1M маршрутов, выдернутый линк и секундомер

В даташите роутера написано: «BGP: 4M маршрутов, 1000 пиров». Число честное в том смысле, что таблица помещается в память. Оно ничего не говорит о том, сколько времени устройство ставит эти маршруты, что происходит с форвардингом в это время и сколько секунд трафик уходит в черную дыру после падения одного аплинка. Эти 3 вещи мы и измеряем.

Стенд

Устройство под тестом (DUT) стоит в стойке, порты 1G, 10G или 100G подключены к генератору трафика. Генератор эмулирует соседей: eBGP-аплинки, iBGP route reflector, несколько сотен пиров, если так требует дизайн, с семействами адресов IPv4 и IPv6, VPNv4 для MPLS-дизайнов, EVPN там, где устройство работает лифом фабрики. Каждый эмулированный пир анонсирует свой кусок таблицы, суммарно до 1M маршрутов, и тот же генератор шлет трафик в эти префиксы, так что мы видим и RIB, и форвардинг.

Конфигурация ваша. Мы берем политику из продакшен-шаблона: community, local preference, фильтры по AS-path, лимиты префиксов, те route map, которые реально написала команда эксплуатации. Тест на пустом конфиге рассказывает про чип. Тест на вашем конфиге рассказывает про вашу сеть.

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

• Установка сессий: 100, 500 и больше пиров поднимаются одновременно, с MD5 или TCP-AO, если они есть в дизайне; время до состояния Established у каждой сессии
• Загрузка таблицы: 1M маршрутов анонсируются разом, время до попадания последнего префикса в FIB, CPU и память во время загрузки
• Политики: в каждый route map и prefix list подаются маршруты, которые должны пройти, и маршруты, которые должны отсеяться; результат читаем со стороны генератора
• Сходимость: падает пир, выдергивается линк, отзывается префикс; генератор замеряет разрыв форвардинга по каждому затронутому потоку в миллисекундах
• Churn: непрерывные флапы нескольких тысяч префиксов в течение часа, forwarding plane все это время под нагрузкой
• Лимиты: max prefix limit, graceful restart и таймеры BFD, route dampening, если он включен
• Прогон: 24 часа на 80% измеренной емкости с таблицей маршрутов и трафиком, затем проверка, что ничего не утекло

В списке от 80 до 150 пунктов в зависимости от дизайна. У каждого пункта критерий прохождения записан до старта теста, поэтому результат выглядит как «да» или «нет», без оценочных суждений.

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

Таблица грузится нормально. Сюрпризы живут в сходимости. Типичный случай: устройство с таблицей на 1M маршрутов отзывает 300 000 префиксов 40 секунд после отказа аплинка, и все эти 40 секунд трафик к потерянным префиксам уходит в мертвый интерфейс. Такой строки в даташите не было.

Второй случай: политика, которая работает на 10 префиксах и тихо перестает работать на масштабе. Prefix list на несколько тысяч записей, route map с continue, и часть маршрутов проходит там, где должна была отсеяться. В продакшене этого никто не видит, пока какой-нибудь клиент не анонсирует что-то странное.

Третий случай: BFD с интервалом 50 мс держится на 10 сессиях и начинает флапать на 200, потому что control plane в этот момент занят установкой маршрутов. Лечится таймером, но число лучше знать до раскатки, чем после первой аварии.

Что в отчете

Каждый пункт с критерием и результатом. Сходимость таблицей: событие, число затронутых префиксов, разрыв в миллисекундах, худший поток и медианный. Загрузка таблицы кривой: установленные маршруты по времени. Графики CPU и памяти за весь прогон. Конфигурация устройства и эмулированных пиров, чтобы вендор мог воспроизвести любой пункт. Версия прошивки, скорости портов, схема стенда. Ничто в отчете не зависит от того, какой генератор мы использовали.

С чего начать

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