Bug 25517

Summary: ARP cache timeout behavior can be improved
Product: Base System Reporter: Archie Cobbs <archie>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.2-RELEASE   
Hardware: Any   
OS: Any   

Description Archie Cobbs 2001-03-04 02:40:01 UTC 
	When an ARP entry expires after 15 minutes, the ARP entry
	is simply deleted from the ARP cache. Then the next packet(s)
	destined for the other host are delayed while a new ARP
	query and response takes place.

	This delay is unnecessary and disruptive for certain
	protocols that are sensitive to jitter. Moreover, as network
	speeds increase while ARP query/response cycles continue
	to take roughly the same amount of time, this effect will
	become more and more pronounced.

	This problem should be easy to fix... 

	> From: Stephen Casner <casner@packetdesign.com>
	> 
	> The suggested enhancement is to _not_ flush an arp cache
	> entry when its timer expires.  Instead, go ahead and send
	> the arp request, but continue using the cache entry to send
	> packets.  If there is no response to the arp request after
	> the number of retries specified in the protocol, then flush
	> the cache entry.
Comment 1 orion freebsd_committer freebsd_triage 2002-03-20 15:57:53 UTC 
State Changed
From-To: open->closed

Fix commited to netinet/if_ether.c. 

From the review request associated with fix: 

"Outbound packets pass through arpresolve (netinet/if_ether.c).  This 
function makes the decision about whether a packet should be forwarded 
or buffered awaiting an arp response.  It does this on the basis on 
whether there is a valid ARP cache entry for the receiving machine on 
the local network.  Since it fetches the ARP cache entry and the ARP 
cache entry has field stating when it will expire, we can trigger an 
ARP request packet if we are within a finite interval of the expiry 
time.  The response for this pre-expiry ARP request will update the 
ARP cache entry and push back the expiration time. 

The additional ARP requests are data-driven, so pre-expiration 
requests are only sent for hosts that we are sending data to.  Entries 
in the ARP cache that the host is not currently sending to are timed 
out in the usual manner. 

The patch referenced below uses a counter to send ARP requests 
triggered by data packets.  The counter ensures that we send at most 1 
ARP packet per arpt_down (default = 20) seconds.  Thus, if an ARP 
response is lost or corrupted we have several well spaced attempts at 
updating the ARP cache entry before it expires.  The number of 
pre-expiry attempts is set to the number of regular ARP request 
attempts (arp_maxtries, default = 5). 

The counter variable used is the same counter ARP uses for sending 
initial ARP requests.  It's state is already reset when ARP responses 
are received so there is no problem in re-using the variable for 
entries that have not yet expired. 

A solution very similar to this is discussed in the last three 
paragraphs of the original ARP RFC (RFC826) and by Casner in 
kern/25517."