[j-nsp] rpm / ip-monitoring
Chuck Anderson
cra at WPI.EDU
Fri Aug 29 09:07:37 EDT 2014
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 <mattias at 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 <bdale at 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 <mattias at 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 <bdale at 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 <mattias at 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 <bdale at 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 <mattias at 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 <
> >>>> darrenoc at 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: gonnason at gmail.com
> >>>> >>> To: juniper-nsp at 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 <tyler at 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 <aj at 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 <
> >>>> >>>>>> mattias at 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;
> >>>> >>>>>>> }
> >>>> >>>>>>> }
> >>>> >>>>>>> }
> >>>> >>>>>>> }
> >>>> >>>>>>> }
> >>>> >>>>>>>
> >>>> >>>>>>> *************************
More information about the juniper-nsp
mailing list