Each stack has a primary 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 primary node.
To support the additional capabilities in a stack that includes multiple switch models, the most capable switch automatically becomes the primary node. When choosing a switch to act as a backup node, a switch with the same capability as the primary node should be chosen.
The following list shows which switch models can cross stack with each other. Within each list, the relative ranking is shown with the most capable switches placed at the top of the list:
* - Cross stack group 1. Switches in this group cannot cross stack with switches in groups 2 or 3.
** - Cross stack group 2. Switches in this group cannot cross stack with switches in groups 1 or 3.
*** - Cross stack group 3. Switches in this group cannot cross stack with switches in groups 1 or 2.
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 primary 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 primary 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 primary-capable nodes in a stack have the same model number, the node with the highest node role election priority becomes the primary 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 primary 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 primary node, that node retains the primary node role until it fails or loses a dual primary 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 primary-capable do not participate in node role election. Priority configuration is not relevant on such nodes.
A dual primary resolution does not use the configured node priority in most cases. Instead, it uses the oldest time that a node became a primary in the current active topology.