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