Can somebody explain scope and target scope?

andreako · Fri Oct 01, 2010 12:06 pm

Hi everybody,

I need help understanding scope and target scope in mikrotik. How can I use this values?

I have to gateways. One is the main gateway and the second is a backup gateway.

How to configure scope and target scope for both gateways?

Thanks in advance

bye

blake · Sat Oct 02, 2010 6:27 am

http://wiki.mikrotik.com/wiki/Manual:Us ... attributes

andreako · Sun Oct 03, 2010 6:45 pm

yes I have read this manual but I still don't understand.

I want it in simple words, or which values are most suitables for scope and target scope.

Thanks

Chupaka · Sat Oct 09, 2010 1:06 am

'scope' and 'target-scope' are for recursive routes. you don't need them until you know what they are for

for main/backup gateways you just need different 'distance' value

anav · Fri Oct 25, 2019 5:25 pm

'scope' and 'target-scope' are for recursive routes. you don't need them until you know what they are for

for main/backup gateways you just need different 'distance' value

Exactly how to use for recursive routes.......... I am guessing that the standard is scope30 target scope 10 but why?
I have no clue what they are doing, I would even prefer plain russian to english MT wiki = greek to me.

xvo · Fri Oct 25, 2019 5:37 pm

Scope/target scope pairs define which routes can be used for recursive nexthop: the route will search for nexthop only among other routes, whose scope is not higher than it's own target scope.

anav · Fri Oct 25, 2019 5:43 pm

I think you have that mixed up. I have been using recursive routes for years now and the scope is 30, target scope 10 for all my routes and it works fine????
Or it just confirms I have no clue when it comes to routes. I still scratch my head when someone puts in table main routes ...........sigh

xvo · Fri Oct 25, 2019 5:49 pm

I think you have that mixed up.

Not me, man. Not me.

anav · Fri Oct 25, 2019 9:47 pm

So in a typical double recursive setup........
This should be the setup.........
where the default setting for IP routes seems to be scope=30 targetscope=10

Primary ISP
First external check
1 - add check-gateway=ping distance=3 gateway=1.0.0.1 (cloudfare) scope=30 targetscope=10
2 - add distance=3 dst-address=1.0.0.1/32 gateway=ISP_Primary scope=10 targetscope=10

Second exernal check
(L2) add check-gateway=ping distance=4 gateway=208.67.220.220 (opendns) scope=30 targetscope=10
(L4) add distance=4 dst-address=208.67.220.220/32 gateway=ISP_Primary scope=10 targetscope=10

Secondary ISP
(L5) add distance=10 gateway=ISP_Secondary scope=30 target scope=10

xvo · Sat Oct 26, 2019 12:55 am

Something like that.

anav · Sat Oct 26, 2019 4:08 am

So it sounds like you have no idea what the purpose of scope is, the purpose of target scope, only that one has to be equal or lower than the other for recursive setups to work.
Haha, then its true you do write WIKIs LOL.

xvo · Sat Oct 26, 2019 11:24 am

I just explained you the purpose of both scope and target scope few comments above, then you wrote a config that should work, and now you state, that you haven't understood a word, that I said?
How are you doing it?

xvo · Sat Oct 26, 2019 11:35 am

Once again, step by step:
1) A route 1 in your config needs a nexthop.
2) It has target-scope=10
3) It then searches the nexthop among the routes that has their scope<=10
4) It finds route 2 that has needed dst-address and scope=10
5) scope=10 (of route 2) <= target-scope=10 (of route 1) ---> route 2 can be used as nexthop for route 1
6) Done!

anav · Sat Oct 26, 2019 5:05 pm

Thanks much! Its getting clearer.
The numbers are meaningless in that I could be using 100 and 50 or 3 and 7. There is no scale.
What is important solely is the relationship between the target scope in one route rule and the scope in an associated route rule.
What is the hierarchy of searches and routing Distance then scope or scope then distance??
Is this scope and target scope used only in recursive routing?

xvo · Sat Oct 26, 2019 5:44 pm

Exactly!

There is no relation between distance and scope/target-scope: one is used for route selection, another for nexthop selection.

anav · Sat Oct 26, 2019 6:33 pm

Exactly!

There is no relation between distance and scope/target-scope: one is used for route selection, another for nexthop selection.

Okay so they are independednt in that target scope is only used for next hop routing rules and scope is used in general for all route rules.
But what does scope do?

