[j-nsp] rpm / ip-monitoring
Mattias Gyllenvarg
mattias at gyllenvarg.se
Fri Aug 29 08:46:55 EDT 2014
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*
More information about the juniper-nsp
mailing list