Date: Wed, 20 Mar 2002 08:00:07 -0800 (PST) From: <orion@FreeBSD.org> To: archie@dellroad.org, orion@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/25517: ARP cache timeout behavior can be improved Message-ID: <200203201600.g2KG07s89094@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
Synopsis: ARP cache timeout behavior can be improved State-Changed-From-To: open->closed State-Changed-By: orion State-Changed-When: Wed Mar 20 07:57:53 PST 2002 State-Changed-Why: 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." http://www.freebsd.org/cgi/query-pr.cgi?pr=25517 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203201600.g2KG07s89094>