Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

RPM Overview

 

The real-time performance monitoring (RPM) feature allows network operators and their customers to accurately measure the performance between two network endpoints. With the RPM tool, you configure and send probes to a specified target and monitor the analyzed results to determine packet loss, round-trip time, and jitter.

RPM allows you to perform service-level monitoring. When RPM is configured on a device, the device calculates network performance based on packet response time, jitter, and packet loss. These values are gathered by Hypertext Transfer Protocol (HTTP) GET requests, Internet Control Message Protocol (ICMP) requests, and TCP and UDP requests, depending on the configuration.

This section contains the following topics:

RPM Probes

You gather RPM statistics by sending out probes to a specified probe target, identified by an IP address or URL. When the target receives the probe, it generates responses, which are received by the device. By analyzing the transit times to and from the remote server, the device can determine network performance statistics.

The device sends out the following probe types:

  • HTTP GET request at a target URL

  • HTTP GET request for metadata at a target URL

  • ICMP echo request to a target address (the default)

  • ICMP timestamp request to a target address

  • UDP ping packets to a target device

  • UDP timestamp requests to a target address

  • TCP ping packets to a target device

UDP and TCP probe types require that the remote server be configured as an RPM receiver so that it generates responses to the probes.

The RPM probe results are also available in the form of MIB objects through the SNMP protocol.

Note

On SRX300, SRX320, SRX340, SRX1500, SRX4600 devices and vSRX instances, when you configure basic RPM probes, the following combination of the configuration parameters is not supported:

Source address and destination port and next-hop.

Configuring RPM probe with these parameters prevents sending out RPM probes to a specified probe target. We recommend you to configure either the source address or destination port and next-hop to configure RPM probe.

RPM Tests

Each probed target is monitored over the course of a test. A test represents a collection of probes, sent out at regular intervals, as defined in the configuration. Statistics are then returned for each test. Because a test is a collection of probes that have been monitored over some amount of time, test statistics such as standard deviation and jitter can be calculated and included with the average probe statistics.

Probe and Test Intervals

Within a test, RPM probes are sent at regular intervals, configured in seconds. When the total number of probes has been sent and the corresponding responses received, the test is complete. You can manually set the probe interval for each test to control how the RPM test is conducted.

After all the probes for a particular test have been sent, the test begins again. The time between tests is the test interval. You can manually set the test interval to tune RPM performance.

Note

On SRX340 devices, the RPM server operation with icmp is not supported. The RPM server works fine with TCP and UDP.

Jitter Measurement with Hardware Timestamping

Jitter is the difference in relative transit time between two consecutive probes.

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

Note

The device supports hardware timestamping of UDP ping and UDP ping timestamp RPM probes only if the destination port is UDP-ECHO (port 7).

Timestamping takes place during the forwarding process of the device originating the probe (the RPM client), but not on the remote device that is the target of the probe (the RPM server).

The supported encapsulations on a device for timestamping are Ethernet including VLAN, synchronous PPP, and Frame Relay. The only logical interface supported is an lt services interface.

RPM probe generation with hardware timestamp can be retrieved through the SNMP protocol.

RPM Statistics

At the end of each test, the device collects the statistics for packet round-trip time, packet inbound and outbound times (for ICMP timestamp probes only), and probe loss as shown in Table 1.

Table 1: RPM Statistics

RPM Statistics

Description

Round-Trip Times

Minimum round-trip time

Shortest round-trip time from the Juniper Networks device to the remote server, as measured over the course of the test

Maximum round-trip time

Longest round-trip time from the Juniper Networks device to the remote server, as measured over the course of the test

Average round-trip time

Average round-trip time from the Juniper Networks device to the remote server, as measured over the course of the test

Standard deviation round-trip time

Standard deviation of the round-trip times from the Juniper Networks device to the remote server, as measured over the course of the test

Jitter

Difference between the maximum and minimum round-trip times, as measured over the course of the test

Inbound and Outbound Times (ICMP Timestamp Probes Only)

Minimum egress time

Shortest one-way time from the Juniper Networks device to the remote server, as measured over the course of the test

Maximum ingress time

Shortest one-way time from the remote server to the Juniper Networks device, as measured over the course of the test

Average egress time

Average one-way time from the Juniper Networks device to the remote server, as measured over the course of the test

Average ingress time

Average one-way time from the remote server to the Juniper Networks device, as measured over the course of the test

Standard deviation egress time

Standard deviation of the one-way times from the Juniper Networks device to the remote server, as measured over the course of the test

Standard deviation ingress time

Standard deviation of the one-way times from the remote server to the Juniper Networks device, as measured over the course of the test

Egress jitter

Difference between the maximum and minimum outbound times, as measured over the course of the test

Ingress jitter

Difference between the maximum and minimum inbound times, as measured over the course of the test

Probe Counts

Probes sent

Total number of probes sent over the course of the test

Probe responses received

Total number of probe responses received over the course of the test

Loss percentage

Percentage of probes sent for which a response was not received

RPM Thresholds and Traps

You can configure RPM threshold values for the round-trip times, ingress (inbound) times, and egress (outbound) times that are measured for each probe, as well as for the standard deviation and jitter values that are measured for each test. Additionally, you can configure threshold values for the number of successive lost probes within a test and the total number of lost probes within a test.

If the result of a probe or test exceeds any threshold, the device generates a system log message and sends any Simple Network Management Protocol (SNMP) notifications (traps) that you have configured.

Starting in Junos OS Release 18.4R1, if the result of a probe or test exceeds the packet loss threshold, the real-time performance monitoring (RPM) test probe is marked as failed. The test probe also fails when the round-trip time (RTT) exceeds the configured threshold value. As a result, the device generates an SNMP notification (trap) and marks the RPM test as failed.

RPM allows you to perform service-level monitoring. When RPM is configured on a device, the device calculates network performance based on packet response time, jitter, and packet loss.

RPM for BGP Monitoring

When managing peering networks that are connected using Border Gateway Protocol (BGP), you might need to find out if a path exists between the Juniper Networks device and its configured BGP neighbors. You can ping each BGP neighbor manually to determine the connection status, but this method is not practical when the device has a large number of BGP neighbors configured.

In the device, you can configure RPM probes to monitor the BGP neighbors and determine if they are active.

Release History Table
Release
Description
Starting in Junos OS Release 18.4R1, if the result of a probe or test exceeds the packet loss threshold, the real-time performance monitoring (RPM) test probe is marked as failed. The test probe also fails when the round-trip time (RTT) exceeds the configured threshold value. As a result, the device generates an SNMP notification (trap) and marks the RPM test as failed.

RPM allows you to perform service-level monitoring. When RPM is configured on a device, the device calculates network performance based on packet response time, jitter, and packet loss.