Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[JUNOS] Behavior of rapid ping in Junos

0

0

Article ID: KB25251 KB Last Updated: 16 Jun 2020Version: 2.0
Summary:

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
 
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search