TechLibrary

Table of Contents

Guide That Contains This Content

[+] Expand All

[-] Collapse All

Understanding Real-Time Performance Monitoring on EX Series 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 Ethernet 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 switches support the following tests and probe types:

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, then timers are generated at the software level and are less accurate than they would have been with hardware timestamps.

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

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: Hardware timestamps are supported on all EX Series switches.

Figure 1 shows the timestamps:

Figure 1: RPM Timestamps

T1 is the time the packet leaves the requester port.
T2 is the time the responder receives the packet.
T3 is the time the responder sends the response.
T4 is the time the requester receives the response.

The round-trip time is (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

Note: See Configuring the Interface for RPM Timestamping for Client/Server on an EX Series Switch (CLI Procedure) for information on how to configure hardware timestamps on the requester.

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 Switches

Two-Way Active Measurement Protocol (TWAMP) is not supported on EX Series switches.
EX Series 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.
- EX Series switches do not support hardware timestamps for HTTP and TCP probes.
- Timestamps apply only to IPv4 traffic.