Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Real-Time Performance Monitoring

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

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.

Understanding Real-Time Performance Monitoring on Switches

Real-time performance monitoring (RPM) enables you to configure active probes to track and monitor traffic across the network and to investigate network problems. You can use RPM with Juniper Networks EX Series and QFX Series switches.

The ways in which you can use RPM include:

  • Monitor time delays between devices.

  • Monitor time delays at the protocol level.

  • Set thresholds to trigger SNMP traps when values are exceeded.

    You can configure thresholds for round-trip time, ingress or egress delay, standard deviation, jitter, successive lost probes, and total lost probes per test. (SNMP trap results are stored in pingResultsTable, jnxPingResultsTable, jnxPingProbeHistoryTable, and pingProbeHistoryTable.)

  • Determine automatically whether a path exists between a host router or switch and its configured BGP neighbors. You can view the results of the discovery using an SNMP client.

  • Use the history of the most recent 50 probes to analyze trends in your network and predict future needs.

RPM provides MIB support with extensions for RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations.

This topic includes:

RPM Packet Collection

Probes collect packets per destination and per application, including ping Internet Control Message Protocol (ICMP) packets, User Datagram Protocol and Transmission Control Protocol (UDP/TCP) packets with user-configured ports, user-configured Differentiated Services code point (DSCP) type-of-service (ToS) packets, and Hypertext Transfer Protocol (HTTP) packets.

Tests and Probe Types

A test can contain multiple probes. The probe type specifies the packet and protocol contents of the probe.

EX Series and QFX Series switches support the following tests and probe types:

Note:

QFX Series switches do not support hardware-timestamp probes.

  • Ping tests:

    • ICMP echo probe

    • ICMP timestamp probe

  • HTTP tests:

    • HTTP get probe (not available for BGP RPM services)

    • HTTP get metadata probe

  • UDP and TCP tests with user-configured ports:

    • UDP echo probe

    • TCP connection probe

    • UDP timestamp probe

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.

Note:

QFX Series switches do not support hardware timestamps.

Note:

On the EX4300 switch, RPM timestamping is performed in the software. The RPM probes at the requester and responder devices are timestamped in the Packet Forwarding Engine instead of the Junos OS process (rmpod) that runs on the Routing Engine. This timestamping method is referred to as pseudo-hardware timestamping.

Note:

EX Series switches support hardware timestamps for UDP and ICMP probes. EX Series switches do not support hardware timestamps for HTTP or TCP 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:

icmp-ping is the default probe type on devices running Junos OS.

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.

Note:

On the EX4300 switch, you must configure the switch as both the requester (the RPM client) and the responder (the RPM server) to timestamp the RPM packet.

Figure 1 shows the timestamps:

Figure 1: RPM TimestampsRPM 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 (T2 – T1) + (T4 – T3). If the responder does not support hardware timestamps, then the round-trip time is (T4 – T1) / 2, 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.

Note:

For correct one-way measurement, the clocks of the requester and responder must be synchronized. If the clocks are not synchronized, one-way jitter measurements and calculations can include significant variations, in some cases orders of magnitude greater than the round-trip times.

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

Limitations of RPM on EX Series and QFX Series Switches

  • Two-Way Active Measurement Protocol (TWAMP) is not supported on the switches.

  • The switches do not support user-configured class-of-service (CoS) classifiers or prioritization of RPM packets over regular data packets received on an input interface.

  • Timestamps:

    • If the responder does not support hardware timestamps, RPM can only report the round-trip measurements and cannot calculate round-trip jitter.

      Note:

      QFX Series switches do not support hardware timestamps.

    • EX Series switches do not support hardware timestamps or pseudo-hardware timestamps for HTTP and TCP probes.

    • Timestamps apply only to IPv4 traffic.

    • In-Service Software Upgrades (ISSU) and Nonstop Software Upgrades (NSSU) do not support pseudo-hardware timestamps.

RPM Support for VPN Routing and Forwarding

Real-time performance monitoring (RPM) is supported on all Juniper Network devices.

VRF in a Layer 3 VPN implementation allows multiple instances of a routing table to coexist within the same device at the same time. Because the routing instances are independent, the same or overlapping IPv4 or IPv6 addresses can be used without conflicting each other.

