Single Fabric Link in an Active/Active SRX4600 Cluster

The status output is a control-plane view. Redundancy group ownership is driven by heartbeats over the control link and by interface monitoring; it does not prove that the data plane has two usable paths.

In an active/active design, the fabric links carry inter-node forwarded traffic and session-state synchronization. With fab1 down, fab0 is the only remaining inter-node path, so it must carry both the session-sync stream and any traffic that ingresses one node and must egress the other. During the RG1 failover, reth0.0 MAC and ARP ownership moved, and sessions that had been synchronized only partially, or whose forwarding path depended on the failed fabric, could not be recreated on the new owner. The 20-second outage is consistent with ARP/gratuitous-ARP convergence plus a sync backlog, not with an RG election failure.

The correct conclusion is that the cluster had been running with a single data-plane interconnect for nine days and that a failover test was unsafe until it was restored. Verify with show chassis cluster statistics, show chassis cluster data-plane statistics, and show interfaces fab1 extensive; a healthy RG status is not evidence of fabric redundancy.

Treat fab1 as a production outage, not as a low-priority cleanup. Order of operations:

1. Confirm the physical layer on both nodes: show interfaces fab1 extensive for down/down, CRC, and optics; check that the correct ports are cabled to ToR-B and that the ToR port is not shut or in an error-disabled state.
2. On the ToR, confirm the port is a plain point-to-point L2 link with consistent MTU and no spanning-tree or storm-control action that could keep it down.
3. On the cluster, confirm show chassis cluster interfaces shows fab1 up on both nodes and show chassis cluster statistics shows fabric probes succeeding, not just session-sync counters rising.
4. Only then schedule the failover test, during a window, with long-lived sessions drained where possible.
5. Before failover, record show security flow session summary and the sync counters so you can distinguish normal convergence from a sync failure. After failover, check the same counters and a sample of long-lived sessions.

Do not use the upcoming ToR upgrade as an opportunity to test failover while fab1 is down; restore the second fabric path first.

The goal is to remove the need for inter-node forwarding and to avoid unnecessary failovers. Pin both redundancy groups to node0 so the cluster runs active/passive: RG1 and RG2 both primary on node0, node1 standby. With no active/active split, node0 does not need to forward traffic to node1, and the surviving fab0 is used mainly for session synchronization.

Also reduce the chance of an accidental failover: review interface-monitor on reth1 and remove or raise thresholds for links that flap, and avoid preempt for the duration. Do not run ToR-A maintenance either, because fab0 is now the only interconnect.

Risk remains. If node0 fails, node1 takes over with whatever session state reached it over fab0; any sessions that were not synchronized are lost. If fab0 fails as well, there is no inter-node path and no session sync, so a node failure becomes a hard outage with no stateful failover. The active/passive change reduces the blast radius but does not restore redundancy; it should be documented as a temporary risk acceptance with a firm repair date.