How does scope relate to distance?

xvo · Sat Oct 26, 2019 6:46 pm

You are joking, right?

sebastia · Sat Oct 26, 2019 7:39 pm

Have a look here too: https://wiki.mikrotik.com/wiki/Manual:I ... hop_lookup

Scope is linked to routing configuration: 10 for local, 30 for static, ...
Target scope is that as well, and by specifying target one can define how next hop can be looked up.

Sob · Sat Oct 26, 2019 8:28 pm

Haven't you met anav before?

But I'm with him. Other options are easy to understand.

Imagine you're in a room and you're deciding where to go. Doors (gateway) have labels saying where they lead to (dst-address). There are multiple doors leading to same destination, so they also list how long the way is (distance). You want to save your feet, so lower is better. Before trying to open some door, you should either knock or look through if they're glass ones (check-gateway). And it's very big room with many doors and many people, so you can have a ticket (routing-mark) and ask at the desk what doors are you allowed to use. Some doors may be locked or have broken handle (type).

See? Everything is obvious, child would get it. But what do you do with scopes?

xvo · Sat Oct 26, 2019 8:38 pm

Haven't you met anav before?

Sure I have!
I'm the one who welcomed him in the world of VLANs!
...The deed I will probably regret for the rest of my life...

anav · Sat Oct 26, 2019 8:45 pm

Sob, I am enjoying your story telling. I started the first sentence, but I'm going to get a cup of hot rum first and then read the rest of it!
Xvo I dont joke about attempting to understand this stuff. Remember MT is a hobby I have no formal training so most of the time I am missing the basic IT knowledge foundation.
Explained 'properly' even I can understand. Love stories though!!

xvo · Sat Oct 26, 2019 9:05 pm

I know, I know.
Just treat it like a trigger for yourself to reread couple of previous comments

Returning to the subject.

Scope/target scope are used for nexthop selection.
You can think of it like a process of "route creation" for recursive routes.
Scope and target scope are related to each other.

Distance is used for route selection. When the packet is being forwarded.
That is a different process.

So distance is completely unrelated to both scope and target scope.

shunkica · Sun Apr 26, 2020 10:37 pm

So in a typical double recursive setup........
This should be the setup.........
where the default setting for IP routes seems to be scope=30 targetscope=10

Primary ISP
First external check
1 - add check-gateway=ping distance=3 gateway=1.0.0.1 (cloudfare) scope=30 targetscope=10
2 - add distance=3 dst-address=1.0.0.1/32 gateway=ISP_Primary scope=10 targetscope=10

Second exernal check
(L2) add check-gateway=ping distance=4 gateway=208.67.220.220 (opendns) scope=30 targetscope=10
(L4) add distance=4 dst-address=208.67.220.220/32 gateway=ISP_Primary scope=10 targetscope=10

Secondary ISP
(L5) add distance=10 gateway=ISP_Secondary scope=30 target scope=10

+1
This is what I was looking for. I wanted to add a secondary resolver to ping before switching to a different gateway, in the case that the first resolver is down and not my primary gateway.
This should be in the wiki AFAIC

The only way this could be better if it could send me an e-mail alert when the primary gateway fails

EDIT: I found this tutorial which describes how you can do this with netwatch so you can clear connections or send alerts on gateway change.
https://scoop.co.za/blog/post/basic-isp ... h-mikrotik

anav · Mon Apr 27, 2020 5:26 am

Hi shuknica......
Of course you picked my post out of all these experts to wax eloquently about.
If you visit I will make you pancakes topped with Canadian maple syrup..........yummy.

I have a eunich situation in that my primary ISP fibre on a vlan itself is flaky.
When the gateway and wanip change (very infrequently), the router is unable to get a new IP from the new gateway itself and I have to manually put the new gateway into my recursive route rule.
My secondary ISP normal cable, has no difficulites in acquiring a new IP if it changes gateway and WANIP.

So to overcome this I use a script in the ip dhcp client field etc.............
The script basically says if the link is down to go to the ip dhcp client field of gateway and stick the gateway in the recursive route............works like a charm.

shunkica · Tue Apr 28, 2020 9:42 pm

I tried to use this logic to add a reversed gateway order for some clients. I would mark these clients with a "Reversed" route mark.
I have two gateways on my network that connect to the internet, 192.168.1.1 and 192.168.1.2

This is what I did:

