Which's the best practice for stackwise when choosing the active and standby switches?

[Marlon AJ]

Good day,

I have the following topology (Stack switches are Catalyst 9k):

Core A (g0/0)--(g0/0) Stack 1 ..... stack 8 (g0/1) -- (g0/1) Core B

At the moment of configuring the stack using the command 

sw# switch <number> priority <priority>

Which is the best practice for choosing the active and standby switch in the stack?

Thanks in advanced.

[Reza Sharifi]

Hi,

Which is the best practice for choosing the active and standby switch in the stack?

Use priority between 1-15 with 15 the highest priority and give a higher priory to the switch you want to be active. For example, I would give the active switch 12 and the next switch 10 and so on...This way, you know for sure what switch supposed to be active on the stack and what switch will take over packet forwarding in case the active switch fails.

HTH

[Marlon AJ]

Hi @Reza Sharifi ,

Thank you for answering. I configured the switches using a priority of 15 for the switch 1, 14 for the switch 2 and so on based on the following topology:

Topology: 

Core A (g0/0)--(g0/0) Stack 1 ..... stack 8 (g0/1) -- (g0/1) Core B

switch 1 priority 15

switch 2 priority 14

switch 3 priority 13

switch 4 priority 12

switch 5 priority 11

switch 6 priority 10

switch 7 priority 9

switch 8 priority 8

Switch 1 is the active, switch 2 is in standby. But, is this the best way to configure the priority? Or is better in this way:

switch 1 priority 8

switch 2 priority 11

switch 3 priority 12

switch 4 priority 15

switch 5 priority 14

switch 6 priority 13

switch 7 priority 10

switch 8 priority 9

Thanks in advanced.

[Reza Sharifi]

Hi,

I usually do the first scenario, with switch-1 15, switch-2 14, and so on...I also make sure that the active switch (15) is on the top in the rack and switch-2 is right below it and so on with labels... This way, you always know that physically the top switch is the active and the one below is standby and so on...This comes handy especially when you need to replace one of the switches.

HTH 

[Joseph W. Doherty]

I think (? -  @Leo Laohoo probably knows) current gen Cisco switch stacks still hold to the recommendation going back to 3750s, that uplink switches shouldn't be master or standby.  If true, you second stack priority allocations would be better.

PS:

The recommendation might still stand.  See figure 20 inhttps://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300-series-switches/white-paper-c11-741468.html or figure 14 in https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9200-series-switches/nb-06-stackwise-architecture-cte-en.html

[Leo Laohoo]

Best practice/rule-of-thumb -- Here's how it goes ...

NOTE:  This is only valid for the 3750/G/E/X, 3650/3850.  

1. Starting from a switch priority of 15, make sure the "interval" between the master and next switch member is 2.  So if the stack master is 15, the next one is 13, the next is 11, and then 9, etc.  This is NOT valid for the 9300 (will explain later). 
2. Stack size:  If the stack is made up of 3750/G/E/X, do not attempt to make a stack "larger" than 5.  Up to 5 switches in a stack is fine.  More than 5 and you need a doctor's certificate to ensure you won't get a heart attack or a stroke due to "lags" when entering commands.  This is NOT valid for the 9300 (will explain later). 
3. When powering up the entire stack for the first time, resist the temptation to power it up the same time.  Power up the intended stack master FIRST.  Give that unit a 10 second "head start" and then power up the next switch.  Give that a 5 second "head start" and then power up the rest at 5 seconds interval.  This will ensure the stack will be assigned to their correct "order".
4. When the stack is finally up and all members are "in", configure switch priority -- this is mandatory.

NOTE:  

Unlike the 3750-, 3650- and 3850-series of switches, the 9300 can support up to 16 switch members in a stack (software support 16.10.X and later).  This means that the stack priority "interval" drops down to 1 (instead of 2).  

[Marlon AJ]

Good day,

Thank you very much @Leo Laohoo :). Regarding to @Joseph W. Doherty  reply, it's ok to say that the uplink switches shouldn't be master or standby? Regarding to the 9k series switch stacks.

Thanks in advanced.

[Leo Laohoo · Accepted solution]

---

@Marlon AJ wrote:

it's ok to say that the uplink switches shouldn't be master or standby

---

That will depend entirely on how to make your network (design) "pretty". 

Traditional method is to put the uplink on the primary and the redundant link on the secondary. 

Lately, I have seen people put the primary uplink AWAY from the stack master.  The reason is because if the stack master crashes the primary uplink goes down with it.  I would recommend people to put the primary uplink into the secondary or the tertiary member of the stack.  

