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.
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."