bugfix: ARP respond on all devices
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Alan Cox
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
Quoted 3 lines · On Tue, 19 Aug 2003 22:00:09 +0200 Andi Kleen <[email protected]> wrote:
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.
Indeed, I'd be thrilled to see such patches.