Re: [j-nsp] rpm / ip-monitoring
how. > > >> > > >> Regards > > >> Mattias > > >> > > >> > > >> > > >> On Fri, Aug 29, 2014 at 12:59 PM, Ben Dale > 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 > 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 > > &g
Re: [j-nsp] rpm / ip-monitoring
gt; >>> > >>> 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 > >>> 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 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 > >>>> 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 > >>>
Re: [j-nsp] rpm / ip-monitoring
gt;> Ben >>> >>> On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg >>> 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 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 >>>> 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 >>>> >> 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 >>>
Re: [j-nsp] rpm / ip-monitoring
>> 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 >>> 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 >>> >> 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 >>> >> 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...@
Re: [j-nsp] rpm / ip-monitoring
rface 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
> mailto: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<mailto:gonna...@gmail.com>
>>> To: juniper-nsp@puck.nether.net<mailto: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
>>> mailto: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
>>>> mailto: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<mailto: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;
>>>>>>>
Re: [j-nsp] rpm / ip-monitoring
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 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 > 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 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 >> 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 > > >> > wrote: >> > >> >> A small topology diagr
Re: [j-nsp] rpm / ip-monitoring
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 mailto: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 mailto: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 mailto: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 > mailto: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<mailto:gonna...@gmail.com> >>> To: juniper-nsp@puck.nether.net<mailto: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 >>> mailto:ty...@adap.tv>> >> wrote: >>> >>>> Good point. I glossed over that a bit. >>>> >>>> In that case, you won't even be able
Re: [j-nsp] rpm / ip-monitoring
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 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 > 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 > > 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 > >> 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 > >> 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 > >>>>>
Re: [j-nsp] rpm / ip-monitoring
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 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
> 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
>> 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
>> 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 addre
Re: [j-nsp] rpm / ip-monitoring
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
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
> 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
> 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;
> > > >>>
Re: [j-nsp] rpm / ip-monitoring
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 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 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;
> > >>> }
> > >>> }
> > >>> }
> > >>> }
> > >>> }
> > >>>
> > >>> *
> > >>>
> > >>> --
> > >>> *Med Vänliga Hälsningar / Best Regards*
> > >>> *Mattias Gyllenvarg*
> > >>> ___
> > >>> juniper-nsp mailing list juniper-nsp@puck.nether.net
> > >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >>>
> > >> ___
> > >> juniper-nsp mailing list juniper-nsp@puck.nether.net
> > >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >>
> > >
> > > ___
> > > juniper-nsp mailing list juniper-nsp@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@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
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 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 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;
> >>> }
> >>> }
> >>> }
> >>> }
> >>> }
> >>>
> >>> *
> >>>
> >>> --
> >>> *Med Vänliga Hälsningar / Best Regards*
> >>> *Mattias Gyllenvarg*
> >>> ___
> >>> juniper-nsp mailing list juniper-nsp@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>>
> >> ___
> >> juniper-nsp mailing list juniper-nsp@puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
>
> --
>
> *Tyler Christiansen | Technical Operations*
> tyler
Re: [j-nsp] rpm / ip-monitoring
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 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;
>>> }
>>> }
>>> }
>>> }
>>> }
>>>
>>> *
>>>
>>> --
>>> *Med Vänliga Hälsningar / Best Regards*
>>> *Mattias Gyllenvarg*
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
*Tyler Christiansen | Technical Operations*
tyler
Re: [j-nsp] rpm / ip-monitoring
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
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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] rpm / ip-monitoring
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
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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] rpm / ip-monitoring
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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
