On Sun, 23 Sep 2007 21:17:12 +0200
Frank Kardel <kardel@NetBSD.org> wrote:

> That matches my impression.
> 
> Is there any sensible strategy to fix routed ?
> 
> Maybe disable the code, make it configurable ?
> 

The problem is that routed doesn't have enough information to really do
things right.

*If* there's a better path to the world (or rather, to desired
destinations), what it's doing is arguably right.  See Section 3.3.1.4
of RFC 1122:

         3.3.1.4  Dead Gateway Detection
                      
            The IP layer MUST be able to detect the failure of a "next-
            hop" gateway that is listed in its route cache and to choose
            an alternate gateway (see Section 3.3.1.5).
            
            Dead gateway detection is covered in some detail in RFC-816
            [IP:11]. Experience to date has not produced a complete
            algorithm which is totally satisfactory, though it has 
            identified several forbidden paths and promising techniques.
 
The section goes on to say that you MUST NOT simply ping the gateway
routinely, but that relying on advice from transport and link layers is
"preferred". 

Strictly speaking, 1122 is speaking of the IP layer.  The RIP
specification (RFC 2453) doesn't say anything about the subject.
Regardless, deleting a default route is only useful if there's another,
distinct choice, and with RIP there isn't.  More precisely, routed
can't tell if another choice would work better, because other choices
may end up going through the same node.  OSPF can, in theory, know
better, but I've never looked to see if any implementations try to.

Perhaps the behavior should be configurable, either in an absolute
sense or by permitting specification of the percentage to use.  I
think, though, that the default should not change, since in the usual
operating model for routed (a) it's being run by routers, not hosts,
and (b) routers frequently have more than one path to use.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb