Multiple default routes on multiple interfaces

I have two DSL lines from the same provider on two different static IPs
and two interfaces for my linux box. I am not particularly worried
about load-balancing here. I just want failover between the two lines,
with next-hop detection if possible. The idea is that I don't need
heavy-weight applications like OSPF or BGP (since it's the same
provider), nor any fancy routers; just something that determines if
line 1 is down, switch the default route to line 2 (automatically: I
know I can do it by hand, or even write a shell script).

For those who will ask, I did try a switch to bring everything to a
single interface and single IP on the linux box. But when line 1 is
down, the default route and IP for line 1 won't work over line 2.
Initially, I thought it was an arp issue, but it wouldn't resolve after
several minutes, nor after arp -d. The IPs are contiguous /29 networks
(which I have successfully combined into a /28), but it does not
failover properly. In the "single interface" scenario, I would have to
assign a new default route *and* IP (and even source routing,
probably...).

I understand that iproute2 will/should allow multiple default routes,
but then it will round-robin based on destination (this is how I used
to setup Cisco behaviour and how I believe Solaris handles it). But
what is the failure detection? Link loss? Next-hop down? Anyone have
an easy solution to what should be relatively common?

Look into Linksys routers RV041, RV042, RV082 and RV016. For example:
http://www.linksys.com/products/prod...id=29&prid=589

On 6 Jul 2005 16:00:51 -0700, (E-Mail Removed) wrote:

>I have two DSL lines from the same provider on two different static IPs
>and two interfaces for my linux box. I am not particularly worried
>about load-balancing here. I just want failover between the two lines,
>with next-hop detection if possible. The idea is that I don't need
>heavy-weight applications like OSPF or BGP (since it's the same
>provider), nor any fancy routers; just something that determines if
>line 1 is down, switch the default route to line 2 (automatically: I
>know I can do it by hand, or even write a shell script).
>
>For those who will ask, I did try a switch to bring everything to a
>single interface and single IP on the linux box. But when line 1 is
>down, the default route and IP for line 1 won't work over line 2.
>Initially, I thought it was an arp issue, but it wouldn't resolve after
>several minutes, nor after arp -d. The IPs are contiguous /29 networks
>(which I have successfully combined into a /28), but it does not
>failover properly. In the "single interface" scenario, I would have to
>assign a new default route *and* IP (and even source routing,
>probably...).
>
>I understand that iproute2 will/should allow multiple default routes,
>but then it will round-robin based on destination (this is how I used
>to setup Cisco behaviour and how I believe Solaris handles it). But
>what is the failure detection? Link loss? Next-hop down? Anyone have
>an easy solution to what should be relatively common?

Multiple routing is not really round robin, and if the (patched)
kernel can detect that one or the other of the links is dead, DGD does
work. Read nano.txt from JA's site (below).

To the best of my knowledge, the only thing that works 100% is a
script that always runs. When 'ping -I eth1 -c1 $GATEWAY1' fails, the
link is dead.

You might want to ask Julian Anastasov. http://www.ssi.bg/~ja/

http://www.geocities.com/mctiew/ffw/dual.htm is also a good read.

My experience has been that DGD only goes to the first "next hop", so
if the DSL modem is powered on, DGD thinks the connection is fine -
even though the gateway (the second next hop) cannot be reached.

You may also want to check out the high availability project. I seem
to have lost my link to that :< I think there is mention of it on the
LARTC mailing list. Oh, here it is: http://linux-ha.org/

My setup is at http://yesican.chsoft.biz/lartc and
ftp://andthatsjazz.org/lartc - in case any of that is of any help. I
screwed myself a bit recently by SNATting incorrectly, but except for
that I'm able to use 2 providers with failover and nobody (except me)
even knows that one of the connections is down.
--
buck

buck wrote:
> On 6 Jul 2005 16:00:51 -0700, (E-Mail Removed) wrote:
>
> >I have two DSL lines from the same provider on two different static IPs
> >and two interfaces for my linux box. I am not particularly worried
> >about load-balancing here. I just want failover between the two lines,
> >with next-hop detection if possible. The idea is that I don't need
> >heavy-weight applications like OSPF or BGP (since it's the same
> >provider), nor any fancy routers; just something that determines if
> >line 1 is down, switch the default route to line 2 (automatically: I
> >know I can do it by hand, or even write a shell script).
> >
> Multiple routing is not really round robin, and if the (patched)
> kernel can detect that one or the other of the links is dead, DGD does
> work. Read nano.txt from JA's site (below).
>
> To the best of my knowledge, the only thing that works 100% is a
> script that always runs. When 'ping -I eth1 -c1 $GATEWAY1' fails, the
> link is dead.
>
Not really elegant, but I guess that's how it works. Even this
document says the same thing (at least for link reactivation after a
failure):

http://www.ssi.bg/~ja/nano.txt


> You might want to ask Julian Anastasov. http://www.ssi.bg/~ja/
>
> http://www.geocities.com/mctiew/ffw/dual.htm is also a good read.
>
> My experience has been that DGD only goes to the first "next hop", so
> if the DSL modem is powered on, DGD thinks the connection is fine -
> even though the gateway (the second next hop) cannot be reached.
>
http://www.ssi.bg/~ja/dgd-usage.txt

This document seems to be what I need. I'm still somewhat lost on the
actual mechanics of detecting next-hop down (not talking about ethernet
link failure). In my case, the modems are bridges, and the next hop
arps are the actual router at the ISP, so I think neighbor detection
will work... I'm going to have to test this a lot.

It really could be as "simple" as a multipath route command.