How can you get an incomplete ARP?

Discussion in 'Cisco' started by crzzy1, Apr 21, 2010.

  1. crzzy1

    crzzy1 Guest

    Perhaps someone can put this into perspective for me.
    This is an age old question that has arisen many times throughout the
    years and my web searches have failed to answer this.
    The host is visible in arp and shows incomplete, the host cannot be
    pinged.
    Sometimes the prob is a cable, sometimes a host route setting,
    sometimes an intermediary device.
    (Let me know if there are other known things that cause this).

    ca-santa-barbara-router#sh arp | i 70.169.191
    Internet 71.169.191.209 0 Incomplete ARPA
    Internet 71.169.191.218 - 0018.731f.407d ARPA Ethernet1

    My question is, how is it, that we get the IP address from the
    directly connected host into the ARP cache, but not the MAC address?
    We arp out for that IP, and the connected host is smart enough to
    reply that it has that IP, but it isn't smart enough to send it MAC
    address?

    Thanks,
    crzzy1
     
    crzzy1, Apr 21, 2010
    #1
    1. Advertising

  2. crzzy1

    Rob Guest

    crzzy1 <> wrote:
    >
    > Perhaps someone can put this into perspective for me.
    > This is an age old question that has arisen many times throughout the
    > years and my web searches have failed to answer this.
    > The host is visible in arp and shows incomplete, the host cannot be
    > pinged.
    > Sometimes the prob is a cable, sometimes a host route setting,
    > sometimes an intermediary device.
    > (Let me know if there are other known things that cause this).
    >
    > ca-santa-barbara-router#sh arp | i 70.169.191
    > Internet 71.169.191.209 0 Incomplete ARPA
    > Internet 71.169.191.218 - 0018.731f.407d ARPA Ethernet1
    >
    > My question is, how is it, that we get the IP address from the
    > directly connected host into the ARP cache, but not the MAC address?
    > We arp out for that IP, and the connected host is smart enough to
    > reply that it has that IP, but it isn't smart enough to send it MAC


    No, this just means the cisco device has sent an ARP for the IP
    in the list (71.169.191.209) and it has not received a reply.

    So the host is down or not connected.
     
    Rob, Apr 21, 2010
    #2
    1. Advertising

  3. crzzy1

    crzzy1 Guest

    On Apr 21, 1:42 pm, Rob <> wrote:
    > crzzy1<> wrote:
    >
    > > Perhaps someone can put this into perspective for me.
    > > This is an age old question that has arisen many times throughout the
    > > years and my web searches have failed to answer this.
    > > The host is visible in arp and shows incomplete, the host cannot be
    > > pinged.
    > > Sometimes the prob is a cable, sometimes a host route setting,
    > > sometimes an intermediary device.
    > > (Let me know if there are other known things that cause this).

    >
    > > ca-santa-barbara-router#sh arp | i 70.169.191
    > > Internet  71.169.191.209          0   Incomplete      ARPA
    > > Internet  71.169.191.218          -   0018.731f.407d  ARPA   Ethernet1

    >
    > > My question is, how is it, that we get the IP address from the
    > > directly connected host into the ARP cache, but not the MAC address?
    > > We arp out for that IP, and the connected host is smart enough to
    > > reply that it has that IP, but it isn't smart enough to send it MAC

    >
    > No, this just means the cisco device has sent an ARP for the IP
    > in the list (71.169.191.209) and it has not received a reply.
    >
    > So the host is down or not connected.


    That is not correct. I forgot to mention that this is a /24,
    and only the host 71.169.191.209 is in fact connected.
    I can ping the broadcast address, and only this IP comes into the ARP
    table.
    In this case there was a problem with the routing on the host.
    So in other words, my router sees the host, the host in some way
    replies that it has this IP, but is unable to say what its MAC is.
    I have seen this numerous times, but never have figured out what
    really takes place to let my router know that that host is there, but
    not what is the MAC?

    crzzy1
     
    crzzy1, Apr 23, 2010
    #3
  4. crzzy1

    Chris Mason Guest

    - the nearest I can get to an identification!

    Interesting. You have managed to work out how to have some contact
    with an interface on a LAN - albeit a not very productive one given
    that it relies on a response to a LAN broadcast - *without* getting a
    complete entry into the ARP cache.

    I believe when an IP node detects that the destination IP address
    corresponds to the broadcast address for an address range assigned to
    an attached LAN (as determined by the subnet mask), it has no need of
    ARP support since it can use the broadcast MAC address on the LAN. I
    hope someone who is a practical specialist in these matters rather
    than only a theoretical amateur like myself can confirm or deny this
    assertion - and, if deny, perhaps provide an alternative explanation.

    I think you need to read and understand the ARP RFC which is quite
    short, 10 pages, and has a very helpful schematic of the ARP logic.

    It may be best to access the RFC, 826, via the Wikipedia article:

    http://en.wikipedia.org/wiki/Address_Resolution_Protocol

    I see that the article references a 3-page PDF of the logic over which
    you can pour.

    >...> My question is, how is it, that we get the IP address from the directly connected host into the ARP cache, but not the MAC address?


    A quick scan of the RFC indicates that it is not required that the
    node sending an ARP request places the requested IP address in the ARP
    cache at this time *without*, obviously, the MAC address. However I
    can see that some implementations might do this. Actually I could be
    wrong - and, if so, I hope for correction.

    >...> We arp out for that IP, and the connected host is smart enough to reply that it has that IP, but it isn't smart enough to send it MAC address?


    According to the RFC, this is an impossibility. How are you certain
    that the ARP request was sent? If an ARP reply is received from the
    interface of another node on the LAN - even when the intended
    recipient is not the receiving node - a *complete* ARP entry should be
    built for the sending node.

    >...> ... this just means the cisco device has sent an ARP for the IP in the list (71.169.191.209) and it has not


    received a reply.

    Rob's response indicates that the presumed Cisco implementation logic
    bothers to create incomplete ARP entries. I guess this may have the
    benefit - assuming it truly is optional - of revealing possible
    problems.

    > I forgot to mention that this is a /24, ...


    It's not clear what you may mean here. If it is a reference to ARP
    processing, you will see that, in effect, all ARP processing is "/32",
    that is, it concerns only the IP address of individual interfaces
    rather than address ranges. As I suggested above, if the destination
    IP address happens to correspond to the broadcast IP address of the
    address range assigned to the LAN to which the interface about to send
    a packet is attached, a broadcast MAC address can be used.

    Having been told that the address range is determined by 24 contiguous
    bits, I can suppose that the broadcast address you used in the
    successful PING command was 71.169.191.255.

    > ... and only the host 71.169.191.209 is in fact connected.


    If there is only one interface other than the sending interface, IP
    address 71.169.191.218 I guess, connected to the LAN, you should
    receive responses only from that node - but based on having used the
    broadcast MAC address at the Ethernet level.

    > I can ping the broadcast address, and only this IP comes into the ARP table.


    I think I see at what you have been getting all this time! Is this one
    of those famous Cisco extensions to the common interpretation of RFCs?
    Could it be that the Cisco implementation of ARP involves the ARP
    logic being informed of the IP addresses of interfaces known to fit
    the address range assigned to a LAN to which a local interface is
    attached in case broadcast requests were used to discover them? It
    would appear that this happens at a level in the logic where the MAC
    address associated with the IP address has been lost.

    I wonder if this mightn't be some way of operating dynamic discovery
    of nodes within the network as extensively as possible. I guess one
    can speculate endlessly ...

    Chris Mason


    On Apr 23, 3:15 pm, crzzy1 <> wrote:
    > On Apr 21, 1:42 pm, Rob <> wrote:
    >
    >
    >
    > > crzzy1<> wrote:

    >
    > > > Perhaps someone can put this into perspective for me.
    > > > This is an age old question that has arisen many times throughout the
    > > > years and my web searches have failed to answer this.
    > > > The host is visible in arp and shows incomplete, the host cannot be
    > > > pinged.
    > > > Sometimes the prob is a cable, sometimes a host route setting,
    > > > sometimes an intermediary device.
    > > > (Let me know if there are other known things that cause this).

    >
    > > > ca-santa-barbara-router#sh arp | i 70.169.191
    > > > Internet  71.169.191.209          0   Incomplete      ARPA
    > > > Internet  71.169.191.218          -   0018.731f.407d  ARPA   Ethernet1

    >
    > > > My question is, how is it, that we get the IP address from the
    > > > directly connected host into the ARP cache, but not the MAC address?
    > > > We arp out for that IP, and the connected host is smart enough to
    > > > reply that it has that IP, but it isn't smart enough to send it MAC

    >
    > > No, this just means the cisco device has sent an ARP for the IP
    > > in the list (71.169.191.209) and it has not received a reply.

    >
    > > So the host is down or not connected.

    >
    > That is not correct. I forgot to mention that this is a /24,
    > and only the host 71.169.191.209 is in fact connected.
    > I can ping the broadcast address, and only this IP comes into the ARP
    > table.
    > In this case there was a problem with the routing on the host.
    > So in other words, my router sees the host, the host in some way
    > replies that it has this IP, but is unable to say what its MAC is.
    > I have seen this numerous times, but never have figured out what
    > really takes place to let my router know that that host is there, but
    > not what is the MAC?
    >
    > crzzy1
     
    Chris Mason, Apr 24, 2010
    #4
  5. crzzy1

    JF Mezei Guest

    Note:

    A host typically creates a temporarey entry in the ARP cache, sends the
    ARP request (broadcast) and when/if a reply is received, it then updates
    the record in the arp cache with the received ethernet address.

    Generally, this is quick enough that you don't see it happening.
     
    JF Mezei, Apr 26, 2010
    #5
  6. crzzy1

    Rob Guest

    JF Mezei <> wrote:
    > Note:
    >
    > A host typically creates a temporarey entry in the ARP cache, sends the
    > ARP request (broadcast) and when/if a reply is received, it then updates
    > the record in the arp cache with the received ethernet address.


    That is what I said, but he does not believe it.
     
    Rob, Apr 26, 2010
    #6
  7. crzzy1

    bod43 Guest

    On 26 Apr, 09:04, Rob <> wrote:
    > JF Mezei <> wrote:
    > > Note:

    >
    > > A host typically creates a temporarey entry in the ARP cache, sends the
    > > ARP request (broadcast) and when/if a reply is received, it then updates
    > > the record in the arp cache with the received ethernet address.

    >
    > That is what I said, but he does not believe it.


    Here is an idea.

    "I can ping the broadcast address, and only this IP
    comes into the ARP table. "

    ca-santa-barbara-router#sh arp | i 70.169.191
    Internet 71.169.191.209 0 Incomplete ARPA
    Internet 71.169.191.218 - 0018.731f.407d ARPA
    Ethernet1

    The broadcast ping from 218 just goes out with no ARPing.
    In order to reply (with a unicast) the "target" host must
    ARP for the ping sender 71.169.191.218.

    The router receives the ARP request from 209:-
    It replies to it and also does gratuitous ARP or ARP
    snooping processing creating the Incomplete entry. For
    some reason the entry cannot be completed. Perhaps
    after the snooping or gratuiting:) the router does a real arp
    to complete the process and the 209 host does not reply.

    I am not sure of the details of gratuitous arp or snooping
    so I am not sure as to the plausibility of this hypothesis.

    Have you checked that you do not have a subnet mask
    mismatch? Well, looking at the addresses I don't
    suppose that is possible without a discontiguous mask
    which is no longer permitted. Worth a check anyway.

    Otherwise, maybe the ARP entry is nothing to do with
    your ping and the 209 host is sending some other traffic.
    Windows hosts for example are very chatty.

    To investigate further you could try:-
    - Packet capture with some external device
    say with wireshark - hub or SPAN port needed.
    - debug arp
    - If you have very recent IOS, packet capture on router.
    - Packet capture on target (209).
    - Check you have no ACLs that could block the ARP.

    You might post the router config.

    By the way, most people mangle IP addresses
    in usenet messages so as to preclude identification.
    e.g change the first octet. Maybe you did that already:?)
     
    bod43, Apr 26, 2010
    #7
  8. crzzy1

    crzzy1 Guest

    On Apr 26, 4:04 am, Rob <> wrote:
    > JF Mezei <> wrote:
    > > Note:

    >
    > > A host typically creates a temporarey entry in the ARP cache, sends the
    > > ARP request (broadcast) and when/if a reply is received, it then updates
    > > the record in the arp cache with the received ethernet address.

    >
    > That is what I said, but he does not believe it.


    Thanks for the reply.
    So are you saying that I am getting an arp reply that doesn't have a
    MAC address in it?
    I ask this because I am only getting an IP and not an "ethernet
    address" that you assert that I am getting in your answer.
    My question is how does it get a reply with only an IP and no MAC?
    Or if there is no reply, then how does it know that only that single
    host out of 254 possibility's is out there?

    Thanks,
    CJ
     
    crzzy1, Apr 26, 2010
    #8
  9. crzzy1

    crzzy1 Guest

    On Apr 26, 4:44 am, bod43 <> wrote:
    > On 26 Apr, 09:04, Rob <> wrote:
    >
    > > JF Mezei <> wrote:
    > > > Note:

    >
    > > > A host typically creates a temporarey entry in the ARP cache, sends the
    > > > ARP request (broadcast) and when/if a reply is received, it then updates
    > > > the record in the arp cache with the received ethernet address.

    >
    > > That is what I said, but he does not believe it.

    >
    > Here is an idea.
    >
    > "I can ping the broadcast address, and only this IP
    > comes into the ARP table. "
    >
    > ca-santa-barbara-router#sh arp | i 70.169.191
    > Internet  71.169.191.209          0   Incomplete      ARPA
    > Internet  71.169.191.218          -   0018.731f.407d  ARPA
    > Ethernet1
    >
    > The broadcast ping from 218 just goes out with no ARPing.
    > In order to reply (with a unicast) the "target" host must
    > ARP for the ping sender 71.169.191.218.
    >
    > The router receives the ARP request from 209:-
    > It replies to it and also does gratuitous ARP or ARP
    > snooping processing creating the Incomplete entry. For
    > some reason the entry cannot be completed. Perhaps
    > after the snooping or gratuiting:) the router does a real arp
    > to complete the process and the 209 host does not reply.
    >
    > I am not sure of the details of gratuitous arp or snooping
    > so I am not sure as to the plausibility of this hypothesis.
    >
    > Have you checked that you do not have a subnet mask
    > mismatch? Well, looking at the addresses I don't
    > suppose that is possible without a discontiguous mask
    > which is no longer permitted. Worth a check anyway.
    >
    > Otherwise, maybe the ARP entry is nothing to do with
    > your ping and the 209 host is sending some other traffic.
    > Windows hosts for example are very chatty.
    >
    > To investigate further you could try:-
    >  - Packet capture with some external device
    > say with wireshark - hub or SPAN port needed.
    >  - debug arp
    >  - If you have very recent IOS, packet capture on router.
    >  - Packet capture on target (209).
    >  - Check you have no ACLs that could block the ARP.
    >
    > You might post the router config.
    >
    > By the way, most people mangle IP addresses
    > in usenet messages so as to preclude identification.
    > e.g change the first octet. Maybe you did that already:?)


    Thank you for your well worded response.
    I did mangle my IP like you mentioned,, yes it would be a breach of
    protocol not to.
    I think you are correct in your assertion of the gratuitous arp.
    This issue was fixed by having the customer concentrate on his routing
    on his host side. (I have no visibility into his side, so I couldn't
    use wireshark. but I would like to try the packet capture on the
    router side next time one of these crop up.
    Again though, a really excellent answer.

    Thanks,
    Crzzy1
     
    crzzy1, Apr 26, 2010
    #9
  10. crzzy1

    Rob Guest

    crzzy1 <> wrote:
    > On Apr 26, 4:04 am, Rob <> wrote:
    >> JF Mezei <> wrote:
    >> > Note:

    >>
    >> > A host typically creates a temporarey entry in the ARP cache, sends the
    >> > ARP request (broadcast) and when/if a reply is received, it then updates
    >> > the record in the arp cache with the received ethernet address.

    >>
    >> That is what I said, but he does not believe it.

    >
    > Thanks for the reply.
    > So are you saying that I am getting an arp reply that doesn't have a
    > MAC address in it?


    No, I think you are getting no ARP reply at all.

    > I ask this because I am only getting an IP and not an "ethernet
    > address" that you assert that I am getting in your answer.


    The "incomplete" entry with only IP in it is created when the router
    wants to send something to that IP. The system does not need to exist
    for that.

    > My question is how does it get a reply with only an IP and no MAC?


    I think it doesn't.

    > Or if there is no reply, then how does it know that only that single
    > host out of 254 possibility's is out there?


    Maybe it has heard traffic from that address.
     
    Rob, Apr 26, 2010
    #10
  11. crzzy1

    JF Mezei Guest

    crzzy1 wrote:

    > So are you saying that I am getting an arp reply that doesn't have a
    > MAC address in it?


    Typically the reverse. It means you have sent an Arp request, but not
    gotten any response.

    "will IP address X please stand up and reply to me with their ethernet
    address ?

    BUT, nobody responded.

    If this is aon a cisco box, you can:

    clear arp <ip address>

    This will remove the incomplete arp entry.

    you can show arp to confirm.

    You can then try to ping that host and you will ether get an incomplete
    arp entry or a completed one.

    (instead of "ping" you can telnet or any other IP level command that
    would try to send an IP packet to that host.


    If 10.0.0.2 sends an ARP to ask about 10.0.0.13, then 10.0.0.13 will
    implicetely know 10.0.0.2's ethernet address and add that record to its
    arp table (allowing it to reply to 10.0.0.2's requests from now on).

    10.0.0.13 will then send a response to 10.0.0.2, and 10.0.0.2 will then
    get the ethernet address corresponding to 10.0.0.13 and complete the
    incomplete arp entry.

    Note that you could theoretically have a misbehaving machine on your LAN
    which uses a blank or otherwise invalid ethernet address so that when it
    responds to arp requests, the responses are considered illegal and not
    added to the arp tables (leaving those incomplete entries).
     
    JF Mezei, Apr 26, 2010
    #11
  12. crzzy1

    JF Mezei Guest

    crzzy1 wrote:

    > This issue was fixed by having the customer concentrate on his routing
    > on his host side.


    Question:

    If host1 thinks host2 is part of the same subnet, it will send an arp
    asking for host2's ethernet address.

    That broadcast arp will specify host2's ip address.

    So at the low level, when host2 gets the ethernet broadcast, it will see
    "this is something that concerns me" and pass it upwards for processing.

    If the ethernet broadcast contained an arp request for an ip address not
    used by host2, it would not be passed upwards for processing.

    So, by the time the "upwards" layer gets the arp request, does it
    blindly respond to the ethernet address of the sender of the broadcast ?

    Or does the arp response behave as an IP packet and gets routed to a
    router if the requestor is not in the same subnet ?

    (at which point the arp request would never get to the requestor,
    leaving a incomplete arp record at the requestor's arp database)
     
    JF Mezei, Apr 26, 2010
    #12
  13. crzzy1

    martyh00

    Joined:
    Oct 19, 2013
    Messages:
    1
    A few people have tried to explain this. Basically you are not "getting the IP address from the directly connected host" By pinging that IP address. You are telling the router that the address exists. It therefore puts that IP address in its ARP cache with an incolmplete value until it receives an ARP reply. If this does not happen (As in your example). It remains as incomplete. If you ping any other address in your IP range you will see all those addresses appear as incomplete as well. So the router does not see the device on its physical LAN. The fact that it tries to ARP for the IP address means that the router is on the same subnet as the IP address. If this was not the case then it would not ARP for it.

    Only things I know that could cause this are VLANs, incorrect address or mask on client or physical network faults, VLAN or MAC ACLs.

    I don't know of any reasons why a client would simply not reply to an ARP.
     
    martyh00, Oct 19, 2013
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paolo

    Delete incomplete download

    Paolo, Oct 11, 2005, in forum: Firefox
    Replies:
    4
    Views:
    1,298
    Leonidas Jones
    Oct 12, 2005
  2. Robert Stanley

    Linksys Router Incomplete DHCP Clients Table

    Robert Stanley, Dec 25, 2005, in forum: Wireless Networking
    Replies:
    1
    Views:
    11,203
    Sooner Al [MVP]
    Dec 25, 2005
  3. Jarrad Cox

    bugzilla: incomplete search results

    Jarrad Cox, Mar 29, 2005, in forum: Microsoft Certification
    Replies:
    0
    Views:
    419
    Jarrad Cox
    Mar 29, 2005
  4. David Arnstein

    Incomplete boot of 806 router

    David Arnstein, Dec 19, 2003, in forum: Cisco
    Replies:
    4
    Views:
    605
    David Arnstein
    Dec 20, 2003
  5. Darren Green

    Arp or Proxy Arp

    Darren Green, Feb 20, 2009, in forum: Cisco
    Replies:
    0
    Views:
    564
    Darren Green
    Feb 20, 2009
Loading...

Share This Page