+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Рекурсивные маршруты

Рекурсивные маршруты, RouterOS

Guscht

Guest

06.03.2021 09:22:00

Привет, это «нормальное поведение» V7 по отношению к рекурсивным маршрутам? Как описано в популярной теме «Advanced Routing Failover without Scripting»: http://forum.mikrotik.com/t/advanced-routing-failover-without-scripting/136599/1 В V6 всё работает:

А в V7 вообще нет «рекурсивной» маршрутизации?! Всё, что я вижу — красным «invalid» или «unreachable»:

wizkid77 Guest	#2 0 28.10.2021 18:03:00 У меня те же проблемы. Похоже, это еще не реализовано. Мой CCR2004 поддерживает только 7 sigh.

mrz Guest	#3 0 28.10.2021 20:52:00 Целевая область должна быть больше области маршрута, по которому вы хотите разрешить шлюз. Установите значение не менее 11.

mducharme

Guest

29.10.2021 16:53:00

Почему это изменили с «меньше или равно» (в RouterOS v6) на просто «меньше» (в v7)? В v6 целевой scope должен быть не меньше размера scope, поэтому 10 работало. Была ли причина для такого изменения? Мне кажется, что способ из RouterOS v6 логичнее — target-scope можно легко объяснить как scope, на который ты нацеливаешься, то есть если хочешь поймать маршруты со scope 10, ставишь target-scope 10.

mrz Guest	#5 0 29.10.2021 17:01:00 Возникнет бесконечный цикл разрешения, если поместить цель в ту же область, в которой происходит разрешение.

Chupaka

Guest

19.11.2021 09:00:00

Судя по всему, target-scope рекурсивного маршрута должен быть больше target-scope разрешающего маршрута. Потому что: это всё ещё работает для connected маршрутов (target-scope у статических маршрутов равен 10, а у connected маршрутов scope тоже 10 — это одинаково, точно не больше); это работает в следующем случае:
dst:host, gw:connected_gateway, scope=11, target-scope=10
dst:subnet, gw:host, scope=30, target-scope=11
Здесь target-scope второго маршрута (11) не больше scope маршрута, через который он разрешается (тоже 11). Но если поменять target-scope первого маршрута на 11 — второй маршрут перестает разрешаться (так как теперь его target-scope не больше, чем у первого маршрута).

Guscht

Guest

02.12.2021 21:56:00

Не могу выразить, как сильно я ненавижу Mikrotik за то, что они делают всё настолько запутанным! Для тех, кто хочет или нуждается в обходе, вот что работает: Проверка одного WAN:

Проверка нескольких WAN:

Всё ещё не хватает уведомления «recursive via…»...

Chupaka Guest	#8 0 03.12.2021 13:10:00 Чтобы немного упростить, можно везде поставить scope=10.

Guscht

Guest

03.12.2021 21:21:00

Можешь объяснить логику? Почему я должен ставить Target Scope равным 12? Насколько я понимаю, это работает так (сверху вниз):
Dst.Address: 0.0.0.0/0 → GTWY: 10.0.0.1 → Target-Scope: 12
Dst.Address: 10.0.0.1 → GTWY: 8.8.8.8 → Target-Scope: 11
[в этот момент происходит магия, то есть проверка шлюза]
Dst.Address: 8.8.8.8 → GTWY: 10.88.20.2 → Target-Scope: 10
Dst.Address: 10.88.20.2 → GTWY: ether1 → Target-Scope: ничего

Почему для первого маршрута нужен Target-Scope равный 12, если у второго и всех остальных он равен 10? Почему 11 недостаточно, хотя для второго маршрута хватает? Тем более 11 — это даже меньше, чем 10 (а ведь должно быть «не меньше и не равно»)?

Кто-нибудь может объяснить это:

Почему здесь Scope отличается от значений на странице Routes? Target-Scope равен 5? Я вообще ничего не вижу на странице Routes.
Почему ether1 указан дважды? Что такое «weight» и зачем там строка с цифрой «2»? Почему состояние шлюза (Gateway State) «unreachable»? Ведь шлюзы доступны!
Что такое Flap Count и этот весь MPLS? Я даже не использую MPLS…

Почему они сделали ROSv7 таким сложным и напичканным бесполезным хламом? Если так будет выглядеть дизайн ROS7 — это катастрофа. Нет ни логики, ни смысла, ни нормальной документации, ничего.

