This is indeed very simple, but has a very limited functionality. You don't even have to specify the interface. Just let the DHCP client add the default route with a different route priority (advanced tab)
This the standard simple fail-over.
You have NOT solved the problem that others tackle. Checking if that path has internet connectivity,. Even if the gateway is UP, and the line active, this does not mean that you should use that line. The internet connection can be broken at many places. The other path could still be better, as it might have internet connectivity.
I believe you can use the interface as path in the other solutions. (Replacing the fixed gateway IP address 192.168.90.1 and 192.168.95.1 in my example by their interfaces)
This is my setup (not with DHCP dynamic IP addresses but at least the rest of the internet checks is there.)
The mechanism is as such: by playing with “scope” one can assign/use/check a remote (not directly reachable) gateway. (AFAIK this comes from iBGP routing. Not the simple routing we know)
The clue is to set scope on 10 while checking for reachability for that remote gateway
(gateway that actually never is used as gateway, just a phantom gateway check to see if that path there leads to internet)
So again my setup:
add check-gateway=ping comment="dynamische default route" distance=2 gateway=184.108.40.206
add check-gateway=ping distance=3 gateway=220.127.116.11
Route set #1: Those lines would normally not work. The gateways 18.104.22.168 and 22.214.171.124 are not directly reachable.
Because of the target scope on 10, routes with scope 10 will be used to resolve recursively, those are normally only directly attached subnets.
add comment="fallback dynamische default route" distance=10 gateway=192.168.90.1
add distance=11 gateway=192.168.95.1
Route set #2 : This is a fallback, just in case all the Google servers are down, and the normal check will give a false negative (servers not reachable, but internet is reachable)
Actually by playing with the distance, this is already a fail-over between them that will function if the named gateway (directly attached) becomes unreachable.
To make it only act as fallback for route set #1, the distance must be higher than the route set #1.
Route set #3: Is not in this table, but is added dynamically by DHCP. This is the fallback of the fallback, where the gateway is actually broken & replaced or changed its IP address.
To make sure that set #3 is only used as 3th solution, the DHCP client default route parameter must set at a higher distance than route set #2. I use 20 and 21.
add comment="check 4G recursive for default route ( scope = 10! )" distance=1 dst-address=126.96.36.199/32 gateway=192.168.95.1 scope=10
add comment="check SkyDSL recursive for default route ( scope = 10!)" distance=1 dst-address=188.8.131.52/32 gateway=192.168.90.1 scope=10
Route set#4: this is the clue. This set of routes that make the gateways for route set #1 reachable, if they are reachable via multiple in between routers. (recursive)
The basic requirement for those routes to help out route set #1 is that the scope is 10 . Standard static routes are added with scope 30 !
If the gateway is reachable the corresponding route from set #1 is UP. If the gateway is NOT reachable, the corresponding route in route set #1 is DOWN.
This route set #4 is not used for data traffic (except for something directly addressed at the named gateways, like a DNS lookup)
See the wiki confusing doc: ( THE clue: we create a static route with scope 10 (value normally reserved for directly connected paths only).
And we know that static routes (with target scope 10) , do use routes with scope 10 as helpers. iBGP does something similar by setting “target scope” to 30.)
https://help.mikrotik.com/docs/display/ ... Are+Routed
You do not have the required permissions to view the files attached to this post.