Typical, looks like it will work fine with a DHCP but not a static as I can not have 2 defaults with different pref.
I can probably make that work but a solution that works on both would be preferred. :P Anyway, thank you for pointing this out. //Mattias On Fri, Aug 29, 2014 at 2:46 PM, Mattias Gyllenvarg <[email protected]> wrote: > 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 <[email protected]> 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 <[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]> 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 <[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]> 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]> >>>> 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]> >>>> > 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] >>>> >>> To: [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]> >>>> >> 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]> >>>> >> 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]> >>>> >>>>>> 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] >>>> >>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >>>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> juniper-nsp mailing list [email protected] >>>> >>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >>>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> juniper-nsp mailing list [email protected] >>>> >>>>> 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 [email protected] >>>> >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >>>> >>>> >>> _______________________________________________ >>>> >>> juniper-nsp mailing list [email protected] >>>> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >> >>>> >> _______________________________________________ >>>> >> juniper-nsp mailing list [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] >>>> > https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >>>> >>>> _______________________________________________ >>>> juniper-nsp mailing list [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* >> >> >> > > > -- > *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
