How to Interpret Real-time Performance Monitoring Tests in Junos

By Walter J. Goralski, Cathy Gadecki, Michael Bushong

Once you have configured and run a test in Junos Real-time Performance Monitoring (RPM), but you need to see and analyze the results of those tests.

To view the results of the RPM measurements, use the show services rpm probe-results command:

user@host> show services rpm probe-results
  Owner: app-server-network, Test: icmp-test
  Probe type: icmp-ping-timestamp
  Minimum Rtt: 312 usec, Maximum Rtt: 385 usec, Average Rtt: 331 usec,
  Jitter Rtt: 73 usec, Stddev Rtt: 27 usec
  Minimum egress time: 0 usec, Maximum egress time: 0 usec,
  Average egress time: 0 usec, Jitter egress time: 0 usec,
  Stddev egress time: 0 usec
  Minimum ingress time: 0 usec, Maximum ingress time: 0 usec,
  Average ingress time: 0 usec, Jitter ingress time: 0 usec,
  Stddev ingress time: 0 usec
  Probes sent: 15, Probes received: 15, Loss percentage: 0

The output can be a bit hard to parse, but focus on the following fields:

  • Owner, Test: This field tells you which RPM test is summarized below.

  • Probe type: Put simply, this field is what you configured as the probe type.

  • RTT: The RTT fields are the round-trip time measurements. You can see the minimum measurement, the maximum measurement, and the average measurement for the probes over the entire test — in this case, 15 probes.

  • Jitter: This is the variation in delay over time. The Jitter value lets you know how consistent the tests were. If one test took three seconds and the second test took 500 usecs, the jitter would be high, an indication that you might want to run the test again because some issues are affecting your network.

    Ideally, you want a small jitter and a small standard deviation, which means that all traffic more or less takes the same amount of time to traverse your network.

  • Loss percentage: Although you shouldn’t see it as non-zero very often, probes can be lost. If you’re seeing probe loss, you have an indication that your network is dropping packets somewhere; a firewall filter may be discarding them; or some device along the path is experiencing congestion. (Pings are generally first to get dropped in times of congestion.) Check into the problem accordingly.

In terms of what kinds of times you should be seeing, as a general rule, you probably want to see round-trip times on the order of 200 to 500 microseconds (usecs). Because these RPM probes are using ICMP ping packets, the times should really be the same as when you issue several pings to the remote destination.