Dynamic routes and High Availability

I’ve found various proposals to deal with this, but all seem somewhat specific to the precise circumstances. This gist seems the closest to what I want to do but I wonder if there are better/easier solutions?

Router (5009 running 7.17, if that matters) has two internet connections. One is a GigE connection to a GPON OLT. The other is an LTE modem plugged into the USB port. Both use DHCP to acquire addresses and routes, with the distance set to 1 on the GPON and 2 on the LTE. The idea is failover backup. The GPON interface will stay up in the event of GPON failure (because the OLT will remain powered) so I can only detect route failure by ping or other “logical” tests.

I assume that if I do nothing it’ll work, but have failover times comparable to the DHCP lease time on the GPON interface. On renewal, the GPON interface will lose its address and eventually the route will fail over.

Because the default routes are dynamic, ping testing is not available directly. The gist I have cited requires that I know (and hard-wire) the gateways: doing that would involve turning off the insertion of the default route by the DHCP client and relying on the remote gateway not changing.

I’m reasonably comfortable this would work medium term: I have a static IP address for the GPON so it seems unlikely the router would move from being .1 in the associated /24, and the gateway for the LTE appears hard-wired to be 192.168.8.1. There is a problem that the GPON router (the .1) doesn’t answer ping, but arp testing should work.

But long term I’d like to do this in a way which doesn’t involve hard-wiring addresses I don’t control. I’ve had various ideas. One is to drop the weights to 2 and 3 and then write a script which adds a weight 1 route to whichever of the other default routes are up. Another is to do roughly that, but from an associated Unix machine using the API (just because “Python and API calls” is easier to debug than Mikrotik scripting). A third is to use the approach in the gist, but have the routes periodically rebuilt by introspection into the dynamic routes.

Overall, “I’ve got two DHCP-supplied default routes, pick the best” doesn’t seem like a weird edge case situation, and I’m slightly surprised there isn’t a standard way to do it. Any thoughts?

One way is to use recursive routing, basic format:

add check-gateway=ping distance=1 dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-table=main scope=10 target-scope=12
add distance=1 dst-address=1.1.1.1/32 gateway=CurrentISP1-gatewayIP routing-table=main scope=10 target-scope=11 comment=WAN1-Recursive
add distance=2 dst-address=0.0.0.0/0 gateway=CurrentISP2-gatewayIP routing-table=main

In IP DHCP settings
DHCP
set peer dns=no, peer ntp=no default route=yes
ADVANCED
set route=255
In the script area put:


:if ($bound=1) do={
:local gw $“gateway-address”
/ip route set [ find comment=“WAN1-Recursive” gateway!=$gw ] gateway=$gw
}

What it would look like in export config:
/ip dhcp-client
add comment=MyWAN default-route-distance=255 interface=etherX script=“:if ($bound=1) do={\r
\n:local gw $"gateway-address"\r
\n/ip route set [ find comment="WAN1-Recursive" gateway!=$gw ] gateway=$gw\r
\n}\r
\n” use-peer-dns=no use-peer-ntp=no


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The other common way is to use NETWATCH… someone else can assist on that as its not my usual go to.

And this is another way using netwatch:
http://forum.mikrotik.com/t/simpler-failover-for-two-gateways-i-found-working/169108/1
the further simplified method here:
http://forum.mikrotik.com/t/simpler-failover-for-two-gateways-i-found-working/169108/1
has been tested and it is working, but is intended for static addresses/routes, if you need to use the DHCP on the GPON and LTE you might want to manualy restrict them to a single address or use DHCP scripts similar to the one anav posted that effectively downgrades the DHCP provided route to distance 255 and sets the actual DHCP provided gateway on the pre-existing static route, and in point 3 the netwatch script will need to be changed back to find comment= (since the gateway may be changed by the DHCP, selecting the route with [find dst-address=0.0.0.0/0 and gateway=w.x.y.z] won’t be a good method anymore).