[j-nsp] SRX cluster and route failover

[Mark Menzies]

Hi Nick

That looks good but in this case its all in one master routing-instance.
There are no clever configs on this box as yet, simply static routes for
customer nets to be sent over the leased line reth and a default route on
the main WAN connection.

As we already have a static route set to the leased line reth its all good
and if the reth goes down, all customers will fail over to the default
route.

I have quickly tested KB25052 and this seems to do what I need in that
using the ip-monitoring policy,  we get a new static route for the customer
net added sending the traffic over the WAN.

I also now need to alert on the route failover, so will likely set a trap
for the srx100 "rmopd[1283]: PING_PROBE_FAILED" log and forward onto some
NMS server.

Is there a better way to do this?


On 18 February 2013 13:44, Nick Ryce <nick at fluency.net.uk> wrote:

>
> Hi Mark,
>
> Maybe something like
> http://kb.juniper.net/InfoCenter/index?page=content&id=KB22052&pmv=print
> is what you are looking for?
>
> Nick
>
>
>
>
>
> On 18/02/2013 13:34, "Mark Menzies" <mark at deimark.net> wrote:
>
> >Hi all
> >
> >I hope someone here can help.
> >
> >I have an SRX cluster with 3 reth interfaces, 2 for WAN and one for LAN.
> >
> >I want to have static routes used to send traffic over the primary WAN
> >reth
> >when the next hop is available and then fail over to the secondary WAN.
> >
> >We have some restraints here.
> >
> >*  We cannot use dynamic routing, the 3rd party devices we are connecting
> >to wont use dynamic routing, so we are left with static routes.
> >
> >*  We cannot use BFD as the 3rd party next hops are not managed by us, nor
> >can we get them to implement BFD
> >
> >*  We have multiple logical interfaces on the primary WAN reth and we dont
> >want to fail over the entire the reth, just the specific static route for
> >the specific customer that has failed.
> >
> >*  We have asked for pingable hosts from each customer from which we are
> >going to base our testing of the next hop.
> >
> >
> >I have looked at using event scripts and also ip-monitoring.  I am looking
> >for any guidance or experience in doing this for customers and any likely
> >gotchas or things to look out for.
> >
> >I have found KB25052 which does tend to imply that ip-moniting using RPMs
> >should do the deed and allow me to set a new route for a specific
> >destination so this seems to fit the bill and a quick test seems to
> >confirm
> >that.  However would I benefit from any junoscript stuff?
> >
> >Does anyone have any experiences or comments on above mechanisms?
> >
> >Thanks in advance
> >
> >
> >Mark
> >_______________________________________________
> >juniper-nsp mailing list juniper-nsp at puck.nether.net
> >https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>