Automatic switching route in Juniper SRX

A small tutorial on how to automate the switching of the network route in case of problems with one of the links. Then I ask under the cat







Legend - there are two sites connected via L2 transport through two different providers. It is necessary to provide connectivity between networks through ISP1 (primary route). In case of problems with ISP1, automatically switch to ISP2.

Devices - Juniper SRX.



For the simplest implementation of this task, it is sufficient on FW1 to register a static route to the network 192.168.2.0 through 10.0.0.2 with a smaller metric and through 10.0.0.6 with a larger one. On the FW2 the opposite. But this method will work only when the interface is dropped towards one of the providers, which in practice is very rare, so you need to monitor the channel status in another way.

')

For this Juniper has an RPM (Real-Time Performance Monitoring) service . Here I also want to tell about its use in this scenario.



On FW1, we have the usual static entry (on FW2 mirrored after 10.0.0.1):

set routing-options static route 192.168.2.0/24 next-hop 10.0.0.2 

In the routing table we see this entry:

 show route 192.168.2.0/24 192.168.2.0/24 *[Static/5] 1d 07:20:14 > to 10.0.0.2 via reth1.1 

We configure the RPM service to control the primary connection. We send a ping to the address 10.0.0.2 for 10 pieces per test with an interval of 5 seconds (probe-interval 5). The interval between tests is also 5 seconds, i.e. we actually have a continuous ping every 5 seconds. If during the test we lost 5 pings in a row, the test is considered failed.

 set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 target address 10.0.0.2 set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 probe-count 10 set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 probe-interval 5 set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 test-interval 5 set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 thresholds successive-loss 5 

We adjust reaction to the test. In case test fails, add route via ISP2

 set services ip-monitoring policy LAN2_FAILOVER match rpm-probe SLA_LAN2 set services ip-monitoring policy LAN2_FAILOVER then preferred-route route 192.168.2.0/24 next-hop 10.0.0.6 

Checking:

 show services ip-monitoring status Policy - LAN2_FAILOVER (Status: PASS) RPM Probes: Probe name Test Name Address Status ------------------ --------------- ---------- --------- SLA_LAN2 CHECK_PRIMARY_FW2 10.0.0.2 PASS Route-Action: route-instance route next-hop state ----------------- ----------------- ---------------- ------------- inet.0 192.168.2.0/24 10.0.0.6 NOT-APPLIED 

On FW2, you need to configure the mirror configuration:

 set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 target address 10.0.0.1 set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 probe-count 10 set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 probe-interval 5 set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 test-interval 5 set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 thresholds successive-loss 5 set services ip-monitoring policy LAN1_FAILOVER match rpm-probe SLA_LAN1 set services ip-monitoring policy LAN1_FAILOVER then preferred-route route 192.168.1.0/24 next-hop 10.0.0.5 

You can test, disable one of the interfaces (vlan from trunk to FW), so that the link physically remains alive. We lose about 6 pings from LAN1 to LAN2, after about 30 seconds. We see the following on FW1:

 show services ip-monitoring status Policy - LAN2_FAILOVER (Status: FAIL) RPM Probes: Probe name Test Name Address Status ------------------ --------------- ---------- --------- SLA_LAN2 CHECK_PRIMARY_FW2 10.0.0.2 FAIL Route-Action: route-instance route next-hop state ----------------- ----------------- ---------------- ------------- inet.0 192.168.2.0/24 10.0.0.6 APPLIED 

In the routing table we see a new entry:

 192.168.2.0/24 *[Static/1] 00:01:24, metric2 0 > to 10.0.0.6 via reth1.2 [Static/5] 1d 07:30:26 > to 10.0.0.2 via reth1.1 

When the connection is restored via ISP1, the test goes back to the PASS state and removes the entry from the routing table.



I draw your attention to the fact that the configuration should be a mirror for both devices.

If there are several static routes, you can add them with new lines then. There may also be several conditions; this is quite a flexible method.



Thank you all, I hope it will save someone time.