Заканчивается память RouterOS: снизить conntrack и логи, не игнорируя leak

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

Когда в /system resource print поле free-memory падает к нулю, RouterOS начинает убивать сервисы, рвать WinBox и писать not enough memory. Сначала измерьте потребителей: conntrack, DNS cache, memory-log, queues, user-manager/dude, контейнеры. Снизьте их осознанно. Если после reboot график RAM пила вниз без роста трафика — это leak или баг версии, не «мало правил firewall». Не игнорируйте leak в пользу вечного max-entries по потолку.

Не отключайте connection tracking: NAT умрёт. Не чистите RAM «сбросом конфигурации» первым шагом.

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

Устройство «тупеет» через N часов аптайма. Reboot помогает на день. Или сразу после включения free memory уже аномально мал для модели (на hEX сотни МБ, на mAP — десятки).

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

1. tcp-established-timeout и прочие таймауты conntrack по умолчанию при P2P/сканерах — таблица растёт.
2. /system logging action memory с огромным memory-lines плюс log каждого drop.
3. /ip dns set cache-size слишком большой на 32–64 МБ устройстве.
4. Address-list с автозаполнением (brute force list без timeout).
5. Утечка в конкретной версии wifi/IPsec — лечится апгрейдом/даунгрейдом по changelog, не «ещё cache».
6. Контейнеры, The Dude, SMB, proxy (если пакеты установлены).
7. Много simultaneous queues / accounting.

Диагностика

/system resource print
/system resource irq print
/ip firewall connection print count-only
/ip firewall connection tracking print
/ip dns print
/system logging print
/system logging action print

Оценка conntrack:

/ip firewall connection print count-only
/ip firewall connection print count-only where protocol=tcp
/ip firewall connection print count-only where protocol=udp

Сотни тысяч на SOHO — патология. Тысячи — норма офиса.

Логи:

/log print count-only

Пакеты:

/system package print
/container print

Снимите backup, пока устройство ещё слушается:

/system backup save name=before-mem
/export file=before-mem

Решение

Сценарий A. Раздут conntrack

Найдите, кто открывает сессии (торрент за NAT, scan с WAN на проброшенные порты). Закройте лишний dstnat. Таймауты (пример, не копируйте слепо на VoIP):

/ip firewall connection tracking
print
set udp-timeout=10s udp-stream-timeout=30s

TCP established по умолчанию длинный — не режьте его до секунд, сломаете долгие загрузки. Сначала уберите flood.

max-entries ограничивает потолок. Слишком низкий — дроп новых сессий. Ставьте по факту модели и трафика, не «1024 на всех».

Сценарий B. Логи в RAM

/system logging action
set memory memory-lines=1000
/system logging print

Уберите topics=firewall в memory на проде. Для разбора — remote syslog, не гигабайт в RAM. См. логи.

Удалите временные action=log в filter.

Сценарий C. DNS cache

/ip dns
set cache-size=2048KiB
/ip dns cache flush

Cache нужен, но на 64 МБ RAM не держите десятки мегабайт кэша.

Сценарий D. Leak

1. Зафиксируйте версию /system resource print.
2. Проверьте changelog/форум конкретной версии — не выдумывайте CVE.
3. План: backup → безопасный апгрейд на известный stable канала.
4. Если leak начался сразу после пакета wifi-qcom — не откатывайте «вслепую» без backup и окна.

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

График Memory стабилен 24 часа при типичной нагрузке. not enough memory не повторяется. Conntrack count в ожидаемом диапазоне. WinBox не выбивает. После искусственного прогона трафика RAM возвращается, а не только растёт.

/system resource print
/log print where message~"memory"

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

• Модель с 32 МБ и CAPsMAN+VPN — не влезает, нужен другой класс устройства.
• После каждого export RAM падает — смотрите скрипты scheduler.
• Подозрение на компрометацию: чужие scheduler/scripts, неизвестный /user, странный NAT. Снимайте export, меняйте пароли с чистого канала, не «ещё cache-size».

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

• Мониторинг free-memory (Netwatch не для RAM; внешний мониторинг SNMP hrStorage / RouterOS API).
• Логи на syslog-сервер.
• Не включать ненужные пакеты.
• Плановые апгрейды со чтением changelog про memory leak.

Что считать leak, а что — рабочий потолок модели

Потолок: на устройстве с 256 МБ при CAPsMAN, IPsec и большом conntrack free-memory в десятки мегабайт после рабочего дня может быть нормой, если график выходит на плато. Leak: после reboot память тает линейно ночью при почти пустом conntrack и пустом DNS cache. Тогда не крутите cache-size и не режьте udp-timeout как «лечение» — фиксируйте /system resource print раз в час, версию пакетов и changelog.

Проверьте scheduler и скрипты, которые делают /export или пишут файлы каждую минуту: на маленьком flash это ещё и износ, плюс пики RAM.

/system scheduler print
/system script print
/file print

Удалите тестовые .backup с устройства после копирования на ПК. Пакет container без memory-limit на CPE — типичный способ получить OOM за вечер. Не отключайте tracking. Если leak совпал с конкретной 7.x — план апгрейда на известный stable, а не ежедневный reboot как архитектура.

FAQ

Reboot каждый день через scheduler — ок?

Это маскировка. Для leak до патча — временный костыль с документированием, не архитектура.

Помогает ли /ip firewall connection tracking set enabled=no?

Снимет RAM и сломает NAT/filter state. Запрещено как «решение нехватки памяти».

Почему после WinBox file copy память не возвращается?

Кэши ОС могут держаться. Смотрите тренд часов, не минуту после копирования .backup.

DNS cache flush безопасен?

Да, кратковременно вырастет число запросов upstream. Не лечит leak.

Контейнер в 7.16+ сколько RAM?

Столько, сколько лимитите /container. Без лимита он съест edge-роутер. Не ставьте container на CPE с 128 МБ «поиграть».

Помогает ли reboot раз в ночь через scheduler?

Как временный костыль при доказанном leak до патча — только с записью в журнал изменений и графиком RAM. Это не эксплуатационная норма: вы маскируете рост conntrack или утечку пакета wifi/IPsec. Сначала снизьте логи и cache, закройте лишний dstnat, проверьте /container и скрипты. Если после чистого reboot без трафика память всё равно тает — планируйте апгрейд по changelog, а не cron reboot. Не ставьте connection tracking enabled=no: NAT и stateful filter умрут вместе с «экономией» RAM.