SRX Chassis Cluster Failover: Redundancy Groups

A chassis cluster is only as good as its failover behaviour, and that behaviour is decided by redundancy group design rather than by the cluster coming up at all. This guide covers how SRX clusters split responsibilities into redundancy groups, how priority and preemption decide which node is primary, what the control and fabric links actually carry, and the commands that verify state before and after a manual failover. It closes with the failure patterns that surprise operators: failover that happens in the wrong direction, and traffic that survives the switch but not the session.

Two nodes, many redundancy groups

Two SRX devices form a cluster over two dedicated links: the control link carries heartbeats and configuration synchronisation, while the fabric link carries data traffic when one node's interfaces are used to forward traffic destined for a session owned by the other. Redundancy groups (RGs) are the unit of failover. RG0 is conventionally the control plane, and RG1 upward are data groups - typically separate groups for separate traffic types or interfaces so that a partial failure only moves the affected group.

Each RG has a primary node and a secondary node, chosen by priority: the higher priority wins, and preempt allows a higher-priority node to take over once it recovers. Whether you want preemption is a design decision - preempting back on recovery moves traffic twice, which matters for long-lived sessions.

Cluster and RG configuration shape

set chassis cluster cluster-id 1 node 0 reboot
set chassis cluster redundancy-group 0 node 0 priority 200
set chassis cluster redundancy-group 0 node 1 priority 100
set chassis cluster redundancy-group 1 node 0 priority 200
set chassis cluster redundancy-group 1 node 1 priority 100
set chassis cluster redundancy-group 1 preempt
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/0 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-5/0/0 weight 255

Interface monitoring with weights is what makes a cluster react to a link failure rather than only to a node failure. Assign weights so that losing the monitored set exceeds the RG's threshold and triggers failover of that group.

Control and fabric links

set interfaces fab0 fabric-options member-interfaces ge-0/0/1
set interfaces fab1 fabric-options member-interfaces ge-7/0/1
set chassis cluster control-ports fpc 0 port 0
set chassis cluster control-ports fpc 7 port 0

Best practice is to build both the control and fabric links as aggregated interfaces whose child links land on different FPCs. That prevents a single line card failure from isolating the nodes, and separation of control from data keeps heartbeats from being delayed by forwarding load.

Verify before you rely on it

show chassis cluster status
show chassis cluster interfaces
show chassis cluster statistics
show chassis cluster control-plane statistics
show chassis cluster data-plane statistics

Read the status output in this order: both nodes present and in the expected primary or secondary state per RG, failover counts at zero on a healthy cluster, and no interface showing as monitoring-failed. In the statistics views, check that heartbeats are being sent and received in both directions - a one-way heartbeat is a classic sign of a duplex or MTU mismatch on the control link, and it fails in the worst possible way: a split brain.

Manual failover: test it in working hours

show chassis cluster status redundancy-group 1
request chassis cluster failover redundancy-group 1 node 1
show chassis cluster status redundancy-group 1

# return to normal if the design expects node 0 primary
request chassis cluster failover reset redundancy-group 1

Fail over one group at a time and confirm the result before moving to the next. Verify the state change, then test real traffic - routing sessions, NAT sessions and VPN tunnels. Stateful session synchronisation should preserve existing flows through the fabric link, but sessions that were not synchronised (very new, or belonging to a protocol that is not synchronised) will need to re-establish.

Failure patterns worth knowing

• Failover in the wrong direction. Priorities or preempt conflict with the intended design; re-check both nodes, not just the one you expect to be primary.
• Cluster healthy, traffic blackholed. The RG moved but the downstream switch did not follow - reth interfaces depend on correct LACP or switch-side behaviour.
• Repeated flapping after recovery. Interface-monitor weights are too sensitive relative to link stability; raise thresholds or increase hold times.

For the adjacent multi-chassis designs, compare MC-LAG ICL versus ICCP failure behaviour and Junos commit confirmed, which is how you make a cluster change safely reversible.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/chassis-cluster-security-devices/topics/topic-map/security-chassis-cluster-redundancy-group-failover.html