Re: Dest Unreach Rate limits, was: Re: Linux 2.1.x showstopper list

Andi Kleen (ak@muc.de)
Wed, 19 Aug 1998 21:59:55 +0200

On Wed, Aug 19, 1998 at 09:09:12PM +0200, kuznet@ms2.inr.ac.ru wrote:
> > can easily make a linux router thrash its routing cache, which is bad.
>
> It is not an exception, but normal operation.
>
> Look, if this packet were absolutely valid, it would be
> delivered to its destination, which would answer,
> grabbing route too.
>
> Actually, paranoia about icmp dst unreachs is close to non-sense.
> The only case, when it does matter, is when it results in
> amplification of traffic (i.e. redirects). In the case of
> dest. unreach icmp output cannot exceed data input, hence
> there is no problem. If packet source is faked forcing us
> to direct packet to slower interface, we still may turn on
> rp filtering. (Or even accept LBNL paradigm, bundling icmp
> errors to 3% cbq class 8) It is configurable option now.)

There is not much I could say against this good argument.

>
> BTW, I do not remeber, that someone complained f.e. about
> TCP RST problems, which has absoluteley the same scope
> and common roots.

This is a good point I forgot. Do you think it would add too much overhead
if a "JUNK" flag could be added that is tested by rt_fast_clean() ?
There are unfortunately no RTCF_* bits left (except for maybe RTCF_NOTIFY,
which seems is only set but never tested, except I missed something), but
dst_entry has an unused "rtt" member which could be used for this purpose.

There are no reports yet about problems caused by this, but I generally
think it is better to fix potential problems before they get exploited
in production.

-Andi

P.S.: Could you please commit your Unix socket fixes? I think they should
be send to Linus ASAP to make sure they appear in 2.1.117.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html