Ben, The BGP selects native over IPsec via local-pref (just a note in this context).
That may work. I will try to describe your idea in my own words. Add a lurking static default to the MPLS-VPN, put it on steroids when ip-monitor fails? Sounds workable and not to ugly eighter. Will look intt this. //Mattias On Fri, Aug 29, 2014 at 2:05 PM, Ben Dale <bd...@comlinx.com.au> wrote: > 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 <matt...@gyllenvarg.se> > 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 <bd...@comlinx.com.au> 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 next-hop at-1/0/0.0 >> set routing-options static route 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 next-hop at-1/0/0.0 >> set services ip-monitoring policy Local-Internet-Test then >> preferred-route route 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 *[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 <matt...@gyllenvarg.se> >> 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 <bd...@comlinx.com.au> 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 <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 >>> >> >> >> >> -- >> *Med Vänliga Hälsningar / Best Regards* >> *Mattias Gyllenvarg* >> >> >> > > > -- > *Med Vänliga Hälsningar / Best Regards* > *Mattias Gyllenvarg* > > > -- *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