svn commit: r205024 - head/sys/net

[Robert Watson]

On Thu, 11 Mar 2010, Qing Li wrote:

>  The if_tap interface is of IFT_ETHERNET type, but it
>  does not set or update the if_link_state variable.
>  As such RT_LINK_IS_UP() fails for the if_tap interface.
>
>  Also, the RT_LINK_IS_UP() needs to bypass all loopback
>  interfaces because loopback interfaces are considered
>  up logically as long as the system is running.
>
>  This patch fixes the above issues by setting and updating
>  the if_link_state variable when the tap interface is
>  opened or closed respectively. Similary approach is
>  already done in the if_tun device.

A couple of questions:

(1) It used to be the case that quite a few interface drivers and types didn't
     have a notion of "link up" -- especially older ethernet devices.  Do those
     all have the same problem?  It was probably a design oversight that
     devices don't declare an explicit capability for "can report link state".

(2) While loopback interfaces don't really have a link state, they can be
     administratively down -- should/do you check that as well as link state?
     And more generally, even if link is up, administratively down should be
     obeyed?

Finally, it would be neat if there were a way to have information beyond link 
state influence the choice to balance to a particular route/interface.  For 
example, imagine if I have a router with ECMP, and on the other side on a 
single ethernet segment, I have two DSL modems.  The ethernet link will remain 
up, but I may (via out-of-band mechanisms, such as SNMP or an active probe) be 
able to tell that one of the DSL lines is down.  Is there a way to push that 
information into the kernel currently without deleting the routes, and instead 
say "yeah, but for ECMP purposes this is 'down'"?

Robert