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