From owner-freebsd-bugs Wed Mar 20 8: 0:14 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2453737B400; Wed, 20 Mar 2002 08:00:07 -0800 (PST) Received: (from orion@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2KG07s89094; Wed, 20 Mar 2002 08:00:07 -0800 (PST) (envelope-from orion) Date: Wed, 20 Mar 2002 08:00:07 -0800 (PST) From: Message-Id: <200203201600.g2KG07s89094@freefall.freebsd.org> To: archie@dellroad.org, orion@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/25517: ARP cache timeout behavior can be improved Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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