SRX Services Gateway
Reply
Contributor
aeroplane
Posts: 724
Registered: ‎06-30-2009
0
Accepted Solution

Redundancy Group Design Question

Hi Folks

 

I have two SRX-3600 cluster in ACTIVE/PASSIVE. I have TRUST-ZONE, DMZ-ZONE, UNTRUST-ZONE. In UNTRUST-ZONE, I have only one ISP.

 

My requirement is that if my ISP link is down then all interfaces should failover to secondary node becuase I do not want "Z" path through fabric-link BUT if interface in TRUST-ZONE or interface in DMZ-ZONE is down then only that interface failover to secondary node.

 

How many redundancy group should I need to create?

 

Thanks

 

 

Recognized Expert
JunOS_Fan
Posts: 241
Registered: ‎02-13-2012
0

Re: Redundancy Group Design Question

Hi ,

 

I think we just need two redundancy groups - RG0 and RG1. We can associate all TRUST-ZONE, DMZ-ZONE, UNTRUST-ZONE interfaces with same redundancy group (RG1)  and need to configure interface-monitoring only for untrust interface with a weight of 255 so that if your ISP link goes down  RG1 will failover to the other node.  As we did not configure interface-monitoring for other interfaces, if they fail , only that particular interface (reth) will failover to the other node.

 

for example,

 

{primary:node1}
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/3 weight 255

 

Best regards
Pradeep (JNCIP-SEC,ENT,SP)
www.networker.co.in
Contributor
aeroplane
Posts: 724
Registered: ‎06-30-2009
0

Re: Redundancy Group Design Question

Hi Pradeep

 

Thanks for the reply. But if we do not configure interface-monitor for other interfaces (TRUST, DMZ) how they can switch over to secondary node?

 

Thanks

Recognized Expert
JunOS_Fan
Posts: 241
Registered: ‎02-13-2012
0

Re: Redundancy Group Design Question

sorry i was wrong - If the member interface from the primary node(for that redundancy group) fails,and if there is no interface-monitoring enabled for that interface ,failover will NOT happen.

Best regards
Pradeep (JNCIP-SEC,ENT,SP)
www.networker.co.in
Contributor
aeroplane
Posts: 724
Registered: ‎06-30-2009
0

Re: Redundancy Group Design Question

So how do you think how to design this?

 

Thanks

Super Contributor
billp
Posts: 124
Registered: ‎05-01-2008

Re: Redundancy Group Design Question

The interfaces in a particular redundancy group will fail together or not at all. Since you want two separate failover scenarios (internet-facing vs. internal), you need 2 RGs (RG1 and RG2). Important to note that the control plane has its own group (RG0) that is created by default and should not have any interfaces in it.

 

As for how to fail the RGs: set up interface tracking for the internet-facing port on the internet-facing RG (let's call that one RG1 and the internal one RG2) with a weight of 255 so that the RG fails if the internet link fails. For RG2 (the internal-facing RG), set up tracking on the internal ports with a weight of 255 each, so that if either your Trust or DMZ ports fail then the internal-facing RG will fail over to the passive firewall. ALSO set up interface tracking on RG2 to watch the internet-facing port with a weight of 255 - that way, if the internet-facing port fails, BOTH RG1 AND RG2 will fail to the passive box (since you said you don't want z-mode traffic if your internet connection fails, just if your internal ports fail).

Contributor
aeroplane
Posts: 724
Registered: ‎06-30-2009
0

Re: Redundancy Group Design Question

That seems cool..... But if RG2 contains reth interfaces for TRUST and DMZ both then in this case if reth interface of TRUST OR DMZ is down then both zones TRUST and DMZ will failover. My question was if reth interface of TRUST OR DMZ down then only that interface should failover BUT if reth interface of UNTRUST down then everything should failover.

 

So what do you think should I create three RG.

 

RG1: For UNTRUST ZONE reth interface

RG2: For TRUST ZONE reth interface

RG3: For DMZ ZONE reth interface

 

In each RG, I will track physical interfaces of that reth interface PLUS physical interface of UNTRUST Zone. What do you think?

 

Thanks

Super Contributor
billp
Posts: 124
Registered: ‎05-01-2008

Re: Redundancy Group Design Question

Yep - if you want them to fail independantly, then three RGs is the way to go.

 

It may also be advisable to set preemption on all 3 RGs. That way, when they're online and things are good they will all be on the same chassis (minimizing z-mode traffic). Otherwise, if one fails and then recovers it would remain on the secondary chassis until something else caused it to fail back.

Contributor
aeroplane
Posts: 724
Registered: ‎06-30-2009
0

Re: Redundancy Group Design Question

Thanks Bill. Just last one confusion is that,

 

- As discussed, if UNTRUST interface is down then all RG will be failover to secondary node because this interface is monitored with weight 255 in ALL THREE RG.

 

- Now in case if preempt is enabled for all three RG and DOWN UNTRUST interface comes UP on primary node then ALL THREE RG will be switched back to Primary node? as UNTRUST interface is tracked with weight 255 in all RG. Am I correct in understanding?

 

- Also in case of preemption, I do not need to monitor the interfaces of secondary node in RG?

 

Thanks in advance

Super Contributor
billp
Posts: 124
Registered: ‎05-01-2008

Re: Redundancy Group Design Question

1. Correct - all 3 RGs will fail if Untrust is down, as long as it is tracked with a weight of 255 in all 3 RGs.

2. Correct - with preempt enabled, as long as there is an active failure (or failures) with a failure weight of 255 the RG will remain on the secondary. Once the failure condition is cleared (in this case, Untrust comes back up), then the RGs will all fail back to the primary.

 

3. This gets more into a question of style and preference than an absolute technical recommendation. I've heard people say yes and I've heard no. Even with preempt I prefer to set up monitoring on both chassis - it doesn't really have any effect if you have preempt enabled, but that way if I disable preempt at some point in the future then I don't have to remember that I didn't set up full bidirectional failovers.

 

Note for #2 above that RG0 (the control plane) will fail independantly of the forwarding planes (RG1+) and does not support preempt; it can continue to run on the secondary unit with typically no issue. I say 'typically' because there are some instances where it matters. UTM/IPS in pre-11.4 code for Branch would only run on the chassis that had the active control plane; on the high-end, LSYS only runs on the chassis with the active control plane. Those are the only examples I can think of where you need to keep the control plane on the same chassis as the forwarding planes, and if you're not runnign them then you can ignore this. To keep RG0 together with RG1+, I typically disable preempt for the forwarding planes (RG1+) and enable interface tracking for the control plane (RG0) on both the primary and secondary units. This would have all RGs failing from one chassis to the other in sync; you would remain in active/passive (you had some scenarios where active/active would be in effect) but UTM (pre-11.4) or LSYS would work for all RGs.

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.