DescriptionPreemption is generally a bad idea in clustering, although sometimes it is the default setting. Indeni will alert if it's on.
Remediation StepsIt is generally best to have preemption disabled. Instead, once this device returns from a crash, you can conduct the failover manually.
1. Generally, it is recommended to have preemption disabled. Instead, once this device returns from a crash, you can conduct the failover manually.
2. If preemption is added to a redundancy group configuration, the device with the high priority in the group can initiate a failover to become a master.
3. On the device command line interface execute "request chassis cluster failover node" or "request chassis cluster failover redundancy-group" commands to override the priority setting and preemption.
4. Review the following article on Juniper TechLibrary for more information: Operational Commands: request chassis cluster failover node
How does this work?This script logs into the Juniper JUNOS-based device using SSH and retrieves the output of the "show chassis cluster status" command. The output includes the status of all redundancy groups across the cluster.
Why is this important?Preemption is a function in clustering which sets a primary member of the cluster to always strive to be the active member. The trouble with this is that if the active member that is set with preemption on has a critical failure and reboots, the cluster will fail over to the secondary and then immediately fail over back to the primary when it completes the reboot. This can result in another crash and the process would happen again and again in a loop.
Without Indeni how would you find this?The administrator has to run the "show chassis cluster status" on the device to find whether preemption is enabled and correctly configured if one of the nodes is expected to be always primary node.
View Source Code