From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 04:57:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA20416A4CE for ; Mon, 27 Sep 2004 04:57:19 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B49D843D2D for ; Mon, 27 Sep 2004 04:57:18 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8R4v3T28107; Mon, 27 Sep 2004 07:57:03 +0300 Date: Mon, 27 Sep 2004 07:57:02 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org cc: snap-users@kame.net Subject: Re: (KAME-snap 8794) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 04:57:19 -0000 On Mon, 27 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > 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. # netstat -s -p icmp6 icmp6: 2633683 calls to icmp_error 4 errors not generated because old message was icmp error or so 0 errors not generated because rate limitation Output histogram: unreach: 2465 packet too big: 416 time exceed: 2630798 echo reply: 824 multicast listener report: 6053 neighbor solicitation: 7587 neighbor advertisement: 4587 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: unreach: 6 echo: 824 multicast listener query: 2014 neighbor solicitation: 4587 neighbor advertisement: 7575 Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 4 address unreachable 2461 port unreachable 416 packet too big 2630802 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 3308 redirect 0 unknown 824 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes I'd estimate the router sends out about 1 million such ICMP time exceeded messages per day. > - 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. Yes, above. > - if you use some network-level hooks (e.g., packet filters) that rely > on routing table lookups, the node may have the host routes. I don't have these. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings