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 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
