Re: ARP request retransmitting

From: Gleb Smirnoff (glebius_at_FreeBSD.org)
Date: 11/11/05

  • Next message: Antony Mawer: "Re: [PATCH FOR REVIEW] kqueue'ify inetd(8) and several other cleanups" 
    Date: Fri, 11 Nov 2005 17:15:19 +0300
To: Bruce M Simpson <bms@spc.org>

    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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Antony Mawer: "Re: [PATCH FOR REVIEW] kqueue'ify inetd(8) and several other cleanups"