athX + ierrs + routed

[Frank Kardel]

Hi,

I just tripped over following effect:
Given a notebook with ath0 & fxp0.
ath0 being the internet access path
fxp0 providing NATed internet service via
fxp0.

When running routed on this machine (not
really necessary in that setup) routed
detects a SICK/BROKEN interface (ath0) because
the ierrs reported exceed input pakets.
So routed drops the routes to that interface
(including cloning llinfo thus disabling ARP) and
the internet link is gone.

Two questions:
- the high ierr counts on ath0 - do they make sense
wrt/ routed's interpretation of a 'broken' interface.

- is it ok that routed cuts off the last somewhat working
link to the rest if the world ?

I guess it all depends on the semantics of the counters which are
said to have ill/no defined meanings somewhere in the manial/code base.

If these semantcs are not well defined how can we allow routed to make
decisions based on the counters ?

What needs to be fixed?
- routed - ignore errors - maybe configurable
- ath(4) - tune down on ierrs

I also wonder whether routed really should disable the 'last' link.

Comments ?

Frank

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Frank Kardel
What needs to be fixed?
- routed - ignore errors - maybe configurable
- ath(4) - tune down on ierrs

IMO, routed is misusing the interface stats.

Dave

[Frank Kardel]

That matches my impression.

Is there any sensible strategy to fix routed ?

Maybe disable the code, make it configurable ?

Frank

Post by David Young

Post by Frank Kardel
What needs to be fixed?
- routed - ignore errors - maybe configurable
- ath(4) - tune down on ierrs

IMO, routed is misusing the interface stats.
Dave

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Sun, 23 Sep 2007 21:17:12 +0200

Post by Frank Kardel
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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Frank Kardel]

Steven M. Bellovin wrote:

[...]

Yes, RIP has a hard time to get it right.

Post by Steven M. Bellovin
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.

It think being able to specify the failure rate might be a good way.
We could add a config keyword like
failrate=xx|ignore to the processing of /etc/gateways with a default that
matches the current behavior. That way we could at least control routed's
behavior.

Post by Steven M. Bellovin
--Steve Bellovin, http://www.cs.columbia.edu/~smb

Frank

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Mon, 24 Sep 2007 00:03:49 +0200

Post by Frank Kardel
[...]
Yes, RIP has a hard time to get it right.

Post by Steven M. Bellovin
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.
It think being able to specify the failure rate might be a good way.

We could add a config keyword like
failrate=xx|ignore to the processing of /etc/gateways with a default
that matches the current behavior. That way we could at least control
routed's behavior.

Post by Steven M. Bellovin
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Frank

Works for me.


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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de