I have created a fairly extensive script, using some of the concepts I've seen in other scripts.
This script does several things.
1) It will ping a host x number of times and will change the metric of the specified route from 1 to 3 when y number of pings aren't returned. [i.e. If <8/10 pings return, consider the route down.]
This, IMO, is a lot better than just a black/white ping return test. [i.e. Did we get ANY pings back, then consider the pipe up.]
Also, by setting the RTT [interval] value, you can also do some rough RTT evaluation, and consider the pipe down if x of y packets returned at a specific RTT value. [You can't tell what the average RTT was, but you can set the RTT to be, say 300 ms. If the packet doesn't come back in <300ms it will consider it a "missed" ping. So, if 300ms was your minimal good RTT value, you would know that either the ICMP response was outside that RTT time, or lost altogether.
It will set the primary route to a metric of 3 when it's down and return it to a metric of 1 when it's "up" - this allows you to continue to test the route to see if it comes back up - without taking the route down and de-activating the interface.
[This is also helpful if you, like I, gather stats on external interfaces with something like smokeping - this way the interface will continue to respond, even if it's officially down. This allows testing, troubleshooting and statistics gathering to go on even when the interface is "down."]
The "backup" route should be set with a metric of 2.
2) It will email you status when the specified route goes down or up.
3) It will update a DynDNS record [optionally] with the new IP of the current default route. [This way you can re-point VPN pipes etc based on a DNS record. (I have a script to repoint an IPSec tunnel on ROS that I'm nearly done with too.)]
The code is extensively documented, and I've done quite a lot of testing - so it should be pretty solid.
It will write to sd or flash to handle the IP state across reboots. [Very similarly to my DynDNS script.]
It won't make changes to DynDNS unless the IP has changed [which will happen when a route is considered down.]
It doesn't write to flash unless the state changes. [Route goes up or down.] So, very short cycle/run times won't stress flash any more than lengthy cycle times.
This script has been created in ROS 5.12, tested on a 450G
It should work on other devices, and probably other ROS versions too, but I can't say which.
If you do use this, I'd appreciate feed-back.
1) Did it work? If not, what kinds of things were a problem?
2) What hardware did you run it on.
3) What ROS version
4) Comments, questions
5) If you modified the code, could you submit it back so I can, perhaps, integrate the changes?
Finally, Karma would be nice.
---
2012-03-21 - Updated to v1.0.0.8 [If you have a prior version, please use the newest version, as the old one has a show-stopper bug.]
---
2012-03-26 - Updated to v1.0.2.4 - MANY changes.
-Will create files needed for dyndns updates if they don't exist, so the user doesn't need to hand-create/install them.
-Documentation changes on how to create a mangle rule, and script modify that rule so that the ping traffic will continue to flow over the primary connection when it goes down so we test the "down" connection until it comes back up and modifies the metric.
-Adds the ability to use a FQDN as the ping target.
-Moves :resolve script commands to "late" in the script, so that failures won't crash the most important parts of the script.
-Many other changes and bug fixes.
This should be really solid. I've done a lot of testing.
I've left quite a lot of :puts for debugging in the code - I'll probably remove them at some point, but I've tried to limit :log output except where it's useful. The log output probably won't change much.
** Update 2012/04/01 **
v1.0.2.5
Minor modifications. No update needed for prior users. Better support for new users, in terms of file initialization.
The comments in the header of the code are very long - sorry - but they have to be for documentation purposes. At least they're not as terse as a man page!
Please let me know how it works for you. Additions, comments, code additions/changes are all welcome.
Karma would be nice!
You do not have the required permissions to view the files attached to this post.