[40300] in North American Network Operators' Group
Negative ARP caching [was Re: TCP session disconnection caused by
daemon@ATHENA.MIT.EDU (Alex Bligh)
Mon Aug 6 17:07:19 2001
Date: Mon, 06 Aug 2001 22:06:43 +0100
From: Alex Bligh <alex@alex.org.uk>
Reply-To: Alex Bligh <alex@alex.org.uk>
To: Craig Partridge <craig@aland.bbn.com>
Cc: nanog@merit.edu, Alex Bligh <alex@alex.org.uk>
Message-ID: <11856718.997135603@[169.254.198.40]>
In-Reply-To: <10922804.997134669@[169.254.198.40]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Errors-To: owner-nanog-outgoing@merit.edu
>> Probably
>> a bad idea. Rate limiting, as RFC 1122 suggests, would seem to be much
>> better.
>
> Agree that rate-limiting is a good idea (indeed that's INCOMPLETE[n] and
> [t1] in my proposal) but I don't see how it helps here.
Or to put it another way:
So if you are storing sufficient state in the OS to do rate-limiting (i.e.
keeping state on incomplete / nonexistant entries too), then put it to
some use, and (say) halve the rate-limit every time one proves
non-existant (and you drop the queued packet(s)), (i.e. twice as
many seconds between ARP packets), down to some minimum, like one
every 5 mins, and reset the rate limit on reception of any IP
packet from that machine and/or successful ARP.
This is almost the same thing as I suggested, but looks more like
rate limiting, with some intelligence as to the rate.
--
Alex Bligh
Personal Capacity
