[j-nsp] rpm / ip-monitoring
Mattias Gyllenvarg
mattias at gyllenvarg.se
Fri Aug 29 09:03:07 EDT 2014
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;
>>>> >>>>>>> }
>>>> >>>>>>> }
>>>> >>>>>>> }
>>>> >>>>>>> }
>>>> >>>>>>> }
>>>> >>>>>>>
>>>> >>>>>>> *************************
>>>> >>>>>>>
>>>> >>>>>>> --
>>>> >>>>>>> *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*
>>>> > _______________________________________________
>>>> > 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*
>>>
>>>
>>>
>>
>>
>> --
>> *Med Vänliga Hälsningar / Best Regards*
>> *Mattias Gyllenvarg*
>>
>>
>>
>
>
> --
> *Med Vänliga Hälsningar / Best Regards*
> *Mattias Gyllenvarg*
>
--
*Med Vänliga Hälsningar / Best Regards*
*Mattias Gyllenvarg*
More information about the juniper-nsp
mailing list