Configure Cluster Failover Parameters

Chassis Cluster Control Link Heartbeats

You configure the heartbeat threshold and heartbeat interval as part of the chassis cluster setup. By default, the system continuously monitors the status of the control link.

On platforms that support dual control links—specifically the SRX5600 Firewall and SRX5800— Firewall, the Juniper Services Redundancy Protocol process (jsrpd) sends and receives control heartbeat messages over both control links. As long as heartbeat messages are successfully received on at least one control link, Junos OS considers the peer node to be alive and operational.

The failover wait time is determined by multiplying the heartbeat-thresholdvalue by the heartbeat-interval value . With the default configuration, this calculation results in a wait time of 3 seconds before a failover is initiated.

For example:

• A heartbeat-threshold of 5 combined with a heartbeat-interval of 1000 milliseconds results in a 5-second wait time.

• Similarly, configuring a heartbeat-threshold of 4 with a heartbeat-interval of 1250 milliseconds also produces a 5-second wait time.

In a chassis cluster environment, when more than 1000 logical interfaces are configured, it is recommended to increase the cluster heartbeat timers from the default of 3 seconds.

Chassis Cluster Control Link Failure and Recovery

When the control link fails in a chassis cluster, Junos OS immediatelychanges the operating state of the secondary node to ineligible and starts a 180-second countdown. If the fabric link also fails within this 180second interval, Junos OS transitions the secondary node to primary. If the fabric link remains operational throughout the interval, the secondary node's state changes to disabled after the 180 seconds expire. A system log message is generated whenever the control link goes down.

A control link failure is defined as a condition in which heartbeats are no longer received over the control link, while heartbeats or probes continue to be received over the fabric link.

In the case of a verified control link failure:

• Redundancy group 0 remains primary on the node where it was already primary.

• Any inactive redundancy groups (x) on the primary node become active.

• The secondary node transitions to a disabled state.

Even while the secondary node is disabled, you can still log in through the management interface to perform diagnostic and troubleshooting tasks.

To determine whether a control link failure is legitimate, the system relies on redundant liveliness signals sent across both the control link and the fabric link.

Junos OS periodically sends:

• Heartbeat messages over the control link

• Probe messages over the fabric link

Heartbeat and probe messages share a common sequence number, which ties them to the same time event. A legitimate control link failure is declared when both of the following conditions are met:

• The configured threshold number of heartbeat messages has been missed.

• At least one probe message with a sequence number matching a missing heartbeat is successfully received over the fabric link.

When the control link fails, a 180-second countdown begins, and the secondary node transitions to the ineligible state. If the fabric link also fails before the countdown expires, the secondary node becomes primary, because the simultaneous loss of both links is interpreted as an indication that the peer node is no longer alive.

Because the concurrent loss of the control and fabric links prevents the nodes from synchronizing state information or comparing priorities, both nodes might temporarily assume the primary role, resulting in an unstable operating condition. Once the control link is restored, the cluster automatically stabilizes:

• The node with the higher priority value becomes primary

• The other node transitions to secondary, and normal cluster operation resumes.

When a legitimate control link failure occurs, the system behaves as follows:

• Redundancy group 0 remains primary on the node where it was already primary, ensuring that its Routing Engine stays active. All other redundancy groups x on that node also transition to the primary state.

  If the system cannot determine which Routing Engine is currently primary, the node with the higher priority value configured for redundancy group 0 is selected as the primary node, and its Routing Engine becomes active. (Node priority values are configured as part of the redundancy-group 0 settings.)

• The peer node is placed into a disabled state.

  To recover a device from the disabled state, you must reboot the affected node. During the reboot process, the node resynchronizes its dynamic state with the primary node and then rejoins the cluster.

If you make configuration changes while the secondary node is in a disabled state, you must run the commit command after rebooting the node to synchronize the configuration with the primary node. If no configuration changes were made during this time, the configuration remains synchronized automatically.

Preemption cannot be enabled for redundancy group 0. To change the primary node for redundancy group 0, you must perform a manual failover.

When using dual control links (supported on SRX5600 and SRX5800), note the following considerations:

• Host inbound or outbound traffic can be disrupted for up to 3 seconds during a control link failure. For example, if redundancy group 0 is primary on node 0 and there is an active Telnet session to the Routing Engine through a network interface on node 1, the session may experience packet loss for approximately 3 seconds while the failure is detected.

• A control link failure that occurs while a commit operation is in progress across both nodes can result in a commit failure. In this case, wait 3 seconds and run the commit command again..

You can enable automatic control link recovery by configuring the control-link-recovery statement. When this option is enabled, the system automatically monitors the health of the control link. Once the control link is determined to be operational again, Junos OS initiates an automatic reboot of the previously disabled node. After rebooting, the node rejoins the chassis cluster and resumes normal operation.