SRX

last person joined: 12 hours ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
Expand all | Collapse all

Redundancy Group Design Question

  • 1.  Redundancy Group Design Question

    Posted 04-29-2012 14:47

    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

     

     



  • 2.  RE: Redundancy Group Design Question

    Posted 04-29-2012 18:08

    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

     



  • 3.  RE: Redundancy Group Design Question

    Posted 04-29-2012 22:25

    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



  • 4.  RE: Redundancy Group Design Question

    Posted 04-29-2012 22:42

    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.



  • 5.  RE: Redundancy Group Design Question

    Posted 04-30-2012 00:44

    So how do you think how to design this?

     

    Thanks



  • 6.  RE: Redundancy Group Design Question

     
    Posted 04-30-2012 05:54

    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).



  • 7.  RE: Redundancy Group Design Question

    Posted 04-30-2012 08:57

    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



  • 8.  RE: Redundancy Group Design Question

     
    Posted 04-30-2012 09:27

    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.



  • 9.  RE: Redundancy Group Design Question

    Posted 04-30-2012 13:24

    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



  • 10.  RE: Redundancy Group Design Question
    Best Answer

     
    Posted 05-01-2012 06:21

    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.



  • 11.  RE: Redundancy Group Design Question

    Posted 05-01-2012 15:18

    Hi Bill

     

    Thanks for the great explaination. As you mentioned for UTM/IPS, RG0 and RG1+ should be on the same chassis.

     

    1- Is that true for IPSE VPN and Routing over IPSEC?

     

    2- For RG0 and RG1+ on the same node, I will track all interfaces of all RG1+ in RG0? Also should I track interfaces in their respective RG1+ as well?

     

    Thanks



  • 12.  RE: Redundancy Group Design Question

     
    Posted 05-01-2012 16:29

    1. VPN and routing are done in SPC, so I don't beleive RG0 has any effect here.

    2. If you want to be sure that everything (RG0+) fails all together every time, then track all the relevant interfaces in all the RGs; that means you'll fail a chassis if ANY interface fails, but that may be necessary depending on your design requirements.



  • 13.  RE: Redundancy Group Design Question

    Posted 05-02-2012 00:26

    Thanks. It really helped. Do you think is there any special relation or considerations between HA and IPSEC. also HA and Routing.

     

    Thanks



  • 14.  RE: Redundancy Group Design Question

     
    Posted 05-03-2012 07:28

    HA and IPSec: On failover of the forwarding plane, I believe you have to rekey your tunnels.

    HA and Routing: On failover of the control plane, you will have to re-establish adjacencies and recalculate your routing tables.