How can you get an incomplete ARP?
in [Cisco]
|
Prev: Vista Smart Security virus (fake program)
Next: WTB: CISCO SWITCHES WS-C3750, WS-C3750G, WS-C3560, WS-C3560G & OTHERS
From: crzzy1 on 21 Apr 2010 13:28 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
From: Rob on 21 Apr 2010 13:42 crzzy1 <cozzmo1(a)hotmail.com> 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.
From: Chris Mason on 24 Apr 2010 10:16 cozzmo1(a)hotmail.com - 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 <cozz...(a)hotmail.com> wrote: > On Apr 21, 1:42 pm, Rob <nom...(a)example.com> wrote: > > > > > crzzy1<cozz...(a)hotmail.com> 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
From: JF Mezei on 26 Apr 2010 00:12 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.
From: Rob on 26 Apr 2010 04:04
JF Mezei <jfmezei.spamnot(a)vaxination.ca> 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. |