/ip route
add check-gateway=ping distance=10 gateway=1.0.0.1
add distance=10 dst-address=1.0.0.1/32 gateway=192.168.1.2 scope=10
add check-gateway=ping distance=11 gateway=208.67.222.222
add distance=11 dst-address=208.67.222.222/32 gateway=192.168.1.2 scope=10
add distance=12 gateway=192.168.1.1

add check-gateway=ping distance=20 gateway=8.8.4.4 routing-mark=Reversed
add distance=20 dst-address=8.8.4.4/32 gateway=192.168.1.1 routing-mark=Reversed scope=10
add check-gateway=ping distance=21 gateway=208.67.220.220 routing-mark=Reversed
add distance=21 dst-address=208.67.220.220/32 gateway=192.168.1.1 routing-mark=Reversed scope=10
add distance=22 gateway=192.168.1.2 routing-mark=Reversed

However the reversed order does not work. Both 8.8.4.4 and 208.67.220.200 are marked as unreachable and it goes straight to the 192.168.1.2 gateway.

Is there some other way to accomplish this?

sindy · Tue Apr 28, 2020 10:10 pm

I tried to use this logic to add a reversed gateway order for some clients
...
Is there some other way to accomplish this?

Can you explain what you mean by "reversed gateway order"? Do you want one group of hosts to prefer one uplink when both are available, and the other group of clients to prefer the other uplink, while both can use their non-preferred uplink if the preferred one is down, or do you mean something completely different?

shunkica · Tue Apr 28, 2020 10:11 pm

Do you want one group of clients to prefer one uplink when both are available, and the other group of clients to prefer the other uplink, while both can use their non-preferred uplink if the preferred one is down

Yes you got it. That is exactly what I mean.

sindy · Tue Apr 28, 2020 11:22 pm

Yes you got it. That is exactly what I mean.

Your nickname has helped me a lot to choose the proper dialect of English for decoding

For the purpose, you don't need to mark the intermediate recursive routes - marking the topmost ones is sufficient. So as you only check a single immortal IP per WAN, the whole setup will be as simple as this:
/ip route
add dst-address=8.8.4.4/32 gateway=192.168.1.1 scope=10
add dst-address=208.67.222.222/32 gateway=192.168.1.2 scope=10
These two are just regular routes to the monitored immortal IPs in the internet, the only modification is that their scope value is changed from the default 30 to 10 so that they could be used for recursive next-hop search by other routes with the default value of target-scope=10.

add dst-address=0.0.0.0/0 distance=1 gateway=8.8.4.4 check-gateway=ping routing-mark=main
add dst-address=0.0.0.0/0 distance=2 gateway=208.67.222.222 check-gateway=ping routing-mark=main
These two are the recursive default routes for the traffic with no routing-mark assigned; the one via 192.168.1.1 via 8.8.4.4 will be preferred if both are active because it has a lower distance value.

add dst-address=0.0.0.0/0 distance=1 gateway=208.67.222.222 check-gateway=ping routing-mark=reverse
add dst-address=0.0.0.0/0 distance=2 gateway=8.8.4.4 check-gateway=ping routing-mark=reverse
These two are the recursive default routes for the traffic with routing-mark=reversed assigned; the one via 192.168.1.2 via 208.67.222.222 will be preferred if both are active because it has a lower distance value.

What may not be obvious is that although the route has a routing-mark different from main, this only affects the choice of that route by packets routed through it, but the ping request packets generated by RouterOS thanks to the check-gateway=ping do not bear this routing-mark, hence they take the corresponding route from the pair with "real" gateways - in another words, they ignore any routes with routing-mark assigned.

From your example it is also visible that you haven't fully grasped the role of the distance parameter of a route - it only plays a role as the very last one in the hierarchy. First, the routing-mark is taken into account; among all matching routes with the same routing-mark, the most narrowly matching ones, i.e. those with the longest dst-address prefix, are chosen; and only if several routes have the same length of the dst-address prefix, the one with the lowest distance value is chosen among them.

bpwl · Wed Apr 29, 2020 2:19 am

another exemple of this recursive route usage.... viewtopic.php?f=23&t=157048

shunkica · Wed Apr 29, 2020 3:50 am

Thank you for the explanation sindy.
How sure are you about the "immortal IP" claim? I read a couple of reddit posts that claim some of these resolvers sometimes drop pings (eg. under heavy load).
I use distance in this way because I like to sort the routing table by distance and this makes the table more legible for me.

