Re: ARP request retransmitting

From: Garance A Drosihn (drosih_at_rpi.edu)
Date: 11/07/05

  • Next message: Peter Jeremy: "Re: ARP request retransmitting" 
    Date: Mon, 7 Nov 2005 12:49:17 -0500
To: Chuck Swiger <cswiger@mac.com>, Gleb Smirnoff <glebius@freebsd.org>

    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            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu
_______________________________________________
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: Peter Jeremy: "Re: ARP request retransmitting"

    Relevant Pages

    • Re: Network scanning: Continued (newbie)
      ... ARP requests are handled a layer under IP. ... > egress packets impossible on layer 1. ... > should be pretty silent if put that firewall ruleset on it. ... > The recent conversation titled network scanning inspired me to ask the ...
      (Security-Basics)
    • cvs commit: src/sys/netinet if_ether.c
      ... The following change appears to have crashed my network today. ... hangs at boot waiting for a DHCP address, ... Rework ARP retransmission algorythm so that ARP requests are ...
      (freebsd-net)
    • Re: Noob question
      ... >> ARP requests for unknown addresses. ... They are identified as VINES SARP or ARP requests, ... to get a clue on the cause... ... The department here actually still uses a VINES network, ...
      (comp.security.firewalls)
    • Re: Windows: Dont try to save me, PLEASE
      ... ARP requests are broadcasts ... If the "adapter" is in a subnet by itself (reguarless of the mask) and there is ... Network portion of the address. ... Provide a means to determine the MAC address. ...
      (microsoft.public.windows.server.networking)
    • Re: ARP request retransmitting
      ... > Currently we after sending several ARP requests, ... > this (we are trying to transmit packets to this particular IP), ... Is the 20 second limit that much of a problem. ... Bill Vermillion - bv @ wjv. ...
      (freebsd-arch)