Date: Tue, 28 Sep 2004 05:27:57 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: snap-users@kame.net Cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8803) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE Message-ID: <y7v8yavsbhu.wl@ocean.jinmei.org> In-Reply-To: <Pine.LNX.4.44.0409270747480.27601-100000@netcore.fi> References: <y7vbrfs6c9f.wl@ocean.jinmei.org> <Pine.LNX.4.44.0409270747480.27601-100000@netcore.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7v8yavsbhu.wl>