Ошибка input does not match any value of new routing mark появляется в RouterOS при попытке сохранить правило mangle или маршрут, где указана метка маршрутизации, которой нет в таблице /routing table. Система буквально сообщает: введённое значение не совпадает ни с одним из существующих значений параметра new routing mark. Чаще всего это происходит после импорта конфигурации с другого роутера, опечатки в имени метки или удаления таблицы маршрутизации, на которую ссылались правила.
Ошибка не критична для работы роутера — трафик продолжает обрабатываться по старым правилам, — но она блокирует сохранение изменений и сигнализирует о рассогласовании конфигурации. Если её игнорировать, политики маршрутизации (PBR, балансировка, VPN-разделение) перестанут работать так, как задумано. Ниже разберём, откуда берётся эта ошибка, как найти проблемное правило и как привести конфигурацию в согласованное состояние.
Что означает эта ошибка в RouterOS
В RouterOS версии 7 механизм меток маршрутизации был переработан: routing mark теперь жёстко привязан к записям в /routing table. Раньше, в RouterOS v6, метку можно было назначить произвольной строкой — таблица создавалась неявно. В седьмой версии система проверяет, существует ли таблица с таким именем, и если нет — отклоняет ввод с сообщением input does not match any value of new routing mark.
То же самое касается параметра routing-table в правилах /ip route rule и /ip firewall mangle. Любая ссылка на несуществующую таблицу вызывает отказ валидации. Это защитный механизм: он не даёт создать «висячие» правила, которые формально есть в конфигурации, но фактически не маршрутизируют трафик.
Ошибка возникает не из-за сбоя, а из-за проверки целостности: RouterOS v7 требует, чтобы каждая routing mark соответствовала существующей записи в /routing table.
Типичные причины появления
Проблема почти всегда сводится к несоответствию между правилами и таблицами маршрутизации. Конкретные сценарии:
- 🔀 Импорт конфигурации с RouterOS v6 — старый экспорт содержит произвольные routing mark, а в v7 соответствующие таблицы не созданы автоматически.
- ✏️ Опечатка в имени метки — например, таблица называется
to_isp1, а в правиле указаноto-isp1илиTo_ISP1(регистр и дефисы имеют значение). - 🗑️ Удалённая таблица — запись из
/routing tableудалили, а правила mangle или route rules, ссылавшиеся на неё, остались. - 📋 Копирование конфигурации с другого роутера — перенесли firewall и routes, но забыли перенести сами таблицы маршрутизации.
- 🔤 Лишние пробелы или невидимые символы при вставке имени метки через терминал или Winbox.
Ещё одна возможная причина — попытка указать метку прямо в поле routing-mark маршрута в /ip route, тогда как в v7 там используется параметр routing-table, принимающий только существующие таблицы. Синтаксис изменился, и старые привычки ввода приводят к отказу.
Как найти проблемное правило
Первое действие — выгрузить текущий список таблиц маршрутизации и сравнить его с метками, которые используются в правилах. В терминале выполните:
/routing table print
/ip firewall mangle print
/ip route rule print
Сопоставьте имена: каждая метка из mangle и route rules должна присутствовать в выводе первой команды. Если какой-то метки в списке таблиц нет — это и есть источник ошибки. Удобно смотреть вывод с деталями через print detail, чтобы видеть все параметры правил.
Для быстрой проверки конкретного имени можно использовать поиск:
/routing table print where name="имя_метки"Пустой вывод означает, что таблицы с таким именем не существует. Дальше два пути: создать таблицу или исправить ссылку в правиле.
В Winbox несуществующие ссылки часто подсвечиваются красным в списках правил — это самый быстрый способ визуально найти «битые» записи без терминала.
Пошаговое исправление ошибки
Последовательность зависит от того, должна ли метка существовать. Если правило осмысленное и метка нужна — создаём таблицу. Если правило устарело — удаляем или исправляем его.
☑️ Приведение конфигурации в порядок
Вариант 1: создать недостающую таблицу. Если метка нужна для policy-based routing, добавьте таблицу с точно таким же именем:
/routing table add name=to_isp1 fibПараметр fib включает таблицу в процесс принятия решений о маршрутизации. После этого правило mangle с new-routing-mark=to_isp1 сохранится без ошибки.
Вариант 2: исправить ссылку в правиле. Если имя в правиле ошибочно, отредактируйте его, указав существующую таблицу:
/ip firewall mangle set [find new-routing-mark="to-isp1"] new-routing-mark=to_isp1⚠️ Внимание: перед любыми правками маршрутизации на удалённом роутере включите Safe Mode в Winbox или используйте /system backup save и экспорт конфигурации. Ошибка в правилах маршрутизации может отрезать доступ к устройству, и без резервной копии восстановление потребует физического доступа.
Особенности при миграции с RouterOS v6 на v7
Именно переход на седьмую версию — самый массовый источник этой ошибки. В v6 конфигурация вида new-routing-mark=WAN2 работала сама по себе: метка существовала как строка в правиле. После обновления до v7 такие метки не конвертируются в таблицы автоматически, и любое редактирование старых правил вызывает отказ валидации.
Алгоритм миграции выглядит так: сначала создаются все таблицы в /routing table с именами, совпадающими со старыми метками, затем проверяются маршруты — в v7 у маршрута указывается routing-table вместо routing-mark. Только после этого правила mangle и route rules начинают сохраняться корректно.
Почему MikroTik изменили это поведение
В RouterOS v7 стек маршрутизации был переписан. Жёсткая привязка меток к таблицам устраняет ситуацию, когда правило ссылается на несуществующую политику и трафик молча уходит по основной таблице main. Проверка на этапе ввода заставляет администратора явно определить все таблицы, что делает конфигурацию предсказуемой и упрощает отладку.
Если роутер обновлён, а старые метки больше не нужны, проще удалить устаревшие правила, чем создавать пустые таблицы. Проверьте, какие правила реально участвуют в обработке трафика, — счётчики пакетов в /ip firewall mangle print stats покажут активность.
Проверка результата и типичные ошибки после исправления
После создания таблицы или правки имени повторите действие, которое вызывало ошибку, — правило должно сохраниться. Затем убедитесь, что маршрутизация работает как задумано: промаркируйте тестовый трафик и проверьте, по какому маршруту он уходит. Полезные команды:
/ip route print where routing-table=to_isp1
/tool traceroute 8.8.8.8 routing-table=to_isp1
Если трассировка идёт через не тот интерфейс — проверьте, есть ли в созданной таблице маршрут по умолчанию. Пустая таблица без маршрутов формально существует, ошибка валидации исчезает, но трафик с такой меткой не маршрутизируется или обрабатывается непредсказуемо.
| Симптом | Вероятная причина | Действие |
|---|---|---|
| Ошибка при сохранении правила mangle | Метки нет в /routing table | Создать таблицу с тем же именем |
| Ошибка после обновления до v7 | Старые метки v6 не конвертированы | Создать таблицы по списку старых меток |
| Правило сохраняется, трафик не идёт | В таблице нет маршрутов | Добавить маршруты с routing-table |
| Ошибка при вставке через терминал | Пробелы или регистр в имени | Сверить имя посимвольно, ввести заново |
| Красная подсветка правила в Winbox | Ссылка на удалённую таблицу | Исправить или удалить правило |
⚠️ Внимание: не создавайте таблицы маршрутизации «про запас» без маршрутов внутри. Правило с меткой на пустую таблицу пройдёт валидацию, но трафик не получит корректного маршрута — диагностировать такую ситуацию сложнее, чем исходную ошибку.
Профилактика: как не столкнуться с ошибкой снова
Главное правило — поддерживать согласованность: любая метка, упомянутая в firewall, route rules или маршрутах, должна иметь запись в /routing table. При удалении таблицы сначала найдите и удалите все ссылающиеся на неё правила, а не наоборот.
При переносе конфигурации между устройствами используйте /export и проверяйте, что блок /routing table присутствует в экспорте и стоит раньше зависимых правил. При ручном переносе начинайте именно с таблиц — тогда остальные разделы импортируются без ошибок валидации.
Давайте таблицам говорящие имена без пробелов и спецсимволов — например, isp1, vpn_office, guest_net. Это снижает риск опечаток и упрощает поиск ссылок на таблицу в конфигурации.
Часто задаваемые вопросы
Появилась ли эта ошибка из-за сбоя прошивки?
Нет. Это штатная проверка целостности конфигурации в RouterOS v7. Система отказывается сохранять правило, которое ссылается на несуществующую таблицу маршрутизации. Сама прошивка при этом работает корректно.
Можно ли отключить эту проверку?
Штатного способа отключить валидацию routing mark нет — это встроенное поведение сетевого стека RouterOS v7. Правильное решение — создать соответствующую таблицу или исправить ссылку в правиле.
Почему в RouterOS v6 такой ошибки не было?
В v6 метка маршрутизации была просто строкой и не требовала существования таблицы. В v7 стек маршрутизации переработан, и каждая метка обязана соответствовать записи в /routing table. Поэтому старые конфигурации после обновления требуют доработки.
Ошибка появляется при импорте .rsc-файла. Что делать?
Откройте файл экспорта в текстовом редакторе, найдите все упоминания routing-mark и routing-table, затем вручную создайте таблицы с этими именами до импорта остальных разделов. Либо импортируйте файл частями, начиная с секции /routing table.
Правило сохранилось, но трафик не идёт по нужному маршруту. Это связано с ошибкой?
Косвенно. Если таблица создана, но в ней нет маршрутов, трафик с этой меткой не получит корректного пути. Проверьте наличие маршрутов командой /ip route print where routing-table=имя_таблицы и добавьте нужные маршруты с указанием этой таблицы.