[40305] in North American Network Operators' Group
Re: TCP session disconnection caused by Code Red?
daemon@ATHENA.MIT.EDU (Daniel Senie)
Mon Aug 6 18:39:17 2001
Message-Id: <5.1.0.14.2.20010806183537.00aa2550@mail.amaranth.net>
Date: Mon, 06 Aug 2001 18:37:42 -0400
To: "Eric A. Hall" <ehall@ehsco.com>,
"Alex Bligh" <alex@alex.org.uk>, <nanog@merit.edu>
From: Daniel Senie <dts@senie.com>
In-Reply-To: <005901c11ec5$39a68710$0a0aa8c0@ferret>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Errors-To: owner-nanog-outgoing@merit.edu
At 06:14 PM 8/6/01, Eric A. Hall wrote:
>Alex Bligh wrote:
>
> > 1. RFC826 appears to mandate only positive ARP caching. I can't
> > see a reason why negative ARP caching shouldn't work this
> > way:
> >
> > Keep only one ARP request in flight at a time. Retry ARPs
> > a maximum of [5] times, separated by at least [1] second.
> > After that, cache non-existance of a h/w address for that
> > IP address for normal positive caching time.
>
>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.
>
>[unsubstantiated conjecture] This may be what's killing the cable networks.
>If they are making room in the NAS ARP caches for the addresses that are
>being probed, then they are making room by flushing the "real" ARP entries,
>resulting in a constant flush/load cycle. [/uc, but exemplary of the problem
>with negative ARP caching.]
Adding to this conjecture, I'm seeing VERY high ARP rates (arp broadcast
packets) arriving via the cable modem in my office. Also seeing a high rate
of Code Red type attacks attempted at the machines attached. Firewall is
just catching and logging them.
-----------------------------------------------------------------
Daniel Senie dts@senie.com
Amaranth Networks Inc. http://www.amaranth.com
