Messages in this thread | | | Date | Wed, 19 Aug 1998 03:14:40 +0200 | From | Andi Kleen <> | Subject | Dest Unreach Rate limits, was: Re: Linux 2.1.x showstopper list |
| |
On Tue, Aug 18, 1998 at 09:59:26PM +0200, David S. Miller wrote: > From: Andi Kleen <ak@muc.de> > Date: 18 Aug 1998 20:39:04 +0200 > > In article <199808181513.IAA28255@dm.cobaltmicro.com>, > "David S. Miller" <davem@dm.cobaltmicro.com> writes: > > IPV4 options > > ICMP dest unreach has load limiting issues > > > Please specify this more clearly, I believe it is fixed in vger (and > > thus will be in my next sync to Linus) but I can't tell just with this > > explanation alone. > > It is not fixed on vger. The problem is that 2.1 uses the destination cache > now to load limit ICMP messages, but dest unreach is send when no suitable > destination entry could be computed. Just adding a new dst_entry for this > would open linux routers to DOS attacks. > > Ok. > > A possible fix would be a separate load limit cache for dest unreachs, > similar to what 2.0 did for all ICMPs, but I decided that it was not worth > the effort and too big a change in the code freeze. > > A general solution for this is hard because a potential cache will be always > too small on a high performace router. > > How about something like the following, could it work? [ hash based solution deleted ]
It could work, but I'm not sure if it is worth the memory needed/the code complexity.
> If the above is insufficient because you can then be bombed with > addresses which all match the same hash value and thus kick each other > out, what you could do is factor in some other part of the packets > such as the TTL field... actually the more I think about this problem > the more difficult it seems to solve fully.
ICMP is unreliable and a few false positives wouldn't hurt too much I think. I'm not sure what the best solution is, but not load limiting them is probably not too bad.
It would be interesting what algorithms Cisco/Bay/Ascend use in this case. Anyone have a 7xxx up for some experiments? @)
There were some discussions about similar problems during the original introduction of the virtual path cache between Pedro and Alexey on netdev, maybe I should reread that stuff.
-Andi
P.S.: Alexey predicted that replacing the 2.0 ICMP small cache could lead to some problems - he was right.
- 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
| |