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

11 comments:

  1. What will happen if you increase the ping timeout?

    ReplyDelete
  2. No difference. The IP packet that triggers ARP request is dropped unconditionally. No timeout will help you, as there is no retransmission with ICMP.

    ReplyDelete
  3. 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??

    ReplyDelete
  4. 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.

    ReplyDelete
  5. I've seen this also cause SLB load balancing to fail out all the real servers until their IP's have all been manually pinged and have entries in the ARP cache.

    ReplyDelete
  6. Are there any other causes? I'm seeing this on a single SRX firewall to a host that is already in the ARP table. It only happens if I wait around 50seconds+ before attempting a new ping. Any pings within that time frame get through 100%

    ReplyDelete
  7. Would be good to mention why 2nd packet is not dropped as well - when target receives 2nd packet sent (1st for target) then why there is no need for ARP request to reply to it and drop target's first response.

    ReplyDelete
  8. If I ping the LAN interface of a remote branch router, I still have the same problem. This doesn't seem to fit the explanation, as the router shouldn't need to perform an ARP broadcast/discovery to locate its own address, right? After all, it is the layer 2/3 boundary.
    Is there something I'm missing, or that can explain this issue?

    ReplyDelete
    Replies
    1. > If I ping the LAN interface of a remote branch router
      Are your routers connected via Ethernet? If yes, then it might be the missing ARP entry for your remote router (your local router should still find MAC address of your remote router to send ping to it). So it might still be just the same situation as stated in article.
      BTW, if you "debug ip packet" then you will see that debug for the first packet (in case ARP was not resolved earlier) says "Encapsulation failed", so I can presume it means "I could not encapsulate this packet due to missing ARP entry for this IP address".

      Delete
  9. Yes before I give ping there wasn't any arp entry and the ping failed for the first packet
    *Mar 1 00:03:40.495: IP: s=10.1.2.1 (local), d=10.1.2.2 (FastEthernet0/0), len 100, encapsulation failed.!!!!

    ReplyDelete
  10. What if we add 50 brand new routers between 2 hosts, now if we try to ping will the first 50 packets will drop so that the ARP and DNS responses for 50 routers will take that much time??

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.