[j-nsp] rpm / ip-monitoring

[Mattias Gyllenvarg]

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;
> > > >>>                 }
> > > >>>             }
> > > >>>         }
> > > >>>     }
> > > >>> }
> > > >>>
> > > >>> *************************
> > > >>>
> > > >>> --
> > > >>> *Med Vänliga Hälsningar / Best Regards*
> > > >>> *Mattias Gyllenvarg*
> > > >>> _______________________________________________
> > > >>> juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> > > >>>
> > > >> _______________________________________________
> > > >> juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> > > >>
> > > >
> > > > _______________________________________________
> > > > juniper-nsp mailing list juniper-nsp at 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 at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
*Med Vänliga Hälsningar / Best Regards*
*Mattias Gyllenvarg*