Перенос гигабитного NAT на MikroTik CCR1009: 70 тысяч соединений и 28,9% CPU

27 февраля в 13:45 перенесли NAT для клиентской сети (~1 Гбит/с трафика) с выделенного сервера на FreeBSD на MikroTik CCR1009-7G-1C-1S+ — 9-ядерный роутер на процессоре Tilera. Вопрос был простой: не просядет ли пропускная способность. Видимого снижения не произошло — но график соединений показал не то, что ожидали.

Контекст: это восстановленный разбор эксплуатации 2019 года. Ниже — показатели сохранившегося мониторинга, а не синтетический тест или оценка актуального оборудования.

Пропускная способность не просела

WAN-интерфейс держит тот же дневной цикл нагрузки, что и до переезда: ночной минимум у нуля, дневной пик около 0,8–0,9 Гбит/с на входящем канале. За неделю после переключения:

Метрика	Входящий	Исходящий
Средняя	555,73 Мбит/с	109,22 Мбит/с
Разовый максимум мониторинга	5,44 Гбит/с	775,9 Мбит/с
Последнее значение	800,02 Мбит/с	119,32 Мбит/с

Разовое значение 5,44 Гбит/с заметно выбивается из видимой формы графика. Причину всплеска по сохранившимся данным установить нельзя, поэтому как показатель устойчивой пропускной способности мы его не используем: рабочая полка остаётся в пределах 0,8–0,9 Гбит/с.

После переноса видимого снижения пропускной способности нет — объём трафика сохранил прежний дневной цикл. Метрики задержки и потерь за тот период не сохранились, поэтому этот график не доказывает отсутствие любой деградации качества.

Соединения подскочили в разы — и это нормально

А вот что изменилось резко — счётчик активных соединений на файрволе. До переноса он держался в районе 5–12 тысяч, с редкими всплесками. Сразу после переключения на CCR1009 счётчик за несколько часов дошёл до пиковых 70,1 тысячи (среднее за неделю — 15,07К, минимум — 4,21К).

Причина — не в росте клиентского трафика, а в смене точки его учёта. До переноса трафик клиентской /22-сети проходил через CCR транзитом к FreeBSD-серверу с пулом примерно из 10 публичных IP и был исключён из conntrack на CCR правилом notrack. FreeBSD-сервер при этом вёл собственное состояние трансляций, но на график соединений CCR оно не попадало.

После переезда и NAT, и conntrack этой сети оказались на CCR1009 — роутер начал видеть и считать реальное число одновременных соединений. Скачок на графике не означает появления нового трафика, но для CCR это новая работа: теперь он сам хранит состояние этих соединений.

А что с CPU

tool profile, снятый сразу после переключения, показывает общую структуру нагрузки CCR1009 в этот момент:

NAME              CPU USAGE
firewall-mgmt      1.5%
snmp                 0%
ethernet              0%
firewall           9.8%
networking        14.8%
management          2.8%
routing               0%
profiling             0%
total             28.9%

total 28.9% — общая загрузка процессорного ресурса, а не сумма, которую можно разделить на девять и получить цену NAT на одно ядро. Профиль также включает всю работу роутера, поэтому по одному снимку после переключения нельзя отдельно вычислить вклад NAT.

При этом признаков насыщения CPU в доступных данных нет. Посуточные графики нагрузки по ядрам за неделю показывают тот же дневной цикл, что и до переноса: пики около 20–30% на ядро в первые дни недели, до 40–46% в последние дни (уже после переезда). Рост есть, но он не выходит за рамки наблюдавшихся суточных колебаний — как и было написано в оригинальной заметке: «прирост нагрузки есть, незначительный».

Версия RouterOS, пакетный профиль и сопоставимый снимок tool profile непосредственно до переключения не сохранились. Поэтому это результат конкретной эксплуатации, а не универсальный тест производительности CCR1009.

Итог

В наблюдавшейся конфигурации ожидаемого упора в CPU после переноса гигабитного NAT не произошло: сразу после переключения общая загрузка составляла 28,9%, устойчивого снижения пропускной способности на графике нет. Одновременно изменилась видимость нагрузки — без notrack на CCR стало ясно, сколько соединений на самом деле держит клиентская сеть.

Вывод исходной заметки сохраняется: CCR1009 справился с конкретной нагрузкой 2019 года с имевшимся запасом. Эти данные не позволяют пересчитать стоимость NAT на одно ядро или превратить наблюдение в общий предел производительности модели.