Outstanding multipath related PR; Floating statics.

[Bruce M. Simpson]

Hi there,

I have been cleaning up my PRs.

The last PR I have remaining in my queue is directly related to the 
multipath work you are doing:
    http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71474

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.

Follow the code in in_rmx.c for in_ifadown() to understand why the 
problem with downed interfaces happens.

Traditionally, BSD has not skipped ifnets which are marked as being down 
during outbound interface selection. I'm not entirely sure why we should 
even be looking at downed interfaces for that last part of next-hop 
selection in the first place. Ruslan (Cc'd) suggests there are cases 
where this is necessary, I can think of none.

The mere fact that the first match may be used fails to take account of 
the ifnet referenced by rt_ifp being down would clobber correct path 
selection behaviour for multipath.

To be sure, recursive resolution of the next-hop could solve the problem 
described in the PR, at the expense of introducing unnecessary 
complexity into the kernel FIB.

However, at the end of the PR I suggest a more general approach which 
could be used to deal with the situation where the destination is *not* 
covered by interface routes -- floating statics.

Both Cisco and Juniper implement floating statics in their FIBs, and 
they would actually allow folks who unplug their cable and expect to be 
able to seamlessly fail over to wireless in the most general case, by 
making 0.0.0.0/0 a floating static.

cheers
BMS