If i assign metric 1 to 1st gway and 2 to 2nd it never falls back from gateway with best metric. Even if it goes down it still sticks to it. Something is terribly wrong. I am running Slackware 10.
I just went back and re-read what "Unix Networking" and "Linux Network Administrator's Guide" have to say about Metrics and I'm wrong.
They apply to Routing daemons (like RIP and gated) and help pick the "fastest" gateways (apparently, the metric is supposed to indicate a number of "hops" from here to there....)
However, what if, you create a process which does nothing else but check the status of interface 1. Set up a default route through interface 1 with a default metric (of say "2"). When the interface goes down, have the process "bring up" the second route by adding it to the routing table with a metric of "1". Now the second interface is the "cheapest". Your process should now continue to monitor the state of interface 1, and when it comes back up, you need to figure out how to "dismantle" the second interface. It could be just as simple as swaping the metrics so that interface 1 is now the "fastest" route.
Like I said before, I'm not a networking expert, and I don't understand all the dependancies of already open connections over the various routes, but it seems like a pretty simple way to do things. OTOH, isn't this essentially what RIP and gated would do for you? Inotice that Fedora Core 2 has a "routed" package. Perhaps that has replaced RIP/gated in todays world (my documentation is 10-14 years old)?
Disclaimer: I don't use RIP or gated (anymore) I have a single default interface (cable modem). The last I tried to use RIP/gated, I was on a corperate network over a 9600 baud modem, and the "RIP storms" eventually consumed the entire bandwidth of the modem rendering the connection unusable.
-- Kevin J. Cummings kjchome@xxxxxxx cummings@xxxxxxxxxxxxxxxxxx cummings@xxxxxxxxxxxxxxxxxxxxxxx - : send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
