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
> route.
> 
> 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.)

Greg,

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 [***].

Dave

*    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
     host.
**** 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
dyoung@ojctech.com      Urbana, IL * (217) 278-3933