[40307] in North American Network Operators' Group
RE: TCP session disconnection caused by Code Red?
daemon@ATHENA.MIT.EDU (David Schwartz)
Mon Aug 6 19:50:53 2001
From: "David Schwartz" <davids@webmaster.com>
To: "Eric A. Hall" <ehall@ehsco.com>, <nanog@merit.edu>
Date: Mon, 6 Aug 2001 16:50:16 -0700
Message-ID: <NOEJJDACGOHCKNCOGFOMGEDCDAAA.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <005901c11ec5$39a68710$0a0aa8c0@ferret>
Errors-To: owner-nanog-outgoing@merit.edu
> The immediate problem with this is that it requires a *MUCH* larger ARP
> cache. Rather than needing enough memory for a couple of thousand active
> entries (the current norm for middle-of-the road routers), you need enough
> room for every possible address on every attached segment.
> Eric A. Hall http://www.ehsco.com/
Weight that against the advantages, however. If you have a large address
space for the segment with few attached hosts (the case where this is a
problem), you're better off with a lot of negative entries cached then with
a lot of active ARP attempts.
One thing I see a lot of on segments with large address spaces is that the
quantity of ARP traffic can get high. Each ARP request causes an interrupt
on each attach host on the segment. I'd rather the router have a larger ARP
cache than the network have more broadcast traffic.
I'm curious what kind of algorithms my routers currently use. If it's one
packet per second with five retries -- consider a network with a /22 that's
only half full. You could see as much as 512 broadcast packets a second just
from one router. Sounds like an interesting technique for getting
amplification by a factor of 5 -- 5 broadcast packets for every unicast
packet you send.
Smarter rate limiting sounds like a win.
DS
