Configuring the Master, Backup, and Standby Roles

Each stack has a master node, and it might have a backup node and multiple standby nodes.

The role of each stack node is determined by:

Some switch models have greater CPU processing capability, more memory, and support additional features – thus making them more suitable for the role of master node.

To support the additional capabilities in a stack that includes multiple Summit switch models, the most capable switch automatically becomes the master node. For this release, the ranking of Summit switch models is as follows:
  • X670-G2 (most capable)
  • X460-G2
  • X770
  • X450-G2
  • X460
  • X440 (least capable)

If the stack configuration includes switches that are more capable than others, the stack will try to select the most-capable backup node.

If a switch with reduced capabilities serves as the backup node for a switch with greater capabilities, that switch might not be able to support the stack as a master node if a failover occurs (for example, the less-capable switch might not have enough processing power or table space to run efficiently as the master node). If your configuration needs to support automatic failover, we recommend that if a stack contains mixed model numbers, one of the following configurations should be used:
  • Identical, most-capable switches available to become the master and backup nodes.
  • The master-capability option is turned off for all less-capable switches.

When all master-capable nodes in a stack have the same model number, the node with the highest node role election priority becomes the master as a result of the first node role election, and the node with the second highest node role election priority becomes the backup node. All other nodes become standby nodes. See Node Election for more information.

During subsequent node role elections that occur when a master node fails, the node priority configuration helps determine the node that becomes the replacement backup node.

Node priority configuration takes effect at the next node role election. A change in node priority configuration does not cause a new election. Once an active topology has elected a master node, that node retains the master node role until it fails or loses a dual master resolution.

You can configure one of the following election priority algorithms:
  • Priority algorithm: If any node has a numeric priority value configured.
  • Automatic algorithm: If all nodes participating in node role election have the automatic priority value configured.

The priority algorithm is selected if any node has a numeric priority value configured. You can specify an integer priority value between 1 and 100. The higher the value, the greater the node role election priority. If any node participating in a role election has a priority value configured, all nodes use the priority algorithm. A node configured with the automatic algorithm uses a priority value of zero (the lowest priority) in the priority algorithm if another node has a priority value configured.

The automatic algorithm is selected if no node participating in a role election has a numeric priority value configured. In automatic mode, the stack determines the highest role election priority based on factors such as available processing power, maintenance level of ExtremeXOS, and so forth.

In both algorithms, if the highest computed node role election priority is shared among multiple nodes, the slot number is used to adjust the node role election priority. A numerically lower slot number results in a higher role election priority than a numerically higher slot number. If you wish to use the slot number as the sole determining factor in node role election priority calculation, you should configure every node with the same priority value, and not automatic.

Note

Note

The automatic priority algorithm may change in future ExtremeXOS releases.

Nodes that are configured as not master-capable do not participate in node role election. Priority configuration is not relevant on such nodes.

A dual master resolution does not use the configured node priority in most cases. Instead, it uses the oldest time that a node became a master in the current active topology.