Re: Linux 2.1.x showstopper list

David S. Miller (davem@dm.cobaltmicro.com)
Tue, 18 Aug 1998 12:59:26 -0700


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