spippan Guest	#10 0 04.12.2021 22:55:00 «Катастрофично» и «нет логики» — только потому, что ты не разделяешь логику производителя оборудования для провайдеров и т. п.? Да ну... это уж чересчур драматично, не находишь?

Chupaka Guest	#11 0 05.12.2021 13:32:00 Ты читал мой пост прямо над твоим? http://forum.mikrotik.com/t/recursive-routes/147430/6

anav

Guest

#12

14.04.2022 20:36:00

Чупака, я думаю, ты хотел сказать, что ЦЕЛЕВОЙ ОБЛАСТЬЮ разрешающего маршрута должна быть область, на единицу большая, чем ОБЛАСТЬ рекурсивного маршрута. Или проще говоря, ЦЕЛЕВОЙ ОБЛАСТЬЮ маршрута ЧЕРЕЗ внешний объект (DNS-сервер) должна быть область, на один больше, чем ОБЛАСТЬ маршрута К внешнему объекту. Ещё проще: ЦЕЛЕВОЙ ОБЛАСТЬ косвенного маршрута должна быть на единицу больше ОБЛАСТИ прямого маршрута. Рекурсивный = прямой к DNS через шлюз ISP → Scope Разрешающий = косвенный через DNS-шлюз → Target Scope

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Кто-нибудь проверял правила для Target Scope после версии 7.2?? Может, что-то поменялось. Всё ещё нужно, чтобы было на один больше, на один или больше, или равно или больше… я вообще запутался. Последний раз, кажется, я видел так: рекурсивный маршрут (прямой) К IP DNS — Scope = X, а разрешающий маршрут (косвенный через IP DNS) — Target Scope = X+1, где IP DNS — это может быть 1.1.1.1 или 8.8.8.8 и так далее (известный рабочий IP в интернете).

Chupaka Guest	#13 0 15.04.2022 10:51:00 Категорически нет. Target Scope должен быть больше или равен Scope, как это было всегда. Target Scope должен уменьшаться на каждом шаге рекурсии (нововведение в RouterOS v7).

anav

Guest

#14

15.04.2022 11:45:00

Спасибо, chupaka, думаю, я понял. (1) В общем, target scope всегда должен быть равен или больше scope. (это верно для всех маршрутов, если смотреть на них как на отдельные объекты) (2) Для рекурсивных маршрутов Resolving Route (Direct → внутренний или ближайший к роутеру) будет иметь Target Scope X. (3) Для каждого успешного рекурсивного маршрута (Indirect → внешний по отношению к роутеру), при дальнейшем поиске следующего хопа маршрут будет иметь Target Scope X+1.

Итак, очень простой рекурсивный Dual WAN failover может выглядеть так…

/ip route add check-gateway=ping distance=3 dst-address=0.0.0.0/0 gateway=1.0.0.1 scope=10 target-scope=12
add distance=3 dst-address=1.0.0.1/32 gateway=Primary-gatewayIP scope=10 target-scope=11
add comment=SecondaryISP distance=10 dst-address=0.0.0.0/0 gateway=Secondary-gatewayIP scope=10 target-scope=30

Тогда рекурсивный Dual WAN failover с использованием ДВУХ внешних DNS-серверов для проверки связи в простом ПЛОСКОМ варианте будет выглядеть так…

/ip route add check-gateway=ping distance=3 dst-address=0.0.0.0/0 gateway=1.0.0.1 scope=10 target-scope=12
add check-gateway=ping distance=4 dst-address=0.0.0.0/0 gateway=9.9.9.9 scope=10 target-scope=12
add distance=3 dst-address=1.0.0.1/32 gateway=Primary-gatewayIP scope=10 target-scope=11
add distance=4 dst-address=9.9.9.9/32 gateway=Primary-gatewayIP scope=10 target-scope=11
add comment=SecondaryISP distance=10 dst-address=0.0.0.0/0 gateway=Secondary-gatewayIP scope=10 target-scope=30

А вот рекурсивный Dual WAN failover с использованием ДВУХ внешних DNS-серверов для проверки связи в СЛОЁНОМ или ВЛОЖЕННОМ варианте будет выглядеть так…

