ARP request retransmitting

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

ARP request retransmitting

Gleb Smirnoff
  Colleagues,

  I have a proposition on changing the behavior of ARP retransmitting.
Currently we after sending several ARP requests, sending ARP requests
for given IP is suppressed for some interval (by default 20 seconds).
Probably this feature was designed in early 90th, when sending one
additional broadcast packet was an expensive thing.

  I suggest to keep sending ARP requests while there is a demand for
this (we are trying to transmit packets to this particular IP),
ratelimiting these requests to one per second. This will help in a
quite common case, when some host on net is rebooting, and we are
waiting for him to come up, and notice this only after 1 - 20 seconds
since the time it is reachable.

  Any objections?

--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Gleb Smirnoff
On Mon, Nov 07, 2005 at 07:44:17PM +0530, Joseph Koshy wrote:
J> Wouldn't the host that is coming up send out a gratuituous
J> ARP packet that could be used?

It would if it is rebooted, but if a switch is rebooting, or in
case of some other link level problems, it won't.

--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Robert N. M. Watson-2
In reply to this post by Gleb Smirnoff

On Mon, 7 Nov 2005, Gleb Smirnoff wrote:

>  I have a proposition on changing the behavior of ARP retransmitting.
> Currently we after sending several ARP requests, sending ARP requests
> for given IP is suppressed for some interval (by default 20 seconds).
> Probably this feature was designed in early 90th, when sending one
> additional broadcast packet was an expensive thing.
>
>  I suggest to keep sending ARP requests while there is a demand for this
> (we are trying to transmit packets to this particular IP), ratelimiting
> these requests to one per second. This will help in a quite common case,
> when some host on net is rebooting, and we are waiting for him to come
> up, and notice this only after 1 - 20 seconds since the time it is
> reachable.

While networks have gotten a lot faster in the last few years, I've
noticed that many of the ones I deal with have also gotten a lot larger in
terms of number of hosts.  This has been possible both because of the
absolute increase in bandwidth, and also because of the widespread use of
switches to suppress unnecessary unicast traffic to segments.  I worry
that significantly increasing the amount of broadcast traffic will be a
problem for sites with large bridged network configurations.  On the other
hand, they already have to deal with things like windows network
neighborhoods, various service discovery protocols, and so on.

Do you have any information on what other operating systems may have done
in terms of tweaking ARP for improved responsiveness?  I imagine we can't
be the first to discuss such changes, and if there is already a widely
deployed system with ARP adaptations of this sort, it would be interesting
to know if they've seen any problems or have recommendations.

Robert N M Watson
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Gleb Smirnoff
On Mon, Nov 07, 2005 at 02:40:43PM +0000, Robert Watson wrote:
R> > I have a proposition on changing the behavior of ARP retransmitting.
R> >Currently we after sending several ARP requests, sending ARP requests
R> >for given IP is suppressed for some interval (by default 20 seconds).
R> >Probably this feature was designed in early 90th, when sending one
R> >additional broadcast packet was an expensive thing.
R> >
R> > I suggest to keep sending ARP requests while there is a demand for this
R> >(we are trying to transmit packets to this particular IP), ratelimiting
R> >these requests to one per second. This will help in a quite common case,
R> >when some host on net is rebooting, and we are waiting for him to come
R> >up, and notice this only after 1 - 20 seconds since the time it is
R> >reachable.
R>
R> While networks have gotten a lot faster in the last few years, I've
R> noticed that many of the ones I deal with have also gotten a lot larger in
R> terms of number of hosts.  This has been possible both because of the
R> absolute increase in bandwidth, and also because of the widespread use of
R> switches to suppress unnecessary unicast traffic to segments.  I worry
R> that significantly increasing the amount of broadcast traffic will be a
R> problem for sites with large bridged network configurations.  On the other
R> hand, they already have to deal with things like windows network
R> neighborhoods, various service discovery protocols, and so on.
R>
R> Do you have any information on what other operating systems may have done
R> in terms of tweaking ARP for improved responsiveness?  I imagine we can't
R> be the first to discuss such changes, and if there is already a widely
R> deployed system with ARP adaptations of this sort, it would be interesting
R> to know if they've seen any problems or have recommendations.

Frankly speaking, I have written my email after looking at Linux behavior.
It sends one ARP request per second while there is demand for this ARP entry.
After demand has disapparead, it sends a few retransmits driven by timer. If
again there is a demand, it starts to retransmit again. Under "demand" here
I mean a traffic to this particular IP, either locally generated or routed.

--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Bill Vermillion
In reply to this post by Gleb Smirnoff
On Mon, Nov 07, 2005 at 17:04 , the primordial soup was bombarded
 with cosmic radiation and a new life form of genus Gleb Smirnoff
emerged to test its air breathing capabilities and with great
effort gasped:

>   Colleagues,

>   I have a proposition on changing the behavior of ARP retransmitting.
> Currently we after sending several ARP requests, sending ARP requests
> for given IP is suppressed for some interval (by default 20 seconds).
> Probably this feature was designed in early 90th, when sending one
> additional broadcast packet was an expensive thing.

