Как мы тестируем IPv6 и переход: dual stack, NAT64, 464XLAT

В даташите маршрутизатора IPv6 стоит галочкой рядом с IPv4, и throughput на оба протокола указан один. На стенде протоколы часто расходятся: на мелких пакетах, с заголовком расширения, за ACL с проверкой портов, внутри шлюза NAT64, который переписывает каждый заголовок. Мы ищем точку, где fast path отдает IPv6 процессору.

Стенд

Маршрутизатор, L3-коммутатор, firewall, шлюз CGNAT или NAT64 ставится на стенд CloudLAB с релизом ПО, ACL и таблицей маршрутизации из продакшена. Генератор шлет IPv4 и IPv6 из диапазонов для бенчмаркинга через порты 1G, 10G или 100G (400G и быстрее по проекту), считает каждый кадр и ставит на нем метку времени, а neighbour discovery работает весь прогон. CPU устройства опрашивается каждую секунду вне полосы теста, поэтому уход в программную обработку виден в том же прогоне: throughput падает, CPU растет.

Для переходных механизмов стенд играет обе стороны: клиентов только с IPv6 за шлюзом NAT64 с DNS64, сторону CLAT в 464XLAT, сторону B4 в DS-Lite с IPv4 внутри туннелей IPv6, CE-устройства MAP-T, IPv4-серверы на дальнем конце. Нативная пересылка идет по RFC 5180, переходные сценарии по RFC 8219. Соотношение IPv4 и IPv6 берем из вашего трафика или задаем шагами 90/10, 50/50 и 10/90, пока переход только в планах.

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

• Dual stack: throughput и задержка IPv4 и IPv6 по размерам кадров на тех же портах, затем смеси; включенный IPv6 не должен стоить IPv4 ни одного кадра
• Заголовки расширения: каждый по отдельности, затем цепочка длиннее 32 байт от 128 B и выше, с ACL по портам TCP или UDP и без него; hop-by-hop на 1, 10 и 50 % скорости
• Фрагменты: фрагментированный IPv6 через фильтры и через транслятор, и что делает с большими передачами отброшенный ICMPv6 Packet Too Big
• Neighbour discovery: сколько соседей держит порт до начала потерь и за какое время тысячи соседей снова разрешаются после флапа линка
• NAT64 с DNS64: новые трансляции в секунду, одновременные привязки, throughput по размеру пакета против нативного IPv6, ответы DNS64 в секунду и их задержка
• 464XLAT, DS-Lite, MAP-T: те же числа для каждого механизма из дизайна, на абонента и в сумме, с накладными расходами по размеру пакета
• Failover: пара трансляторов переключается под нагрузкой; какие привязки переживают переключение и сколько ждут новые потоки

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

Фильтр. В типичной приемке маршрутизатор пересылает чистый IPv6 на line rate при любом размере кадра. Цепочка заголовков расширения за ACL, который смотрит на порты TCP, опускает его примерно до 70 % на 128 B, а CPU стоит у предела. Без ACL та же цепочка ничего не стоит: маршрутизатор ее просто не читает. В продакшене ACL есть.

Медленная полоса транслятора. Шлюзы NAT64 и border relay MAP-T подбирают по throughput TCP на больших пакетах. Фрагментированный UDP, первый пакет каждой новой привязки и ICMP-ошибки часто уходят в программную обработку. В типичном проекте фрагментированный UDP проходил через шлюз примерно на трети от скорости обычного.

Path MTU. Фильтр, который режет ICMPv6 Packet Too Big, пропускает любой ping и любой мелкий запрос. Маршрутизаторы IPv6 пакеты не фрагментируют, поэтому большая передача через туннель или транслятор встает на первом полноразмерном пакете.

Перестройка соседей. Порт с несколькими тысячами хостов держит их в стабильном режиме. После флапа устройство разрешает их всех разом, и в типичном проекте последние хосты получали трафик обратно на несколько секунд позже первых.

Что в отчете

Throughput, задержка и потери по размерам кадров для IPv4, чистого IPv6, каждого заголовка расширения и цепочки, с CPU по каждому прогону. Числа по каждому протоколу внутри каждой смеси. Трансляции в секунду, привязки и throughput для каждого переходного механизма рядом с нативной пересылкой на тех же портах маршрутизатора. Масштаб ND и восстановление после флапа. Конфигурация, адресный план и наборы заголовков, чтобы прогон повторился на следующем релизе. Если та же коробка делает еще и NAT444, блоки портов и логирование разобраны в посте про CGNAT.

С чего начать

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