Juniper SRX: Using RPM to monitor and change routes

I’ve been using the SRX series of Juniper for about 1 year now. I’ve always used the SSG series with pleasure and never had any doubts or issues with them, I often deploy dual wan solutions which need to be highly available or at least have some form of fail-over because my clients use VOIP or cloud services that rely on a stable internet connection.

In the old SSG series this was very straightforward – Set up Track-ip on the Interface and it will bring the interface down when several pings to IPs fail and reach your set threshold. In SRX series this gets a little more complicated. There are now 3 types of monitors, which all have extra subtypes;

  • HTTP Probes
  • ICMP(PING) Probes
  • TCP/UDP port connection Probes


Now there are some things to really pay attention to, When you set up RPM you add onto your static routing table with the one in the RPM configuration. That means if you have a route based VPN enabled you will need to add this route to your RPM configuration instead of the static route configuration as the routes in RPM will take precedence.

Time to dissect the simple ICMP RPM config given to us by Juniper:

Here we set up the basics. We create a a probe named "Example" and set a blank test on it with the name "Test-Name". We tell the RPM that 3 probes should be sent, with an probe interval of 15 seconds. that means 3 probes are sent 15 seconds between each other. The final is the Test-Interval, which tells the RPM service to wait 10 seconds between the tests. Quite simply put it means that it sends 1 probe every 15 seconds, and after 3 probes are reached it waits 10 seconds and starts again.

set services rpm probe example test test-name probe-count 3
set services rpm probe example test test-name probe-interval 15
set services rpm probe example test test-name test-interval 10

Next we tell the RPM service how many failures are allowed within this test. Seeing we’re sending 3 probes I only want to change the route when all 3 pings have failed

set services rpm probe example test test-name thresholds successive-loss 3
set services rpm probe example test test-name thresholds total-loss 3

After which we set the test-action to preform, in this case a simple ICMP ping to google DNS (Please note that in a production environment you should never ping a host that is not under your management). We are using external interace fe-0/0/0.0

set services rpm probe example test test-name target address
set services rpm probe example test test-name destination-interface fe-0/0/0.0
set services rpm probe example test test-name next-hop

And to finish it up we set the RPM, and the route to be used if the probes fail.

set services ip-monitoring policy test match rpm-probe example
set services ip-monitoring policy test then preferred-route route next-hop

Tada! Simple monitoring and fail-over achieved. 🙂 You can check the status via the web-interface or via the CLI using show services ip-monitoring status


  1. Tony Vichai July 29, 2016 at 12:53 pm

    Great read. Beautifully broken down. Question for you, does the route rollback to the previous 0/0 route once the probes are successful? Also is there a way to do this on an EX9200?

    1. TeGek August 11, 2016 at 8:16 pm

      The route returns to the default routing table the moment the probe has multiple successes. I haven’t had a chance to play with the EX9200, I know it works with any CPE that has RPM and Junos 🙂

  2. Johnny August 11, 2021 at 10:56 am

    Is there a delay UP timer equivalent in Juniper RPM? to avoid choppy links. In Cisco implementation of IP SLA they have both delay down and up timers. Thanks in advance for your answer!

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.