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

17 comments:

  1. What will happen if you increase the ping timeout?
  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.
  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??
  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.
  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.
  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%
  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.
  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?
    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".
  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.!!!!
  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??
  11. It's all about ARP request and NIC's buffering ... first ping's packet waits certain time for ARP reply to put it's destination MAC in its frame after exceeding this time and the reply didn't reach ... the packet will be dropped and the next packets will be sent ..
  12. Hey guys... Does anyone know how to configure a router(A) so it can send acopy of its arp table to another router(B)

    All hosts inside X subnet are pointing towards router A. I need to have that exact copy dynamically if possible in router B.

    Thanks!
    Replies
    1. Well, if you'd be running Cumulus Linux (or any other routing-over-Linux product) it would be a simple matter of writing a Python (or Perl) script.

      AFAIK there's no such option in traditional routers.
  13. Thanks for this article. This answers my problem: I send only one ping and I get a timeout even after increasing (a lot) the delay before the timeout (like some other articles suggest). In the captures, the ICMP request is not emitted at all after the ARP response.

    But what is your source? I cannot find any document on Cisco about this.
    Replies
    1. What is my source? Packet traces, debugging printouts, and familiarity with how things are done ;)... slowly gained while studying real-life networking operating systems for 30 years.
    2. Hehe, thanks again for the valuable article then. I'm just surprised to find so many answers about increasing the timeout delay whereas this is pointless since the request was dropped.
Add comment
Sidebar