Each stack has a master node, and it might have a backup node and multiple standby nodes. Each switch's role is determined by its priority.
The role of each stack node is determined by, in order of precedence:
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 switch models, the most capable switch automatically becomes the master node. For this release, the ranking of switch models is as follows:
Note
While the ExtremeSwitching X690, X590, and X870 switches are the most capable for becoming the master node based on their features, these models can stack only with themselves and with each other .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:
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:
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. For example, the command configure stacking slot 2 priority 10 assigns a priority of 10 to the switch in slot 2.
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 want 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, rather than using the automatic algorithm.
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.
Print
this page
Email this topic
Feedback
View PDF
Download EPUB