View Only
last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Modifying routing table with ip-monitoring

    Posted 08-24-2014 14:07

    I am running BGP on an SRX-100. I have two active interfaces, "A" & "B".


    (A) To BGP Peer <--> SRX100 <--> (B) Static Default Route


    Interface B is normally the default route which is assigned statically.

    Interface A is dynamically routing via BGP and is advertising default route B and receiving other default route choices.


    What I would like to accomplish is to actively verify that B is passing traffic and if it fails, to

    1. Stop using B as the default route,
    2. Stop advertising B via BGP.

    I was able to find instructions for setting up an rpm to verify operation of B and use ip-monitoring policy to change a static route. The rpm seems to work fine*, but I am not clear what to use in the "then" clause of the ip-monitoring policy. The examples I found use "then preferred-route route w.x.y.z/n". But the alternate default route is not another static route on this SRX. If this default route fails, I want it simply removed and for BGP to find the new default route.


    The two options I see are either

    1. to set preferred-route a static default route out A, but then I am still advertising a default route that just points backwards. This seems messed up.
    2. To have ip-monitoring disable the interface. But if it disables the interface, how would rpm be able to notice if the link became available again in order to bring the interface back up? It seems to be a one way ticket.

    So I guess I am asking how to make a static route psedo-dynamic by making it modify the dynamic routing table. I hope I succeeded in explaining clearly. Thanks for any help. 


    * though it did require I include a next-hop even though the default route was in the routing table.


  • 2.  RE: Modifying routing table with ip-monitoring

    Posted 08-24-2014 15:46
    Couldn't you instead run BFD on your default static route B?

  • 3.  RE: Modifying routing table with ip-monitoring

    Posted 08-24-2014 16:26

    > Couldn't you instead run BFD on your default static route B?


    I only control one end of route B. I thought BFD required a service running at both ends.

  • 4.  RE: Modifying routing table with ip-monitoring

    Posted 08-25-2014 03:22

    I invite you to consult the Junos Cup Challenge: Argentina – The Reacting Probe.

    I believe you still can consult and run the topology here:

    You can also consult the official and alternative solutions for this challenge downloading the Day One book below:



    In this challenge you had to properly configure your router so that a failing RPM probe (ICMP ping) would apply local configuration changes.

    I believe you can apply a similar solution to achieve your goal. You will need to download the script probeReactor.slax and adapt it to suit your requirements (delete or create a static route). However as it is explained in the Day One Book there are alternative solutions that won't require to use that script.






  • 5.  RE: Modifying routing table with ip-monitoring

    Posted 08-05-2019 13:17

    Where do you download the probeReactor.slax script from?  Is it still available?

  • 6.  RE: Modifying routing table with ip-monitoring

    Posted 08-25-2014 12:26

    Sounds to me like you could use a few options to make it possible. Add the "active" option to the static route to B, so that if it becomes unavailable it is completely removed from the routing table. Then instead of just a simple policy to advertise that default static route into BGP, use the "generated route" to advertise into BGP, so only if it exists it would be advertised to BGP.

  • 7.  RE: Modifying routing table with ip-monitoring
    Best Answer

    Posted 08-26-2014 21:01

    I followed the clue from pantunes and read up on rpm probes which lead to a solution. There are three pieces to this solution.

    1. rpm probe: which pings my test address and responds with a pass or fail.
    2. ip-monitoring: which looks at the result of the rpm and applies a configuration change upon match.
    3. a groups entry to specify the configuration change to be applied when ip-monitoring detects failure.
    services {
        rpm {
            probe myprobe {
                test gw-ping {
                    target address;     # IP address to test by icmp ping
                    probe-count 3;
                    probe-interval 15;
                    test-interval 10;
                    thresholds {
                        successive-loss 3;
                        total-loss 3;
                    destination-interface fe-0/0/0.0;
                    next-hop;  # The docs said this was optional if routing table could already find target address, but that wasn't enough in my case and it didn't work until I added next-hop explicitly.
        ip-monitoring {                     
            policy my-test {
                match {
                    rpm-probe myprobe;
                then {
                    apply-groups Close_Default;
    groups {
        Close_Default {
            routing-options {
                static {
                    route {
                        no-retain;  # Removes default route from static table with the next two settings.
                        no-readvertise;  # Removes default route from peer advertisements.



    To observe the results of the test, use commands such as:

    show services rpm history-results

    show services ip-monitoring status



    To observe results of the actions, examine your routing table and advertisements.

    To see application of groups configuration changes you need to show inheritances from groups with

    show configuration | display inheritance



  • 8.  RE: Modifying routing table with ip-monitoring

    Posted 01-07-2016 00:52

    I tried your config. not working on vsrx. don't know why. I need to advertise higher metrics incase of rpm probe fails

  • 9.  RE: Modifying routing table with ip-monitoring

    Posted 03-17-2017 08:28

    I do not think it will work - as it is not possible to use no-retain and other modifiers in the context of ip-monitoring.

    Basically - this setup will not even commit.


    I have solved a simmilar problem with something like this:


    policy Failure {
       match {
             rpm-probe [ ... ];
       then {
        preferred-route {
           route {



        term AcceptDefaultRoute_term {

            from {

                instance master;

                preference 5; # "good" static route has this preference, route added by ip-mon has preference 1

                route-filter exact;

                state active; 


            then {






    Hope it will help someone.



    Pawel Mazurkiewicz