SJM> understood. However it would be nice if (under an option)
SJM> the rspfd could enable proxy arping on an interface it
SJM> controls, IFF it knows it is the "right" gateway for the
SJM> station doing an arp request. I guess the problem here is
SJM> there is a potential conflict where more than one routing
SJM> station thinks it has a route: ideally the one with the
SJM> shortest path should answer, but I imagine the solution to
SJM> this is not trivial.
I cannot emphasize strongly enough that combining proxy ARP with RSPF is a
really bad idea. I don't mean a slightly bad idea, but an extremely bad idea.
RSPF is supposed to monitor the ARP table for prospective adjacencies. In
theory, any change in the ARP table does represent at least a one-way
adjacency, but proxy ARP messes this up completely. All of the RSPF routers
who are fooled by the proxy ARP would then "discover" this new prospective
adjacency and attempt to test it. Exactly what behavior results would be
undefined, but there is a very real possibility that RSPF would set up a kind
of tunnel through the proxy. This, in turn, could cause absurd metrics to be
propagated by RSPF, essentially claiming zero-length paths through the proxy
and possibly even linking whole subnets across a grossly inefficient tunnel.
In the worst case, a routing loop could close through an alternate interface.
SJM> Otherwise "stale" dynamic routes won't be very dynamic :-)
SJM> Dynamic routes don't have a TTL field in the kernel routing
SJM> table do they? How do other routers solve this problem?
RSPF defines the process by which routes should become suspect and, if tested
and found bad, removed.