/ip route add dst-address=0.0.0.0/0 gateway=10.10.10.10 scope=doesnt matter target-scope=14
+++++++++++++++++
add check-gateway=ping dst-address=10.10.10.10/32 gateway=1.0.0.1 scope=14 target-scope=13
add dst-address=1.0.0.1/32 gateway=Primary-gatewayIP scope=13 target-scope=12
+++++++++++++++++
add check-gateway=ping dst-address=10.10.10.10/32 gateway=9.9.9.9 scope=14 target-scope=13
add dst-address=9.9.9.9/32 gateway=Primary-gatewayIP scope=13 target-scope=12
+++++++++++++++++
add comment=SecondaryISP distance=10 dst-address=0.0.0.0/0 gateway=Secondary-gatewayIP scope=10 target-scope=30

Chupaka

Guest

#15

15.04.2022 15:50:00

Итак, у вас есть маршрут, указывающий на IP какого-то шлюза. Этот маршрут использовать напрямую нельзя: он должен быть разрешён до интерфейса. Для этого нужен другой маршрут, который разрешает предыдущий. Я называю его разрешающим маршрутом, потому что не знаю другого термина.

Технически, при использовании «рекурсивных маршрутов» для резервирования у вас получается два разрешения (для простоты 10.0.0.1 — это шлюз провайдера):

Маршрут 1: 0.0.0.0/0 указывает на 8.8.8.8, с target-scope=TS1
8.8.8.8 нужно разрешить, поэтому используем следующий маршрут:
Маршрут 2: 8.8.8.8/32 указывает на 10.0.0.1, с target-scope=TS2

Снова, 10.0.0.1 должен быть разрешён через:
Маршрут 3: 10.0.0.0/24 указывает на ether1 — это подключённый маршрут с пустым target-scope.

В RouterOS версии 6 и ниже TS1 мог быть равен TS2. Сейчас требуется, чтобы TS1 был больше TS2 (на случай, чтобы избежать возможных циклов).

anav

Guest

#16

15.04.2022 15:57:00

Хорошо, ты меня запутал с маршрутом 10.0.0.0/24, привязанным к ether1, но если ты имел в виду маршрут, который уже существует внутри роутера, тогда понятно. Похоже, мы наконец поняли друг друга. Спасибо! Значит, ты не видишь никаких проблем в представленных настройках, и я правильно объяснил как плоский, так и вложенный подход?

anav Guest	#17 0 18.04.2022 12:15:00 … Привет, Chupaka! Я пытаюсь разобраться с двумя разными наборами правил, которые ты указал в разных местах, чтобы понять, означают ли они одно и то же. Думаю, мы быстро согласимся, что #2 и #4 ясны и последовательны. В Ver7 TS должен уменьшаться на каждом шаге рекурсии. Другими словами, нам нужно сравнивать ДВА отдельных, но связанных маршрута при рассмотрении этого правила. [TS по одному правилу и TS по другому правилу]. Для меня сложнее с #1 и #3. Кажется, в первой строчке #1 ты говоришь, что каждый маршрут, рассмотренный отдельно, должен иметь связь между собственными настройками Scope и Target Scope, и, более конкретно, TS должен быть равен или больше Scope. Иными словами, это правило смотрит только на одно правило за раз — S в одном правиле и TS в том же правиле. Но в #3, похоже, ты подразумеваешь нечто иное! Ты, кажется, сравниваешь Scope одного правила с Target Scope другого правила??? То есть сравниваешь два разных правила!! S в одном правиле и TS в другом правиле. Поясни, пожалуйста! Если выразиться иначе, у нас точно есть сравнение TS к TS между разрешающим маршрутом и рекурсивным маршрутом. Но в отношении сравнения S к TS, о котором ты говоришь, мы применяем это к одной и той же паре маршрутов или к каждому правилу по отдельности (то есть S и TS внутри одного правила)? Мне кажется, это именно та логика, о которой ты говоришь… ДАЛЬНЕЙШИЙ МАРШРУТ: SCOPE = (неважно) / TARGET SCOPE = Y+2 БЛИЖАЙШИЙ МАРШРУТ: SCOPE = Y+2 или меньше / TARGET SCOPE = Y+1 ЕЩЁ БЛИЖЕ МАРШРУТ: SCOPE = Y+1 или меньше / TARGET SCOPE = Y (шлюз = ISP) ВНУТРЕННИЙ МАРШРУТ: (внутри роутера, scope не используется, рекурсии вообще нет)

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры