Date: Mon, 27 Sep 2004 04:50:04 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: Pekka Savola <pekkas@netcore.fi> Cc: snap-users@kame.net Subject: Re: (KAME-snap 8794) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE Message-ID: <y7vbrfs6c9f.wl@ocean.jinmei.org> In-Reply-To: <Pine.LNX.4.44.0409251428430.6730-100000@netcore.fi> References: <y7vzn3fijpb.wl@ocean.jinmei.org> <Pine.LNX.4.44.0409251428430.6730-100000@netcore.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Sat, 25 Sep 2004 14:34:39 +0300 (EEST), >>>>> Pekka Savola <pekkas@netcore.fi> said: >> >> 1. do you see massive number of entries with "netstat -rna"? >> >> > Yes. >> >> > # netstat -nra | wc -l >> > 32468 >> > # >> >> Okay, to be sure, most of them are IPv6 routing entries, right? > Yes, 99.99%. 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' - if this node can be the originator (i.e., not a forwarder as a router) to those destinations, it can create host routes for the destinations. - if you use some network-level hooks (e.g., packet filters) that rely on routing table lookups, the node may have the host routes. Can one of those be the case in your environment? 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?y7vbrfs6c9f.wl>