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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
