I have the following setup in my 2011 router:
ether2 - WAN (backup) - distance 10
ether3 - WAN (primary) - distance 1
ether10 - LAN
When I ping from ether3, (/ping 8.8.8.8 interface=ether3) I get response.
When I want to ping from the backup interface to check if it has internet (/ping 8.8.8.8 interface=ether2), I get timeout and I am unable to ping from it…
When I set the backup interface to distance 1, and primary to distance 10 I can ping with no problems, but then I get timeouts on the interface with distance 10…
How can I overcome this behaviour? I really appreciate your help and input!
Regards
Now you can rest assured that pings to Google’s primary DNS 8.8.8.8 will go out WAN1 & pings to Google’s secondary DNS 8.8.4.4 will go out WAN2 and if one is down the pings to that one will fail.
There are more elegant solutions but this one is a quick way.
Please note that “ping something to see if the internet is working” is relying on two different factors:
your internet connection being ok (what you want to test)
the destination system being up and responding to pings
Should google decide that pinging their DNS servers is some kind of abuse, and to filter that, you will suddenly think
that your internet connection is down. This may cause difficulty when you attach script actions to that situation
that change routes, reboot the router or modem, etc.
My internet provider has been offering a dedicated DNS name for such ping checks starting from about 15 years
ago, because more and more users were running ping on their routers and other equipment to check if their link
was working or not (this was when always-on internet, DSL in this case, appeared).
They noticed the equipment was sometimes heavily loaded by this, because the pings were processed by a management
processor rather than the normal hardware. So they asked everyone “please only ping to this system” and filtered
pings in some places. A couple of days ago, that system went down. This caused many “interesting effects”…
Agreed. I don’t use pings at all. I use two tunnels per WAN for connection monitoring. If both tunnels are down for x then that WAN is considered down and routing is adjusted accordingly. When they come back online for x then it returns to normal routing.
would be nice, but it is not meant for ipv4. But there is a simple workaround.
Let’s say 10.0.0.1 is the connected gateway for the interface wan. You have to prepare a special routing table:
will test if 8.8.8.8 can be reached through wan. The second route, the blackhole ensures that the
command will not try finding another route in the main routing table.
Simple and clear, but you need to run periodically a script. Activating-deactivating routes based on availability of an address is also possible using recursive routes, setting the scope and target-scope parameters … good luck figuring out how. The documentation about that is too blurry for me.