svn commit: r205024 - head/sys/net
Qing Li
qingli at freebsd.org
Thu Mar 11 23:30:26 UTC 2010
>
> 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".
>
What you raised is definitely a possibility and these fixes take the
similar approach. I am going to try and go through each of these
drivers in /sys/dev/ and converting them, very soon.
>
> (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?
>
For loopback interfaces, althgouth administrative these can be taken down,
I personally cannot think one practical usage case where ECMP across
loopback interfaces would be interesting or usefaul. So I can think of
very little reason to be concerned in the loopback case.
>
> 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'"?
>
The above really falls into policy based routing. And policy based
routing infrastrucutre is something I have already been working on
but cannot yet
push back into -current. In fact Julian and I had a conversation about
this topic during the FIBs implementation time in late 2008.
This infrastructure enhancement is definitely coming but I cannot yet prvoide
a timeline for merge back.
It's mostly a time issue.
Let me know if I have answered these questions to your satisfaction.
-- Qing
More information about the svn-src-all
mailing list