Outstanding multipath related PR; Floating statics.

[Bruce M. Simpson]

Bruce M. Simpson wrote:
>
> The problem which caused Thomas to raise the PR, is that of allowing 
> the prefix route for 192.168.1.0/24 to float over to the other 
> interface which *can* reach that prefix.

I should also point out that the problem exists at Layer 2 and Layer 3.

To be sure, if a route already exists for 192.168.1.0/24 which transits 
the downed interface, it will be chosen first. However if ARP entries 
are still in the stack, they represent the most specific match and their 
/32 entries will be chosen *before* any Layer 3 route, regardless of 
interface status.

In other words, the removal of ARP entries from the routing table would 
solve only half of the problem that Thomas has observed.

So I guess the real question is: should the lookup of the next-hop for a 
"connected" route, that is, the network prefix route associated with an 
interface, be allowed to "float" to the next interface which is UP? I 
think it should. Interface routes are NOT STATIC routes.

I'm in favour of retaining the existing meaning of STATIC routes. But I 
also think we should allow the IFP resolution for STATIC routes to 
"float" if they are configured as FLOATING STATICs as this is what most 
folk really want the forwarding code to do.

regards
BMS