Messages in this thread | | | Date | Tue, 18 Aug 1998 12:59:26 -0700 | From | "David S. Miller" <> | Subject | Re: Linux 2.1.x showstopper list |
| |
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?
struct icmp_unreach_bucket { unsigned long base_jiffies; u32 dest_addr; signed short unreaches_sent; }; struct icmp_unreach_bucket dest_unreach_filter[32]; #define UNREACH_HASH(addr) whatever(addr)
send_dest_unreach(u32 addr, ...) { struct icmp_unreach_bucket *bp;
bp = &dest_unreach_filter[UNREACH_HASH(addr)]; if (bp->dest_addr == addr) { int rate;
if (bp->unreaches_sent == -1) goto drop; bp->unreaches_sent++; rate = ((jiffies - bp->base_jiffies) / bp->unreaches_sent); if (rate > DEST_UNREACH_MAX_RATE) { bp->unreached_sent = -1; goto drop; } } else { bp->base_jiffies = jiffies; bp->dest_addr = addr; bp->unreaches_sent = 1; } /* Ok, really send it out... */
drop: ... }
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.
Later, David S. Miller davem@dm.cobaltmicro.com
- 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
| |