Rather than making configuration changes, if you're running recent code (12.1) on branch SRX, have a look at the preferred-route option in ip-monitoring.
You can override your default route dynamically based on the RPM failing, without having to override config. The day this is feature (and ip-monitoring in general) is merged back down to mainline Junos will be a glorious one... Cheers, Ben On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg <matt...@gyllenvarg.se> wrote: > I have looked over these and they are the basis of the configuration I am > using. > > The setup is advanced in some senses. > > The Primary link is a to an IP-VPN running BGP to the "mpls cloud" of a > global operator. > So, from there I get a default that I override with a static OR dynamic > default to a local Internet connection that also serves as backup via IPsec > (BGP on top of that too but peers with a HUB node and not the "cloud"). > > As the local internet is just a cheap line, I do not have the luxury of BGP > and so must use some other metod like this one. > > What I would have want is to have the ip-monitor not actually disable the > interface and just set the admin-distance for it to the worst level. > > That way the test would still work as it requests the packet be sent by the > exact interface, but no other traffic would take this route unless all > other options are down. > > //Mattias > > > > On Thu, Aug 28, 2014 at 10:50 AM, Darren O'Connor <darre...@outlook.com> > wrote: > >> A small topology diagram would help so we could figure out exactly what >> this interface points to. Not sure if its in the path or not. If it is, >> then the below comments already state what the problem is. >> >> Thanks >> Darren >> http://www.mellowd.co.uk/ccie >> >> >> >>> Date: Wed, 27 Aug 2014 17:52:02 -0700 >>> From: gonna...@gmail.com >>> To: juniper-nsp@puck.nether.net >>> Subject: Re: [j-nsp] rpm / ip-monitoring >>> >>> Instead of disabling the interface, can you just alter routing to avoid >>> that path, but RPM could still test since that interface would still be >> up? >>> >>> -Mike Gonnason >>> >>> >>> On Wed, Aug 27, 2014 at 5:37 PM, Tyler Christiansen <ty...@adap.tv> >> wrote: >>> >>>> Good point. I glossed over that a bit. >>>> >>>> In that case, you won't even be able to test if it's working or not as >> you >>>> have disabled it (as Andrew points out). I suppose you could write a >>>> script that re-enables the interface every hour or twenty four hours or >>>> whatever interval, then the RPM probe would just shut it back down if >> it's >>>> not fixing, but that seems a bit of a hassle. >>>> >>>> --tc >>>> >>>> >>>> On Wed, Aug 27, 2014 at 4:35 PM, Andrew Jones <a...@jonesy.com.au> >> wrote: >>>> >>>>> Surely the test will never recover without intervention, as the >> interface >>>>> it uses gets disabled? >>>>> >>>>> >>>>> On 28.08.2014 02:28, Tyler Christiansen wrote: >>>>> >>>>>> I could be mistaken, but I believe it automatically reverts when the >>>> test >>>>>> is successful unless you specify no-preempt. >>>>>> >>>>>> >>>>>> On Wed, Aug 27, 2014 at 12:50 AM, Mattias Gyllenvarg < >>>>>> matt...@gyllenvarg.se> >>>>>> wrote: >>>>>> >>>>>> Dear List >>>>>>> >>>>>>> I have a rpm /ip-monitor setup that is supposed to test the >> function >>>> of a >>>>>>> local internet line (ping internet destination). >>>>>>> >>>>>>> And disable it if it is not responding. >>>>>>> >>>>>>> This works fine BUT, how do I get it to re-enable when it is >> working >>>>>>> again. >>>>>>> >>>>>>> I need this to work with DHCP so I cannot work with a default >> route. >>>>>>> >>>>>>> >>>>>>> ********************** >>>>>>> >>>>>>> services { >>>>>>> rpm { >>>>>>> probe Internet { >>>>>>> test PING-GOOGLE-DNS { >>>>>>> target address 8.8.8.8; >>>>>>> probe-count 5; >>>>>>> probe-interval 2; >>>>>>> test-interval 20; >>>>>>> thresholds { >>>>>>> total-loss 4; >>>>>>> } >>>>>>> destination-interface fe-0/0/3.0; >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> ip-monitoring { >>>>>>> policy Local-Internet-Test { >>>>>>> match { >>>>>>> rpm-probe Internet; >>>>>>> } >>>>>>> then { >>>>>>> interface fe-0/0/3 { >>>>>>> disable; >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> ************************* >>>>>>> >>>>>>> -- >>>>>>> *Med Vänliga Hälsningar / Best Regards* >>>>>>> *Mattias Gyllenvarg* >>>>>>> _______________________________________________ >>>>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>>>> >>>>>> _______________________________________________ >>>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>>> >>>>> >>>>> _______________________________________________ >>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Tyler Christiansen | Technical Operations* >>>> tyler <http://adap.tv/>@adap.tv <http://adap.tv/> | www.adap.tv >>>> *m :* 864.346.4095 >>>> _______________________________________________ >>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >>> _______________________________________________ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > > > -- > *Med Vänliga Hälsningar / Best Regards* > *Mattias Gyllenvarg* > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp