Date: Mon, 7 Nov 2005 19:49:30 -0500 From: Charles Swiger <cswiger@mac.com> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: arch@freebsd.org, Garance A Drosihn <drosih@rpi.edu> Subject: Re: ARP request retransmitting Message-ID: <036D3BD4-D856-4D50-A7D3-2300EFEA604F@mac.com> In-Reply-To: <20051107234548.GF775@funkthat.com> References: <20051107140451.GU91530@cell.sick.ru> <436F7DDB.40703@mac.com> <p06230904bf9542d696b6@[128.113.24.47]> <20051107224338.GE775@funkthat.com> <CE57F103-4C41-492E-9A5C-789B67A7D158@mac.com> <20051107234548.GF775@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 7, 2005, at 6:45 PM, John-Mark Gurney wrote: >> Really? You're saying that "tcpdump -nt arp" never shows any >> requests except those made by the local host? >> >> Which vendor and which switch model? > > Just a random search for smart arp large, turned up user's manual > for the WaveSwitch 9000, from Plaintree Systems.. > > The docs say: > Address Resolution Protocol (ARP) is the means by which a host or > router > maps an IP address to a physical address. WaveSwitch 9000 software > contains the SmartARP feature that allows for reduced impact of ARP > broadcasting. > > Normally, ARP broadcasts are flooded to all ports on a switch. Switch > ports that are not connected to the target host must, therefore, > receive > and partially process the broadcast frames. This can potentially > affect > the performance of all hosts on the bridged network. [ ... ] > A coworker also says that the Foundary switches can do it, and did > it like five years ago... I haven't confirmed this myself... OK, I appreciate the response and the pointer to a specific model. This being said, I'd prefer a first-hand account from someone who has actually run tcpdump for a few days on a production network and confirmed that this feature really works as advertised. (There can be a big difference between what the documentation claims a switch does, and what the switch actually does. In particular, switch vendors have also claimed that VLAN tagging was reliable and secure and that traffic from one VLAN could never leak to a port on another VLAN...) ----- I think your other comment about extending the lifespan of entries in the ARP cache is a more useful idea, at least for extending the lifespan of valid entries. Negative response to an ARP request should not be cached for very long. Does FreeBSD update the ARP cache when ARPOP_REQUESTs are seen? At the very least, one could refresh the timer if you have an entry for the host making the request... -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?036D3BD4-D856-4D50-A7D3-2300EFEA604F>