In any case here is what I did to fix my routing table:

/ip route
add dst-address=8.8.4.4/32 gateway=192.168.1.1 scope=10
add dst-address=208.67.220.220/32 gateway=192.168.1.1 scope=10
add dst-address=1.0.0.1/32 gateway=192.168.1.2 scope=10
add dst-address=208.67.222.222/32 gateway=192.168.1.2 scope=10
add check-gateway=ping distance=10 gateway=1.0.0.1
add check-gateway=ping distance=11 gateway=208.67.222.222
add distance=12 gateway=192.168.1.1
add check-gateway=ping distance=20 gateway=8.8.4.4 routing-mark=Reversed
add check-gateway=ping distance=21 gateway=208.67.220.220 routing-mark=Reversed
add distance=22 gateway=192.168.1.2 routing-mark=Reversed

sindy · Wed Apr 29, 2020 12:35 pm

How sure are you about the "immortal IP" claim?

I'm not claiming anything - I use the adjective "immortal" to describe the role (or purpose) in the whole setup, not as a property.

I was concentrated on other aspects of your setup, so I misinterpreted the 1.0.0.1 address as one of the auxiliary ones while it is actually one of the two "immortal" ones you use per each WAN. The point is that when I use this setup with two "immortal" addresses per WAN, I use intermediate recursive gateways.

In your setup, you have two default routes per WAN per routing table:

{dst-address=a.a.a.a/32 via connected gateway
    dst-address=0.0.0.0/0 via a.a.a.a/32 check-gateway=ping}
{dst-address=b.b.b.b/32 via connected gateway
    dst-address=0.0.0.0/0 via b.b.b.b/32 check-gateway=ping}

