Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Real-Time Performance Monitoring for SRX Devices

SUMMARY This section describes the real-time performance monitoring (RPM) feature that allows network operators and their customers to accurately measure the performance of the network between two endpoints.

RPM Overview (SRX)

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 Virtual Firewall 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.

Guidelines for Configuring RPM Probes for IPv6 (SRX Series Firewalls)

Starting with Junos OS Release 15.1X49-D10, you can configure RPM Probes for IPv6.

Keep the following guidelines in mind when you configure IPv6 addresses for RPM destinations or servers:

  • IPv6 RPM uses ICMPv6 probe requests. You cannot configure ICMP or ICMP timestamp probe types.

  • Only Routing Engine-based RPM is supported for IPv6 targets including VRF support, specification of the size of the data portion of ICMPv6 probes, data pattern, and traffic class.

  • You can configure probes with a combination of IPv4 and IPv6 tests. However, an individual test must be either IPv4 or IPv6.

  • Routing Engine-based RPM does not support hardware-based, or one-way hardware-based timestamping.

  • We recommend that you include the probe-limit statement at the [edit services rpm] hierarchy level to set the limit on concurrent probes to 10. Higher concurrent probes can result in higher spikes.

  • SNMP set operation is permitted only on ICMP probes and it is not supported for other probe types.

  • The following table describes the IPv6 special address prefixes that you cannot configure in a probe.

    IPV6 Address Type

    IPV6 Address Prefix

    Node-Scoped Unicast

    ::1/128 is the loopback address

    ::/128 is the unspecified address

    IPv4-Mapped Addresses

    ::FFFF:0:0/96

    IPv4-Compatible Addresses

    :<ipv4-address>/96

    Link-Scoped Unicast

    fe80::/10

    Unique-Local

    fc00::/7

    Documentation Prefix

    2001:db8::/32

    6to4

    2002::/16

    6bone

    5f00::/8

    ORCHID

    2001:10::/28

    Teredo

    2001::/32

    Default Route

    ::/0

    Multicast

    ff00::/8

  • In Routing Engine-based RPM, route-trip time (RTT) spikes might occur because of queuing delays, even with a single test.

  • Since RPM might open TCP and UDP ports to communicate between the RPM server and RPM client, we recommend that you use firewalls and distributed denial-of-service (DDoS) attack filters to protect against security threats.

IPv6 RPM Probes (vSRX Virtual Firewall)

Starting with Junos OS Release 15.1X49-D10, Route Engine-based RPM can send and receive IPv6 probe packets to monitor performance on IPv6 networks.

A probe request is a standard IPv6 packet with corresponding TCP, UDP, and ICMPv6 headers. A probe response is also a standard IPv6 packet with corresponding TCP, UDP, and ICMPv6 headers. No RPM header is appended to the standard packet for RE-based RPM. An IPv6-based RPM test occurs between an IPv6 RPM client and IPv6 RPM server.

Note:

You can have both IPv4 tests and IPv6 tests in the same probe.

Configuring IPv6 RPM Probes (vSRX Virtual Firewall)

Starting with Junos OS Release 15.1X49-D10, you can configure IPv6 destination addresses for an IPv6-based RPM probe test.

To configure an IPv6 RPM test:

  1. Specify the RPM probe owner for the probe you want to configure as an IPv6 test.
  2. Specify a name for the test.
  3. Specify the probe type.
  4. Specify the target address for the test.
  5. Configure the remaining RPM test parameters.

Tuning RPM Probes (SRX Series Firewalls)

After configuring an RPM probe, you can set parameters to control probe functions, such as the interval between probes, the total number of concurrent probes that a system can handle, and the source address used for each probe packet.

To tune RPM probes:

  1. Set the maximum number of concurrent probes allowed on the system to 10.
  2. Access the ICMP probe of customer A.
  3. Set the time between probe transmissions to 15 seconds.
  4. Set the number of probes within a test to 10.
  5. Set the source address for each probe packet to 192.168.2.9. If you do not explicitly configure a source address, the address on the outgoing interface through which the probe is sent is used as the source address.
  6. If you are done configuring the device, enter commit from configuration mode.

Monitoring RPM Probes (SRX Series Firewalls)

The RPM information includes the round-trip time, jitter, and standard deviation values for each configured RPM test on the device. To view these RPM properties, select Troubleshoot>RPM>View RPM in the J-Web user interface, or in configuration mode enter the show command:

In addition to the RPM statistics for each RPM test, the J-Web user interface displays the round-trip times and cumulative jitter graphically. Figure 1 shows sample graphs for an RPM test.

Figure 1: Sample RPM GraphsSample RPM Graphs

In Figure 1, the round-trip time and jitter values are plotted as a function of the system time. Large spikes in round-trip time or jitter indicate a slower outbound (egress) or inbound (ingress) time for the probe sent at that particular time.

Table 2 summarizes key output fields in RPM displays.

Table 2: Summary of Key RPM Output Fields

Field

Values

Additional Information

Currently Running Tests

Graph

 

Click the Graph link to display the graph (if it is not already displayed) or to update the graph for a particular test.

Owner

Configured owner name of the RPM test.

Test Name

Configured name of the RPM test.

Probe Type

Type of RPM probe configured for the specified test:

  • http-get

  • http-get-metadata

  • icmp-ping

  • icmp6-ping

  • icmp-ping-timestamp

  • tcp-ping

  • udp-ping

Target Address

IPv4 address, IPv6 address, or URL of the remote server that is being probed by the RPM test.

Source Address

Explicitly configured IPv4 or IPv6 source address that is included in the probe packet headers.

If no source address is configured, the RPM probe packets use the outgoing interface as the source address, and the Source Address field is empty.

Minimum RTT

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

Maximum RTT

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

Average RTT

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

Standard Deviation RTT

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

Probes Sent

Total number of probes sent over the course of the test.

Loss Percentage

Percentage of probes sent for which a response was not received.

Round-Trip Time for a Probe

Samples

Total number of probes used for the data set.

The Juniper Networks device maintains records of the most recent 50 probes for each configured test. These 50 probes are used to generate RPM statistics for a particular test.

Earliest Sample

System time when the first probe in the sample was received.

Latest Sample

System time when the last probe in the sample was received.

Mean Value

Average round-trip time for the 50-probe sample.

Standard Deviation

Standard deviation of the round-trip times for the 50-probe sample.

Lowest Value

Shortest round-trip time from the device to the remote server, as measured over the 50-probe sample.

Time of Lowest Sample

System time when the lowest value in the 50-probe sample was received.

Highest Value

Longest round-trip time from the Juniper Networks device to the remote server, as measured over the 50-probe sample.

Time of Highest Sample

System time when the highest value in the 50-probe sample was received.

Cumulative Jitter for a Probe

Samples

Total number of probes used for the data set.

The Juniper Networks device maintains records of the most recent 50 probes for each configured test. These 50 probes are used to generate RPM statistics for a particular test.

Earliest Sample

System time when the first probe in the sample was received.

Latest Sample

System time when the last probe in the sample was received.

Mean Value

Average jitter for the 50-probe sample.

Standard Deviation

Standard deviation of the jitter values for the 50-probe sample.

Lowest Value

Smallest jitter value, as measured over the 50-probe sample.

Time of Lowest Sample

System time when the lowest value in the 50-probe sample was received.

Highest Value

Highest jitter value, as measured over the 50-probe sample.

Time of Highest Sample

System time when the highest jitter value in the 50-probe sample was received.

Example: Configuring Basic RPM Probes (SRX)

This example shows how to configure basic RPM probes to measure performance between two network endpoints.

Requirements

Before you begin:

Overview

In this example, you configure basic probes for two RPM owners, customerA and customerB. You configure the RPM test as icmp-test for customerA with a test interval of 15 seconds and specify a probe type as icmp-ping-timestamp, a probe timestamp, and a target address as 192.178.16.5. You then configure the RPM thresholds and corresponding SNMP traps to catch ingress (inbound) times greater than 3000 microseconds.

Then you configure the RPM test as http-test for customerB with a test interval of 30 seconds and specify a probe type as http-get and a target URL as http://customerB.net. Finally, you configure RPM thresholds and corresponding SNMP traps as probe-failure and test-failure to catch three or more successive lost probes and total lost probes of 10.

Note:

On SRX300, SRX320, SRX340, SRX1500 devices and vSRX Virtual Firewall 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.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide .

To configure basic RPM probes:

  1. Configure the RPM.

  2. Configure the RPM owners.

  3. Configure the RPM test for customerA.

  4. Specify a probe timestamp and a target address.

  5. Configure RPM thresholds and corresponding SNMP traps.

  6. Configure the RPM test for customerB.

  7. Specify a probe type and a target URL.

  8. Configure RPM thresholds and corresponding SNMP traps.