RPM ICMP and UDP probe with VPN routing and forwarding (VRF) has been improved. In previous releases, the RPM probes specified to a VRF table were not handled by the real-time forwarding process (FWDD-RT). In Junos OS Release 10.0, RPM probes specified to a VRF table are handled by the FWDD-RT, thereby providing more accurate results.

This feature supports RPM ICMP and UDP probes configured with routing instances of type VRF.

RPM Configuration Options

You can configure real-time performance monitoring (RPM) parameters. See Table 2 for a summary of the configuration options.

Table 2: RPM Configuration Summary

Field

Function

Your Action

Performance Probe Owners  

Owner Name (required)

Identifies an RPM owner for which one or more RPM tests are configured. In most implementations, the owner name identifies a network on which a set of tests is being run (a particular customer, for example).

Type the name of the RPM owner.

Identification  

Test name (required)

Uniquely identifies the RPM test

Type the name of the RPM test.

Target (Address or URL) (required)

IPv4 or IPv6 address or URL of probe target

Type the IPv4 address, in dotted decimal notation, IPv6 address, or the URL of the probe target. If the target is a URL, type a fully formed URL that includes http://.

Source Address

Explicitly configured IPv4 or IPv6 address to be used as the probe source address

Type the source address to be used for the probe. If the source address is not one of the device's assigned addresses, the packet uses the outgoing interface's address as its source.

Routing Instance

Particular routing instance over which the probe is sent

Type the routing instance name. The routing instance applies only to probes of type icmp , icmp6-ping, and icmp-timestamp. The default routing instance is inet.0.

History Size

Number of probe results saved in the probe history

Type a number between 0 and 255. The default history size is 50 probes.

Request Information  

Probe Type (required)

Specifies the type of probe to send as part of the test.

Select the desired probe type from the list:

  • http-get

  • http-get-metadata

  • icmp6-ping

  • icmp-ping

  • icmp-ping-timestamp

  • tcp-ping

  • udp-ping

Interval

Sets the wait time (in seconds) between each probe transmission

Type a number between 1 and 255 (seconds).

Test Interval (required)

Sets the wait time (in seconds) between tests.

Type a number between 0 and 86400 (seconds).

Probe Count

Sets the total number of probes to be sent for each test.

Type a number between 1 and 15.

Destination Port

Specifies the TCP or UDP port to which probes are sent.

To use TCP or UDP probes, you must configure the remote server as a probe receiver. Both the probe server and the remote server must be Juniper Networks devices configured to receive and transmit RPM probes on the same TCP or UDP port.

Type the number 7—a standard TCP or UDP port number—or a port number from 49152 through 65535.

DSCP Bits

Specifies the Differentiated Services code point (DSCP) bits. This value must be a valid 6–bit pattern. The default is 000000.

Type a valid 6–bit pattern.

Data Size

Specifies the size of the data portion of the ICMP probes.

Type a size (in bytes) between 0 and 65507.

Data Fill

Specifies the contents of the data portion of the ICMP probes.

Type a hexadecimal value between 1 and 800h to use as the contents of the ICMP probe data.

Hardware Timestamp

Enables timestamping of RPM probe messages. You can timestamp the following RPM probes to improve the measurement of latency or jitter:

  • ICMP ping

  • ICMP ping timestamp

  • UDP ping—destination port UDP-ECHO (port 7) only

  • UDP ping timestamp—destination port UDP-ECHO (port 7) only

To enable timestamping, select the check box.

Maximum Probe Thresholds  

Successive Lost Probes

Sets the total number of probes that must be lost successively to trigger a probe failure and generate a system log message.

Type a number between 0 and 15.

Lost Probes

Sets the total number of probes that must be lost to trigger a probe failure and generate a system log message.

Type a number between 0 and 15.

Round Trip Time

Sets the total round-trip time (in microseconds), from the device to the remote server, that triggers a probe failure and generates a system log message.

Type a number between 0 and 60,000,000 (microseconds).

Jitter

Sets the total jitter (in microseconds), for a test, that triggers a probe failure and generates a system log message.

Type a number between 0 and 60,000,000 (microseconds).

Standard Deviation

Sets the maximum allowable standard deviation (in microseconds) for a test, which, if exceeded, triggers a probe failure and generates a system log message.

Type a number between 0 and 60,000,000 (microseconds).

Egress Time

