Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

external-header-nav
keyboard_arrow_up
list Table of Contents
file_download PDF
keyboard_arrow_right

Configuring IP Monitoring with Route Failover

date_range 02-Aug-23

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.

Figure 1: Real-Time Performance Monitoring TopologyReal-Time Performance Monitoring Topology

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:

content_copy zoom_out_map
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:

content_copy zoom_out_map
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:

content_copy zoom_out_map
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:

content_copy zoom_out_map
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.

content_copy zoom_out_map
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:

content_copy zoom_out_map
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:

content_copy zoom_out_map
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:

content_copy zoom_out_map
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:

content_copy zoom_out_map
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
content_copy zoom_out_map
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
content_copy zoom_out_map
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
content_copy zoom_out_map
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.

external-footer-nav