Results

From configuration mode, confirm your configuration by entering the run show services rpm command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying RPM Services

Purpose

Verify that the RPM configuration is within the expected values.

Action

From operational mode, enter the show services rpm command. The output shows the values that are configured for RPM on the device.

Verifying RPM Statistics

Purpose

Verify that the RPM probes are functioning and that the RPM statistics are within expected values.

Action

From operational mode, enter the show services rpm probe-results command.

Configure the traps you want using the set services rpm probe p1 test t1 traps command.

If a trap is triggered, you can view the same in the log file named messages using the show snmp log messages | match rmopd command.

Possible Option

Set of values

egress-jitter-exceeded

Exceeded jitter in egress time threshold

egress-std-dev-exceeded

Exceeded egress time standard deviation threshold

egress-time-exceeded

Exceeded maximum egress time threshold

ingress-jitter-exceeded

Exceeded jitter in ingress time threshold

ingress-std-dev-exceeded

Exceeded ingress time standard deviation threshold

probe-failure

Successive probe loss threshold reached

rtt-exceeded

Exceeded maximum round trip time threshold

std-dev-exceeded

Exceeded round trip time standard deviation threshold

test-completion

Test completed

test-failure

Total probe loss threshold reached

Example: Configuring RPM Using TCP and UDP Probes (SRX Series Firewalls)

This example shows how to configure RPM using TCP and UDP probes.

Requirements

Before you begin:

Overview

In this example, you configure both the host (device A) and the remote device (device B) to act as TCP and UDP servers. You configure a probe for customerC, which uses TCP packets. Device B is configured as an RPM server for both TCP and UDP packets, using an lt services interface as the destination interface, and ports 50000 and 50037, respectively.

CAUTION:

Use probe classification with caution, because improper configuration can cause packets to be dropped.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide .

To configure RPM using TCP and UDP probes:

  1. Configure the RPM owner on device A.

  2. Configure the RPM test.

  3. Set the probe type.

  4. Specify the target address.

  5. Configure the destination interface.

  6. Configure port 50000 as the TCP port to which the RPM probes are sent.

  7. Configure device B to act as a TCP server using port 50000.

  8. Configure device B to act as a UDP server using port 50037.

Results

From operational mode, confirm your configuration by entering the show services rpm command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying RPM Probe Servers

Purpose

Confirm that the configuration is working properly.

Verify that the device is configured to receive and transmit TCP and UDP RPM probes on the correct ports.

Action

From operational mode, enter the show services rpm active-servers command. The output shows a list of the protocols and corresponding ports for which the device is configured as an RPM server.

Example: Configuring RPM Probes for BGP Monitoring

This example shows how to configure RPM probes to monitor BGP neighbors.

Requirements

Before you begin:

Overview

In this example, you specify a hexadecimal value that you want to use for the data portion of the RPM probe as ABCD123. ( It ranges from 1 through 2048 characters.) You specify the data size of the RPM probe as 1024 bytes. ( The value ranges from 0 through 65,507.)

Then you configure destination port 50000 as the TCP port to which the RPM probes are sent. You specify the number of probe results to be saved in the probe history as 25. (It ranges from 0 through 255, and the default is 50.) You set the probe count to 5 and probe interval as 1. (The probe count ranges from 1 through 15, and the default is 1; and the probe interval ranges from 1 through 255, and the default is 3.) You then specify tcp-ping as the type of probe to be sent as part of the test.

Finally, you set the test interval as 60. The value ranges from 0 through 86,400 seconds for the interval between tests.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide .

To configure RPM probes to monitor BGP neighbors:

  1. Configure the RPM and BGP.

  2. Specify a hexadecimal value.

  3. Specify the data size of the RPM probe.

  4. Configure the destination port.

  5. Specify the number of probes.

  6. Set the probe count and probe interval.

  7. Specify the type of probe.

    Note:

    If you do not specify the probe type the default ICMP probes are sent.

  8. Set the test interval.

Results

From configuration mode, confirm your configuration by entering the run show services rpm command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying RPM Probes for BGP Monitoring

Purpose

Confirm that the configuration is working properly.

Verify that the RPM probes for BGP monitoring is configured.

Action

From operational mode, enter the show services rpm command.

Release History Table
Release
Description
18.4R1
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.