Sets the total one-way time (in microseconds), from the device to the remote server, that triggers a probe failure and generates a system log message.

Type a number between 0 and 60,000,000 (microseconds).

Ingress Time

Sets the total one-way time (in microseconds), from the remote server to the device, that triggers a probe failure and generates a system log message.

Type a number between 0 and 60,000,000 (microseconds)

Jitter Egress Time

Sets the total outbound-time jitter (in microseconds), for a test, that triggers a probe failure and generates a system log message.

Type a number between 0 and 60,000,000 (microseconds)

Jitter Ingress Time

Sets the total inbound-time jitter (in microseconds), for a test, that triggers a probe failure and generates a system log message.

Type a number between 0 and 60,000,000 (microseconds).

Egress Standard Deviation

Sets the maximum allowable standard deviation of outbound times (in microseconds) for a test, which, if exceeded, triggers a probe failure and generates a system log message.

Type a number between 0 and 60,000,000 (microseconds).

Ingress Standard Deviation

Sets the maximum allowable standard deviation of inbound times (in microseconds) for a test, which, if exceeded, triggers a probe failure and generates a system log message.

Type a number between 0 and 60,000,000 (microseconds).

Traps  

Egress Jitter Exceeded

Generates SNMP traps when the threshold for jitter in outbound time is exceeded.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Egress Standard Deviation Exceeded

Generates SNMP traps when the threshold for standard deviation in outbound times is exceeded.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Egress Time Exceeded

Generates SNMP traps when the threshold for maximum outbound time is exceeded.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Ingress Jitter Exceeded

Generates SNMP traps when the threshold for jitter in inbound time is exceeded.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Ingress Standard Deviation Exceeded

Generates SNMP traps when the threshold for standard deviation in inbound times is exceeded.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Ingress Time Exceeded

Generates traps when the threshold for maximum inbound time is exceeded.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Jitter Exceeded

Generates traps when the threshold for jitter in round-trip time is exceeded.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Probe Failure

Generates traps when the threshold for the number of successive lost probes is reached.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

RTT Exceeded

Generates traps when the threshold for maximum round-trip time is exceeded.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Standard Deviation Exceeded

Generates traps when the threshold for standard deviation in round-trip times is exceeded.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Test Completion

Generates traps when a test is completed.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Test Failure

Generates traps when the threshold for the total number of lost probes is reached.

  • To enable SNMP traps for this condition, select the check box.

  • To disable SNMP traps, clear the check box.

Performance Probe Server  

TCP Probe Server

Specifies the port on which the device is to receive and transmit TCP probes.

Type the number 7—a standard TCP or UDP port number—or a port number from 49160 through 65535.

UDP Probe Server

Specifies the port on which the device is to receive and transmit UDP probes.

Type the number 7—a standard TCP or UDP port number—or a port number from 49160 through 65535.

Note:

On SRX300, SRX320, SRX340, SRX1500 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.

Two-Way Active Measurement Protocol (TWAMP) Overview

SUMMARY Learn about Two-Way Active Measurement Protocol (TWAMP) to measure network performance between any two devices in a network.

Benefits of TWAMP

  • TWAMP configuration helps you activate, test, monitor, and troubleshoot your network end-to-end without using a dedicated testing device.

  • TWAMP-Test timestamps provide two-way or round-trip metrics with greater accuracy than other methods (processing delays can be factored as well).

  • TWAMP is often used to check service-level agreement (SLA) compliance, and the TWAMP feature is often used in that context.

  • Two-way measurements are better than one-way measurements because round-trip delays do not require host clock synchronization. This is possible because the reflector places its own sequence number in the packet.

Note:

We recommend that you do not configure the RPM client and a TWAMP server on the same device. This might cause some issues in the RPM probe results.

Understand Two-Way Active Measurement Protocol (TWAMP)

The Two-Way Active Measurement Protocol (TWAMP) is an open protocol for measuring network performance between any two devices in a network that supports the protocols in the TWAMP framework. It is a standard protocol framework that separates sessions based on the client/server architecture. The TWAMP client is a host that initiates the TCP connection and acts as a control-client and a session-sender, while the TWAMP server is a host that acknowledges the TCP connection and performs the roles of a server and a session-reflector. TWAMP-Control messages are exchanged between the control-client and the server and TWAMP-Test messages are exchanged between the session-sender and the session-reflector. Four different TWAMP devices can perform the four logical roles of TWAMP control-client, server, session-sender, and session-reflector.

