Высокая загрузка CPU MikroTik: найти firewall, tracking или шторм

Короткий ответ

Высокий CPU на RouterOS 7 почти никогда не лечится «поменять модель в голове». Снимите /tool profile (или Profiler в WinBox): firewall, networking, bridging, wireless, management. Параллельно /ip firewall filter print stats и /ip firewall connection print count-only. Дальше развилка: шторм/loop, слишком умный filter без FastTrack, раздутый conntrack, flood на input, или CAPsMAN/шифрование.

Не отключайте firewall навсегда и не включайте FastTrack вслепую на IPsec. Сначала доказательство профилировщиком.

Симптомы и как отличить

hEX/ax2 «тёплый», WinBox открывается секундами, NAT жив, но скорость «как на 10 Мбит». Это может быть CPU, а не канал провайдера.

Мало RAM при высоком CPU — смотрите память, процессы связаны через conntrack.

Возможные причины

1. Нет fasttrack-connection на established/related при гигабитном NAT на слабом CPU.
2. action=log в filter/nat на high-traffic правилах.
3. Layer-7, длинные address-list, сложный mangle на каждый пакет.
4. Connection tracking table у упора, flood SYN, P2P.
5. Ethernet loop, DHCP flood, Wi‑Fi retry.
6. IPsec AES без железа / WireGuard на CCR слишком хорошо, на mAP — плохо.
7. /tool flood-ping, bandwidth-test, контейнеры на 7.16 (если пакет container установлен).

Диагностика

/system resource print
/system resource cpu print
/tool profile

В CLI profile работает интерактивно; в WinBox Tools → Profile удобнее для скриншота в заявку.

/ip firewall filter print stats
/ip firewall connection print count-only
/ip firewall connection tracking print
/interface print stats

Сравните RX на bridge/ether2.. с WAN. RX лавины на LAN при маленьком WAN — внутренний шторм, не DDoS из интернета.

Топик логов firewall, critical, error — диагностика по логам.

Проверка FastTrack:

/ip firewall filter print where action=fasttrack-connection

Нулевые packets при гигабитном NAT на hAP — FastTrack не бьёт, CPU будет в firewall.

Решение

Сценарий A. NAT на CPU, FastTrack отсутствует

Типичные два правила выше остального forward (как в defconf):

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related hw-offload=yes
add chain=forward action=accept connection-state=established,related

hw-offload=yes имеет смысл на чипах, где offload поддерживается; если не поддерживается, правило всё равно fastpath'ит на CPU лучше, чем полный filter.

Для VPN оставьте исключения выше FastTrack — иначе сломаете туннель.

Сценарий B. Log-шторм

Удалите или disable правила с action=log на forward established. Оставьте log только на drop new с prefix.

Сценарий C. Conntrack flood

Временно, с пониманием риска, ужесточите:

/ip firewall filter
add chain=input action=drop connection-state=new protocol=tcp in-interface-list=WAN dst-port=23,22,8291

22/8291 на WAN и так должны быть закрыты. Для SYN-flood смотрите connection-limit точечно, не «drop все new».

Не ставьте connection tracking set enabled=no: умрёт NAT.

Сценарий D. Loop / broadcast

Отключите подозрительный порт, включите RSTP, loop-protect — статья про loop. CPU в bridging сразу падает, если это петля.

Как проверить, что проблема устранена

/system resource print
/tool profile
/ip firewall filter print stats

CPU в простое офиса — десятки процентов максимум на SOHO, не 100%. Profiler больше не залипает в firewall на established. WinBox отзывчив. Прогоните iperf/скорость провайдера: если канал 500 Мбит и CPU снова 100% без FastTrack — вернитесь к сценарию A.

Если не помогло

• Модель слабее канала (NAT 1 Гбит на старом RB750) — апгрейд железа, не «ещё правила».
• Только при бэкапе/графике The Dude — вынесите мониторинг.
• Только в рабочее время Wi‑Fi — радио, не NAT.
• Подозрение на leak после апгрейда — обновление на известный stable, не рандомный testing.

Профилактика

• FastTrack + узкие исключения VPN.
• Никакого log на fast path.
• Мониторинг CPU и conntrack count.
• Storm/RSTP на bridge.
• Не запускать bandwidth-test на проде против интернета без окна.

Как отделить flood на input от тяжёлого NAT

Снимите две картины CPU: в простое офиса и во время жалобы. Если profiler в простое уже в firewall, ищите log-правила и сложный mangle. Если в простое тихо, а в час пик networking+firewall — смотрите скорость WAN и наличие FastTrack.

Отдельно посчитайте new-сессии с WAN:

/ip firewall connection print count-only where src-address~"203.0.113."
/ip firewall filter print stats where chain=input

Рост input drop на 23/22/8291 — сканеры, их должен отсекать ранний drop, не тяжёлый accept с log. Рост forward new без FastTrack на гигабите для hAP/hEX — ожидаемый упор CPU: либо FastTrack с VPN-исключениями, либо устройство слабее канала.

Не запускайте /tool bandwidth-test на этом же роутере «чтобы понять, тянет ли»: вы сами создадите 100% CPU и исказите профиль. Тест скорости — с хоста в LAN к внешнему серверу или между двумя ПК через роутер.

Контейнеры и графики The Dude на том же CPU, что и NAT, в 7.16+ легко съедают бюджет SOHO-модели. /container print и /system resource print в одной заявке. Если management в профиле скачет пачками — закройте лишние WinBox-сессии и отключите torch.

FAQ

FastTrack всегда снижает CPU?

На транзите established — да. На input (сам роутер) FastTrack в defconf не стоит. Flood на WinBox порт FastTrack не спасёт.

hw-offload vs FastTrack?

Это связанные, но разные механизмы. Offload зависит от чипа и bridge/VLAN. Если VLAN filtering включён, часть offload падает — читайте возможности именно вашей модели в документации MikroTik, не обобщайте.

Почему CPU 50% — это плохо?

На CCR с туннелями 50% может быть нормой. На hAP ac² в простое 50% — ищите torch/CAPsMAN/scan.

Отключить conntrack для «ускорения»?

Убьёте masquerade и state firewall. Нельзя.

Контейнеры в 7.16 грузят CPU?

Да, если пакет установлен и контейнер крутится. /container print. Не держите lab-контейнеры на edge-роутере офиса.