Configuring IP Monitoring with Route Failover
Using IP monitoring with route failover, you can track an IP address or a set of IP addresses using a real-time performance monitoring (RPM) probe. If the RPM probe fails, you can inject a route into the routing table. After the RPM probe successfully reaches its target, the route is withdrawn from both the routing and forwarding tables.
Figure 1 shows the topology used in the configuration example and how IP monitoring works.
In the normal state of operation, the next-hop router to reach IP address 5.1.1.1 on the SRX Series gateway is 1.1.1.2. However, when the RPM probe to IP address 5.1.1.2 fails, you should use IP address 2.1.1.2 as the next hop.
To achieve this result, define an RPM probe to monitor IP address 5.1.1.2. Enter the following configuration:
set services rpm probe Probe-Payment-Server test paysvr target address 5.1.1.2 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 paysvr destination-interface fe-0/0/1.0 set services rpm probe Probe-Payment-Server test paysvr hardware-timestamp set services rpm probe Probe-Payment-Server test paysvr next-hop 1.1.1.2
Also configure the IP monitoring policy to add a preferred route when the RPM probe fails. Enter the following configuration:
set services ip-monitoring policy payment match rpm-probe Probe-Payment-Server set services ip-monitoring policy payment then preferred-route route 5.1.1.0/24 next-hop 2.1.1.2
In the steady state, you can reach IP address 5.1.1.1 through the device with the IP address 1.1.1.2, and the RPM probes are successful. To verify the operation of the steady state, use the following commands:
root# run traceroute 5.1.1.1 source 10.1.1.1 traceroute to 5.1.1.1 (5.1.1.1) from 10.1.1.1, 30 hops max, 40 byte packets 1 1.1.1.2 (1.1.1.2) 14.697 ms 2.953 ms 9.043 ms 2 5.1.1.1 (5.1.1.1) 9.916 ms 3.612 ms 4.085 ms
In the following show
command output, the PASS
results in the Status
field indicates that the probe
is successful:
root# run show services ip-monitoring status Policy - payment RPM Probes: Probe name Address Status ---------------------- ---------------- --------- Probe-Payment-Server 5.1.1.2 PASS Route-Action: route-instance route next-hop State ----------------- ----------------- ---------------- ------------- inet.0 5.1.1.0 2.1.1.2 NOT-APPLIED
In the following show
command output, the Probes
sent
count and Probes received
count are equal and
the Loss percentage
is 0
. This indicates that
the probe is successful.
root# run show services rpm probe-results Owner: Probe-Payment-Server, Test: paysvr 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 06:18:00 2011, No hardware timestamps Rtt: 1776 usec Results over current test: Probes sent: 5, Probes received: 5, Loss percentage: 0 Measurement: Round trip time Samples: 5, Minimum: 1490 usec, Maximum: 7399 usec, Average: 2952 usec, Peak to peak: 5909 usec, Stddev: 2235 usec, Sum: 14758 usec Results over last test: Probes sent: 5, Probes received: 5, Loss percentage: 0 Test completed on Tue Sep 20 06:18:00 2011 Measurement: Round trip time Samples: 5, Minimum: 1490 usec, Maximum: 7399 usec, Average: 2952 usec, Peak to peak: 5909 usec, Stddev: 2235 usec, Sum: 14758 usec Results over all tests: Probes sent: 45, Probes received: 45, Loss percentage: 0 Measurement: Round trip time Samples: 45, Minimum: 1490 usec, Maximum: 93350 usec, Average: 4766 usec, Peak to peak: 91860 usec, Stddev: 13517 usec, Sum: 214456 usec
When IP address 5.1.1.2 is unreachable, the RPM probes fail,
and the route specified in the IP monitoring configuration is pushed
to the routing table. The route pushed has a preference of one (1),
which has a higher preference than any static route or route learned
through a routing protocol. The server with the IP address of 5.1.1.1
is now reachable through the device with the IP address of 2.1.1.2
. To verify the operation of the fail state, use the following commands:
root# run show services ip-monitoring status Policy - test-remote-server RPM Probes: Probe name Address Status ---------------------- ---------------- --------- Probe-Payment-Server 5.1.1.2 FAIL Route-Action: route-instance route next-hop State ----------------- ----------------- ---------------- ------------- inet.0 5.1.1.0 2.1.1.2 APPLIED
In the following show
command output, to 2.1.1.2
via fe-0/0/2.0
indicates that the route has changed:
root# run show route 5.1.1.1 inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 5.1.1.0/24 *[Static/1] 00:00:18, metric2 0 > to 2.1.1.2 via fe-0/0/2.0 [Static/5] 00:01:38 > to 1.1.1.2 via fe-0/0/1.0
In the following show
command output, (2.1.1.2)
indicates that the route has changed from (1.1.1.2)
shown
in the steady state traceroute:
root# run traceroute 5.1.1.1 source 10.1.1.1 traceroute to 5.1.1.1 (5.1.1.1) from 10.1.1.1, 30 hops max, 40 byte packets 1 2.1.1.2 (2.1.1.2) 9.436 ms 9.457 ms 9.011 ms 2 5.1.1.1 (5.1.1.1) 3.671 ms 3.553 ms 4.036 ms
When IP address 5.1.1.2 is again reachable, the RPM probe successfully reaches its target, and the route that was added in the routing table is withdrawn.
To verify the operation of the restored steady state, use the following commands and verify that the results are similar to the steady-state results previously described:
root# run show services rpm probe-results Owner: Probe-Payment-Server, Test: paysvr 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 08:00:02 2011, No hardware timestamps Rtt: 1410 usec Results over current test: Probes sent: 3, Probes received: 3, Loss percentage: 0 Measurement: Round trip time Samples: 3, Minimum: 1410 usec, Maximum: 1769 usec, Average: 1596 usec, Peak to peak: 359 usec, Stddev: 147 usec, Sum: 4788 usec Results over last test: Probes sent: 5, Probes received: 5, Loss percentage: 0 Test completed on Tue Sep 20 07:59:49 2011 Measurement: Round trip time Samples: 5, Minimum: 1509 usec, Maximum: 3057 usec, Average: 1922 usec, Peak to peak: 1548 usec, Stddev: 579 usec, Sum: 9612 usec Results over all tests: Probes sent: 143, Probes received: 25, Loss percentage: 82 Measurement: Round trip time Samples: 25, Minimum: 1410 usec, Maximum: 8086 usec, Average: 2973 usec, Peak to peak: 6676 usec, Stddev: 2337 usec, Sum: 74333 usec
root# run show route 5.1.1.1 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 5.1.1.0/24 *[Static/5] 00:13:18 > to 1.1.1.2 via fe-0/0/1.0
root# run show services ip-monitoring status Policy - test-remote-server RPM Probes: Probe name Address Status ---------------------- ---------------- --------- Probe-Payment-Server 5.1.1.2 PASS Route-Action: route-instance route next-hop State ----------------- ----------------- ---------------- ------------- inet.0 5.1.1.0 2.1.1.2 NOT-APPLIED
root# run traceroute 5.1.1.1 source 10.1.1.1 traceroute to 5.1.1.1 (5.1.1.1) from 10.1.1.1, 30 hops max, 40 byte packets 1 1.1.1.2 (1.1.1.2) 9.590 ms 9.968 ms 15.589 ms 2 5.1.1.1 (5.1.1.1) 9.175 ms 3.914 ms 3.750 ms
It is important to note that in the RPM configuration, you specify the next-hop value. This guarantees that all of the probes (even after the failover) take the same route to reach the tracked IP address.
Without the next-hop value, it is possible that after the new
route is injected (when the RPM probe fails), there might be a new
route to reach the tracked IP address. It is also possible that if
the system chooses this new route, an upstream router might not have
a route to the tracked IP address, the probes might always fail, and
the system might never fail back. Hence, it is always a best practice
to include the next-hop
statement in the configuration.