Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: Dest Unreach Rate limits, was: Re: Linux 2.1.x showstopper list | Date | Wed, 19 Aug 1998 23:09:12 +0400 (MSK DST) |
| |
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
| |