Зачем при рекурсивной маршрутизации указывать scope и target-scope, если в маршрутах уже явно заданы пути и их порядок?

Например, вот список путей на маршрутизаторе: <br/> 0.0.0.0/0 -> 8.8.8.8 distance = 1 <br/> 0.0.0.0/0 -> 1.1.1.1 distance = 2 <br/> 8.8.8.8/32 -> 10.10.10.1 <br/> 1.1.1.1/32 -> 10.10.20.1 <br/> 10.10.10.1 -> wan1 <br/> 10.10.20.1 -> wan2 <br/> В этой схеме явно указано, куда и через что отправлять трафик — нужны ли тогда значения scope и target-scope для принятия решения о маршрутизации, или они избыточны?
  • 6 апреля 2026 г. 7:01
Ответы на вопрос 2
Коротко — они не избыточны. Scope и target‑scope не влияют на выбор «лучшего» маршрута (distance / pref) — они используются на шаге рекурсивного разрешения next‑hop‑адреса, чтобы решить, какие именно маршруты можно использовать как «шаги» для достижения этого next‑hop и чтобы избежать нежелательной рекурсии/петель.

Что это значит на практике
- У вас есть маршрут вида 0.0.0.0/0 → 8.8.8.8 (gateway — IP). Роутеру надо «разрешить» 8.8.8.8: найти маршрут к этому IP. Это называется рекурсией.
- scope определяет «уровень» маршрута (насколько он «близкий»/доверенный для использования в рекурсии).
- target‑scope у маршрута с gateway говорит: разрешать ли использовать маршруты с какими‑то scope для нахождения этого gateway. Проще — target‑scope ограничивает, какие записи таблицы можно применять для поиска next‑hop.

Зачем это нужно (конкретные проблемы, которые решают)
- Предотвратить использование менее подходящих маршрутов для резолюции next‑hop (например, разрешать резолюцию только по напрямую подключённым маршрутам, а не по другим динамическим/дефолтным).
- Избежать рекурсии/петлей, когда next‑hop сам может быть разрешён через дефолтный маршрут (и тогда роутер «угадывает» сам и может попасть в бесконечный цикл).
- Контролировать поведение при мультипути/нескольких дефолтах, чтобы гарантировать, что gateway резолвится только через нужный интерфейс/канал.

Применение к вашему примеру
Маршруты у вас явно заданы, и при простом однозначном сценарии действительные значения scope/target‑scope по умолчанию вполне справятся. Но если появится перекрёстная зависимость (например, один gateway резолвится через другой дефолт, или оба gateway резолвятся через общую менее специфичную запись), без target‑scope роутер может:
- использовать неправильный путь для резолюции адреса next‑hop,
- попасть в рекурсию/петлю.

Рекомендации
- Для простой конфигурации ничего менять не нужно — дефолты обычно подходят.
- Если вы используете рекурсивные next‑hop (gateway — не напрямую подключённый IP), или наблюдаете странное поведение (резолюция next‑hop идёт через другой дефолт, петли), задавайте target‑scope/scope, чтобы ограничить, какие маршруты могут участвовать в рекурсии (обычно разрешают резолюцию только через напрямую подключённые/статические маршруты).

Итого: scope/target‑scope — инструмент для управления рекурсией и безопасности маршрутизации. Они не решают, какой маршрут «лучше» (это делает distance), но решают, можно ли вообще использовать конкретный маршрут как шаг для достижения next‑hop.
Представь что wan1 упал и маршрут 8.8.8.8/32 пропал. Без правильного scope/target-scope дефолт через 8.8.8.8 не деактивируется, микротик зарезолвит 8.8.8.8 через 0.0.0.0/0 (сам через себя) и получится петля вместо failover на второй канал. scope/target-scope не про выбор маршрута, а про то когда маршрут считать мёртвым. target-scope=11 ограничивает рекурсию маршрутами с scope ≤ 11, и когда /32 пропадает, дефолт корректно гаснет.
Похожие вопросы