Define the stack elections of the 9300X

[Antoine Chemin]

Hi,

How to definitively and predictively define the master of a stack of switches from the 9300X series in a basic configuration and/or in the stack cabling?

Thanks,

Regards

[Flavio Miranda]

@Antoine Chemin 

Use Priority

 switch stack-member-number priority new-priority-value

You can use from 1 (default) to 15. The higher priority is the master

[balaji.bandi]

Active election

To determine the single ACTIVE and STANDBY switch role during the complete stack reboot process or during the initial boot-up, all switches are required to go through an election process. All member switches participate in the election of an ACTIVE stack switch if they all boot up within the election window (120 seconds).
The following parameters are taken into account in the order listed below for active switch election:
● Highest priority
● Lowest MAC address

STANDBY is elected by the ACTIVE switch after two minutes to reduce the stress of high-availability sync on the stack.
example :
9300#switch <number> priority 15 !Set priority 15 to elect switch in ACTIVE role

refer document :

https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300-series-switches/white-paper-c11-741468.html

[Joseph W. Doherty]

BTW, the stack election is only held when a stack master is needed.  A switch that joins a stack, with an active master, even with a higher priority, will not preempt the active master.  I.e. the stack's master might not be the switch you desire.

[shambhu.kumar]

That's correct, here is example,

 switch 3 is being elected as the active switch with priority 5

[Joseph W. Doherty]

Nice!

Your example's active master also doesn't have the lowest MAC.

This example well shows what switch is the active master is not guaranteed by configuration or MAC.

Although my experience with Cisco stackable switches was limited to the various 3750 series, it was in large Enterprises where we had quite a few (possiblity a hundred or more stacks).  We never bothered with assigning priorities or which switch member was the active master.  As far as I recall, this was never an issue.  (We did focus on impact of the active master failure and its mitigation, such as "permanent" stack MAC and NSF.)

[Leo Laohoo]

If all the switches are cabled up (stack) and powered up at the same time, the switch with the "lowest" stack MAC address will always be the stack master.  

[Antoine Chemin]

Hi,

The architecture of our sites and the configuration that we manage must ensure that in a nominal state, it is always the same switch that is the master. I cannot rely on the MAC address.

The switch priority is indeed set to define the election order, but this command can only be applied in exec mode and not in conf t mode.

I was looking for another method, such as the order of connecting the stack cables or a boot variable.

Regards

[Joseph W. Doherty]

"The architecture of our sites and the configuration that we manage must ensure that in a nominal state, it is always the same switch that is the master."

Again, don't believe it's possible to fully guarantee that without, perhaps, using a something to monitor the stack master and correct (like possibly an EEM script).

BTW, why such a requirement?  Possibly console access?

[Antoine Chemin]

The requirement is primarily the definition of port numbering, which must always be the same because it is defined in an orchestrator and used for a hard-coded purpose.

It is necessary that the order of switch election is always the same and as previously defined.

[Joseph W. Doherty]

Unless Cisco has changed how stack member port numbering works, it's tied to each individual switch regardless of stack priority or where stack member is physically connected to other stack members. I.e. active stack master is not an issue.

[Antoine Chemin]

I'm sorry but I disagree.

The stack master will have this numbering:

interface TwentyFiveGigE 1/0/1 - 24 or interface range TenGigabitEthernet 1/1/1 - 8;

whereas the third member will have:

interface TenGigabitEthernet 3/1/1 - 8 or interface range TwentyFiveGigE 3/1/1 - 16.

This directly impacts the management of interface numbering.

[Joseph W. Doherty]

So you're saying, for example, in @shambhu.kumar example, that shows switch member 3 is the active master all its ports all start with member #1?  How do all the remaining stack member ports are numbered, if not tied to the switch number?

If what you say is true, it would be nuts, as the port configurations would need to follow and since, I believe, you can have different (same series) models in the same stack, the new master may not have the same physical ports plus other link side devices may now have a totally incompatible configuration for the reassigned port configuration.

Again, I don't have any direct experience with the Catalyst 9k switches, stacked or otherwise, but what you're saying, if correct, is insane.

@Leo Laohoo or anyone else want to comment?  I.e. a switch master change renumbers stack member ports?

Possibly what you have in mind, as you build a stack, generally the stack master uses member #1, but, again, the member number is tied to the physical stack member (as provisioned for a particular stack), it's not related to what switch is the master (although, again, in a newly built stack, active master is likely #1).

The above is at the configuration level.  I do recall some Cisco devices might change port SNMP OIDs with certain changes (reloads?, card swaps?), but I recall there was a way to "lock" those.  Recall it was a chassis issue, but perhaps it might be true with stacks too?  So is the concern port configs or SNMP monitoring?

[Leo Laohoo]

---

@Antoine Chemin wrote:
we manage must ensure that in a nominal state, it is always the same switch that is the master. I cannot rely on the MAC address.

---

There are many ways to ensure that the selected switch will always be the "stack master".  It is just how one "adjusts" towards the rules and understands not just the concepts but the logic behind this.  First thing to always consider is the switch priority.  Even until now, not everyone knows about this.  So the switch that has the configuration goes in, with the rest of the stack members, with the default priority of 1.  

Next, another method of making sure that the selected switch will be the master is the order in which the entire stack is powered up.  Again, even now not everyone knows about this.  So they are going to stand up an entire stack with all stack members in default priority 1 and going to apply power simultaneously. 

And because of the stack election, there is a fair chance the intended stack master will not be the stack master plus the stack will boot up with NO CONFIG.  

I have been advocating the following "rule-of-thumbs" and they are: 

1.  Put the configuration in the switch master.  Make sure switch priority of 15 is configured. 

2.  Power up the switches one by one.  Start with the stack master, wait 30 seconds, power up the intended next member of the stack and so on with 30 seconds interval.  

3.  As soon as all members of the stack are in, configure priority so failover will not be a dog's breakfast. 

4.  Stacking cables is there for redundancy.  It is not an "expense".  Do not skimp by not installing the return cable.  

5.  The screws of the stacking cables are there for a reason.  Use them.  Screw them in finger tight.  Otherwise, don't bother putting in the cables.  (Ask me why!)

[Joseph W. Doherty]

BTW, what Leo is describing is useful for initial stack building/provisioning.  For that, you do need to be mindful of exactly how you power up and configure the stack.

What I had mind is working with a provisioned stack, where you're not on-hand to selectively manage power for each stack member (or even if you are, you don't want to do so).

Most of my on-going configuration experience has been supporting remote location equipment, often without any remote location (networking) technical personal.

Very much different mindsets and approaches in an initial build out vs. stack master fails in the middle of the day.  (Also BTW, by design, even an active stack master failure, excluding single homed devices connected to it, was a non-issue.  If needed, we could also physically replace a failed switch member, including it having been the active master w/o additional impact.)

Decades ago, at one company, even our smallest offices would almost always have a pair of WAN routers connected to a dual L3 switch stack which might have L2 stacks connected to it.