Rejoining an offline node to a logical chassis cluster
If a node goes into offline state, and configuration changes are made to online nodes while the cluster is in a degraded state, database mismatches can occur when the offline node tries to rejoin the cluster.
Situations that can cause a node to go offline include:
- ISLs are shutdown, isolating a node from the fabric and cluster.
- A node reboots.
The following list describes possible scenarios that can occur when an offline node tries to rejoin its cluster, and what actions, if any, you must take. For more information about commands that are referenced, refer to the Network OS Command Reference.
- If local-only configurations have been added, updated, or deleted for online nodes after another node has temporarily left the cluster, the offline node automatically rejoins the cluster. Any non-default configurations specific to the rejoining node are then pushed back to the cluster configuration. If the rejoining node has the default configuration, and if no local-only configuration changes were made while this node was offline, then the cluster's configuration for the rejoining node is pushed onto the rejoining node.
- If the offline node has local-only configuration changes and its global configuration is non-default and matches the global configuration of the cluster, then the offline node is allowed to rejoin the cluster. The local-only configuration changes that were made while the node was offline are preserved.
- If global configurations have been added, updated, or deleted after another node has temporarily left the cluster, the global configuration differences between the cluster and the rejoining node result in a configuration database mismatch and node segmentation. To rejoin the cluster, issue the copy default-config startup-config on the segmented node.
- If the rejoining node's global configuration is the default configuration, and both of the following are true: 1) local-only configuration changes have been made to the rejoining node while it was offline, and 2) the cluster contains a different set of local configurations for the rejoining node, then a configuration database mismatch occurs. This situation can occur if the user issues a copy default to start command on a segmented node and issues local-only configurations on the segmented node before it rejoins the cluster. To rejoin the cluster, issue the copy default to startup command on the segmented node or cluster island.
The following table lists commands that change a local configuration for a node but also affect the global configuration. If these commands are run on online nodes in the cluster, be aware that global configuration in the cluster will also change.
|Command (Local Configuration)||Description|
|flexport <RBridge-ID/slot/port>, followed by the type fibre-channel command from the flexport rbridge-id/slot/port prompt, changes the global configuration.||Done in Hardware configuration mode, this command, which converts an Ethernet interface to a Fibre-Channel interface, can cause global configuration changes because the Ethernet interface affects L2Sys, SPAN, IGMPs, and MLD configuration settings.|
|vrf <name>||Done in RBridge-ID configuration mode, the creation of a VRF on an RBridge is a local-only VRF configuration exception and also changes the global configuration.|