Related Documentation
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.
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.
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.
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.
