Eliminating a Dual Master Situation Manually

To eliminate the dual master situation, you need to know all the nodes that are supposed to be in the stack. You might lose the management connectivity to the master node because the other master node duplicates the stack‘s primary management IP address and stack MAC address.

Note

The following procedure is necessary only if you cannot reconnect the severed link in a timely manner. If you can reconnect, the dual master condition resolves itself. The formerly broken portion of the stack reboots and the nodes come up as standby nodes.

If you lose the management connectivity, log into the master node using its alternate management IP address.
Use the show stacking command to determine which nodes have been lost from the stack.
You should already know which nodes are expected to be part of the stack.
Log into any node in the severed segment you want to deactivate, either through its console port or through the management interface using the alternate management IP address.
Issue the show stacking command to find out whether the broken segment has indeed elected a new master node.
Using the reboot stack-topology as-standby command, reboot the broken segment.
This forces all nodes in the segment to come up as standby nodes.
If you have unsaved configuration changes, take care when selecting the stack segment to be rebooted. You should reboot the segment that has the smaller System UpTime.

If you know the node that was master of the unbroken stack, you can reboot the stack segment that does not contain this master node. Otherwise, determine the System UpTime shown by each master node.

If the System UpTimes of both masters are the same, you can reboot either segment without loss of unsaved configuration changes. If the System UpTimes of both masters differ, you must reboot the segment with the smaller System UpTime.