Re: (KAME-snap 8803) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE

From: B ($B?_at_L@C#:H(B)
Date: 09/27/04

  • Next message: George V. Neville-Neil: "Patch for fragment problem in key.c" 
    Date: Tue, 28 Sep 2004 05:27:57 +0900
To: snap-users@kame.net

    >>>>> On Mon, 27 Sep 2004 07:57:02 +0300 (EEST),
    >>>>> Pekka Savola <pekkas@netcore.fi> said:

    >> I can think of several possibilities that may cause the entries:
    >>
    >> - when this node sends ICMPv6 error messages to those addresses, it
    >> can create route entries. I suspect this is the main reason since
    >> in this case the destination of route entries would contain other
    >> types of addresses than 6to4. You can (implicitly) check if this
    >> happened by looking at the result of 'netstat -s -p icmp6'

    > This is likely the case. Due to Microsoft's implementation of '6to4
    > relay probing', each host tries to send an IPv6 packet of Hop Count=1,
    > which results in an ICMP unreachable back from the relays. See below.

    Okay. Now I think I figure out the problem. Those host routes were
    created not deliberately, so the kernel will eventually need a fix to
    this.

    But if you are in a hurry and/or cannot replace the kernel soon, I
    think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with
    this you even do not have to reboot the kernel - though rebooting may
    also help if you can).

                                            JINMEI, Tatuya
                                            Communication Platform Lab.
                                            Corporate R&D Center, Toshiba Corp.
                                            jinmei@isl.rdc.toshiba.co.jp
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: George V. Neville-Neil: "Patch for fragment problem in key.c"