Как мы тестируем CGNAT: трансляции в секунду, порты и логи

В даташите CGNAT два числа: одновременные сессии и throughput. Сайзинг умножает число абонентов на среднее число сессий, и на бумаге все сходится. В 21:00 коробка упирается в другие пределы: сколько новых трансляций она создает в секунду, сколько портов получает каждый абонент и какую нагрузку дают логи трансляций, которые хранят для запросов по закону. Это мы и измеряем, с вашим числом абонентов и вашим часом пик.

Стенд

CGNAT ставится на стенд CloudLAB как отдельное устройство или маршрутизатор с сервисной картой либо запускается на стенде как виртуальная функция. Стенд эмулирует абонентов внутри, по одному адресу из общего диапазона 100.64.0.0/10 на домашний роутер, так, как их видит CGNAT в схеме NAT444, а снаружи серверы интернета. Трафик stateful, TCP и UDP по вашему профилю: веб, видео, игры, VoIP, DNS, а число сессий на абонента берется из выгрузки NetFlow или pcap вашего часа пик. Конфигурация тоже ваша: пулы, размер блока портов, таймауты, ALG, режим логирования и HA-пара.

Счетчики и CPU устройства опрашиваются каждую секунду out of band. Коллектор логов на стенде считает каждую запись, которую шлет коробка, на одной шкале с нагрузочным тестом, и падение скорости установления совпадает с секундой, когда логи начали копиться в очереди.

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

• Скорость установления: новые трансляции в секунду, TCP и UDP отдельно, до отказа в создании записей
• Потолок одновременных трансляций: таблица заполнена до заявленного числа при идущем трафике и боевых таймаутах; что происходит со следующей сессией, когда места нет
• Блоки портов: размер и число блоков на абонента против профиля часа пик; абонент, у которого порты кончились, получает новый блок или теряет сессии, с тем же публичным адресом или другим
• Логирование: по сессиям против логов по блокам, записи в секунду через syslog или IPFIX, скорость установления с логами и без
• ALG: SIP и FTP через трансляцию, адреса внутри payload переписаны верно, скорость установления с каждым включенным ALG
• Hairpinning и mapping: 2 абонента за одним CGNAT достают друг друга через публичные адреса; endpoint-independent mapping и filtering для игр и VoIP
• Stateful failover: активный узел выключается под нагрузкой; сохраненные сессии по протоколам, сохраненные блоки и публичные адреса, секунды до полной скорости

Базовая пересылка по размерам кадра, IPv4 и IPv6 на одних портах, идет по процедуре RFC 5180. NAT64, DS-Lite и остальные механизмы перехода разобраны в отдельном посте: как мы тестируем переход на IPv6.

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

Блок портов. В типичном проекте план дает 512 портов на блок и до 4 блоков на абонента, из расчета на несколько десятков сессий на квартиру в среднем. В час пик дом, где торрент-клиент работает рядом с игровой приставкой, добирается до 4-го блока, и его новые сессии отбрасываются. Коробка считает эти отказы в счетчике, который никто не опрашивает, и не пишет о них ни одной записи в лог.

Логирование. Логи по сессиям превращают каждую новую трансляцию в запись. В типичном проекте скорость установления упала примерно на треть, когда поток логов вышел на полный пик, и коллектор начал терять записи раньше, чем коробка. Логирование по блокам пишет одну запись на блок, и нагрузка на коробку почти исчезла.

Failover. HA-пара синхронизирует сессии, активный узел падает под нагрузкой, TCP-сессии переживают переход. UDP-трансляции, созданные в последнюю секунду перед переключением, до резервного узла не дошли: VoIP и игры за ними регистрируются заново, а часть абонентов возвращается с другим публичным адресом и вылетает из интернет-банка. «Stateful failover» в даташите верен для большинства сессий, и отчет считает те, которые он теряет.

Что в отчете

Трансляции в секунду и потолок одновременных трансляций по каждому профилю трафика и режиму логирования, рядом CPU. План блоков портов, проверенный против вашего часа пик: доля абонентов, которые уперлись в лимит, и что коробка делала дальше. Записи логов в секунду и потерянные записи, на коробке и на коллекторе. Результаты по ALG и hairpinning по каждому протоколу, с захватами трафика. По failover: потерянные сессии по протоколам, абоненты, у которых сменился публичный адрес, секунды до полной скорости. Следующий релиз проходит те же случаи по приложенным конфигурации и профилю.

С чего начать

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