In my architecture (actually, not mine but Timo Puiskaja's one which I like), I have a single default route per WAN:

{
{dst-address=a.a.a.a/32 via connected gateway
    dst-address=x.x.x.x/0 via a.a.a.a/32 check-gateway=ping}
{dst-address=b.b.b.b/32 via connected gateway
    dst-address=x.x.x.x/0 via b.b.b.b/32 check-gateway=ping}
}
        dst-address=0.0.0.0 via x.x.x.x

The advantage I can see in this is the very fact that you have a single virtual gateway per WAN, so the more complex routing setups (where some destinations must not be reached via a backup uplink even if their primary one is broken) become more readable as you don't have to double every route through that WAN.

I use distance in this way because I like to sort the routing table by distance and this makes the table more legible for me.

OK. Since I usually don't use Winbox nor WebFig, I haven't noticed that they allow to sort routes by any parameter. In commandline they are always sorted by dst-address.

In any case here is what I did to fix my routing table:

/ip route
add dst-address=8.8.4.4/32 gateway=192.168.1.1 scope=10
add dst-address=208.67.220.220/32 gateway=192.168.1.1 scope=10
add dst-address=1.0.0.1/32 gateway=192.168.1.2 scope=10
add dst-address=208.67.222.222/32 gateway=192.168.1.2 scope=10
add check-gateway=ping distance=10 gateway=1.0.0.1
add check-gateway=ping distance=11 gateway=208.67.222.222
add distance=12 gateway=192.168.1.1
add check-gateway=ping distance=20 gateway=8.8.4.4 routing-mark=Reversed
add check-gateway=ping distance=21 gateway=208.67.220.220 routing-mark=Reversed
add distance=22 gateway=192.168.1.2 routing-mark=Reversed

Do I read you right that the default routes via physical gateways are there to address the situation where both "immortal" addresses would be down so you take the availability of the physical gateway as the last chance?

And, second, in this configuration you check four "immortal" addresses, but use only one per WAN per routing table, so you have the same amount of pings but less redundancy. There is nothing bad about using the same virtual gateway for routes with different routing-marks, as the intermediate routes are not actually used to route the "real" packets - they are used solely to find the physical gateway for the topmost routes and to monitor the transparency of the uplink all the way to the internet.

shunkica · Wed Apr 29, 2020 3:13 pm

Do I read you right that the default routes via physical gateways are there to address the situation where both "immortal" addresses would be down so you take the availability of the physical gateway as the last chance?

And, second, in this configuration you check four "immortal" addresses, but use only one per WAN per routing table, so you have the same amount of pings but less redundancy. There is nothing bad about using the same virtual gateway for routes with different routing-marks, as the intermediate routes are not actually used to route the "real" packets - they are used solely to find the physical gateway for the topmost routes and to monitor the transparency of the uplink all the way to the internet.

If I understand the first question correctly then yes.
I don't get the second remark you made, as far as I can tell I have ping check redundancy on both WANs.

I will try to explain my logic here. Keep in mind I am just a hobbyist in this area and this is a home setup.

/ip route
add dst-address=1.0.0.1/32 gateway=192.168.1.2 scope=10
add check-gateway=ping distance=10 gateway=1.0.0.1

1. check if 1.0.0.1 is reachable via 192.168.1.2 gateway
- reachable - route the packets through that gateway
- not reachable - go to step 2

/ip route
add dst-address=208.67.222.222/32 gateway=192.168.1.2 scope=10
add check-gateway=ping distance=11 gateway=208.67.222.222

2. 1.0.0.1 is not reachable via 192.168.1.2 (for example 1.0.0.1 is dropping pings) -> check if 208.67.222.222 is reachable via 192.168.1.2 gateway
- reachable - route the packets through that gateway
- not reachable - go to step 3

/ip route
add distance=12 gateway=192.168.1.1

3. both 1.0.0.1 and 208.67.222.222 are unreachable via 192.168.1.2 gateway -> now it is safe to assume that 192.168.1.2 has no internet connectivity
- at this point try to route the packets via the 192.168.1.1 gateway
- there are no checks here because if that gateway is down too it doesn't matter, I can't connect to the internet anyway

And the same logic applies for the "Reversed" route, just with different "immortal" IPs.

sindy · Wed Apr 29, 2020 3:39 pm

And the same logic applies for the "Reversed" route, just with different "immortal" IPs.

OK, this final remark made me understand your concept. You simply don't monitor the backup path within each group as you see no purpose in it. So in the group which prefers WAN A, you use recursive routing via two "immortal" addresses via WAN A, but you use a direct route via the "physical" gateway of WAN B as a backup; in the group which prefers WAN B, you do the same with accordingly swapped uplink roles.

My problem was that I had my fully symmetric implementation in mind while reading yours, so I've misunderstood the role of those direct routes.

For me, my model is simpler to use because it strictly layered - each uplink is checked for transparency using two "immortal" addresses (same like in your case), but all "application routes" use only a single "virtual gateway" for each uplink, and the priority of use of these "application routes" is determined by their distance parameters alone. So one doesn't need to think about each set of application routes all the way down to the physical gateways - for any traffic group (routing-mark), it is always just a choice between "only WAN x" (single route) or "prefer WAN x" (two routes prioritized by distance). And somewhere below, the availability monitoring silently does its job.

PackElend · Thu Jul 29, 2021 7:00 pm

Returning to the subject.

Here are some additional resources, explaining it in different words what may supports to understand it:

Scope/target scope are used for nexthop selection.
Distance is used for route selection. When the packet is being forwarded.
1. Administrative distance - Wikipedia
2. What Is Administrative Distance? - Cisco

bpwl · Tue Dec 07, 2021 12:04 pm

That "scope" "target scope" seems painfull to grasp for most. It needs time, also for me, and maybe another narrative can help.

Let's project it in on travel. One person wants to travel from US [LAN] to Europe [internet], and needs to decide what to tell [next hop] to the taxi-driver.
There are multiple international airports, But there is covid, lockdown, strikes, roadblocks, ... so before chosing the airport there needs to be a test.
The person has servants [PING] that can be sent. To have some value that servant has to travel each week [PING interval] to an available spot in Europe, e.g. the capital of a country.

Then maps are used (GPS would not solve the answer). Global maps ([scope=30] for the continents and cities, and flight plans [scope=10] for the airports.
The travellers are given rules , how to proceed.
To go to Europe [the internet 0.0.0.0/0] there are 2 paths defined [scope=30], either via Paris or via Amsterdam.
1. One path to Europe [scope=30] is over Paris [Cloudflare DNS] , the other over Amsterdam [Google DNS]
One servant [PING] has to check and report if he can get to Paris [gateway], the other to Amsterdam [gateway] only by airplane [target scope=10]
2. For finding an airport towards Paris, another map/rule [scope=10] is used. Also for Amsterdam an airport to depart is defined in a routing rule. [scope=10]

If the servant [PING] gets to Paris or Amsterdam that means that the defined airport is operational for travel to Europe.[internet]
Only if both are operational, the travel time and price [distance] will be used to decide if the Paris or Amsterdam route is followed.
To go to somewhere in Europe the best airport is choosen based on the reachability of Paris and Amsterdam [PING test] and traveltime [distance], and is defined as the airport [next hop] defined in their specific [scope=10] route.

PS: Europe is reachable via failover or load balancing paths over 2 airports. Except Paris and Amsterdam who are bound to a specific path.
[Redundant reachability of Cloudflare DNS and Google DNS have the same limitation]

PS: target scope will need to 11 in ROS7 to match with scope=10

PS: What binds the scope=30 and scope=10 rules together? As always in routing the gateway IP of scope=30 rule must be in the destination range of scope=10

Sob · Tue Dec 07, 2021 11:52 pm

I'm still missing some intuitive and easy to grasp definition of scope/target-scope. The others are simple and obvious, dst-address, gateway, distance, even beginner with little to no experience is likely to guess what they mean. But with scope? No chance.

sindy · Wed Dec 08, 2021 12:21 am

@bpwl, I'd say your travel analogy is really great as an explanation of how the recursive next-hop search means, but like for @Sob apparently, it doesn't make the notion of "scope" and "target-scope" any more imaginable for me. I used to understand target-scope as some kind of threshold allowing to disqualify routes with too high scope from being used for the recursion, in order to prevent indefinite looping, but it may be an oversimplification.

bpwl · Wed Dec 08, 2021 1:31 am

Yes I thought implicitly on that better definition on 'scope/target scope', but would make the analogy a bit weaker, and the text too long.
Here the focus is only on the case of recursive routes and ping test on a known far away gateway to figure out if a path should be taken or not.
And triggered by the question "what is the relation between scope and distance".
Should have made that clear I guess. The nice part is that everyone can see that the Paris and Amsterdam test is not actually covering the intented travel, and can give the wrong answer.

I saw as as possible story the type of maps used when looking for direction: earth globe, continental map, national map , regional map, down to topographic map, with lowering scope.
The same could be said about continental flight, international flight, national flight, or airport interconnect.
To find the path from the international airport to a national city ... international and continal is then "out of scope"
The target scope is then which maps you should use to find more detail. Or with flight-type to use, you would not go from NY to Atlanta over Rome.

anav · Wed Dec 08, 2021 2:29 am

As some handsome fella said........
Well, easier way of thinking about it is: "target-scope must be lower on each level of recursion"

As bpwl intimated, one goes to a finer map (zooms in) to find the airport and then the runway..............

TRNX · Fri Jul 22, 2022 2:34 pm

Once again, step by step:
1) A route 1 in your config needs a nexthop.
2) It has target-scope=10
3) It then searches the nexthop among the routes that has their scope<=10
4) It finds route 2 that has needed dst-address and scope=10
5) scope=10 (of route 2) <= target-scope=10 (of route 1) ---> route 2 can be used as nexthop for route 1
6) Done!

