Subject: Re: down interfaces, link detection, and connected routes
To: None <tech-net@NetBSD.org>
From: David Young <email@example.com>
Date: 01/17/2005 20:27:46
On Mon, Jan 17, 2005 at 11:30:08AM -0500, Greg Troxel wrote:
> On the quagga lists (www.quagga.net) we have been discussing handling
> of connected routes for interfaces that are down, or for which link
> detection is supported and no carrier is reported.
> By 'connected route', I mean a route that represents that a prefix is
> on a directly-connected interface. This is essentially a "cloning"
> route, except that we don't care about the ARP part. NetBSD installs
> such a route when an address is ifconfig' onto an interface.
> People desire two things to happen:
> a) if interface is down, or reports no carrier, don't redistribute the
> connected route. This is purely a quagga issue, and I think only the
> second part needs work for the NetBSD case.
> b) if the interface is down, or reports no carrier, don't use the
> connected route, and instead be able to put another route for that
> prefix (or a larger prefix) from the RIB into the FIB.
> The point of b is e.g. that if 10.0.1.1/24 is on ex0, and 10.0.2.1/24
> is on ex1, and if ex1 reports no carrier, and there is a route to
> 10.0.2.0/24 available via OSPF to 10.0.1.3, then install the OSPF
> An example where this would have been useful was a notebook with an
> ethernet and an ath(4) interface, which is one of two machines routing
> bewteen an ad-hoc subnet and a particular ethernet. The cable was
> unplugged, and the notebook moved (to take to a conference room).
> The notebook continued to advertise the ethernet, and thus black-holed
> packets for it. Typing 'ifconfig wm0 down' stopped importing the
> route into ospf, but the notebook still used it itself.
> Arguably this was a configuration error not to remove the interface
> address and take it down before disconnecting.
> So, I wonder if the kernel should remove the cloning routes when an
> interface goes down, and reinstall them when it goes up. And then if
> it should do this on link detect events. This is messy since on the
> upward transition there may be another route present. So this might
> get into having them both present, with weights, and marking them
> inactive, etc., which is even more complicated. (I realize this may
> be controversial and should perhaps be optional.)
Can you use ifwatchd to add/remove routes for interfaces whose carrier
state changes? Hopefully Quagga will cope if you RTM_CHANGE a route
that comes from, say, OSPF.
FWIW, I have improved [*] the RADIX_MPATH patches from KAME.net.
RADIX_MPATH most famously lets us store more than one nexthop for a
single destination prefix; it chooses the nexthop to use by hashing
the source/destination pair; for better or worse, the forwarding
decision is cached "in the usual way." I have added a hook to
RADIX_MPATH for "weighting" routes [**], made it possible to keep both
RTF_GATEWAY/RTF_LLINFO information (indirect/direct route) for a single
destination, and added a "wireless" forwarding heuristic [***].
* They're "improved" except for the bugs. I ahd to cut the project
loose shortly after the FIB code started to make sense, FSVO of
"make sense." [****]
** The "hook" is a macro that yields 1; it would presumably read
an rt->rt_weight member of a 'struct route'. I do not remember
the details, but I think that if rt_weight were set to 0, that
would effectively prevent RADIX_MPATH+dyoung patches from picking
that route. Cached routes would have to be expired, but we badly
need to do that anyway.
*** If the routing daemon enters an indirect route to a host that
is directly connected, the wireless heuristic assumes that the
routing daemon knows best, and forwards to the indirectly connected
**** Clearly the code was written in another time, when compilers
were not as sophisticated, computers were not as powerful, and
programming practices were different. That said, the longevity of
the code speaks for itself.
David Young OJC Technologies
firstname.lastname@example.org Urbana, IL * (217) 278-3933