Configuring Real-Time Performance Monitoring Probes
For both IP monitoring with route failover and IP monitoring with interface failover, the probes that are used to test the target device are real-time performance monitoring (RPM) probes that not only test the reachability of the IP address but also perform service-level monitoring on parameters such as jitter and latency.
Real-time performance monitoring 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 HTTP GET requests, Internet Control Message Protocol (ICMP) requests, TCP requests, and UDP requests, depending on the configuration.
You can 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 SRX Series device. By analyzing the transit times to and from the remote server, the device can determine network performance.
SRX Series gateways send out the following probe types:
HTTP GET request to a target URL
HTTP GET request for metadata from a target URL
ICMP echo request to a target IP address (the default)
ICMP timestamp request to a target address
UDP ping packets to a target device
UDP timestamp requests to a target IP address
TCP ping packets to a target device
The default probe is an ICMP echo request unless otherwise configured.
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.
Within a test, RPM probes are sent at regular intervals and 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 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.
To monitor multiple IP addresses, multiple tests can be defined for each probe, and the probe fails only if all tests fail. The system can perform a logical AND operation of all test results to determine the outcome of a probe.
Figure 1 shows the topology used in the following configuration example.
The following is an example configuration of an RPM probe that monitors three IP addresses:
set services rpm probe Probe-Payment-Server test paysvr target address 5.1.1.3 set services rpm probe Probe-Payment-Server test paysvr probe-count 5 set services rpm probe Probe-Payment-Server test paysvr probe-interval 5 set services rpm probe Probe-Payment-Server test paysvr test-interval 3 set services rpm probe Probe-Payment-Server test paysvr thresholds successive-loss 5 set services rpm probe Probe-Payment-Server test paysvr1 target address 5.1.1.2 set services rpm probe Probe-Payment-Server test paysvr1 probe-count 5 set services rpm probe Probe-Payment-Server test paysvr1 probe-interval 5 set services rpm probe Probe-Payment-Server test paysvr1 test-interval 3 set services rpm probe Probe-Payment-Server test paysvr1 thresholds successive-loss 5 set services rpm probe Probe-Payment-Server test paysvr2 target address 5.1.1.5 set services rpm probe Probe-Payment-Server test paysvr2 probe-count 5 set services rpm probe Probe-Payment-Server test paysvr2 probe-interval 5 set services rpm probe Probe-Payment-Server test paysvr2 test-interval 3 set services rpm probe Probe-Payment-Server test paysvr2 thresholds successive-loss 5
After the RPM probe configuration is committed, results of the probe can be displayed using the following command:
root# run show services rpm probe-results Owner: Probe-Payment-Server, Test: paysvr Target address: 5.1.1.3, Probe type: icmp-ping Destination interface name: fe-0/0/1.0 Test size: 5 probes Probe results: Request timed out, Tue Sep 20 02:22:28 2011 Results over current test: Probes sent: 1, Probes received: 0, Loss percentage: 100 Results over last test: Probes sent: 5, Probes received: 0, Loss percentage: 100 Results over all tests: Probes sent: 56, Probes received: 0, Loss percentage: 100 Owner: Probe-Payment-Server, Test: paysvr1 Target address: 5.1.1.2, Probe type: icmp-ping Destination interface name: fe-0/0/1.0 Test size: 5 probes Probe results: Response received, Tue Sep 20 02:22:27 2011, No hardware timestamps Rtt: 1742 usec Results over current test: Probes sent: 2, Probes received: 2, Loss percentage: 0 Measurement: Round trip time Samples: 2, Minimum: 1582 usec, Maximum: 1742 usec, Average: 1662 usec, Peak to peak: 160 usec, Stddev: 80 usec, Sum: 3324 usec Results over last test: Probes sent: 5, Probes received: 5, Loss percentage: 0 Test completed on Tue Sep 20 02:22:19 2011 Measurement: Round trip time Samples: 2, Minimum: 1582 usec, Maximum: 1742 usec, Average: 1662 usec, Peak to peak: 160 usec, Stddev: 80 usec, Sum: 3324 usec Results over last test: Probes sent: 5, Probes received: 5, Loss percentage: 0 Test completed on Tue Sep 20 02:22:19 2011 Measurement: Round trip time Samples: 5, Minimum: 1454 usec, Maximum: 1701 usec, Average: 1587 usec, Peak to peak: 247 usec, Stddev: 92 usec, Sum: 7935 usec Results over all tests: Probes sent: 67, Probes received: 67, Loss percentage: 0 Measurement: Round trip time Samples: 67, Minimum: 1427 usec, Maximum: 712721 usec, Average: 13074 usec, Peak to peak: 711294 usec, Stddev: 86142 usec, Sum: 875977 usec Owner: Probe-Payment-Server, Test: paysvr2 Target address: 5.1.1.5, Probe type: icmp-ping Destination interface name: fe-0/0/1.0 Test size: 5 probes Probe results: Request timed out, Tue Sep 20 02:22:28 2011 Results over current test: Probes sent: 1, Probes received: 0, Loss percentage: 100 Results over last test: Probes sent: 5, Probes received: 0, Loss percentage: 100 Results over all tests: Probes sent: 56, Probes received: 0, Loss percentage: 100
With the RPM probes, you can detect the reachability of the monitored IP address, and you can also measure network parameters and take an action if round-trip time (RTT) or jitter is greater than a configured value. The following command displays the parameters that can be measured:
root# set services rpm probe probetoremote test paysrvr thresholds ? Possible completions: <[Enter]> Execute this command + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups egress-time Maximum source to destination time per probe ingress-time Maximum destination to source time per probe jitter-egress Maximum source to destination jitter per test jitter-ingress Maximum destination to source jitter per test jitter-rtt Maximum jitter per test (0..60000000 microseconds) rtt Maximum round trip time per probe (microseconds) std-dev-egress Maximum source to destination standard deviation per test std-dev-ingress Maximum destination to source standard deviation per test std-dev-rtt Maximum standard deviation per test (microseconds) successive-loss Successive probe loss count indicating probe failure total-loss Total probe loss count indicating test failure (0..15) | Pipe through a command