How to understand the failover process on mikrotik with two WANs?

Question

Mikrotik

There is an example: wiki.mikrotik.com/wiki/Advanced_Routing_Failover_w...
I am considering an advanced version with 4 host checks (2 through ISP1, and 2 other hosts through ISP2). In general terms, the idea is clear, everything works for me, but with modifications, but the question is not in them, but in the clarity of the process. Just in case, I saw articles on Habré and in many other places.
I would like to understand what should be added to the official wiki, which I cited above.
Here is the code (I will number the lines, of course, there is no numbering in the script):

1) /ip route
2) add dst-address=Host1A gateway=GW1 scope=10
3) add dst-address=Host1B gateway=GW1 scope=10
4) add dst-address=Host2A gateway=GW2 scope=10
5) add dst-address=Host2B gateway=GW2 scope=10

6) add dst-address=GW1 gateway=Host1A scope=10 target-scope=10 check-gateway=ping
7) add dst-address=GW1 gateway=Host1B scope=10 target-scope=10 check-gateway=ping
8) add dst-address=GW2 gateway=Host2A scope=10 target-scope=10 check-gateway=ping
9) add dst-address=GW2 gateway=Host2B scope=10 target-scope=10 check-gateway=ping

check-gateway=ping checks the availability of the host specified as the gateway (Host1A...Host2B, I used 8.8.8.8, 8.8.4.4 and two other IPs). If it is not available, then the gateway is marked as inactive (official wiki: Periodically (every 10 seconds) check gateway by sending either ICMP echo request (ping) or ARP request (arp). If no response from gateway is received for 10 seconds, request times out. After two timeouts gateway is considered unreachable. After receiving reply from gateway it is considered reachable and timeout counter is reset.).
What thus should be registered default routes?
The first thing that comes to mind (default listing v.1):

add dst-address=0.0.0.0/0 gateway=GW1 distance=1
add dst-address=0.0.0.0/0 gateway=GW2 distance=2

will not work as a failover, because even if ISP1 crashes and Host1A and Host1B become unavailable, it won't affect the default routes (0.0.0.0/0) in any way.
Here is an option (default listing v.2):

/ip route add dst-address=0.0.0.0/0 gateway=Host1A distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=Host2A distance=2 check-gateway=ping

I'm clear it works. But he:

1. works completely independent of lines 6)-9), they are simply not needed in this situation.
   
2. does not provide the advantage of checking the availability of two hosts at once through ISP1 and the other two hosts through ISP2
   

If you “finish” the example from the wiki, mark the default routes with ISP1 and ISP2 tags, respectively, then using Netwatch you can create tasks that, if Host1A is unavailable, will do something like:
/ip route disable [find comment="ISP1"]
and if available:
/ip route enable [find comment="ISP1"]
Everything is great, and this also works.
Question: why does the wiki at the link at the beginning say nothing at all about default routes? It is understood that the reader himself will prepret that it is necessary to dodge somehow? Why are lines 6)-9) given - I still do not understand their real functioning. Can you clear the chain for me?

Answer 1

Read the article carefully. as a result, we come to a double recursion. By the way, an interesting solution. It turns out that we monitor several hosts with direct routes to the Internet, through each of them we make a route for a "virtual" address, which, in turn, is a gateway for the default recursive route for clients. It turns out that routes through "virtual" addresses check any number of external addresses. And if one of the addresses is not available, and the rest are working, it will be in the apa. If all addresses are dead, then the provider is unavailable, deactivate the route. If you understand how it works, you won't get confused. You need to register a lot of routes, yes. But the solution is interesting)
I completely disagree with the statement l0ser140about the fact that fireover on scripts is better. There is nothing good in it. Pure routing handles this 200% without any crutches.

Answer 2

I also spent a very long time with the redundancy setting, I got this design.

/ip address
add address=<ISP1_IP_ADDRESS> interface=ether1_WAN_MAIN
add address=<ISP2_IP_ADDRESS> interface=ether2_WAN_RESERVE

/interface list
add name=WAN

/interface list member
add interface=ether2_WAN_RESERVE list=WAN
add interface=ether1_WAN_MAIN list=WAN

/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN

/ip firewall mangle
add action=mark-connection chain=input in-interface=ether1_WAN_MAIN new-connection-mark=Input/ISP1
add action=mark-routing chain=output connection-mark=Input/ISP1 new-routing-mark=ISP1 passthrough=no
add action=mark-connection chain=input in-interface=ether2_WAN_RESERVE new-connection-mark=Input/ISP2
add action=mark-routing chain=output connection-mark=Input/ISP2 new-routing-mark=ISP2 passthrough=no
add action=mark-connection chain=prerouting in-interface=ether1_WAN_MAIN new-connection-mark=Forward/ISP1
add action=mark-routing chain=prerouting connection-mark=Forward/ISP1 in-interface=!ether1_WAN_MAIN new-routing-mark=ISP1 passthrough=no
add action=mark-connection chain=prerouting in-interface=ether2_WAN_RESERVE new-connection-mark=Forward/ISP2
add action=mark-routing chain=prerouting connection-mark=Forward/ISP2 in-interface=!ether2_WAN_RESERVE new-routing-mark=ISP2 passthrough=no

/ip route
add distance=1 gateway=<ISP1_GATEWAY> routing-mark=ISP1
add distance=1 gateway=<ISP2_GATEWAY> routing-mark=ISP2
add distance=1 dst-address=8.8.4.4/32 gateway=<ISP2_GATEWAY>
add distance=1 dst-address=8.8.8.8/32 gateway=<ISP1_GATEWAY>
add distance=1 dst-address=77.8.8.1/32 gateway=<ISP2_GATEWAY>
add distance=1 dst-address=77.8.8.8/32 gateway=<ISP1_GATEWAY>
add check-gateway=ping distance=10 gateway=8.8.8.8 target-scope=30
add check-gateway=ping distance=20 gateway=8.8.4.4 target-scope=30
add check-gateway=ping distance=10 gateway=77.8.8.8 target-scope=30
add check-gateway=ping distance=20 gateway=77.8.8.1 target-scope=30

/ip route rule
add action=lookup-only-in-table routing-mark=ISP1 table=ISP1
add action=lookup-only-in-table routing-mark=ISP2 table=ISP2

Checking for two hosts on both interfaces (Google and Yandex DNS).
But for me, this is half the trouble, the connection to another branch is organized via L2TP / IPSec, this particular router is a client and an L2TP / IPSec session that successfully switches from ISP1 to ISP2, tk. the session breaks and reconnects along a new route, but when the Internet appears on ISP1, it is in no hurry to re-up on it, because she and ISP2 is not bad.

Answer 3

I think it's some kind of crutch.
The only plus in them is that there is no script, but otherwise there are solid minuses.
I advise you to implement using a script, you can google examples. You will check the same hosts through both connections, run at the desired frequency, write to the logs about the unavailability of the Internet, there will be no such trash in the routing and other goodies.