[j-nsp] rpm / ip-monitoring
Sergei Udovenko
udovenko at gmail.com
Sun Aug 31 03:14:08 EDT 2014
Hey,
Did you try evet-options?
*Master at MX80-LAB# show event-options *
policy disable-on-ping-failure {
events ping_test_failed;
within 120 {
trigger on 1;
}
attributes-match {
ping_test_failed.test-owner matches icmp-ping-probe;
ping_test_failed.test-name matches ping-probe-test;
}
then {
change-configuration {
retry count 5 interval 4;
commands {
"set interfaces xe-0/0/0 disable";
}
user-name Master;
commit-options {
log "updating configuration from event policy
disable-on-ping-failure";
}
}
}
}
policy enable-on-ping-ok {
events ping_test_completed;
within 120 {
trigger on 1;
}
attributes-match {
ping_test_completed.test-owner matches icmp-ping-probe;
ping_test_completed.test-name matches ping-probe-test;
}
then {
change-configuration {
commands {
"delete interfaces xe-0/0/0 disable";
}
user-name Master;
commit-options {
log "RPM OK, enable xe-0/0/0";
}
}
}
}
!
probe icmp-ping-probe {
test ping-probe-test {
probe-type icmp-ping;
target address 8.8.8.8;
probe-count 2;
test-interval 20;
thresholds {
successive-loss 1;
}
}
}
--------------------
Best regards,
Sergei Udovenko
On Fri, Aug 29, 2014 at 4:07 PM, Chuck Anderson <cra at wpi.edu> wrote:
> 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;
> > >>>> >>>>>>> }
> > >>>> >>>>>>> }
> > >>>> >>>>>>> }
> > >>>> >>>>>>> }
> > >>>> >>>>>>> }
> > >>>> >>>>>>>
> > >>>> >>>>>>> *************************
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list