Why is the first ping lost?
When pinging a directly-attached host (end-station) from a router, it's quite common to lose the first reply, as shown in the following example (the same symptom might occur when pinging a remote host that has been inactive).
a2#ping 10.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
Actually, it's not the reply that was lost, the request was never sent out. Whenever a router has to send a packet to the next-hop (or directly attached destination) that has no entry in the ARP table, the ARP request is sent out, but the original packet is unconditionally dropped.
You can easily test this behavior in the lab (live networks are too busy for that) by debugging ARP requests while performing the ping command:a2#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.0.6 - 0016.c876.8b38 ARPA FastEthernet0/0
Internet 10.0.0.5 0 0016.c7fe.f150 ARPA FastEthernet0/0
a2#debug arp
ARP packet debugging is on
a2#ping 10.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
08:26:21: IP ARP: creating incomplete entry for IP address: 10.0.0.10 interface
FastEthernet0/0
08:26:21: IP ARP: sent req src 10.0.0.6 0016.c876.8b38,
dst 10.0.0.10 0000.0000.0000 FastEthernet0/0
08:26:21: IP ARP: rcvd rep src 10.0.0.10 000c.29a7.8ade, dst 10.0.0.6 FastEthernet0/0
Posts
4 comments:
What will happen if you increase the ping timeout?
No difference. The IP packet that triggers ARP request is dropped unconditionally. No timeout will help you, as there is no retransmission with ICMP.
There could be some buffer to store ICMP packet to store and once ARP request resolved, the buffer can release the first packet. why this is not happening??
IP is designed to be an unreliable protocol, so when a packet is dropped in the network (or delayed for too long), the source will retransmit. If you delay the packet in the network for too long, you might end up with duplicate packets, which could cause quite a headache for some poorly written applications.
It's thus better to drop what you can't handle immediately and let the source deal with the problem ... and anyway, with CEF glean adjacencies ARP tables almost never time out.
This blog is using JS-Kit comments. You have to enable JavaScript if you want to post a comment.