Subject: down interfaces, link detection, and connected routes
To: None <tech-net@netbsd.org>
From: Greg Troxel <gdt@ir.bbn.com>
List: tech-net
Date: 01/17/2005 11:30:08
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.)

Thoughts?

-- 
        Greg Troxel <gdt@ir.bbn.com>