ARP behaviour - TCP-IP

This is a discussion on ARP behaviour - TCP-IP ; Hi, I would like to ask you which of the following ARP behaviours you would consider normal and which not: 1. a host sends out arp replies without a request send out by any other host (unsolicited) 2. a host ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: ARP behaviour

  1. ARP behaviour

    Hi,

    I would like to ask you which of the following ARP behaviours you would
    consider normal and which not:

    1. a host sends out arp replies without a request send out by any other
    host (unsolicited)
    2. a host sends out an arp request, but to a special mac address and
    not to the broadcast address
    3. arp packets where the ethernet sender/destination mac does not match
    the arp sender/destination mac

    I know that some of such packets are jused by arp poisoning tools, but
    which of the three (maybe you know more! please let me know!) are
    really _not_ ok and which are (sometimes) being used by normal hosts,
    routers, switches, ... anything.

    My DSL router for example sends out unsolicited replies all the time
    .... but I would not consider this rfc conform.

    Thanks,
    Chris


  2. Re: ARP behaviour

    On 2006-07-28, chrismc911@hotmail.com wrote:

    > I would like to ask you which of the following ARP behaviours you would
    > consider normal and which not:
    >
    > 1. a host sends out arp replies without a request send out by any other
    > host (unsolicited)


    This is a mode sometimes used called "Promiscuous ARP" - I'm not sure
    if it's RFC'd offhand, but the basic idea is that a host configured
    to participate in a redundant NIC situation (two NICs on the same
    segment that "share" an IP address active only on one NIC at a time)
    where one NIC takes over for the other if heartbeat is lost between
    them, can send out an unsolicited ARP in an attempt to update the
    local router's ARP table.

    > 2. a host sends out an arp request, but to a special mac address and
    > not to the broadcast address


    The only case I knew of for this was some old printer vendors and
    other devices use to use odd MAC addresses for configuration
    information or to be discovered on the network. If you see an "odd"
    MAC address you haven't seen before - make sure it's not multicast
    traffic first. If you see anything except a hex F in the first byte
    of the MAC address, this might be the case.

    > 3. arp packets where the Ethernet sender/destination mac does not match
    > the arp sender/destination mac


    This question is a little confusing to me - can you provide more
    detail?

    /dmfh


    ----
    __| |_ __ / _| |_ ____ __
    dmfh @ / _` | ' \| _| ' \ _ / _\ \ /
    \__,_|_|_|_|_| |_||_| (_) \__/_\_\
    ----

  3. Re: ARP behaviour

    DMFH writes:

    > On 2006-07-28, chrismc911@hotmail.com wrote:
    >
    > > I would like to ask you which of the following ARP behaviours you would
    > > consider normal and which not:
    > >
    > > 1. a host sends out arp replies without a request send out by any other
    > > host (unsolicited)

    >
    > This is a mode sometimes used called "Promiscuous ARP" - I'm not sure


    No ... it's commonly called "gratuitous ARP," not "promiscuous."

    "Promiscuous ARP" is fairly obscure, but refers to a node that
    intentionally sends out replies for nodes that are not explicitly
    configured -- i.e., a node that's doing proxy ARP for an entire
    subnet. The replies in "promiscuous ARP" are in response to specific
    queries, not unsolicited.

    "Promiscuous ARP" is a bit of a degenerate case.

    Gratuitous ARP, though, is common. It's how a node establishes and
    defends its address on the wire. You'll commonly see it when an
    interface is first configured, as the node attempts to clear out any
    stale caches that might be present on other hosts.

    > > 2. a host sends out an arp request, but to a special mac address and
    > > not to the broadcast address

    >
    > The only case I knew of for this was some old printer vendors and
    > other devices use to use odd MAC addresses for configuration
    > information or to be discovered on the network. If you see an "odd"
    > MAC address you haven't seen before - make sure it's not multicast
    > traffic first. If you see anything except a hex F in the first byte
    > of the MAC address, this might be the case.


    What?

    Multicast on Ethernet is designated as having the least significant
    bit in the first octet set to 1. In other words, if the first number
    is _odd_ (rather than _even_), then the target is multicast. There's
    no "might" or "maybe;" multicast is a single bit that's either set or
    not.

    Except for bug-ridden implementations, ARP is never sent as multicast
    -- it's broadcast. If you see it sent as multicast, then return that
    device to the vendor, because it's broken.

    > > 3. arp packets where the Ethernet sender/destination mac does not match
    > > the arp sender/destination mac

    >
    > This question is a little confusing to me - can you provide more
    > detail?


    ARP itself has fields that have the hardware address -- specifically,
    ar$sha and ar$tha. The Ethernet frame itself also has an Ethernet
    destination and source address.

    If I saw a frame where ar$spa was non-zero and ar$sha didn't match the
    Ethernet source address, I'd be very suspicious indeed, as they likely
    represent either bugs or possibly outright forgeries. (Frames where
    ar$spa is zero are probes. I'd be less concerned about those.)

    The one case where that _might_ be valid would be with a node that's
    intentionally doing proxy ARP for some other non-ARP-speaking node on
    the same physical network. I can't say I've ever seen a network set
    up that way (and it doesn't seem sane), but it's at least possible in
    theory.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  4. Re: ARP behaviour

    chrismc911@hotmail.com wrote:

    > I would like to ask you which of the following ARP behaviours you
    > would consider normal and which not:


    > 1. a host sends out arp replies without a request send out by any other
    > host (unsolicited)


    Normal. When an interface is first brought-up, or if an IP is moved
    from one interface (eg MAC) to another. Done to get the ARP tables
    updated.

    > 2. a host sends out an arp request, but to a special mac address and
    > not to the broadcast address


    Normal. IIRC done to refresh an ARP entry for that IP/MAC pair.

    > 3. arp packets where the ethernet sender/destination mac does not
    > match the arp sender/destination mac


    I don't know.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  5. Re: ARP behaviour

    In article <4Xrzg.1332$_K6.414@news.cpqcorp.net>,
    Rick Jones wrote:

    > chrismc911@hotmail.com wrote:
    >
    > > I would like to ask you which of the following ARP behaviours you
    > > would consider normal and which not:

    >
    > > 1. a host sends out arp replies without a request send out by any other
    > > host (unsolicited)

    >
    > Normal. When an interface is first brought-up, or if an IP is moved
    > from one interface (eg MAC) to another. Done to get the ARP tables
    > updated.


    Isn't this normally an ARP query, not an ARP reply? That way, it also
    detects duplicate IP's on the LAN -- if something replies, it has the
    same IP.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  6. Re: ARP behaviour

    Barry Margolin wrote:
    > In article <4Xrzg.1332$_K6.414@news.cpqcorp.net>,
    > Rick Jones wrote:
    >> Normal. When an interface is first brought-up, or if an IP is moved
    >> from one interface (eg MAC) to another. Done to get the ARP tables
    >> updated.


    > Isn't this normally an ARP query, not an ARP reply? That way, it also
    > detects duplicate IP's on the LAN -- if something replies, it has the
    > same IP.


    Well, now that you put it that way, I'm not so sure any longer which
    it is.

    rick jones


    --
    Process shall set you free from the need for rational thought.
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  7. Re: ARP behaviour

    Rick Jones wrote:
    >> Normal. When an interface is first brought-up, or if an IP is moved
    >> from one interface (eg MAC) to another. Done to get the ARP tables
    >> updated.


    Barry Margolin writes:
    > Isn't this normally an ARP query, not an ARP reply? That way, it also
    > detects duplicate IP's on the LAN -- if something replies, it has the
    > same IP.


    This is called "the gratuitous ARP request" and you can find it cited
    in Stevens, though I can't cite chapter & verse this instant. The
    interface coming to life sends the gratuitous ARP, and any host on the
    segment which hears its own name being called will recognize that an
    address duplication is in need of being addressed.

    I'm not familiar with anything sending gratuitous ARP _replies_.

  8. Re: ARP behaviour

    In article ,
    Karl Kleinpaste wrote:

    >This is called "the gratuitous ARP request" and you can find it cited
    >in Stevens, though I can't cite chapter & verse this instant. The


    >I'm not familiar with anything sending gratuitous ARP _replies_.


    I think some hosts send replies instead of requests for gratuitous ARP.

    Separately, if a host sees a gratuitous or any ARP packet that indicates
    that some other host has stolen its IP address, then some rate limited
    but reasonably high volume ARP screaming can keep applications (especially
    shells) going while the collision is sorted out.


    Vernon Schryver vjs@rhyolite.com

  9. Re: ARP behaviour


    Barry Margolin wrote:

    > Isn't this normally an ARP query, not an ARP reply? That way, it also
    > detects duplicate IP's on the LAN -- if something replies, it has the
    > same IP.


    I thought duplicate IP detection was done by using the request variety
    and those frames are called "unsolicited ARPs" as opposed to
    "gratuitous ARPs". Gratuitous ARPs are replies that are sent to
    have neighbors update their ARP cache.

    Anoop


  10. Re: ARP behaviour

    On 2006-07-31 08:32:07 -0400, James Carlson said:

    > DMFH writes:
    >
    >> On 2006-07-28, chrismc911@hotmail.com wrote:
    >>
    >>> I would like to ask you which of the following ARP behaviours you would
    >>> consider normal and which not:
    >>>
    >>> 1. a host sends out arp replies without a request send out by any other
    >>> host (unsolicited)

    >>
    >> This is a mode sometimes used called "Promiscuous ARP" - I'm not sure

    >
    > No ... it's commonly called "gratuitous ARP," not "promiscuous."



    I appreciate being corrected when I'm wrong when I post at 6AM off of
    no sleep, thank you. However, I think we'd all do a lot better if folks
    stopped coming off to other folks as if they threw the Bolts Of Zeus
    out when expressing an opinion or correcting poor or just wrong
    information. If poor information irritates you folks, please point the
    cannon at the information.

    /dmfh



  11. Re: ARP behaviour

    On Mon, 31 Jul 2006 22:52:30 +0000, Rick Jones wrote:

    > Barry Margolin wrote:
    >> In article <4Xrzg.1332$_K6.414@news.cpqcorp.net>,
    >> Rick Jones wrote:
    >>> Normal. When an interface is first brought-up, or if an IP is moved
    >>> from one interface (eg MAC) to another. Done to get the ARP tables
    >>> updated.

    >
    >> Isn't this normally an ARP query, not an ARP reply? That way, it also
    >> detects duplicate IP's on the LAN -- if something replies, it has the
    >> same IP.

    >
    > Well, now that you put it that way, I'm not so sure any longer which
    > it is.


    Gratitous arp, as I know it and see it regularly in sniffers is an arp
    reply without an arp query.

    In fact I recently debugged a problem where some hosts didn't send them
    (Brother printers) so replacing a printer with a new one on the same IP
    made you wait for arp timeouts. Other printers did send gratitous arp
    (reply).

    OTOH, IIRC AIX does send out an arp request before assigning an IP to an
    interface, and refuses to do so when it sees a reply.

    M4
    --
    Redundancy is a great way to introduce more single points of failure.


  12. Re: ARP behaviour

    wrote in message
    news:m34pwx2nmr.fsf@invalid.address...
    > vjs@calcite.rhyolite.com (Vernon Schryver) writes:
    >
    > > In article ,
    > > Karl Kleinpaste wrote:
    > >
    > > >This is called "the gratuitous ARP request" and you can find it cited
    > > >in Stevens, though I can't cite chapter & verse this instant. The

    > >
    > > >I'm not familiar with anything sending gratuitous ARP _replies_.

    > >
    > > I think some hosts send replies instead of requests for gratuitous
    > > ARP.

    >
    > Isn't this done in failover situations, when a new interface is taking
    > over and wants other hosts to update their arp caches with its
    > ethernet address?


    not sure about a host with multiple interfaces - there doesnt seem to be
    much standardisation inthe way they work (and the Microsoft server cluster
    flavour can use a multicast MAC source address as an option).

    VRRP uses an ARP when it swaps a logical default gateway between router
    interfaces.

    see RFC 3768 section 6.4.1 and 6.4.2

    FWIW it is called gratuitous ARP request in the RFC text....
    >
    > Joe

    --
    Regards

    stephen_hope@xyzworld.com - replace xyz with ntl



  13. Re: ARP behaviour

    Martijn Lievaart writes:
    > Gratitous arp, as I know it and see it regularly in sniffers is an
    > arp reply without an arp query.


    Stevens, _TCP IP Illustrated Vol 1_, 4.7, p.62:

    Another feature of ARP that we can watch is called /gratuitous ARP./
    It occurs when a host sends an ARP request looking for its own IP
    address. This is usually done when the interface is configured at
    boot time.
    ...
    Gratuitous ARP provides two features:
    1. It lets the host determine if another host is already configured
    with the same IP address...
    2. If the host sending the gratuitous ARP has just changed its
    hardware address ... this packet causes any other host on the cable
    that has an entry in its cache for the old hardware address to
    update its ARP cache entry accordingly...

  14. Re: ARP behaviour

    While we are on the subject of ARP

    I recently saw in a trace a series of ARP requests directed to a specific
    MAC address, not the broadcast address, The MAC address was of the owner of
    the requested IP address which responded with an ARP reply. All I know about
    the source of the ARP requests is that it had a Cisco MAC address and
    appears to be a router (multiple IP addresses from different subnets all
    with this MAC address)

    I've never see this before but a little resrarch leads me to understand that
    some OSes will send this type of ARP before sending a broadcast, if it has
    an "expired" entry in its ARP cache and it needs the entry updated. What
    confuses me is that I don't see any subsequent traffic from the source.

    The interval between ARP requests is approximately 36 seconds or
    approximately some multiple of 36 seconds.

    Basically I am wondering is anyone knows what the trigger for these packets
    is. I'm just curious this has nothing to do with why I was doing a trace.

    Here is an example of the ARP request

    No. Time Source Destination
    Protocol Info
    14462 2006-08-01 17:09:54.652620 10.11.12.2 10.11.12.9 ARP
    Who has 10.11.12.9? Tell 10.11.12.2

    Frame 14462 (64 bytes on wire, 64 bytes captured)
    Arrival Time: Aug 1, 2006 17:09:54.652620000
    Time delta from previous packet: 278.026866000 seconds
    Time since reference or first frame: 278.026866000 seconds
    Frame Number: 14462
    Packet Length: 64 bytes
    Capture Length: 64 bytes
    Ethernet II, Src: 00:0e:d6:22:b8:3c, Dst: 00:00:a8:84:81:73
    Destination: 00:00:a8:84:81:73 (10.11.12.9)
    Source: 00:0e:d6:22:b8:3c (10.11.12.2)
    Type: ARP (0x0806)
    Trailer: 00000000000000000000000000000000...
    Frame check sequence: 0x1230f4a4 (correct)
    Address Resolution Protocol (request)
    Hardware type: Ethernet (0x0001)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (0x0001)
    Sender MAC address: 00:0e:d6:22:b8:3c (10.11.12.2)
    Sender IP address: 10.11.12.2 (10.11.12.2)
    Target MAC address: 00:00:a8:84:81:73 (10.11.12.9)
    Target IP address: 10.11.12.9 (10.11.12.9)




    wrote in message
    news:1154126769.723958.59070@b28g2000cwb.googlegro ups.com...
    > Hi,
    >
    > I would like to ask you which of the following ARP behaviours you would
    > consider normal and which not:
    >
    > 1. a host sends out arp replies without a request send out by any other
    > host (unsolicited)
    > 2. a host sends out an arp request, but to a special mac address and
    > not to the broadcast address
    > 3. arp packets where the ethernet sender/destination mac does not match
    > the arp sender/destination mac
    >
    > I know that some of such packets are jused by arp poisoning tools, but
    > which of the three (maybe you know more! please let me know!) are
    > really _not_ ok and which are (sometimes) being used by normal hosts,
    > routers, switches, ... anything.
    >
    > My DSL router for example sends out unsolicited replies all the time
    > ... but I would not consider this rfc conform.
    >
    > Thanks,
    > Chris
    >




  15. Re: ARP behaviour

    In article <98bBg.2293$W01.294@dukeread08>,
    "Noah Davids" wrote:

    > While we are on the subject of ARP
    >
    > I recently saw in a trace a series of ARP requests directed to a specific
    > MAC address, not the broadcast address, The MAC address was of the owner of
    > the requested IP address which responded with an ARP reply. All I know about
    > the source of the ARP requests is that it had a Cisco MAC address and
    > appears to be a router (multiple IP addresses from different subnets all
    > with this MAC address)
    >
    > I've never see this before but a little resrarch leads me to understand that
    > some OSes will send this type of ARP before sending a broadcast, if it has
    > an "expired" entry in its ARP cache and it needs the entry updated. What
    > confuses me is that I don't see any subsequent traffic from the source.


    I think when you do "clear arp" on a Cisco router, it goes through its
    current ARP cache and tries to refresh each entry; any that don't
    succeed are deleted. I've never captured this, and assumed it sent
    normal broadcast ARP queries, but maybe it actually directs each to the
    MAC address in its current cache entry, and that's what you were seeing.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  16. Re: ARP behaviour


    If you really want to find out why this is occuring , then you need to
    speak to the person who look after the Cisco router/switch.

    If you are getting an ARP request every 36 seconds for the same IP
    address, then this seems a little unusal.

    There is a new Cisco iOS feature called ARP-Auto Logoff that might
    result in this behaviour


+ Reply to Thread