Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Andi Kleen]

Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/