[Seb Rupik · Accepted solution]

The design pattern mentioned by @Joseph W. Doherty  of not connecting uplinks to stack master has been in the Campus CVD for years. The current version which specifies C9000's:

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-campus-lan-wlan-design-guide.html

...still suggests it as best practice:

"Another best practice is to select switches without uplinks as the active and standby of the switch stack, as shown in the figure above. Uplinks should be provisioned on the member switches. This way, if the active switch of the stack fails, you don’t have a double failure – meaning that you lose both the active switch and half of your uplinks."

cheers,

Seb.

[Marlon AJ]

Good day,

Thank you very much guys @Seb Rupik @Leo Laohoo @Joseph W. Doherty @Reza Sharifi  for the valuable information. It will be of great help at the moment of designing my network.

Have a nice day everyone and again, thank you very much.

[Jesse P]

I don't see how that makes things any safer than using a switch WITH uplinks as the active or standby.  If the switch with uplinks fails - whether it's the active or standby stack master, or just a member switch - it's still taking the uplinks with it, and moving the uplinks to a remaining member is still a potential necessity.

Maybe I'm missing something.

[Joseph W. Doherty]

"Regarding to @Joseph W. Doherty reply, it's ok to say that the uplink switches shouldn't be master or standby? Regarding to the 9k series switch stacks."

I would say yes (to keep uplinks off master and first potential replacement), both by the documents I referenced in my original post, and what @seb Rubik also found. Although, Cisco's recommendation, in Seb's reference, doesn't, to me, make much sense. Unclear why this "double failure" is a real issue.

I.e. Ok, so you lose the master switch with uplinks. How's the impact really worst? Stack recovers from losing a master, regardless of having uplinks on it or not. Losing an switch with uplinks, you lose those uplinks. The first "failure" is transient, the second failure is same regardless of which switch is hosting the uplinks. So, again, don't see why this "double failure" is really a reason to avoid placing uplinks on expected master or its primary backup.

(I recall [?] reason for avoiding master and its backup, at least way back on 3750s, although data plane was distributed across all the switches, control plane was managed by current/active master. Thinking appeared to be to avoid any extra data plane processing on the switch supporting control plane.)

As an aside, personally, beyond avoiding having all uplinks on just one switch, I never thought this recommendation mattered that much. Again, at least on the 3750 stacks, a more important consideration, for a master switch failure, was, by default, change in MAC(s), for the stack. 3750 stack would recover, but other devices depending on stack's MAC(s), might take some extra time to resolve a new stack MAC.

[Marlon AJ]

Good day,

Do you think it may be related to the STP logic?

@Joseph W. Doherty wrote:
"Regarding to @Joseph W. Doherty reply, it's ok to say that the uplink switches shouldn't be master or standby? Regarding to the 9k series switch stacks."

I would say yes (to keep uplinks off master and first potential replacement), both by the documents I referenced in my original post, and what @seb Rubik also found. Although, Cisco's recommendation, in Seb's reference, doesn't, to me, make much sense. Unclear why this "double failure" is a real issue.

I.e. Ok, so you lose the master switch with uplinks. How's the impact really worst? Stack recovers from losing a master, regardless of having uplinks on it or not. Losing an switch with uplinks, you lose those uplinks. The first "failure" is transient, the second failure is same regardless of which switch is hosting the uplinks. So, again, don't see why this "double failure" is really a reason to avoid placing uplinks on expected master or its primary backup.

(I recall [?] reason for avoiding master and its backup, at least way back on 3750s, although data plane was distributed across all the switches, control plane was managed by current/active master. Thinking appeared to be to avoid any extra data plane processing on the switch supporting control plane.)

As an aside, personally, beyond avoiding having all uplinks on just one switch, I never thought this recommendation mattered that much. Again, at least on the 3750 stacks, a more important consideration, for a master switch failure, was, by default, change in MAC(s), for the stack. 3750 stack would recover, but other devices depending on stack's MAC(s), might take some extra time to resolve a new stack MAC.

---

[Joseph W. Doherty]

"Do you think it may be related to the STP logic?"

Hmm, perhaps.

STP, I believe, is managed at the control plane, so losing the active/master switch may impact that, possibly more so if stack's MAC(s) change. Losing L2 uplinks, if not in an Etherchannel (across stack members), may also impact STP. So, possibly yes, the "double failure" might be "worse" for something like STP. (I don't recall every having a stack of switches not using either L2 Etherchannel or L3 for uplinks [also on different stack members], i.e. an issue I haven't considered before.)

Excellent question!