0

I am pinging from one of the Juniper L3 interfaces to another with a rapid ping count of 10000 packets. It's a direct 100G optical connection and I am seeing 10-15 packets being dropped by the end of the ping test. If I do the same test connecting back to back on the same device, I don't see any drop at all. The results would be 10k packets sent and 10k packets received. I haven't really changed the cable or transievers between the tests. Why are the packets getting dropped?

From one device to another device

root>ping 26.10.10.20 rapid count 10000 source 26.10.10.10
PING 26.10.10.20 (26.10.10.20) from 26.10.10.10 : 56(84) bytes of data.
--- 26.10.10.20 ping statistics ---
10000 packets transmitted, 9991 received, 0% packet loss, time 39859ms
rtt min/avg/max/mdev = 0.886/1.474/71.194/2.454 ms, pipe 2, ipg/ewma 3.986/1.757 ms

Between two interfaces of same device

root> ping 26.10.10.11 rapid count 10000 source 26.10.10.10
PING 26.10.10.11 (26.10.10.11) from 26.10.10.10 : 56(84) bytes of data.
--- 26.10.10.11 ping statistics ---
10000 packets transmitted, 10000 received, 0% packet loss, time 40655ms
rtt min/avg/max/mdev = 0.063/0.088/2.062/0.040 ms, ipg/ewma 4.065/0.099 ms
2
  • 3
    Pinging interfaces on the same device will not put the packets on the wire.
    – Ricky
    Mar 4 at 22:35
  • Outgoing ICMP is usually rate limited.
    – Zac67
    Mar 5 at 7:16
1

There are several reasons why not all ICMP echo requests receive a reply:

  • Outgoing ICMP (echo reply) may be rate-limited on the pinged device. Check settings/docs. There might not be indicators/counters for this but you'd likely see differences when varying the ping frequency.
  • Outgoing ICMP is low priority and may be limited by device (CPU) load. Check the device for load peaks.
  • Echo requests or replies may be lost to congestion in the path. Check the drop counters on all relevant devices.
  • Request or reply packets may be damaged in transit and subsequently dropped. Check all ports' counters for FCS errors or similar.

If you ping to a local interface's IP address on a device, that's interpreted as loopback and doesn't use any physical interfaces. Additionally, I might not be subject to the same limitations as physically received/transmitted traffic.

2
  • Rate limited - It is not because there is nothing configured on the device explicitly to rate limit. CPU limit - I am not sure about verifying this. I don't think there is anything to make sure from the CLI. At least I don't know. Congestion - We can rule this out because it's a direct connection and the link speed 100G. Damaged in transit - This could be possible if the cable or transceiver is bad. So, there is no guarantee that I get replies to all my ping requests to make sure the cable/transceiver is doing it's thing correctly. Right? Mar 5 at 20:53
  • @RakeshNittur ICMP rate limiting is often active by default. No, there's no guarantee you'd receive replies for (all) your echo requests, generally. Testing links and transceivers should be done with more serious trafic (e.g. using iperf3) - ICMP is low rate and lowest priority. ping is a quick way to check connectivity and routing, nothing else.
    – Zac67
    Mar 5 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.