Re: High Latency ping times

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.

Topology

Procedure

From SRX1, ping the directly connected interface IP 192.168.1.2:

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.