The four elements are shown Figure 2.

Figure 2: Four Elements of TWAMPFour Elements of TWAMP

TWAMP consists of two interrelated protocols –TWAMP-Control and TWAMP-Test. TWAMP- Control is used to initiate, start, and stop test sessions, whereas TWAMP-Test is used to exchange test packets between two TWAMP entities.

  • TWAMP-Control —A TWAMP control connection is responsible for managing (initiating, starting, and ending) the test sessions between a TWAMP client and a TWAMP server for performance measurement.

    The remote operation process or daemon (rmopd) in the Junos OS Routing Engine takes care of the control plane operations that include handling both the client and server control message exchanges. The packet path processing for the control connection is the same as for any other control process. After the server-greeting, setup-response, and setup-start messages are successfully exchanged, the TWAMP client starts processing the session creation messages. One or more test sessions are created with the following tuples, that contain:

    • Destination IP (DIP) addresses of the client and server

    • Source IP (SIP) addresses of the client and server

    • UDP ports on the client and server

  • TWAMP-Test —A TWAMP test session exchanges probe packets to measure the performance metrics. Each test session between a client and server can use different QoS values –for example, round trip time (RTT), delay, and latency variations –to test QoS behavior on the network path for different packet priorities.

    The timestamps on the test probes on the sender side are just before the packet is sent out on the link. Similarly, timestamps on the test probes on the receiver (server) side are recorded as soon as the probe packets are received from the link. This prompt recording of timestamps helps to calculate fairly accurate RTT, delay, and jitter characteristics of the probes. The test probes can also be set to different QoS values to test the QoS behavior on the network path.

Implementation of TWAMP Elements

A common implementation of TWAMP elements combines the roles of control-client and session-sender in one device (known as the TWAMP controller or TWAMP client) and the roles of server and session-reflector in the other device (known as the TWAMP responder or TWAMP server). In this case, each device runs both the TWAMP-Control (between control-client and server) and TWAMP-Test (between session-sender and session-reflector) protocols.

Figure 3 illustrates the TWAMP elements, which are implemented as client and server.

Figure 3: The Elements of TWAMP Implemented as Client and ServerThe Elements of TWAMP Implemented as Client and Server

Limitations

SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100, and SRX4200 devices and vSRX instances have the following limitations for TWAMP support:

  • TWAMP for IPv6 is not supported.

  • TWAMP server and TWAMP client authentication are not supported.

Example: Configuring TWAMP Client and Server

This example shows how to configure the Two-Way Active Measurement Protocol (TWAMP) client and TWAMP server.

Requirements

This example uses the following hardware and software components:

  • SRX Series device.

  • Junos OS Release 18.1R1 and later releases.

Before you begin configuring TWAMP client and TWAMP server, ensure that you have read Two-Way Active Measurement Protocol (TWAMP) Overview to understand how this task fits into the overall configuration process.

Overview

The TWAMP is an open protocol for measuring network performance between any two devices in a network that supports the TWAMP protocol. The TWAMP consists of TWAMP-Control protocol and TWAMP-Test protocol. The TWAMP-Control protocol is used to initiate, start and stop the test sessions between the control client. The TWAMP-Test protocol used to exchange the test packets between the session sender and the session reflector.

Figure 4 shows the TWAMP architecture composed of the following entities that are responsible for starting a monitoring session and exchanging packets:

  • The control client initiates all requested test sessions with a start sessions message, and the TWAMP server acknowledges. When necessary, the control client sends a message to stop all test sessions.

  • The session sender and the session reflector exchange test packets according to the TWAMP-Test protocol for each active session. On receiving a TWAMP-Test packet, the session reflector reflects a measurement packet and does not collect any packet statistics in TWAMP.

Figure 4: Configuring TWAMP Client and TWAMP ServerConfiguring TWAMP Client and TWAMP Server

The TWAMP server is an end system that manages one or more TWAMP sessions and capable of configuring per-session ports. The TWAMP server listens to the TCP port. The session reflector and TWAMP server make up the TWAMP responder in an IP service-level agreement operation.

For Junos OS Release 18.1R1, both the control client and session sender resides on the same device. The client design does not mandate the TWAMP server and the session reflector to be on the same system. Hence, the Juniper TWAMP client is also capable of working with a third-party server implementation.

