[lkml]   [1998]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux 2.1.x showstopper list
       From: Andi Kleen <>
    Date: 18 Aug 1998 20:39:04 +0200

    In article <>,
    "David S. Miller" <> 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.


    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;
    rate = ((jiffies - bp->base_jiffies) /
    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... */


    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.

    David S. Miller

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.021 / U:5.552 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site