Re: fallback default gateway

From: Andi Kleen (ak@suse.de)
Date: Tue Sep 12 2000 - 03:26:22 EST


On Tue, Sep 12, 2000 at 10:15:52AM +0200, Dr. Michael Weller wrote:
> On Mon, 11 Sep 2000, Andi Kleen wrote:
>
> > On Mon, Sep 11, 2000 at 02:31:55PM -0400, Edwin Chiu wrote:
> > > Hi,
> > >
> > > If I have multiple default gateways, and I'm using iproute2 for routing,
> > > how can I define fallback default gateways?
> > >
> > > i.e. if gateway 192.168.0.1 dies or goes down, how do I make traffic go
> > > through 192.168.0.10?
> >
> > You don't need to do anything, just define multiple default routes.
>
> How is this going to work? How will the kernel know which of the default
> gateways is currently up? Usually packets to down gateways just vanish
> unnoticed. Any timeouts from the TCP/IP application go back to the
> originator, the linux *router* would have problems to realize they belong
> to a packet it routed some seconds ago (provided it actually is a hop on
> the back route which cannot be guaranteed).

Linux does regular unicast ARP probes to maintain its neighbour states
unless it gets feedback from upper layers, e.g. TCP ACKs or MSG_CONFIRM.
When a neighbour goes suspect it tries other default routes.

This unfortunately only works for default routes currently, not for
multipath routes.

>
> I'd really like to know how this is implemented (pointers/url to readme,
> docs.. ), it would be a great feature. However, I doubt this will work.

RFC2461 is a good reference. Linux 2.2 uses the same algorithms for IPv4.

>
> I can imagine that the kernel routes default packets to the gateways in a
> round robin fashion. This way, if one of three default gateway fails, a
> third of the packets is lost but network connectivity is still there (at
> least to some extent). Not a really clean solution though, IMHO.
>
> I'd assume you need some kind of routing process/daemon that checks
> availability of the gateways (by ping or some other routing info exchange)
> and adjusts the routing tables accordingly. Theoretically this process
> could be embedded into the kernel, but I don't see a real advantage about
> a user process here.

OSPF works somewhat faster than this mechanism, correct.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org



This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:29 EST