17 messages in org.freebsd.freebsd-archARP request retransmitting| From | Sent On | Attachments |
|---|---|---|
| Gleb Smirnoff | Nov 7, 2005 6:04 am | |
| Gleb Smirnoff | Nov 7, 2005 6:28 am | |
| Robert Watson | Nov 7, 2005 6:40 am | |
| Gleb Smirnoff | Nov 7, 2005 6:52 am | |
| Bill Vermillion | Nov 7, 2005 7:19 am | |
| Chuck Swiger | Nov 7, 2005 8:16 am | |
| Garance A Drosihn | Nov 7, 2005 9:49 am | |
| Peter Jeremy | Nov 7, 2005 9:55 am | |
| Gleb Smirnoff | Nov 7, 2005 11:41 am | |
| John-Mark Gurney | Nov 7, 2005 2:44 pm | |
| Charles Swiger | Nov 7, 2005 3:18 pm | |
| John-Mark Gurney | Nov 7, 2005 3:45 pm | |
| Charles Swiger | Nov 7, 2005 4:49 pm | |
| Peter Jeremy | Nov 8, 2005 1:11 am | |
| Bruce M Simpson | Nov 11, 2005 6:09 am | |
| Gleb Smirnoff | Nov 11, 2005 6:15 am | |
| Peter Wemm | Dec 27, 2005 12:22 pm |
| Subject: | ARP request retransmitting | |
|---|---|---|
| From: | Peter Wemm (pet...@wemm.org) | |
| Date: | Dec 27, 2005 12:22:37 pm | |
| List: | org.freebsd.freebsd-arch | |
On Friday 11 November 2005 06:15 am, Gleb Smirnoff wrote:
On Fri, Nov 11, 2005 at 02:09:26PM +0000, Bruce M Simpson wrote: B> On Mon, Nov 07, 2005 at 05:04:51PM +0300, Gleb Smirnoff wrote: B> > I suggest to keep sending ARP requests while there is a demand for B> > this (we are trying to transmit packets to this particular IP), B> > ratelimiting these requests to one per second. This will help in a B> > quite common case, when some host on net is rebooting, and we are B> > waiting for him to come up, and notice this only after 1 - 20 seconds B> > since the time it is reachable. B> > Any objections? B> B> In response to the other replies to this thread citing broadcast B> pollution on Ethernet-based networks: B> Please add this functionality under a sysctl where it is turned off by default. B> B> It is desirable in situations where ARP entries cached further upstream are B> stale, but it may cause flooding in an environment where the layer 2 backbone B> hasn't been split or has not been segregated well. B> B> Other people cited examples where vendor switch implementations were B> retransmitting across VLANs -- this week I've been offering moral support B> to a friend who is dealing with similar VLAN brokenness at his $DAYJOB B> (there was an extension to 802.1d to support multiple spanning tree instances B> across VLANs which I think not everyone supports correctly).
I'd like to see a proven evidence that this functionality leads to a measurable increase in broadcast traffic. Many modern operating systems behave in such way and no-one complains. The increase of broadcast traffic is very theoretical, it happens only when there are downed hosts.
Personally, I think that the place that this can most benefit is small home/office/business networks of a small number of hosts.
People with large networks already have to deal with this sort of problem anyway. FreeBSD systems retransmit once per second for 20 seconds, then take a short break, then resume the once-per-second retransmits again. The "short break" is useless IMHO and makes such a small difference in modern networks.
The saddest thing I see these days is a constant stream of ARP traffic coming in my cable modem. About 20-30 per second.
09:36:27.040649 arp who-has 67.174.245.39 tell 67.174.244.1 09:36:27.104437 arp who-has 67.188.248.237 tell 67.188.240.1 09:36:27.128126 arp who-has 67.188.240.180 tell 67.188.240.1 09:36:27.162068 arp who-has 67.174.244.30 tell 67.174.244.1 09:36:27.162313 arp who-has 67.174.244.37 tell 67.174.244.1 09:36:27.166890 arp who-has 67.174.244.48 tell 67.174.244.1 09:36:27.167550 arp who-has 67.174.244.44 tell 67.174.244.1 09:36:27.168296 arp who-has 67.174.244.45 tell 67.174.244.1 09:36:27.168735 arp who-has 67.174.244.50 tell 67.174.244.1 09:36:27.168984 arp who-has 67.174.244.91 tell 67.174.244.1 09:36:27.170819 arp who-has 67.174.244.97 tell 67.174.244.1 09:36:27.171062 arp who-has 67.174.244.101 tell 67.174.244.1 09:36:27.171226 arp who-has 67.174.244.107 tell 67.174.244.1 09:36:27.171662 arp who-has 67.174.244.110 tell 67.174.244.1 09:36:27.171909 arp who-has 67.174.244.116 tell 67.174.244.1 09:36:27.174206 arp who-has 67.174.244.92 tell 67.174.244.1 09:36:27.174447 arp who-has 67.188.248.57 tell 67.188.240.1 09:36:27.174603 arp who-has 67.174.244.112 tell 67.174.244.1 09:36:27.176663 arp who-has 67.174.244.135 tell 67.174.244.1 09:36:27.177101 arp who-has 67.174.244.158 tell 67.174.244.1 09:36:27.177352 arp who-has 67.174.244.144 tell 67.174.244.1 09:36:27.178172 arp who-has 67.174.244.141 tell 67.174.244.1 09:36:27.178413 arp who-has 67.174.244.146 tell 67.174.244.1 09:36:27.180278 arp who-has 67.174.244.148 tell 67.174.244.1 09:36:27.180948 arp who-has 67.174.244.151 tell 67.174.244.1 09:36:27.181184 arp who-has 67.174.244.152 tell 67.174.244.1 09:36:27.716214 arp who-has 67.188.247.253 tell 67.188.240.1 09:36:27.765102 arp who-has 69.181.212.233 tell 69.181.212.1 09:36:27.799458 arp who-has 67.188.113.101 tell 67.188.112.1 09:36:27.848736 arp who-has 67.188.240.194 tell 67.188.240.1 09:36:27.854934 arp who-has 67.188.240.142 tell 67.188.240.1 09:36:27.897613 arp who-has 67.188.240.195 tell 67.188.240.1 09:36:27.997441 arp who-has 67.188.240.95 tell 67.188.240.1
I'm sure most of this is comcast's self-inflicted pain, but FreeBSD doesn't even make a dent in ARP traffic like this.
Most of the ARP traffic I see at work on our corp network comes from routers trying to reach down hosts or re-arping up machines. But then again, we use vlans to limit the size of broadcast domains. I suspect most well managed "large" networks will have something similar. The difference between sending 20 arps per 40 seconds or 40 arps per 40 seconds for a down host isn't going to make a dent.
What does seem to hurt is when some body does an nmap and you get thousands of arps from the router...
-Peter