Routing
Routing

Modifying routing table with ip-monitoring

‎08-24-2014 02:06 PM

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.

8 REPLIES 8
Routing

Re: Modifying routing table with ip-monitoring

‎08-24-2014 03:45 PM
Couldn't you instead run BFD on your default static route B?
Routing

Re: Modifying routing table with ip-monitoring

‎08-24-2014 04:26 PM

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

Routing

Re: Modifying routing table with ip-monitoring

[ Edited ]
‎08-25-2014 03:21 AM

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

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

http://forums.juniper.net/t5/Junos-Cup-2014/Tournament-1-Argentina-Challenge-amp-Solution-The-Reacti...

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

http://forums.juniper.net/t5/Day-One-Books/Day-One-Junos-Cup-2014/bc-p/250984

 

 

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.

 

 

 

 

 

Routing

Re: Modifying routing table with ip-monitoring

‎08-25-2014 12:25 PM

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.

[KUDOS PLEASE! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]
Routing
Solution
Accepted by topic author randomandy
‎08-26-2015 01:27 AM

Re: Modifying routing table with ip-monitoring

‎08-26-2014 09:01 PM

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 1.2.3.4;     # 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 4.5.6.7;  # 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 0.0.0.0/0 {
                    no-retain;  # Removes default route from static table with the next two settings.
                    no-install;
                    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

 

 

Routing

Re: Modifying routing table with ip-monitoring

‎01-07-2016 12:51 AM

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

Routing

Re: Modifying routing table with ip-monitoring

‎03-17-2017 08:28 AM

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 0.0.0.0/0 {
       discard;
       }
    }
   }
}

(...)

 

    term AcceptDefaultRoute_term {

        from {

            instance master;

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

            route-filter 0.0.0.0/0 exact;

            state active; 

        }

        then {

 

            accept;

        }

    }

 

Hope it will help someone.

 

Regards,

Pawel Mazurkiewicz

 

Routing

Re: Modifying routing table with ip-monitoring

‎08-05-2019 01:17 PM

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