Hello.
I am sorry for opening an old topic and thank everyone for this discussion which helped me, but I don´t understand one thing.
In example above, xvo used logical operator < or =.
And now, please look at my pictures.

Picture 1:
-scope (10) < target-scope (11)
-works

Picture 2:
-scope (11) = target-scope (11)
-works

Picture 3:
-scope (10) = target-scope (10)
-not work

Why it works at picture 2, where scope = target scope (both value = 11) but at picture 3, where scope = target scope (but value = 10) it doesn´t work?
What am I doing wrong?

Thanks for any help.

rextended · Fri Jul 22, 2022 2:57 pm

simply, you consider other routes what scope have???

anav · Fri Jul 22, 2022 3:35 pm

@TRNX
Please read para I ( it explains recursive, provides rules of thumb, and has examples )
viewtopic.php?t=182373

TRNX · Fri Jul 22, 2022 3:51 pm

I thought about it, but I don't know the right answer again.
Because routes which left are dynamic routes which target-scope isn't specified and their scope is 10. So their scope is still = target-scope of other routes.
(To make it easier for me to understand I disabled the second default route for second WAN). I am sorry if I don't see what I should.

Now when I changed target-scope in default route to 10 (this change is not in picture above), I saw that Immediate Gateway changed from "192.168.24.251..." to "wlan1". So I understand that default route select wrong nexthop and this is the problem. But still don´t understand why. Target-scope 10 is still = scope of other routes.
Why when I set target-scope = 11 in default route, immediate gateway is not wrong set to "wlan1" as when I set target-scope to 10?

