Its a really nice script. But this also works like a charm and this is very simple.
/ip route
add gateway=gateway1ip distance=1 comment=WAN1
add gateway=gateway2ip distance=2 comment=WAN2
/tool netwatch
add down-script="/ip route set [find where comment=\"WAN1\"] distance=3;\r\
\n:log warning \"WAN1 down, switching to WAN2\"" host=208.67.222.222 up-script="/ip\
\_route set [find where comment=\"WAN1\"] distance=1;\r\
\n:log warning \"WAN1 restored\""
/ip route
add check-gateway=ping distance=1 dst-address=208.67.222.222/32 gateway=gateway1ip
add check-gateway=ping distance=2 dst-address=208.67.222.222/32 type=blackhole
Netwatch send only one echo request and react if dont get response. This scary me alot. It is pretty normal, that some pings can be lost sometimes.
I have a potentially unique scenario in that I have to manually put in my Bell Fibre Op gateway information.
In other words lets say Bell is my primary and I have a secondary Cable connection (that works easy peasy just plug and connect).
The Bell on the hand is a pita, runs on vlanxx from the provider. Whenever I reboot or turn it off and on, the router does not pull an IP.
That is because I have to manually find out what the gateway is by going to dhcp client and double clicking on the Bell interface and then pulling up the status.
From there I read the gateway and plug that into my router rules and then I get reachable indications.
Do the scripts simple and new one address this scenario???
Decent attempt, but as with many scripts of the same nature that I see around these forums, this one too heavily relies on hard-coded values. Plus it will only work with up to 2 gateways.
I personally would avoid using the print command (although in this case you’re not using it with multiple records, so you get away with it) and restricting my find commands with too much criteria bar the necessary ones (so troubleshooting and maintaining is a little less of a headache).
One more thing is that I find the checking method a bit questionable.
It’s not uncommon for a couple of pings to fail, especially if this is used in environments with satellite internet.
Your 3/10 failures may occur every 3 successful pings for all you know, but that doesn’t mean that the internet is down.
One suggestion is to actually look for -consecutive- failures, before determining if the gateway is down for real.
Lastly, I believe that your implementation is a little bit too… talkative.
It’s fine really to help you learn and troubleshoot, but if you plan on using this on a more “production” environment, I would eliminate all but the necessary logs/messages.
If you’re interested in reviewing a more robust solution and pick up a few more tricks that you can do while scripting, you may check my signature for a suite of scripts which includes a fail-over mechanism amongst other things.