Rescuing a Stack that has No Primary-Capable Node

It is possible for all nodes in a stack to have primary-capability set to OFF. For example, if a stack was operating with no redundancy (for example, with one primary-capable node) and the primary node failed, all other nodes in the stack restart as standby nodes and there is no primary node.

Another example is the case where you dismantle a stack before using the unconfigure stacking command or the unconfigure switch all command. In this case, the individual switches are configured for stacking, are not primary-capable, and are isolated from a stack primary.

In this situation, the only security information available is the failsafe account. If you know the failsafe user name and password, you can log into any node and reconfigure primary-capability or redundancy. However, if you do not know the failsafe account information, there is another way you can change the configuration.

The procedure described here generally is not needed if another primary-capable node is expected to rejoin the stack. If this procedure is used, it is possible that the new primary will duplicate the primary that is expected to rejoin later.

To assign a new primary-capable node, follow these steps.

  1. At the login prompt, enter the following special login ID exactly as displayed below (all uppercase letters) and press [Enter]:
    The following message appears:
    Node reboot initiated with primary-capability turned on.

    This node then sets an internal indicator that is preserved across the reboot. While restarting, the node notices and resets this indicator, ignores the node primary-capability configuration, and becomes a primary node.

    The special login ID described here is available only if all of the following conditions are met:

    • The node supports the SummitStack feature.
    • Stacking mode is active on the node.
    • All nodes in the active topology have primary-capability turned off.
    • There is no primary node in the active topology.

    If the above conditions are met, five minutes after starting the node and every five minutes after that, the following message displays on the console:

    Warning: the stack has no Primary node and all active nodes are operating 
    with primary-capability turned off. If you wish to reconfigure, you may log 
    in using the failsafe account. Alternatively, you may use the special login
    REBOOT AS PRIMARY-CAPABLE with no password to force a reboot of a node with 
    primary-capability temporarily turned on.

    Using the special login ID does not alter the primary-capability configuration permanently. If you restart a node that has been restarted with the special login ID, that node restarts using its configured primary-capability, unless you again use the special login ID to restart.

    When a node has been rebooted using the special login ID, it becomes a primary node. While the node is a primary, the special login ID is not recognized, even though the entire stack is still configured as not primary-capable. To get the special login ID to be recognized, the node must be rebooted again.

  2. If a node was intentionally separated from the stack without first being unconfigured, its security configuration might be unusable. In this case, perform the following steps:
    1. Connect to the node's console port.
    2. Reboot the node using the special REBOOT AS PRIMARY-CAPABLE login ID described in step 1.
    3. During the reboot, enter the bootrom program by waiting until you see the message Starting Default Bootloader ... and then pressing and holding the space bar until the bootrom prompt displays.
    4. Force the switch to boot up with a default configuration by entering the following commands at the bootrom prompt:
      config none

    The switch boots up in stacking mode operating as a primary-capable switch. You can then log in using the default admin account with no password.