Wed Sep 28, 2022 5:05 pm
You are mixing too many subjects together.
scope and target-scope control the recursion, where a destination (dst-address) of a "server" route can be used as the gateway address of another, "client", route. The purpose of these two parameters is to prevent recursive loops - a "client" route can only use other routes as its "server" ones if its target-scope value is higher than (or equal to in RouterOS 6) their scope ones.
Recursive routing and these parameters were originally intended for use in dynamic routing (using BGP or other routing protocols); the possibility to use them for uplink redundancy with statically configured routing alone is a welcome side-effect. Using check-gateway=ping, an indirect route may monitor the actual availability of the network path, and become unavailable if the gateway address doesn't respond to pings, allowing other routes to take over.
This way of thinking does not go away - there are subtle changes between RouterOS 6 and RouterOS 7, but the basic idea remains. You may not be satisfied with the speed of detection of the uplink unavailability because you cannot affect the frequency of check-ping (which is hardcoded to 1 ping in 10 seconds), but other than this, there is no need to use anything else to monitor the uplink availability.
scope values 1 and 2 of the topmost "client" routes do not affect the mutual priority of multiple available routes with otherwise identical parameters (dst-address, routing-mark). For this purpose, the distance parameter is used.
Routing rules (and/or mangle rules) are used for a different purpose - to use specific routing strategies for distinct classes of traffic, assigning them distinct routing marks, each identifying a specific routing table to use. But in these specific routing tables, you can still use recursive routes.
So ex.:
/ip route add
dst-address=8.8.8.8 gateway=192.168.111.1 scope=10
dst-address=8.8.4.4 gateway=192.168.222.1 scope=10
routing-mark=main gateway=8.8.8.8 target-scope=11 check-gateway=ping distance=1
routing-mark=main gateway=8.8.4.4 target-scope=11 check-gateway=ping distance=2
routing-mark=pref-wan-222 gateway=8.8.8.8 target-scope=11 check-gateway=ping distance=2
routing-mark=pref-wan-222 gateway=8.8.4.4 target-scope=11 check-gateway=ping distance=1
routing-mark=only-wan-222 gateway=192.168.222.1 distance=1
routing-mark=only-wan-222 type=blackhole
The first pair of routes are the server routes for the recursive client ones, specifying the actual gateways in connected subnets, hence their scope is lowered to 10 as compared to the default 30.
The second pair of default routes are recursive clients of the first two, so their target-scope is set to 11 (the default 10 would be sufficient for RouterOS 6). The route via 8.8.8.8, resolving to 192.168.111.1, is to be preferred whenever both WANs are available, hence its distance is set to 1 whereas the other one has distance 2. Routing table main is used if no routing-mark is assigned to the packet (and it is the default value of routing-mark when adding a route).
The third pair of default routes are also recursive clients of the first two, but they are intended for traffic that should prefer WAN 2, so the route via 8.8.4.4, resolving to 192.168.222.1, has a lower distance value here.
The fourth pair of default routes is for traffic that must only use WAN 2 and not fail over to WAN 1 even if WAN 2 becomes unavailable. Hence there is no point in monitoring availability of WAN 2, so the first route is not a recursive client of any other one and specifies the address of the actual gateway. But if WAN 2 goes down physically, this route becomes unavailable, so there must be the second one that will prevent the routing process from using routing table main instead (this is just one possible way of doing that, there are other ones as well).
What you use to assign the routing-mark values to particular packets is another question, and the behaviour differs between RouterOS 6 and older versions of RouterOS 7 at one hand, and recent versions of RouterOS 7 on the other one. In particular, in the older versions the routing-mark assigned by mangle rules can be overwritten using routing rules; this is not possible in the newer versions.