From owner-freebsd-net Thu Mar 7 12:28:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id BC56337B41A; Thu, 7 Mar 2002 12:28:11 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g27KSBU01868; Thu, 7 Mar 2002 12:28:11 -0800 (PST) (envelope-from rizzo) Date: Thu, 7 Mar 2002 12:28:11 -0800 From: Luigi Rizzo To: Orion Hodson Cc: freebsd-net@FreeBSD.ORG Subject: Re: Pre-emptive ARP refresh Message-ID: <20020307122811.B1614@iguana.icir.org> References: <200203071936.g27JaJw38650@mule.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203071936.g27JaJw38650@mule.icir.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am not totally sure about the fix you propose. If you send a preemptive refresh request when the entry is about to timeout, how do you let an arp table entry go away, other than hoping that the host goes down ? This might be a problem with a busy host on a large switched lan (there are some large ones around). I'd rather see something like the following (along the lines of what Steve Casner suggested): 1) do lazy deletion of arp cache entries (much like ipfw/dummynet does with dynamic rules and pipes); 2) when an entry has expired but there is state about it, keep using the cached value for some grace period from the last transmission, while you send ARP requests and wait for the replies to come back. 3) possibly refresh ARP entries on incoming input packets. This should not be terribly expensive if we link the inpcb to the arp entry somehow. Not sure if #1 and #3 are already implemented. cheers luigi On Thu, Mar 07, 2002 at 11:36:19AM -0800, Orion Hodson wrote: > > There is a very minor issue with our ARP implementation and it's > refresh behaviour. At present, entries in the ARP cache timeout and > are removed from the cache. The number of packets buffered from a > host with an incomplete entry in the ARP table is limited to 1, so > high packet rate sources therefore experience drops when their ARP > entry times out. > > This was reported in kern/25517 and pointed out on the IETF AVT > mailing yesterday: > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/25517 > http://www.ietf.org/mail-archive/working-groups/avt/current/msg00850.html > > A simple fix would be to send ARP requests about a host before it > times out if that host is exchanging packets with us. An example of > how this might be done (relative to -STABLE) is: > > http://people.freebsd.org/~orion/if_ether.c.1.64.2.17.arp-patch > > For an entry in the cache that is sending data it sends an ARP request > every arpt_down seconds for up to a maximum arp_maxtries before the > entry times out. This is in the spirit of what's described in the > last three paragraphs of RFC826. > > Does this seem reasonable? > > Kind Regards > - Orion > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message