An SRX chassis cluster node disabled state is split-brain protection. It almost always follows a control link or fabric link failure. The node that goes disabled stops forwarding, and it stays disabled until it reboots. Run show chassis cluster information detail no-forwarding first, because the Events line names the reason in plain text.
Rebooting clears the state. It does not fix the cause. If the link that failed is still broken, the node will rejoin, lose the peer again and drop back to disabled. Find the cause before you reboot.
This guide is written against the Junos OS 23.4 train on the SRX300 line and the SRX1500. We have not lab-tested every command on every platform and release. Confirm each statement with ? completion on your version. Test cluster-id and fabric changes in a lab, because they require reboots. For general counter reading, the Troubleshooting hub covers show interfaces extensive.
Why Junos Disables a Healthy-Looking Node
A chassis cluster has one control plane. Redundancy group 0 (RG0) decides which Routing Engine is primary, and the other node follows it. The two nodes learn about each other through heartbeats on the control link and probes on the fabric link.
Suppose both links fail at once. Each node sees a silent peer and could promote itself to primary for every redundancy group. Two primaries would advertise the same reth MAC addresses and the same IP addresses. That is split brain, and it breaks the network far more badly than losing one firewall.
Junos deals with this by giving up the secondary. When the secondary loses its peer in a way it cannot explain, it moves to ineligible. If the problem does not clear, it moves to disabled. In the Juniper KB example, the move from ineligible to disabled came about three minutes later with the reason Ineligible timer expired. A disabled node cannot take over, so the cluster carries on with one working node.
The trade-off is recovery. Junos picks a safe outcome with no redundancy over a risky outcome with two primaries, and it will not bring the node back by itself unless you configure control-link-recovery. In our experience, most engineers first meet this behaviour hours after the event, when the next failover fails because the secondary has been disabled since a cable was knocked.
Healthy vs Broken: What the Output Looks Like
A healthy two-group cluster looks like this. Priorities are examples, and the header lists monitor failure codes such as CS, FL, IF and IP.
{primary:node0}
user@srx-a> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual Monitor-failures
Redundancy group: 0 , Failover count: 1
node0 200 primary no no None
node1 100 secondary no no None
Redundancy group: 1 , Failover count: 1
node0 200 primary no no None
node1 100 secondary no no NoneThe broken state shows the secondary as disabled, usually with a zero priority and a monitor failure code. The output below is illustrative and the codes vary with the cause.
Redundancy group: 0 , Failover count: 1
node0 200 primary no no None
node1 0 disabled no no FL
Redundancy group: 1 , Failover count: 1
node0 200 primary no no None
node1 0 disabled no no FLAlways run the command on both nodes. In a recent r/Juniper thread about an SRX380 cluster that fell back to hold, node0 reported node1 as lost while node1 reported a normal secondary. The two nodes disagreeing tells you traffic is being lost in one direction only, and that points at whatever sits between them.
The Events line names the reason
This is the fastest diagnostic available and the one most engineers skip. The detail output keeps a timestamped state history for each redundancy group.
user@srx-a> show chassis cluster information detail no-forwarding
Cluster configuration:
Heartbeat interval: 1000 ms
Heartbeat threshold: 3
Control link recovery: Disabled
Fabric link down timeout: 66 sec
Node health information:
Local node health: Not healthy
Remote node health: Not healthy
Redundancy group: 0, Threshold: 255, Monitoring failures: none
Events:
Sep 21 03:10:41.118 : secondary->ineligible, reason: Control link failure
Sep 21 03:13:41.140 : ineligible->disabled, reason: Ineligible timer expiredRead the first transition, not the last one. Ineligible timer expired only tells you the node gave up waiting. The line before it tells you what it was waiting for. Juniper walks through the same method in its KB on finding the cause of a disabled secondary.
SRX Chassis Cluster Node Disabled: Ordered Diagnostic
Work through these in order. The first four are read-only and take seconds. Leave the reboot until the end, because rebooting wipes the evidence in the live state.
- Status on both nodes. Run
show chassis cluster statuson node0 and node1. Note which node is disabled and whether the two views agree. - Events reason. Run
show chassis cluster information detail no-forwardingand read the first transition out of secondary. - Link state. Run
show chassis cluster interfaces. Check control link status and the Physical and Monitored columns for every fabric child link. - Counters. Run
show chassis cluster statisticstwice, about ten seconds apart. Heartbeat packets received and probes received must both increase. - Daemon log. Run
show log jsrpdon both nodes around the timestamp from step 2. - Hardware. Run
show chassis fpc pic-statuson both nodes and confirm every FPC and PIC is online. - Fix, then reboot the disabled node. Only once the link cause is fixed, reboot the disabled node from its own console and watch it pass through hold to secondary.
user@srx-a> show chassis cluster interfaces
user@srx-a> show chassis cluster statistics
user@srx-a> show log jsrpd | last 100
user@srx-a> show chassis fpc pic-status
user@srx-a> show chassis cluster information detail no-forwarding | match "reason|health"Juniper publishes its own flow in Troubleshoot Chassis Cluster with One Node in the Primary State and the Other Node in the Disabled State. It includes a hidden no-fabric-monitoring statement for use during troubleshooting. Treat that statement as a step to take with JTAC guidance only. It removes the protection this whole mechanism exists to provide, so delete it as soon as the test ends.
Root Causes Ranked by Frequency
This ranking reflects what we see and what repeats across r/Juniper, the Juniper community forum and Stack Exchange. It is our experience, not a Juniper statistic.
1. Control or fabric link cabled to the wrong port
Branch SRX platforms use fixed control ports, and the node1 interface name depends on the platform FPC offset. New builds and RMA replacements get this wrong more than anything else. The mapping below follows the Juniper guide to connecting firewalls to create a chassis cluster.
| Platform | Control link | Fabric link |
|---|---|---|
| SRX300 | ge-0/0/1 on node0 to ge-1/0/1 on node1 | Any port except ge-0/0/0 and ge-0/0/1 |
| SRX320 | ge-0/0/1 on node0 to ge-3/0/1 on node1 | Any port except ge-0/0/0 and ge-0/0/1 |
| SRX340, SRX345, SRX380 | ge-0/0/1 on node0 to ge-5/0/1 on node1 | Any port except fxp0 and ge-0/0/1 |
| SRX1500, SRX1600, SRX2300, SRX4120, SRX4300 | Dedicated built-in HA control ports | Revenue ports |
On the SRX300 and SRX320, ge-0/0/0 becomes the fxp0 management port in cluster mode. That is why the table excludes it from fabric use. Configs copied from an SRX340 build often fail on this point.
2. The Layer 2 path between the nodes
Stretching control and fabric links through switches is supported, but the switches must be set up for it. Juniper lists the requirements in its KB on connecting two SRX in an HA cluster through a Layer 2 switch. These include a separate VLAN for control and for fabric, and jumbo frames. Community threads also cite a latency ceiling of 100 ms between nodes.
The SRX380 thread above adds two failure modes the documentation does not mention. IGMP snooping on the intermediate switches silently dropped control traffic in one direction, and each redundant fabric child link needed its own VLAN. The same engineer also removed LACP from the switch ports facing the fabric links. The reth side is different. If reth members run LACP towards a switch, our guide to Junos LACP ae interfaces stuck in Defaulted or Detached covers how that negotiation fails.
3. Fabric physically up, monitored down
In this case the cable, the LEDs and show interfaces terse all look healthy. But show chassis cluster interfaces reports the fabric child as Up / Down, and probes received sits at zero. Juniper suggests moving the fabric to a different port, then swapping the cable, then swapping the transceivers, and rebooting between steps.
On the Juniper community forum, one SRX340 user tried reboots, cable swaps and port moves with no change. The problem finally cleared after forcing an RG0 failover to node1 and later failing back. Treat that as a reported workaround, not a documented fix, and test it in a maintenance window.
4. Identity mistakes: cluster ID and node ID
Common mistakes include both units set as node 0 after a copy-paste, and a replacement unit that still holds an old cluster ID. Another is two clusters with the same cluster ID sharing a Layer 2 segment. The cluster ID feeds into the reth virtual MAC addresses, so a duplicate causes address conflicts that look like link problems. Check with show chassis cluster status, which prints the cluster ID, and confirm it is unique per segment.
5. Hardware or a software defect
An offline FPC or PIC on the secondary will keep it out of the cluster whatever state the links are in. Heartbeat counters that stop rising with no link fault point at the platform itself, and Juniper recommends opening a case at that point. Old releases have also carried cluster defects on specific platforms. Compare your version with the JTAC Junos suggested releases KB before you spend a day on a problem that may already be fixed.
Recovery and Hardening Configuration
These changes touch the control plane of a production firewall. Have console access to both nodes before you start, because fxp0 on the disabled node may not be reachable. Use commit confirmed 5 for redundancy-group and monitoring changes. Cluster ID and fabric membership changes take effect only after a reboot, so a confirmed-commit rollback will not save you there.
Joining or rejoining a node (operational mode, on each console)
user@srx-a> set chassis cluster cluster-id 1 node 0 reboot
user@srx-b> set chassis cluster cluster-id 1 node 1 rebootBaseline cluster configuration for an SRX340 pair
set groups node0 system host-name srx-a
set groups node0 interfaces fxp0 unit 0 family inet address 192.0.2.11/24
set groups node1 system host-name srx-b
set groups node1 interfaces fxp0 unit 0 family inet address 192.0.2.12/24
set apply-groups "${node}"
set chassis cluster control-link-recovery
set chassis cluster reth-count 2
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 interface-monitor ge-0/0/4 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-5/0/4 weight 255
set interfaces fab0 fabric-options member-interfaces ge-0/0/2
set interfaces fab1 fabric-options member-interfaces ge-5/0/2
commit confirmed 5For an SRX300, the node1 interfaces start at ge-1/0/x, and the fabric must avoid ge-0/0/0 and ge-0/0/1. The heartbeat defaults are 1000 ms and a threshold of 3. The configurable ranges are 1000 to 2000 ms and 3 to 8 missed heartbeats. Raise them only for a stretched cluster with measured jitter, since slower detection means slower failover.
What control-link-recovery does and does not cover
With control-link-recovery set, the system waits for three consecutive heartbeats after the control link returns. It then reboots the disabled node automatically, and that node rejoins the cluster. This is documented in the control-link-recovery statement reference.
It only helps when the control link failed and recovered cleanly. It does nothing for a fabric problem. A flapping control link can also cause repeated automatic reboots of the secondary. We enable it on most branch clusters and pair it with an alert on any chassis cluster state change.
Manual failover and reset
user@srx-a> request chassis cluster failover redundancy-group 0 node 1
user@srx-a> show chassis cluster status redundancy-group 0
user@srx-a> request chassis cluster failover reset redundancy-group 0A manual failover raises the selected node to priority 255 for that group, and the Manual column shows yes until you reset it. The forum workaround in cause 3 needed the force keyword, because the target node was reporting a monitor failure. Check that the keyword exists on your release with ?. Remember that failing over RG0 moves the control plane, so expect a short management interruption.
Verification After Recovery
Confirm the links, then the counters, then the state. Healthy output looks broadly like this. The control interface name varies by platform.
user@srx-a> show chassis cluster interfaces
Control link status: Up
Control interfaces:
Index Interface Monitored-Status Internal-SA Security
0 em0 Up Disabled Disabled
Fabric link status: Up
Fabric interfaces:
Name Child-interface Status Security
(Physical/Monitored)
fab0 ge-0/0/2 Up / Up Disabled
fab1 ge-5/0/2 Up / Up Disabled
user@srx-a> show chassis cluster statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 4211
Heartbeat packets received: 4209
Heartbeat packet errors: 0
Fabric link statistics:
Child link 0
Probes sent: 8420
Probes received: 8416Sent and received should track each other closely and keep rising. Probes received stuck at zero with the fabric physically up is cause 3. Heartbeats received rising on one node but not the other is the one-way loss pattern from cause 2.
Finish with show chassis cluster status on both nodes. Every group should show one primary, one secondary and None under Monitor-failures. Leave it for at least one full Fabric link down timeout period before you close the change.
Platform and Release Differences
High-end platforms such as the SRX5000 line use control ports on SPC cards rather than built-in ports. Juniper notes that a single SPC hosting the control port is a single point of failure. Dual control links are supported on some platforms but not others, so confirm in Feature Explorer before designing around them.
vSRX clusters depend on the hypervisor passing control and fabric traffic. Several community reports of nodes that never fail over turned out to be old vSRX releases or virtual switch settings. If your two nodes sit in different data centres, compare chassis cluster with Juniper Multinode High Availability, which is designed for Layer 3 separation, and check platform support first.
If you are still choosing an HA platform, our small business firewall comparison of SRX, FortiGate and Palo Alto covers the wider trade-offs. More SRX material is in the Security and Firewalls hub.
Juniper, Junos, MX, SRX, EX and QFX are trademarks of Juniper Networks, Inc., now part of HPE. juniperclient.com is independent and unaffiliated.
Frequently Asked Questions
Secondary node of a chassis cluster is in disabled state: how do you find the cause?
Run show chassis cluster information detail no-forwarding and read the first Events transition out of secondary. A reason such as Control link failure tells you which link to check. Then look at show log jsrpd on both nodes around that timestamp.
Why does node1 go from hold to secondary to disabled?
The node joins, then loses heartbeats or fabric probes, then gives up once the ineligible timer expires. Commonly the link comes up but drops traffic, through wrong cabling, a switch in the path or a duplicate cluster ID. Check show chassis cluster statistics on both nodes while the node is in secondary.
Why is the SRX HA fabric link physically up but monitored status down?
The ports have link, but fabric probes are not being received, so the monitored status fails. Move the fabric to another port, then swap the cable and transceivers, rebooting the secondary after each change. One forum user cleared a stubborn case by forcing an RG0 failover to node1 and later failing back.
How does the secondary node recover from a hard shutdown or hardware failure?
A disabled node rejoins only after a reboot, either manual or triggered by set chassis cluster control-link-recovery once the control link is healthy again. If the secondary will not take over when the primary dies, check that the control link really goes down in show chassis cluster interfaces. Old releases on some virtual and mid-range platforms had defects here, so check the suggested releases KB.
Why did the secondary node come online but go back to hold?
Usually the path between the nodes passes traffic for a while and then starts dropping it. In one SRX380 case, IGMP snooping on intermediate switches dropped control traffic one way after a timeout. Give control and each fabric link its own VLAN, disable IGMP snooping on those VLANs, and verify jumbo MTU end to end.
Discussion (0)