> > 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 _______________________________________________ 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"
