Understanding Using Probes for Real-Time Performance Monitoring on M, T, ACX, MX, and PTX Series Routers, EX and QFX Switches

Overview

When RPM is configured on a device, the device calculates network performance based on packet response time, jitter, and packet loss. The device gathers RPM statistics by sending out probes to a specified probe target, identified by an IP address. When the target receives a probe, it generates responses that are received by the device. A test can contain multiple probes. The probe type specifies the packet and protocol contents of the probe. You can use the history of the most recent 50 probes to analyze trends in your network and predict future needs.

With probes, you can monitor:

• Average round-trip time

• Jitter of the round-trip time—The difference between the minimum and maximum round-trip time

• Maximum round-trip time

• Minimum round-trip time

• Standard deviation of the round-trip time (Junos OS only)

One-way measurements for ICMP timestamp probes include:

• Minimum, maximum, standard deviation, and jitter measurements for egress and ingress times

• Number of probe responses received

• Number of probes sent

• Percentage of lost probes

You can set thresholds to trigger SNMP traps when the values are exceeded. You can configure the following RPM thresholds:

• Ingress/egress delay

• Jitter

• Round-trip time

• Standard deviation (Junos OS only)

• Successive lost probes

• Total lost probes (per test)

You can also configure CoS classifiers and prioritization of RPM packets over regular data packets received on an input interface with the dscp-code-points configuration statement.

Hardware Timestamps

To account for latency or jitter in the communication of probe messages, you can enable timestamping of the probe packets (hardware timestamps). If hardware timestamps are not configured, timers are generated at the software level that are less accurate than they would have been with hardware timestamps.

You can timestamp the following RPM probes to improve the measurement of latency or jitter.

• ICMP ping

• ICMP ping timestamp

• UDP ping

• UDP ping timestamp

The probe packets are time-stamped with the times at which they are sent and received at both the source and destination endpoints.

You should configure the requester (the RPM client) with hardware timestamps (see Figure 1) to get more meaningful results than you would get without the timestamps. The responder (the RPM server) does not need to be configured to support hardware timestamps. If the responder supports hardware timestamps, it timestamps the RPM probes. If the responder does not support hardware timestamps, RPM can only report round-trip measurements that include the processing time on the responder.

Figure 1 shows the timestamps:

Figure 1: RPM Timestamps

• T1 is the time the packet leaves the requester port.

• T2 is the time the responder receives the packet.

• T3 is the time the responder sends the response.

• T4 is the time the requester receives the response.

The round-trip time is T4 – T1 – (T3 – T2). If the responder does not support hardware timestamps, then the round-trip time is (T4 – T1), and thus includes the processing time of the responder.

You can use RPM probes to find the following time measurements:

• Minimum round-trip time

• Maximum round-trip time

• Average round-trip time

• Standard deviation of the round-trip time

• Jitter of the round-trip time—Difference between the minimum and maximum round-trip time

The RPM feature provides a configuration option to set one-way hardware timestamps. Use one-way timestamps when you want information about one-way time, rather than round-trip times, for packets to traverse the network between the requester and the responder. As shown in Figure 1, one-way timestamps represent the time T2 – T1 and the time from T4 – T3. Use one-way timestamps when you want to gather information about delay in each direction and to find egress and ingress jitter values.

When you enable one-way timestamps in a probe, the following one-way measurements are reported:

• Minimum, maximum, standard deviation, and jitter measurements for egress and ingress times

• Number of probes sent

• Number of probe responses received

• Percentage of lost probes

Junos OS Support

Starting in Junos OS Release 17.3R1, you can apply RPM to IPsec tunnels and GRE tunnels for PIC-based and Routing Engine-based RPM clients and servers if you are using MS-MPCs or MS-MICs. Packet Forwarding Engine-based RPM is not supported for IPsec tunnels. Support of RPM on IPSec tunnels enables service level agreement (SLA) monitoring for traffic transported in IPSec tunnels.

In Junos OS, you can also configure RPM services to determine automatically whether a path exists between a host device and its configured BGP neighbors. You can view the results of the discovery using an SNMP client. Results are stored in pingResultsTable, jnxPingResultsTable, jnxPingProbeHistoryTable, and pingProbeHistoryTable.

Starting in Junos OS Release 18.4R1 for MX Series routers, you can use RPM probes to detect link status, and change the preferred-route state on the basis of the probe results. RPM-tracked routes can be IPv4 or IPv6, and support a single IPv4 or IPv6 next hop. You configure this feature with the rpm-tracking statement at the [edit routing-options] or [edit routing-instances routing-options] hierarchy level. For example, RPM probes can be sent to an IP address to determine if the link is up, and if so, the software installs a static route in the route table. RPM-tracked static routes are installed with preference 1 and thus are preferred over any existing static routes for the same prefix. Starting in Junos OS Release 19.1R1, you can track up to 16 next hops for each IPv4 or IPv6 RPM-tracked static route, for MX Series routers. Starting in Junos OS Release 20.4R1, we've extended support to the PTX Series routers. In addition, for this feature, you can configure route preference and tag values for each IPv4 or IPv6 destination prefix. Starting in Junos OS Release 22.3R1, you can configure RPM-tracked static routes for the ACX710 and ACX5448 routers. Starting in Junos OS Release 24.2R1, you can configure RPM-tracked static routes for the EX4100, EX4400, and EX4650 switches, including multiple next hops and the setting of preference and tag values for each IPv4 or IPv6 destination prefix.

In Junos OS, probe configuration and probe results are supported by both the command-line interface (CLI) and SNMP. You set the probe options in the test test-name statement at the [edit services rpm probe owner] hierarchy level. You use the show services rpm probe-results command to view the results of the most recent RPM probes.

Table 1 provides information about RPM and related timestamp support on MPC, MS-MIC/MPC, and Routing Engine:

Junos OS Evolved Support

Starting in Junos OS Evolved Release 20.1R1, you can configure RPM probes. For Junos OS Evolved, RPM is configured at the [edit services monitoring rpm] hierarchy level. The scope of support is limited to:

• Probe generation and reception (client) as well as reflection (server) for the following RPM probe types:

  • http-get (added in Junos OS Evolved 23.4R1)

    You must set the offload-type statement to none to configure this probe type.

  • http-metadata-get (added in Junos OS Evolved 23.4R1)

    You must set the offload-type statement to none to configure this probe type.

  • icmp-ping

  • icmp-timestamp

  • tcp-ping (added in Junos OS Evolved 23.4R1)

    You must set the offload-type statement to none to configure this probe type.

  • udp-ping

  • udp-timestamp

• Probe history management

• Reporting through syslog only

Starting in Junos OS Evolved Release 21.2R1, reporting through SNMP MIB objects is supported for RPM.