cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9715
Views
0
Helpful
6
Replies
Highlighted
Beginner

sh arp, no entry vs incomplete

Trying to discover IPs used on a subnet.  The subnet does not have any firewalls, etc. Purely access layer switches attached to the router port and hosts attached to the switches (think remote office setup).

What does the router use to determine putting incomplete vs "no entry" in the sh arp?    BTW there is other live traffic through the router onto the segment, so the tcl ping script may not have been the packet to cause the original arp request to populate the arp cache.

Thanks.

Use tcl script similar to this to ping sweep segment:

tclsh

for { set i 1 } { $i <= 254 } { incr i } {

ping 172.16.233.$i re 3

}

Then do a sh arp and get response similar to this:

show ip arp

Protocol  Address    Age(min)  Hardware Addr  Type   Interface

Internet  172.16.233.22    9    0000.0c59.f892 ARPA   FastEthernet0/0

Internet  172.16.233.21    8    0000.0c07.ac00 ARPA   FastEthernet0/0

Internet  172.16.233.19    -    0000.0c63.1300 ARPA   FastEthernet0/0

Internet  172.16.233.30    9    0000.0c36.6965 ARPA   FastEthernet0/0

Internet  172.16.168.11    -    0000.0c63.1300 ARPA   FastEthernet0/0

Internet  172.16.233.32   0       Incomplete      ARPA

Internet  172.16.168.254    9    0000.0c36.6965 ARPA   FastEthernet0/0

6 REPLIES 6
Highlighted
Beginner

Incomplete means it has sent an arp request but has not got a reply.

Sent from Cisco Technical Support iPad App

Highlighted

Didn't the router need to send an ARP request (or use ARP cache) to every device in order to complete the tclsh/tcl script? 

Clarification, the tcl script is tclsh scripting on the router.

Highlighted

The time is interesting.
I suspect that the 32 had already been arped and so your ping did not generate a new arp.
What do you get if you clear arp first.

You can ping the broadcast address to find out what devices are on the LAN btw.

Sent from Cisco Technical Support iPad App

Highlighted

Depending on OS and security setting B-cast pings are not replied to.  Been there, got burned.

Have a look at 37, 38, 136-140.   Note that global edits done to replace IPs, to protect customer.

Highlighted

The zip file above is a sh arp, then clear arp, then sh arp, then tclsh ping, then sh arp.  none of the mentioned devices reply to pings.  they empty out of the arp cache (except 37 who I am guessing has user traffic to be delivered so the router arped it before the ping got a chance).  The final sh arp for  37, 38, 136 are "incomplete" while 137-140 are not in the table at all. 

Highlighted

Since no one answered my question, I did lab testing, wiresharek etc as well as some Google searches.  I found a lot of others wondering about the same thing I am asking about, but no real answers.  Here is what I believe is the answer.  Understand that this may be a little bit incorrect as I do not have access to IOS internal code.

When a packet comes into the router for delivery, and there is not existing ARP entry in cache, it sends out an ARP request, and immediately the router fills the ARP cache with an incomplete.  the incomplete stays there for about 55 seconds unless an ARP reply is received.  It an ARP reply is received the router fills the MAC address in the table.  If 55 seconds pass without any more traffic, a ARP reply, etc, the incomplete entry ages out and the table is empty for that IP address..

So the situation I am seeing is that something is trying to communicate with the devices more often then once a minute. The router puts out an ARP request, does not get back a reply, and the device appears as always in the incomplete ARP status.

Content for Community-Ad