08-19-2020 12:29 PM
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.
Solved! Go to Solution.
08-19-2020 05:24 PM
@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.
08-20-2020 02:09 AM - edited 08-20-2020 02:13 AM
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.
08-19-2020 12:55 PM - edited 08-19-2020 12:57 PM
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
08-19-2020 01:05 PM
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.
08-19-2020 02:09 PM - edited 08-19-2020 02:11 PM
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
08-19-2020 02:17 PM - edited 08-19-2020 02:24 PM
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
08-19-2020 03:48 PM
Best practice/rule-of-thumb -- Here's how it goes ...
NOTE: This is only valid for the 3750/G/E/X, 3650/3850.
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).
08-19-2020 04:43 PM
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.
08-19-2020 05:24 PM
@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.
08-20-2020 02:09 AM - edited 08-20-2020 02:13 AM
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.
08-20-2020 09:24 AM
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.
11-22-2023 07:35 AM - edited 11-22-2023 07:36 AM
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.
08-20-2020 09:31 AM
08-20-2020 10:40 AM
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.
08-20-2020 11:03 AM - edited 08-20-2020 01:45 PM
"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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide