Even with a qualified next-hop? http://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/qualified-next-hop-edit-routing-options.html
On Fri, Aug 29, 2014 at 03:03:07PM +0200, Mattias Gyllenvarg wrote: > 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 <matt...@gyllenvarg.se> > 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 <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; > >>>> >>>>>>> } > >>>> >>>>>>> } > >>>> >>>>>>> } > >>>> >>>>>>> } > >>>> >>>>>>> } > >>>> >>>>>>> > >>>> >>>>>>> ************************* _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp