Best practice for assigning switch priority in a stacked design

[Charlie Jones]

With stacked switches, we set the higher priorities on the switches that have the trunks to the core.  Is there any benefit to assigning a priority to the other stack members?  As an example, if it is three stacked switches, we would assign them: SW1=15, SW2=13, SW=14.  The other option would be to leave SW2 with the default of 1.

[M02@rt37 · Accepted solution]

Hello @Charlie Jones 

From my point of vieuw, setting SW2 to 13 is better than leaving it at 1, as it ensures a predictable failover process.

[Joseph W. Doherty]

Cannot say if it still holds true for 9k series, but traditionally stacked switches with uplinks were recommended to have the lowest priority.

[M02@rt37]

Hello and agree @Joseph W. Doherty. The idea behind this was to ensure that the switch with the lowest priority would become the root switch in the stack, giving it better control over the network and ensuring more predictable failover behavior.

[Dustin Anderson]

Am I missing something on your statement and wouldn't you want the uplinks to be your active/standby thus being higher priority?

We set switch1 as 15 and 2 as 14 with the rest being defaulted to 1. This is all I could find from cisco on it.

We recommend assigning the highest priority value to the that you prefer to be the active switch. This ensures that the is reelected as the active switch if a reelection occurs.

[M02@rt37]

Right !

The misconception about using the lowest priority for uplink switches might come from older general recommendations about stp root bridge selection or confusion with other platforms' election processes... However, in modern stackwise virtual or catalyst stacking, the higher priority ensures preferred active switch election...

Thanks.

[Dustin Anderson]

ok, I think I'm getting you. Say you have a primary link on Sw2 and the secondary STP shut on Sw1, you may want 2 to be primary this set to 15 and 1 set to 14.

We use a port channel to VPCd cores so haven't had to think about spanning tree too much anymore.

[Joseph W. Doherty]

Again, don't know if recommendations have changed for the latest stackable switches, but I recall the original recommendation was since the stack master member was the most control plane loaded switch member, managing the other switch members, ideally you also wanted it the least loaded in all other respects, such as not using for supporting uplinks.

Personally, as I understand it, the latter is mostly dataplane, so I don't see busy uplinks having (ideally) a significant impact on the switch's control plane.  I.e., I never took much stock in that recommendation being much important.  Likewise, personally, I never thought there was much benefit in "selecting" an election prioritization.  If I really need to concern myself with what switch member is the active "brain" for the stack, perhaps it's questionable whether a stack should be used in a particular case.

I (historically) recall (?), the only time I cared about what switch member was managing the stack was if I needed physical console access.

BTW, I'm not saying there are no cases where what member switch is managing the stack could be impactful, just, again, if that's a real concern, possibly you shouldn't be using a stack.

[Dustin Anderson]

That makes sense, realistically with the power of the switches it's more just preference.

I mean, if the active has an uplink and the control plane crashes it'll reboot the switch so an uplink will go down. This is a pro to have the active a non-uplink switch.

but as also mentioned the active is your console so knowing that is nice if you set switch 1 as active by default. 

personally for our warehouses, a lot of stacks are only 2 switches so have an uplink. So we do sw1 priority 15, sw2 priority 14 and the rest are 1 since is we loose 2 we have a bigger issue anyway.

[DavidMcClain9266]

Switch 1 priority 15
Switch 2 priority 14. Then switch 1 renumber 2
Switch 3 priority 13. Then switch 1 renumber 3
Then save and reload switches, then run your stack cables, and stack power cables if you use them.
Switch 1 will be the primary, switch 2 will be the secondary. Switch 3 will be a member.

[Joseph W. Doherty]

---

@Charlie Jones wrote:

With stacked switches, we set the higher priorities on the switches that have the trunks to the core.  Is there any benefit to assigning a priority to the other stack members?

---

Possibly as much benefit as assigning any priorities, at all, which, IMO, is practically none.  (If anyone can provide any documentation about this really being critically important - please post it.)

Consider (assuming the later stackable switches still do not have a preempt capability), the active/master switch 1 fails.  Standby, becomes active/master, your 3rd switch becomes standby.  Then switch 1 comes back on line, but now as a member switch.  (If correct and) if it's "critical" switch 1 has to be the active/master (without preemption) you'll need to reload the stack or minimally reload active/master, switch 3.  Otherwise, if it's not "critical", why should it matter what switch is elected to active/master to begin with?

Of course, there's nothing "wrong" with assigning election priorities, but personally, I was more concerned about much more impactful issues, things like what happens if a single member switch power supply fails (especially if supporting PoE), NSF setups (if stack is L3), STP root placement (if L2), or even, if still an issue on the later stackable switches, change of stack interface(s) MAC unless configured to retain original stack boot MAC, etc.

There other other subtle issues, which makes selecting a "busy" or not, switch member critical.  Say for instance, you do have a port-channel on switches 1 and 3.  You have traffic that ingresses switch 1 bound for the uplink.  But, again unless the later stackable switches have added path affinity, the switch 1 source uplink traffic, might be directed to the uplink on switch 3, which may cross the switch 2's stack cables, or it may go directly to switch 3.  The converse traffic direction, might do the same.  I.e. traffic being sent to a port on switch 1, coming down from the core, might not take the switch 1 uplink.

When you start to think about actual stack traffic paths, not being easily deterministic by switch member port selection, where the "ideal" place to patch in, say a dozen really, really high traffic edge ports, is pretty problematic.

So, perhaps assigning switch election priorities isn't on the same level as the old joke about rearranging the deck chairs on the Titanic, again, for "best practice", possibly it might be just don't worry about it.  (Again, if someone can document why it really needs to be worried about, please do.  Also again, if you want to concern yourself doing it in some predictable way, nothing "wrong" in that either.)

[Leo Laohoo]

The answer is "TWO minutes". 

That is how much extra time it will take for an entire stack to boot up if switches have priority set to "1".  

[Joseph W. Doherty]

"The answer is "TWO minutes". 

That is how much extra time it will take for an entire stack to boot up if switches have priority set to "1". "

@Leo Laohoo so you're saying a current gen 9k stack takes two minutes longer to boot up if all stack members are the default priority?

If so, WTF?

Such a delay also appear to hold constant regardless of stack units and/or IOS being used, and/or switch series, and/or individual switch models, and/or etc.?

Any similar delay, for a running stack, that the active/master fails while awaiting another stack member replace it?

[Joseph W. Doherty]

I just did some quick reading about current stack elections, and did find mention of a two minute window, during an initial boot, that a later joining switch member can become the active/master.  So, as I understand it, priority settings wouldn't necessarily matter in boot time, but would matter in active/master selection.

[vishalbhandari · Accepted solution]

Yes, assigning a priority to the other stack members can be beneficial. If you leave SW2 at the default priority of 1, it will be the last choice for becoming the stack master in case SW1 and SW3 fail. However, setting a priority (like 13) ensures that SW2 takes over in a predictable order rather than leaving it to chance. This helps maintain network stability and faster recovery during failures. If the stack is critical, it's best to define clear priorities rather than relying on defaults.