This article discusses latency in ICMP pings when a Junos OS platform is responsible for ICMP echo reply.
An ICMP ping shows intermittent latency on a directly connected link with the default Junos Class of Service (CoS) configuration.
router1 (192.168.1.1)---------------------------(192.168.1.2) router2
From router1, ping the directly connected interface IP 192.168.1.2:
router1> ping 192.168.1.2 64 bytes from 192.168.1.2: icmp_seq=28 ttl=64 time=0.524 ms 64 bytes from 192.168.1.2: icmp_seq=29 ttl=64 time=0.503 ms 64 bytes from 192.168.1.2: icmp_seq=30 ttl=64 time= 16.205 ms 64 bytes from 192.168.1.2: icmp_seq=31 ttl=64 time=0.543 ms 64 bytes from 192.168.1.2: icmp_seq=32 ttl=64 time= 32.299 ms
Note that the time is nearly 0.5 ms for most of the ping requests, but in some instances we see a value which is much larger.
Although ICMP is a great way to check for link availability, it is not a good way to test latency or delay on a Juniper Networks platform. One of the best and most accurate ways to test for latency is to simulate data plane traffic using a traffic generator for the transit traffic.
Juniper Networks platform architecture separates the control plane from the data plane. There are various rate-limiting and prioritization functions within the packet forwarding engine (PFE) and the routing engine. When a ping is sent from the routing platform to the end device, it is using the control plane on the local router in order to generate the ICMP request packet. The control plane is used again when the ICMP reply packet is received from the end device.
ICMP messages are considered low priority within Junos OS, so the routing platform will respond to and process other higher priority messages, such as routing updates, before processing the ICMP messages. The microkernel may introduce tens of milliseconds of processing delay to ICMP message handling. The delay is not uniform, meaning that some ICMP messages might be delayed while others may not be delayed. This matches the behavior observed here with the testing.
ICMP ping latency in traffic generated for the device itself is not a recommended way of testing the bandwidth or integrity of the link.
Latency and Jitter Meaurement via Real Time Performance Monitoring
Sample Topology
Traffgen1---DUT----PeerQFX--Trafficgen2
Below config is confirmed on DUT device:
Heres the test result from sample testbed which can be configured.
root@n05-44# show services | display set
set services rpm probe probe1 test test1 target address 1.1.1.2
set services rpm probe probe1 test test1 probe-count 5
set services rpm probe probe1 test test1 probe-interval 10
set services rpm probe probe1 test test1 thresholds rtt 20
> show services rpm probe-results
sample test results
{master:0}[edit]
root# run show services rpm probe-results
Owner: probe1, Test: test1
Target address: 1.1.1.2, Probe type: icmp-ping, Icmp-id: 10, Test size: 5 probes
Probe results:
Response received
Probe sent time: Thu Dec 12 11:12:06 2024
Probe rcvd/timeout time: Thu Dec 12 11:12:06 2024, No hardware timestamps
Rtt: 14288 usec, Round trip jitter: 3711 usec
Round trip interarrival jitter: 5287 usec
Results over current test:
Probes sent: 3, Probes received: 3, Loss percentage: 0.000000
Measurement: Round trip time
Samples: 3, Minimum: 5689 usec, Maximum: 14288 usec, Average: 10185 usec, Peak to peak: 8599 usec, Stddev: 3521 usec, Sum: 30554 usec
Measurement: Positive round trip jitter
Samples: 2, Minimum: 3711 usec, Maximum: 4888 usec, Average: 4300 usec, Peak to peak: 1177 usec, Stddev: 588 usec, Sum: 8599 usec
Measurement: Negative round trip jitter
Samples: 1, Minimum: 3901 usec, Maximum: 3901 usec, Average: 3901 usec, Peak to peak: 0 usec, Stddev: 0 usec, Sum: 3901 usec
Results over last test:
Probes sent: 5, Probes received: 5, Loss percentage: 0.000000
Test completed on Thu Dec 12 11:11:45 2024
Samples: 5, Minimum: 6560 usec, Maximum: 9590 usec, Average: 8493 usec, Peak to peak: 3030 usec, Stddev: 1169 usec, Sum: 42467 usec
Samples: 2, Minimum: 1867 usec, Maximum: 2810 usec, Average: 2339 usec, Peak to peak: 943 usec, Stddev: 472 usec, Sum: 4677 usec
Samples: 3, Minimum: 146 usec, Maximum: 6356 usec, Average: 2668 usec, Peak to peak: 6210 usec, Stddev: 2666 usec, Sum: 8003 usec
Results over all tests:
Probes sent: 153, Probes received: 153, Loss percentage: 0.000000
Samples: 153, Minimum: 2924 usec, Maximum: 46733 usec, Average: 11011 usec, Peak to peak: 43809 usec, Stddev: 7114 usec, Sum: 1684669 usec
Samples: 81, Minimum: 107 usec, Maximum: 28520 usec, Average: 6153 usec, Peak to peak: 28413 usec, Stddev: 7171 usec, Sum: 498425 usec
Samples: 71, Minimum: 146 usec, Maximum: 37511 usec, Average: 6863 usec, Peak to peak: 37365 usec, Stddev: 8495 usec, Sum: 487297 usec
Dec 16 2024: Added the right method to measure latency and jitter via real time performance monitoring