Configuration for TWAMP Client

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.

To configure the TWAMP Client:

  1. Configure the target address.

  2. Specify the name of the test-session and the target address.

  3. Specify the number of probes within a test.

  4. Set the family inet address.

  5. Configure zones.

Results

From the configuration mode of Router 1, confirm your configuration by entering the show services rpm twamp, show interfaces, and show security commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuration for TWAMP Server

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.

To configure the TWAMP Server:

  1. Configure the services and set the authentication mode for the TWAMP server.

  2. Specify the client-list name and the address.

  3. Configure the interface and the address.

  4. Configure zones.

Results

From the configuration mode of Router 1, confirm your configuration by entering the show services rpm twamp, show interfaces, and show security commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying TWAMP Client Sessions

Purpose

Verify that the TWAMP client sessions are established.

Action

From operational mode, enter the show services rpm twamp client session command.

Verifying TWAMP Server Sessions

Purpose

Verify that the TWAMP server sessions are established.

Action

From operational mode, enter the show services rpm twamp server session command.

Guidelines for Configuring RPM Probes for IPv6

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.

Configuring the Interface for RPM Timestamping for Client/Server on a Switch (CLI Procedure)

Use real-time performance monitoring (RPM) to configure active probes to track and monitor traffic across the network and to investigate network problems. To configure basic RPM probes on the EX Series or QFX Series switch, you must configure the probe owner, the test, and the specific parameters of the RPM probe.

You can also set a timestamp to improve the measurement of latency or jitter. The probe is timestamped by the device originating the probe (the RPM client). If you do not enable hardware timestamps, the timer values are set. You should configure both the RPM client (the requester) and the RPM server (the responder) to timestamp the RPM packets. However, if the RPM server does not support hardware timestamps, RPM can only report the round-trip measurements.

Note:

On the EX4300 switch, RPM timestamping is performed in the software. The RPM probes at the requester and responder devices are timestamped in the Packet Forwarding Engine instead of the Junos OS process (rmpod) that runs on the Routing Engine. This timestamping method is referred to as pseudo-hardware timestamping.

Note:

QFX Series switches do not support hardware timestamps.

Timestamps apply only to IPv4 traffic.

You can enable hardware timestamps for the following RPM probe types:

  • icmp-ping

  • icmp-ping-timestamp

  • udp-ping

  • udp-ping-timestamp

To configure RPM probes and to enable hardware timestamping:

  1. Specify the probe owner:
  2. Specify a test name. A test represents the range of probes over which the standard deviation, average, and jitter are calculated.
  3. Specify the packet and protocol contents of the probe:
  4. Specify the destination IPv4 address to be used for the probes:
  5. Specify the number of probes within a test:
  6. Specify the time, in seconds, to wait between sending packets:
  7. Specify the time, in seconds, to wait between tests:
  8. Specify the source IP address to be used for probes. If the source IP address is not one of the switch’s assigned addresses, the packet uses the outgoing interface’s address as its source.
  9. Specify the value of the Differentiated Services (DiffServ) field within the IP header. The DiffServ code point (DSCP) bits value must be set to a valid 6-bit pattern.
  10. If you are using ICMP probes, specify the size of the data portion of ICMP probes:
  11. Enable hardware timestamping of RPM probe messages:
    Note:

    QFX Series switches do not support hardware timestamps.

Directing RPM Probes to Select BGP Devices

If a device has a large number of BGP neighbors configured, you can direct (filter) the RPM probes to a selected group of BGP neighbors rather than to all the neighbors. To identify the BGP devices to receive RPM probes, you can configure routing instances.

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 direct RPM probes to select BGP neighbors:

  1. Configure routing instance RI1 to send RPM probes to BGP neighbors within the routing instance.
  2. If you are done configuring the device, enter commit from configuration mode.

IPv6 RPM Probes

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

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

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. See Example: Configuring Basic RPM Probes.

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 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

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 15 shows sample graphs for an RPM test.

Figure 5: Sample RPM GraphsSample RPM Graphs

In Figure 15, 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 3 summarizes key output fields in RPM displays.

Table 3: 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

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 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 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 configuration 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

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 configuration 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 configuration 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 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 configuration 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.