Okay, I'm still sure this can be made to work ; ) I'm still a little hazy on your setup though - based on your email: You have a local line which gets an address via DHCP and a default gateway with a preference of 12 You then also receive another default via BGP over an IPSEC tunnel over this same local line interface with a preference of 170 You then have an MPLS service/Native VPN which receives another BGP-sourced default route, presumably also with a preference of 170
If that is the case, configure a static with high preference (>170) pointing to your MPLS service/Native VPN, and override this with the lower preference route via your ip-monitoring policy on local-line/Internet failure - it should still work exactly as described, unless I'm missing something else? Ben On 29 Aug 2014, at 7:42 pm, Mattias Gyllenvarg <[email protected]<mailto:[email protected]>> wrote: Ben Close but no cigar. The IPsec also receives a default via BGP so that works like a charm. No need for interface routing. The thing is that we use the local line for Internet use, so the primary default route goes out that way. The IPsec is there if the Native VPN line fails. So, what I want this ip-monitor/rpm to do is fail over the local internet to the Native VPN in case the local line is broken some how. Regards Mattias On Fri, Aug 29, 2014 at 12:59 PM, Ben Dale <[email protected]<mailto:[email protected]>> wrote: Hi Mattias, It is still possible to bend it to your will ; ) I may be misunderstanding your topology, but essentially you have a Primary link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back to your head office. Are you trying to move the default route to your IPSEC tunnel interface, or the underlying "cheap line"? You could try the following: Set up a static default with a high metric (so that it will lose to both DHCP and BGP) via your IPSEC tunnel/underlying link. If the underlying link is not point-to-point (eg: you will need to know the far-side IP), you can point it down your IPSEC tunnel, or anywhere else - it should never actually get used): set routing-options static route 0.0.0.0/0<http://0.0.0.0/0> next-hop at-1/0/0.0 set routing-options static route 0.0.0.0/0<http://0.0.0.0/0> preference 190 Then in your ip-monitoring policy, you can override this dummy route with a better metric than both BGP and DHCP: set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0<http://0.0.0.0/0> next-hop at-1/0/0.0 set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0<http://0.0.0.0/0> preferred-metric 1 Now when your test fails (even if BGP does not): inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0<http://0.0.0.0/0> *[Static/1] 00:13:15, metric2 0 > via at-1/0/0.0 [Access-Internal/12] 00:21:45 > to 192.168.1.2 via at-1/0/0.0 [BGP/170] 2d 21:51:10, localpref 100 AS path: 65500 I, validation-state: unverified > to 172.30.3.2 via ge-0/0/3.0 Cheers, Ben On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg <[email protected]<mailto:[email protected]>> wrote: Even is the default routes are both from dynamic protocols (BGP and DHCP). For a regular static this is perfect. No such luck in this sollution. //Mattias On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> > 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: [email protected]<mailto:[email protected]> >>> To: [email protected]<mailto:[email protected]> >>> 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 >>> <[email protected]<mailto:[email protected]>> >> 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 >>>> <[email protected]<mailto:[email protected]>> >> 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 < >>>>>> [email protected]<mailto:[email protected]>> >>>>>> 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 >>>>>>> [email protected]<mailto:[email protected]> >>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>>>> >>>>>> _______________________________________________ >>>>>> juniper-nsp mailing list >>>>>> [email protected]<mailto:[email protected]> >>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>>> >>>>> >>>>> _______________________________________________ >>>>> juniper-nsp mailing list >>>>> [email protected]<mailto:[email protected]> >>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Tyler Christiansen | Technical Operations* >>>> tyler <http://adap.tv/>@adap.tv<http://adap.tv/> <http://adap.tv/> | >>>> www.adap.tv<http://www.adap.tv/> >>>> *m :* 864.346.4095 >>>> _______________________________________________ >>>> juniper-nsp mailing list >>>> [email protected]<mailto:[email protected]> >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >>> _______________________________________________ >>> juniper-nsp mailing list >>> [email protected]<mailto:[email protected]> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> _______________________________________________ >> juniper-nsp mailing list >> [email protected]<mailto:[email protected]> >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > > > -- > *Med Vänliga Hälsningar / Best Regards* > *Mattias Gyllenvarg* > _______________________________________________ > juniper-nsp mailing list > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/juniper-nsp -- Med Vänliga Hälsningar / Best Regards Mattias Gyllenvarg -- Med Vänliga Hälsningar / Best Regards Mattias Gyllenvarg _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
