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

Recent posts in the same categories

17 comments:

  1. Anonymous 29 November 2007 23:57
    What will happen if you increase the ping timeout?
  2. Ivan Pepelnjak 30 November 2007 07:22
    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. Anonymous 18 August 2008 08:56
    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. Ivan Pepelnjak 22 August 2008 18:24
    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. Anonymous 18 June 2012 20:33
    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. Anonymous 31 October 2012 04:49
    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. Anonymous 03 February 2013 21:12
    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. Scott 13 June 2013 02:24
    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. Alexandr 21 July 2013 14:05
      > 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. Rahman 06 October 2013 11:22
    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. @n@nD 07 February 2014 12:35
    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. Unknown 25 February 2015 10:04
    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. Anonymous 30 March 2016 22:14
    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. Ivan Pepelnjak 31 March 2016 08:33
      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. Anonymous 12 November 2017 18:23
    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. Ivan Pepelnjak 12 November 2017 19:45
      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. Anonymous 12 November 2017 20:54
      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
Home
Sidebar