From owner-freebsd-stable@FreeBSD.ORG Tue Mar 15 18:50:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 726E5106567D for ; Tue, 15 Mar 2011 18:50:12 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 97A828FC15 for ; Tue, 15 Mar 2011 18:50:10 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id KWoq1g0051ei1Bg51WqADL; Tue, 15 Mar 2011 18:50:10 +0000 Received: from [192.168.2.164] ([206.210.89.202]) by omta24.westchester.pa.mail.comcast.net with comcast id KWpY1g00u4Mx3R23kWpkhJ; Tue, 15 Mar 2011 18:49:58 +0000 Message-ID: <4D7FB4BB.1080103@comcast.net> Date: Tue, 15 Mar 2011 14:49:31 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110125 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D7F69FF.2020608@comcast.net> <20110315182603.GA37095@icarus.home.lan> In-Reply-To: <20110315182603.GA37095@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable Subject: Re: MAC address / per-proto ARP caching in 8.1-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:50:12 -0000 On 03/15/11 14:26, Jeremy Chadwick wrote: > On Tue, Mar 15, 2011 at 09:30:39AM -0400, Steve Polyack wrote: >> Is anyone aware of some sort of facility in either FreeBSD >> 8.1-RELEASE or the em(4) driver which would cause it to cache MAC >> addresses / ARP entries for hosts on a per-protocol basis? >> >> [snipping remaining details; readers can read it here instead:] >> [http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/061908.html] > The only thing I can think of would be flowtable, but I'm not sure > if it's enabled by default on 8.1-RELEASE-p2. You can try the following > sysctl to disable it (I would recommend setting this in sysctl.conf and > rebooting; I don't know what happens in the case you set it on a live > system that's already experiencing the MAC issue you describe). > > net.inet.flowtable.enable=0 > > Details: > > http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf > It looks like it is enabled by default on 8.1-RELEASE. Here's the net.inet.flowtable tree from the box in question: [spolyack@web00 ~]$ sysctl net.inet.flowtable net.inet.flowtable.stats: table name: ipv4 collisions: 1 allocated: 0 misses: 20013 max_depth: 0 free_checks: 377953 frees: 19993 hits: 69519580 lookups: 69539593 net.inet.flowtable.nmbflows: 50176 net.inet.flowtable.tcp_expire: 86400 net.inet.flowtable.fin_wait_expire: 600 net.inet.flowtable.udp_expire: 300 net.inet.flowtable.syn_expire: 300 net.inet.flowtable.enable: 1 net.inet.flowtable.debug: 0 I'm planning on setting net.inet.flowtable.debug=1 next time we see this behavior, but from looking at the code, it looks like we might have to rebuild with -DFLOWTABLE_DEBUG to get really useful information. It's too bad that there is not yet a method to dump the contents of the flowtable. Thanks for the suggestion.