Date: Tue, 15 Mar 2011 14:49:31 -0400 From: Steve Polyack <korvus@comcast.net> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-net@freebsd.org, freebsd-stable <freebsd-stable@FreeBSD.org> Subject: Re: MAC address / per-proto ARP caching in 8.1-RELEASE Message-ID: <4D7FB4BB.1080103@comcast.net> In-Reply-To: <20110315182603.GA37095@icarus.home.lan> References: <4D7F69FF.2020608@comcast.net> <20110315182603.GA37095@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D7FB4BB.1080103>