lkml.org 
[lkml]   [1998]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Dest Unreach Rate limits, was: Re: Linux 2.1.x showstopper list
Date
Hello!

> But - we had actual reports of floods together with tcpdumps as proof
> (if you remember it was in the netdev or linux-net thread some months
> ago that lead to the invention of RTCF_BADROUTE).

As I remember, that problem was related to bug, that I wrongly marked
all invalid routes as destined to us(!), so that icmp_send tried
to sent with wrong source. Certainly, in this case ip_route_output
always failed. And I do not remember, that guy who found it, complained
about load limiting. I'll try to find that thread though.

> Maybe the token bucket filters used are not aggressive enough and should
> be more limiting.

It is very aggressive. Yes, it is vulnerable to random source
attack, but:

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

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

> a "temporary dst_entry" that is not inserted into the routing cache and is
> freed as soon as the ICMP skb leaves the system.

It does not sleep, but it does worse: it queues packets. F.e. in arp,
in device etc.

I do not think, that it will help. In any case we will have to count
memory somewhere. If route is out of common pool, more real problem
of infinite allocation of routes to one destination appears.

BTW I never heard of problems of this kind.
If reports will appear really, we have huge margins to fix it.
Starting from more clever GC strategies, finishing with
route space reduction. But it would be stupid to try to
solve problem, which never existed really 8)

Alexey

-
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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.113 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site