Understanding Chassis Cluster Redundancy Group Manual Failover
You can initiate a redundancy group x failover manually. A manual failover applies until a failback event occurs.
For example, suppose that you manually do a redundancy group 1 failover from node 0 to node 1. Then an interface that redundancy group 1 is monitoring fails, dropping the threshold value of the new primary redundancy group to zero. This event is considered a failback event, and the system returns control to the original redundancy group.
You can also initiate a redundancy group 0 failover manually if you want to change the primary node for redundancy group 0. You cannot enable preemption for redundancy group 0.
When you do a manual failover for redundancy group 0, the node in the primary state transitions to the secondary-hold state. The node stays in the secondary-hold state for the default or configured time (a minimum of 300 seconds) and then transitions to the secondary state.
State transitions in cases where one node is in the secondary-hold state and the other node reboots, or the control link connection or fabric link connection is lost to that node, are described as follows:
- Reboot case—The node in the secondary-hold state transitions to the primary state; the other node goes dead (inactive).
- Control link failure case—The node in the secondary-hold state transitions to the ineligible state and then to a disabled state; the other node transitions to the primary state.
- Fabric link failure case—The node in the secondary-hold state transitions directly to the disabled state.
Keep in mind that during an in-service software upgrade (ISSU), the transitions described here cannot happen. Instead, the other (primary) node transitions directly to the secondary state because Juniper releases earlier than 10.0 do not interpret the secondary-hold state. While you start an ISSU, if one of the nodes has one or more redundancy groups in the secondary-hold state, you must wait for them to move to the secondary state before you can do manual failovers to make all the redundancy groups be primary on one node.
![]() | Caution: Be cautious and judicious in your use of redundancy group 0 manual failovers. A redundancy group 0 failover implies a Routing Engine failover, in which case all processes running on the primary node are killed and then spawned on the new master Routing Engine. This failover could result in loss of state, such as routing state, and degrade performance by introducing system churn. |
Related Topics
- Junos OS Feature Support Reference for SRX Series and J Series Devices
- Understanding Chassis Cluster Redundancy Group Failover
- Initiating a Chassis Cluster Manual Redundancy Group Failover
- Example: Configuring Chassis Cluster with a Dampening Time Between Back-to-Back Redundancy Group Failovers (CLI)
- Understanding SNMP Failover Traps for Chassis Cluster Redundancy Group Failover
- Understanding Chassis Cluster Redundant Ethernet Interfaces
- Understanding Chassis Cluster Monitoring of Global-Level Objects
- Upgrading Both Devices in a Chassis Cluster Using an ISSU
Hide Navigation Pane
Show Navigation Pane
Download
SHA1
