If you have two or more gateways to the internet with fail over you need to know if your link to the internet is up and running or not. It is not enough to know if the next device (=your gateway) is up.
I have wireless symmetric line delivered to me and it comes with two boxes sealed by ISP and unreachable by me.
My gateway to that line connects to THEIR router and my router checks with ping that next unit.
But next unit of provider is radio box (I don’t know bridged or routed) and then other side of the link their tower has more stuff..)
Last time when heavy thunderstorm broke loose they shut down their tower (??? Yes, don’t ask me why!) but my router was still having a perfect ping check to their first box! So my router thinks that gateway is still alive and routes didn’t jump to backup!
So yes, it would be VERY useful if route can ping towards remote server somewhere in the internet cloud.
Better option, if router could actually ping towards TWO different remote servers for more security. (Even the most reliable servers don’t respond ping’s at time…)
Best option would then if we could even choose for name resolving to remote dns server(s).
Ping is only icmp and when a dns server respond you have better change internet really works and at same time you also check dns server. If you use your preferred dns server for gateway check the route can also jump to backup if dns server is down (if you need that).
Ok, we can probably do this all with scripts. But 20 years ago I heard about “script kiddy’s” and always found these are some defect in human beings…
MT scripting is not very simple, takes a learning curve and why should I write rules to get a device to do what I want if that device is been sold to me as the ultimate router?
[Apart from the fact that MT scripting syntax has been changed several times so even the nowadays “script daddy’s” went crazy each time they found it’s been changed yet again… ]
I’ve created a script that addresses this as well. You can feed it 3 IP addresses, it will ping each one 9 times to determine the link state, and if they fail will shut down the specified routes:
:local x 0; {:do {:set x ($x + 1)} while (($x < 3) && ([/ping 4.2.2.1 interval=1 routing-table=ISP1_Test count=3]<=1))};
:local y 0; {:do {:set y ($y + 1)} while (($y < 3) && ([/ping 4.2.2.2 interval=1 routing-table=ISP1_Test count=3]<=1))};
:local z 0; {:do {:set z ($z + 1)} while (($z < 3) && ([/ping 4.2.2.3 interval=1 routing-table=ISP1_Test count=3]<=1))};
:if ($x=3 && $y=3 && $z=3) do={:if ([/ip route get [find comment="ISP1-Script"] disabled]=no) do={:log error "ISP1 Down";
/ip route disable [find comment=ISP1];
/ip route disable [find comment=ISP1-Script];
/tool e-mail send to="support@domain.com" subject=([/system identity get name] ." ISP1 Down") body=("On ".[/system clock get date]." at ".[/system clock get time]." ISP1 appears to have gone offline.");
delay delay-time=5;
:foreach i in=[/ip firewall connection find connection-mark=outside1_connection] do= {ip firewall connection remove $i;}
}
} else { :if ([/ip route get [find comment="ISP1-Script"] disabled]=yes) do {:log info "ISP1 UP";
/ip route enable [find comment=ISP1];
/ip route enable [find comment=ISP1-Script];
/tool e-mail send to="support@domain.com" subject=([/system identity get name] ." ISP1 UP") body=("On ".[/system clock get date]." at ".[/system clock get time]." ISP1 appears to have come back online.");
}
}
Set up a route with a routing mark that will be used to ping over, as long as check gateway is turned off in all of the routes that you are testing and it maintains an Ethernet link on the interface, this script works well to monitor the state of the connection. I have it find the routes to disable by their comment since it is much easier to select what you want to disable that way and seems to be the most efficient and accurate way to do it. I also have it clear out established connections with a connection mark for that route so the router will not continue to try and send established connections out through the failed route. In addition to this it sends out an e-mail with a time stamp of when the internet connection went down and when it comes back up.
Something similar just happened to us: One of our ISPs gives us a box that cannot be bridged; it is a router that hands us a LAN address and default gateway via DHCP. Today, their upstream link failed–but because our next hop (their router, on our premises) was still responding, our router didn’t see anything wrong, and kept sending traffic to the dead-end. It would be very helpful to be able to specify a ping address on the other side of the gateway, to check it.
I agree, it would be much more elegant to be able to tell ROS who to ping via each interface, than to write a script to do it.
Speaking of writing scripts, I discovered that the “/ ping” command doesn’t seem to work when you specify an interface, and that the “/ tool ping” command doesn’t allow you to specify an interface–one of the rare times when you can do more in Winbox than you can from the command prompt.
It is! But we are not (yet) using routing marks on our traffic, just a simple ECMP default route, in which one ISP is weighted 4x the other. It wasn’t clear to me how to adapt your solution to our environment. I understand the part about routing a specific target address through a specific interface, but will the check-gateway=ping in those routes disable the same gateway in our ECMP default route as well?
Brilliant! Within 30 seconds of disconnecting one of the WAN lines, the corresponding “test routes” all turn blue in Winbox and report “unreachable”–and the default route stops sending packets to the disconnected interface.
It would still be nice if ROS let us do this directly, but this is definitely a solution that gets the job done without any additional programming (and especially debugging) on our part. Many thanks!
]