Thank you.

EDIT: Thank you anav, I am going to look at it.

TRNX · Sun Jul 24, 2022 3:12 am

@TRNX
Please read para I ( it explains recursive, provides rules of thumb, and has examples )
viewtopic.php?t=182373

Thank you very much!
Your guide is very usefull

broderick · Fri Jul 29, 2022 12:05 pm

Here I am again. I hope that I will not wreak havoc on this topic even more. By reading articles on this subject, and especially by watching this video:

https://www.youtube.com/watch?v=c9ybewdi3qk

I managed to setup Recursive Failover on my Mikrotik devices.

add distance=1 gateway=8.8.8.8
add distance=2 gateway=1.1.1.1
add check-gateway=ping distance=1 dst-address=1.1.1.1/32 gateway=192.168.9.1 scope=10
add check-gateway=ping distance=1 dst-address=8.8.8.8/32 gateway=192.168.1.1 scope=10

Yes, I am on Double NAT on both ways: the main connection and the backup one, but it not a big deal really.

It works great, but I'd like to have a complete understanding of the setup and what is going on with it. I bought a MK device to dive deeper into Computer Networking, and not to "just make it work by doing this way, and be happy."

The guy in the video I linked above does a great job, but, in my humble opinion, his explanation about how it exactly works becomes cursory just on the step many seem to be struggling with, i.e., "scope" and "target scope and how the route rules are related and triggered.

I know that it already has been written and said a lot about scope and target scope, but I need to figure it out and said it my own way, and check with your help if I'm on the right path.
So,

1) I first set two routes with dst-addresses the two DNS IPs which in turn can be reached via my gateways (in my case, the IPs of my upstreams routers, but they should be the ISP IPs usually)
2) I make sure that they are reachable by pinging them
3) I set their scopes to 10, making them "believe" that 1.1.1.1 and 8.8.8.8 are next hops.

4) I set two other route rules up which I need in order to reach any sites on the internet (0.0.0.0/0)
5) They have DNS IPs as their gateways (this is one of the points I'm trying to wrap my head around), say, for example, 8.8.8.8. The router sees that there is a dst- address route for 8.8.8 in the list, then it runs it, which in turn knows how to reach 8.8.8.8 since the my upstream router IP (or a ISP IP if you like) is set up.
6) if both routes are available and running, it picks the one with the lower distance, i.e., 1.

If not everything, did I get something right at least?

Thanks

bpwl · Mon Aug 08, 2022 10:11 pm

Why it works at picture 2, where scope = target scope (both value = 11) but at picture 3, where scope = target scope (but value = 10) it doesn´t work?
What am I doing wrong?

Thanks for any help.

Whatever one reads about "target scope" and "scope" requirements, verify if this is for ROS6 or for ROS7. The requirements have changed !
For ROS6 "target scope" is the selection criteria to select a next hop route, which must have the "scope" lower than (or even equal to) the target scope in the selection.

For ROS7 some extra checks are added. Behavior is different. Some ROS6 configs stop working.
(Reason for that extra is unclear to me. Seems to be about next-hop lookup loops. Which could be caused by that 'even equal to', which does not garantee for scope value reduction, and as such never ends.)
The extra check is not documented clearly AFAIK. And Forum guru's here give sometimes different definitions for that extra rule.
The extra check seems to be (dificult wording here): 'the target scope of the selected next hop route, selected via the scope criteria, must also be smaller than the "target scope" used for selection.'
Others explain it as: 'defined "scope" is not used, but scope used for selection is calculated from that routes "target scope as ["used scope" = "target scope +1"] '
So picture 3 will work in ROS6 and will not work in ROS7. I know it happens. I have no clue about the exact working of that extra rule.

miklin · Sat Sep 23, 2023 4:50 pm

add distance=1 gateway=8.8.8.8
add distance=2 gateway=1.1.1.1
add check-gateway=ping distance=1 dst-address=1.1.1.1/32 gateway=192.168.9.1 scope=10
add check-gateway=ping distance=1 dst-address=8.8.8.8/32 gateway=192.168.1.1 scope=10

Can someone correct me if i don't understand it right. If ping (two times) failed to gateway 192.168.1.1 it will mark this two routes:

add distance=1 gateway=8.8.8.8
add check-gateway=ping distance=1 dst-address=8.8.8.8/32 gateway=192.168.1.1 scope=10

as Inactive ?