lkml.org 
[lkml]   [2003]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [2.4 PATCH] bugfix: ARP respond on all devices
From
Date
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>
> One thing I agree with you about is that an ARP resolution for an
> address via one path should not block a resolution for it by another
> path since to begin with the two paths may be to different routers
> one of which is down.

ARP resolution is per device. You can have multiple neighbours per
route, either using a multipath route (ip route add ... nexthop 1 nexthop ...)
or using default routing failover for the default route. When there
is an existing neighbour entry (valid or invalid) on a device there
cannot be another one, but there could be one on another device.
The routing code could transparently fail over to other devices using
suitable routes.

One long standing problem however in that code is that there is no
feedback from ARP to the multipath routing code to trigger failover.
The only way currently to get a failover in the multipath route is to run
a daemon with a keepalive protocol (like gated/zebra with OSPF) that does
ifconfig down for bad interfaces, triggering the route failover.
The kernel already has such a keepalive protocol in the form
of ARP, just it doesn't use the information for routing.

For multiple default routes it should work already transparently
in the kernel, just not for normal multipath routes.

I suspect if someone fixed this (implementing feedback from the
neighbour state engine to the rt cache/FIB code for failover) cleanly
the network maintainers would consider it favourably.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.072 / U:2.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site