Backup Switch Selection; Master Failover; Secondary Backup; Master Recovery - Lenovo RackSwitch G8264CS Application Manual

Backup Switch Selection

Master Failover

Secondary Backup

Master Recovery

256
G8264CS Application Guide for ENOS 8.4
An operational stack can have one optional Backup at any given time. Only the
Backup specified in the active Master's configuration is eligible to take over current
stack control when the Master is rebooted or fails. The Master automatically
synchronizes configuration settings with the specified Backup to facilitate the
transfer of control functions.
The Backup retains its status until one of the following occurs:
The Backup setting is deleted or changed using the following commands from

the active Master:
RS 8264CS(config)# no stack backup
‐or‐
RS 8264CS(config)# stack backup <csnum 1‐8>
 A new Master assumes operation as active Master in the stack, and uses its own
configured Backup settings.
 The active Master is rebooted with the boot configuration set to factory defaults
(clearing the Backup setting).
When the Master switch is present, it controls the operation of the stack and
pushes configuration information to the other switches in the stack. If the active
Master fails, then the designated Backup (if one is defined in the Master's
configuration) becomes the new acting Master and the stack continues to operate
normally.
When a Backup takes over stack control operations, if any other configured Masters
(acting as Member switches) are available within the stack, the Backup will select one
as a secondary Backup. The primary Backup automatically reconfigures the
secondary Backup and specifies itself (the primary Backup) as the new Backup in case
the secondary fails. This prevents the chain of stack control from migrating too far
from the original Master and Backup configuration intended by the administrator.
If the prior Master recovers in a functioning stack where the Backup has assumed
stack control, the prior Master does not reassert itself as the stack Master. Instead,
the prior Master will assume a role as a secondary Backup to avoid further stack
disruption.
Upon stack reboot, the Master and Backup will resume their regular roles.