The man page says the host is considered down "for a short period
(normally 20 seconds), allowing an error to be returned to
transmission attempts in this interval".

>   I suggest to keep sending ARP requests while there is a demand for
> this (we are trying to transmit packets to this particular IP),
> ratelimiting these requests to one per second. This will help in a
> quite common case, when some host on net is rebooting, and we are
> waiting for him to come up, and notice this only after 1 - 20 seconds
> since the time it is reachable.

>   Any objections?

Is the 20 second limit that much of a problem.  And the 20 minute
timeout for caching is certainly far more generous that my old
big Cisco that had a 4 hour cache.  A user complained that he put
up new machines and things weren't working.  I told him he should
have called me before he put the IPs back the way they were as
cleanring the arp-cache took care of that.

How big is your network?

Bill
--
Bill Vermillion - bv @ wjv . com
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Chuck Swiger-2
In reply to this post by Gleb Smirnoff
Hi--

Gleb Smirnoff wrote:
>   I have a proposition on changing the behavior of ARP retransmitting.
> Currently we after sending several ARP requests, sending ARP requests
> for given IP is suppressed for some interval (by default 20 seconds).
> Probably this feature was designed in early 90th, when sending one
> additional broadcast packet was an expensive thing.

Well, we've got ten or a hundred times as much bandwidth, so sending more data
is relatively cheap, but the per-packet overhead hasn't improved to the same
extent.  ARP requests still get sent to and are processed by all machines on
the network, even if a switch is being used.

>   I suggest to keep sending ARP requests while there is a demand for
> this (we are trying to transmit packets to this particular IP),
> ratelimiting these requests to one per second. This will help in a
> quite common case, when some host on net is rebooting, and we are
> waiting for him to come up, and notice this only after 1 - 20 seconds
> since the time it is reachable.
>
>   Any objections?

No, no objection.  However, this type of situation could be handled by either
an incremental or exponential timeout.  Instead of waiting:

1 1 1 1 1

...seconds between packets as you proposed, consider waiting either of:

1 2 3 4 5
1 2 4 8 16

...seconds, and cap the maximum wait between ARP requests to 16 or so.  Backing
off politely and gradually when the host is not getting any answers is more
network-friendly.

--
-Chuck
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Garance A Drosehn-2
At 11:16 AM -0500 11/7/05, Chuck Swiger wrote:

>Hi--
>
>Gleb Smirnoff wrote:
>>   I suggest to keep sending ARP requests while there is a demand for
>>this (we are trying to transmit packets to this particular IP),
>>ratelimiting these requests to one per second.
>
>No, no objection.  However, this type of situation could be handled
>by either an incremental or exponential timeout.  Instead of waiting:
>
>1 1 1 1 1
>
>...seconds between packets as you proposed, consider waiting either of:
>
>1 2 3 4 5
>1 2 4 8 16
>
>...seconds, and cap the maximum wait between ARP requests to 16 or
>so.  Backing off politely and gradually when the host is not getting
>any answers is more network-friendly.

I think Chuck's suggestion is a very good idea.  In a separate message
in this thread, Robert noted that:


    I worry that significantly increasing the amount of broadcast
    traffic will be a problem for sites with large bridged network
    configurations.  On the other hand, they already have to deal
    with things like windows network neighborhoods, various service
    discovery protocols, and so on.

While that "other hand" is true, here at RPI we deal with some of
those other-hand issues by simply turning them off.  We turn off
multi-cast by default on some of our networks, for instance.  But
there's no way we can turn off ARP, so I think more care needs to
be taken to make sure ARP remains network-friendly.

