Description

This article explains how rapid pings work in junos, and its behavior.

Solution

The behavior is similar to how flood ping is implemented in Free BSD, where a minimum of 100 packets are sent in one second or each packet is generated as soon as a reply to the request has come.

With rapid ping, we wait at most 500ms for the receipt of the response after which we declare a timeout in ping output (a DOT is printed). But the next packet is sent as soon as response for the last packet is received within 500 ms (no wait). So the minimum time interval between 2 ping packets is at most 500ms in a packet loss scenario. In case there is no packet loss, then there is no wait, which means immediately after a response is received

Example of successful rapid ping:

[edit]
lab@R1# run ping 192.168.5.2 rapid count 1000
PING 192.168.5.2 (192.168.5.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 192.168.5.2 ping statistics ---
1000 packets transmitted, 1000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.409/0.457/6.061/0.254 ms
[edit]
lab@R1#


Example of an unsuccessful rapid ping which shows 500ms delay between the request packets using packet capture:

[edit]
lab@R1# run ping 192.168.5.2 rapid count 20
PING 192.168.5.2 (192.168.5.2): 56 data bytes
....................
--- 192.168.5.2 ping statistics ---
20 packets transmitted, 0 packets received, 100% packet loss

[edit]
lab@R1#

lab@R1# run monitor traffic interface ge-1/1/1.0 size 9999
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-1/1/1.0, capture size 9999 bytes

Reverse lookup for 192.168.5.2 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

08:52:55.144894 Out IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 7876, seq 5, length 64
08:52:55.646126 Out IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 7876, seq 6, length 64
08:52:56.146891 Out IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 7876, seq 7, length 64
08:52:56.647880 Out IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 7876, seq 8, length 64
08:52:57.148906 Out IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 7876, seq 9, length 64
08:52:57.649873 Out IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 7876, seq 10, length 64
08:52:58.150867 Out IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 7876, seq 11, length 64
08:52:58.651860 Out IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 7876, seq 12, length 64

The time difference from the above captures shows that there is a 500ms delay between each response packet.

Modification History

2020-06-07: Article reviewed for accuracy; no changes required