--
Garance Alistair Drosehn            =   [hidden email]
Senior Systems Programmer           or  [hidden email]
Rensselaer Polytechnic Institute    or  [hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Peter Jeremy
In reply to this post by Robert N. M. Watson-2
On Mon, 2005-Nov-07 14:40:43 +0000, Robert Watson wrote:
>Do you have any information on what other operating systems may have done
>in terms of tweaking ARP for improved responsiveness?

Solaris 8 and 9 appear to re-transmit ARP requests every second or so
even when they know the response :-(.  This does make for a noisy network.

--
Peter Jeremy
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Gleb Smirnoff
In reply to this post by Gleb Smirnoff
On Mon, Nov 07, 2005 at 05:04:51PM +0300, Gleb Smirnoff wrote:
T>   I suggest to keep sending ARP requests while there is a demand for
T> this (we are trying to transmit packets to this particular IP),
T> ratelimiting these requests to one per second. This will help in a
T> quite common case, when some host on net is rebooting, and we are
T> waiting for him to come up, and notice this only after 1 - 20 seconds
T> since the time it is reachable.

Here is code explaining what I am speaking about.

--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

arp.request.diff (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

John-Mark Gurney
In reply to this post by Garance A Drosehn-2
Garance A Drosihn wrote this message on Mon, Nov 07, 2005 at 12:49 -0500:

> I think Chuck's suggestion is a very good idea.  In a separate message
> in this thread, Robert noted that:
>
>
>    I worry that significantly increasing the amount of broadcast
>    traffic will be a problem for sites with large bridged network
>    configurations.  On the other hand, they already have to deal
>    with things like windows network neighborhoods, various service
>    discovery protocols, and so on.
>
> While that "other hand" is true, here at RPI we deal with some of
> those other-hand issues by simply turning them off.  We turn off
> multi-cast by default on some of our networks, for instance.  But
> there's no way we can turn off ARP, so I think more care needs to
> be taken to make sure ARP remains network-friendly.

And most places that have VERY large number of hosts in a broadcast
domain (a partially populated class b), have smart switches that cache
arp requests, and prevent the arp traffic from killing the network...
So, I'd vote for the change...

Though we might want to increase the length we keep arp entries
around...

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Chuck Swiger-2
On Nov 7, 2005, at 5:43 PM, John-Mark Gurney wrote:
>> While that "other hand" is true, here at RPI we deal with some of
>> those other-hand issues by simply turning them off.  We turn off
>> multi-cast by default on some of our networks, for instance.  But
>> there's no way we can turn off ARP, so I think more care needs to
>> be taken to make sure ARP remains network-friendly.
>
> And most places that have VERY large number of hosts in a broadcast
> domain (a partially populated class b), have smart switches that cache
> arp requests, and prevent the arp traffic from killing the network...

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?

Smart switches will generally keep track of 1000 or 4000 or so MAC  
addresses and the ports those MACs are associated with, but I am not  
aware of anything in them which blocks ARP traffic or anything else  
which uses the all-ones broadcast MAC address.  I can see ARP  
requests going out from any/all of the other machines on the network  
I'm using right now (using several 3com SuperStack 3300's), and I've  
seen the same thing on networks using the HP Procurve or Cisco 29xx  
switches.

--
-Chuck

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

John-Mark Gurney
Charles Swiger wrote this message on Mon, Nov 07, 2005 at 18:17 -0500:

> On Nov 7, 2005, at 5:43 PM, John-Mark Gurney wrote:
> >>While that "other hand" is true, here at RPI we deal with some of
> >>those other-hand issues by simply turning them off.  We turn off
> >>multi-cast by default on some of our networks, for instance.  But
> >>there's no way we can turn off ARP, so I think more care needs to
> >>be taken to make sure ARP remains network-friendly.
> >
> >And most places that have VERY large number of hosts in a broadcast
> >domain (a partially populated class b), have smart switches that cache
> >arp requests, and prevent the arp traffic from killing the network...
>
> 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.

With the SmartARP feature, ARP broadcasts are confined to only the
applicable switch ports (see Figure 67).

And the diagram shows the arp request being restricted to only the
port with the router and the host on it...

A coworker also says that the Foundary switches can do it, and did
it like five years ago... I haven't confirmed this myself...

> Smart switches will generally keep track of 1000 or 4000 or so MAC  
> addresses and the ports those MACs are associated with, but I am not  
> aware of anything in them which blocks ARP traffic or anything else  
> which uses the all-ones broadcast MAC address.  I can see ARP  
> requests going out from any/all of the other machines on the network  
> I'm using right now (using several 3com SuperStack 3300's), and I've  
> seen the same thing on networks using the HP Procurve or Cisco 29xx  
> switches.

I'd imagine you have to turn it on... since it'd have odd behavior if
you weren't expecting it...

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Chuck Swiger-2
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

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Peter Jeremy
On Mon, 2005-Nov-07 19:49:30 -0500, Charles Swiger wrote:
>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...)

ISTR that some years ago, I did a check and found that ~0.5% of
packets in our corporate network were being leaked into the incorrect
VLAN.  [Though my memory may be going]  I haven't looked recently.

I've also got a switch that believes that VLANs are only related
to IP - it will happily copy DECnet packets to all switch ports
irrespective of VLAN associations.  (And this switch came from
the company that DEC sold their switch business to).

--
Peter Jeremy
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Bruce M Simpson
In reply to this post by Gleb Smirnoff
On Mon, Nov 07, 2005 at 05:04:51PM +0300, Gleb Smirnoff wrote:
>   I suggest to keep sending ARP requests while there is a demand for
> this (we are trying to transmit packets to this particular IP),
> ratelimiting these requests to one per second. This will help in a
> quite common case, when some host on net is rebooting, and we are
> waiting for him to come up, and notice this only after 1 - 20 seconds
> since the time it is reachable.
>   Any objections?

In response to the other replies to this thread citing broadcast
pollution on Ethernet-based networks:
Please add this functionality under a sysctl where it is turned off by default.

It is desirable in situations where ARP entries cached further upstream are
stale, but it may cause flooding in an environment where the layer 2 backbone
hasn't been split or has not been segregated well.

Other people cited examples where vendor switch implementations were
retransmitting across VLANs -- this week I've been offering moral support
to a friend who is dealing with similar VLAN brokenness at his $DAYJOB
(there was an extension to 802.1d to support multiple spanning tree instances
across VLANs which I think not everyone supports correctly).

Regards,
BMS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Gleb Smirnoff
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.

--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ARP request retransmitting

Peter Wemm-2
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

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"