Cisco Stack clarification

[tanner.zaitt]

Hello all,

I have one question.

What is the difference in the behavior of stacked switches in these two possible configurations:
1 All switches in the stack are with default switch priority 1
2 The master switch is with priority 15 the second member of the stack is with 12.

I did see scenario 2 in the core and distribution switching level.
I did see scenario 1 in the access level switching.


Is it scenario 2 SSO architecture?
Why scenario 2?
Why scenario 1?
When 1 is usable and when 2 is usable?

Thank you in advance.
Best Regards.

[Joseph W. Doherty]

What switch priority provides, if all the switches in the stack, boot at the same time, you can control which switch will become the master.

If priority isn't set, the switches use other conditions to determine the master (such as perhaps switch's native MAC and/or the IOS feature set installed [I recall 3750s considered that], etc.)

In your second situation, if, for example, all the switches, but the priority 15 switch are in a "running" stack, adding the priority 15 switch doesn't replace the current master (at least on older stack switches, like the 3750, believe that's still true on newer stackable switches).

What's the point of even "forcing" the master switch?  Cisco recommends (or did on 3750s) master switches not have uplinks.  There also might be some consideration when using the console port, as in, perhaps only the stack master's console port accesses the whole stack.

[Leo Laohoo]

---

@tanner.zaitt wrote:

1 All switches in the stack are with default switch priority 1

---

In addition to @Joseph W. Doherty,

If all switches have a stack priority of 1 and the entire stack reboots/cold boot, the stack will take 2 minutes LONGER to boot because there will be a mandatory "stack master election".  Stack Master Election WAITS for all switch members to boot up.  The switch with the "lowest" MAC address becomes the Master and the next one becomes the secondary (and the song continues). 

If the switch priority is set correct, the system will go something like "stack priority is set to all stack member + all members are accounted for, so no need for stack election".  

The two-minute Stack Master Election stage is not a bug, it is by design.  

[Joseph W. Doherty]

Leo, that's a very interesting observation!  How many different switch series have you noticed this on?

I'm surprised because I would think, even with stack priorities set, switch members need to boot to some extent to "declare" their priority.  Further what if there's something like two switches set with priority 15?  I'm wondering whether there's always an "election", but perhaps with stack priorities set, it's "faster".

[Leo Laohoo]

---

@Joseph W. Doherty wrote:

How many different switch series have you noticed this on?

---

The 2-minute-waiting-for-stack-members?  I have seen this on 2960S/X/XR and 3750-series switches. 

With the Catalyst 9300 (I do not have a 9200 to test and verify), everything we know about "how to stack" with 2960S/X/XR and 3750-series switches process/procedure must be thrown out the window.  The Catalyst 9300 is a different beast and has it's own set of "rules" and gotchas.  

Catalyst 9300 have a different "twist" in it.  In Catalyst 9300, if the switch priority is not set, the stack will have a stack-master-election during every bootup and I am not sure if this is a bug or a "feature".  

---

@Joseph W. Doherty wrote:

Further what if there's something like two switches set with priority 15?  I'm wondering whether there's always an "election", but perhaps with stack priorities set, it's "faster".

---

If two (or more) switches have the same priorities, and the entire stack boots up simultaneously, there will be an election and the "lowest" MAC address becomes the master.  

If I want to "build" a stack, my recommended steps are: 

1. Power up the intended stack master FIRST (this means all switch members must be powered off).  
2. It is highly imperative that stacking cables must not be attached.  Repeat:  DO NOT ATTACH THE STACKING CABLE to any switch member just yet.  Just DON'T!. 
3. Look at the LED display of the intended stack master:  Next to "Mode" button are two rows of LED.  The ones to look out for is the first LED on the top and bottom (from the left), closest to the Mode button.  The "S" and the "*" LED must be SOLID ON and not blinking.  Once these two LED are solid ON, attach the stacking cable(s) to the intended stack master. 
4. Connect the stacking cable from the stack master to the intended standby switch. 
5. Power up the intended standby switch. 
6. Again, like step 3, look at LED display and wait for the "S" and the "*" to be solid ON.  
7. Rinse, repeat until all stack members are formed and in the order desired.
8. Manually configure the switch priority while it is possible (and before anyone forgets).  
9. DONE.  

My apologies for a long and tedious process. 

Hope this helps.

[Joseph W. Doherty]

Tx!

[tanner.zaitt]

Please Could you explain me this:
https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9200-series-switches/nb-06-stackwise-architecture-cte-en.htmlSSO architecture

The highly resilient stateful switchover (SSO) technology is a widely deployed solution in mission-critical campus and branch network designs. The key advantage of SSO is that it constantly delivers network availability without compromising performance and scalability during planned or unplanned network outages. The StackWise-160/80 architecture takes advantage of the same technology to maintain state machines and gracefully recover during an ACTIVE switch failure.

StackWise-160 SSO technology expands route processor redundancy (RPR) capabilities to provide transparent failover of several high-availability-aware Layer 2 and 3 protocols and Cisco IOS Software applications when the ACTIVE switchover occurs.

The state machines of non-high-availability-aware protocols and applications are not synchronized from ACTIVE to STANDBY, something the Cisco Catalyst 9200 Series Switches require to rebuild adjacencies and forwarding entries during an ACTIVE switch failure.

Implementing StackWise-160/80 SSO

To increase availability, the SSO capability is enabled by default when Cisco Catalyst 9200 Series Switches are deployed in StackWise-160/80 mode. No additional user intervention is required to enable this capability. The user can verify that SSO is configured and that the operational state is using a consistent CLI as a modular Cisco Catalyst system. The following example shows sample output of SSO redundancy states in the StackWise-160-based network design.

C92-Stack#show redundancy states

       my state = 13 -ACTIVE

     peer state = 8  -STANDBY HOT

           Mode = Duplex

           Unit = Primary

        Unit ID = 1

Redundancy Mode (Operational) = sso

Redundancy Mode (Configured)  = sso

Redundancy State              = sso

     Maintenance Mode = Disabled

    Manual Swact = enabled

 Communications = Up

   client count = 86

 client_notification_TMR = 30000 milliseconds

           RF debug mask = 0x0  

CoreSW#show redundancy states
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 2

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Manual Swact = enabled
Communications = Up

client count = 110
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0
1 Standby 00b8.b3c3.af00 14 V01 Ready
*2 Active 00b8.b3c3.b180 12 V01 Ready

Distribution switch#show redundancy states
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 1

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Manual Swact = enabled
Communications = Up

client count = 86
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0

*1 Active 00a5.bf2a.2380 14 V02 Ready
2 Standby 00a5.bf5b.1080 12 V02 Ready

AccessSW#show redundancy states
no output
1 Member 1c1d.86bf.3400 1 4 Ready
2 Member 3c0e.230a.1800 1 4 Ready
*3 Master 1c1d.866f.cd00 1 4 Ready

[Leo Laohoo]

Explain what?  

[Mohsin Alam]

Is it scenario 2 SSO architecture? Both will be SSO 
Why scenario 2? 
Why scenario 1?

Whatever the scenario is , the switch will always be in SSO and priority is only for election and has nothing to do with redundancy mode.
When 1 is usable and when 2 is usable?

Depends how you want to use it, it's better to have good marking of priorities for the switches. 

## Make sure to mark post as helpful, If it resolved your issue. ##

[tanner.zaitt]

If I understand you correctly with manually configured switch priority we win two minutes avoiding master elections

Am I right?

And it's not wrong with default configuration switch priority 1?

At Core and distribution level manually is configured to win two minutes during boot without master election

If I should set manually priority in access level switching.
The high priority I will give to the switch with the uplink to the network.
I am on the right path?

[tanner.zaitt]

What will happen if two switches at stack with switch priority 1. one of them unexpectedly rebooted?

I did see for now what is happening when two switches at a stack, switch A  with priority 15 and switch B with priority 14.
If I reboot Master switch A the B switch will be Master transperently.
If I check the uptime the rebooted switch A with priority 15 is now with short uptime of 6 days and it's not master, but the switch B now is the master even with low priority 14, the uptime is 2 years.

[Mohsin Alam]

hmm see stacking doesn't work like HSRP or other protocols where higher priority stays on top always.

There is no preemption in stacking , so if you have 2 priorities consider this:

Switch A = 15

Switch B= 14

Initially switch A is master, once you reboot A switch B becomes master and stays master even if A comes back.

So now if you reboot B then A will become the master again. You can use --> Redundancy force-switchover to achieve this.

Also when you say giving correct priority reduces 2 min time , you are right.

It helps with who always becomes master and there is nothing wrong in giving 2 switches priority as 1.

The switch that boots up first becomes the master.

So now consider this, you have 2 switches :
Switch C = 15
Switch D = 1 

you would assume switch C will be master, but if you boot up switch D first and then later C. Switch D will become master because during the initial wait of 2 minutes switch C did not respond and D thought it was the only switch in stack.  

I hope you have a clear understanding now. 

## Make sure to mark post as helpful, If it resolved your issue. ##

[tanner.zaitt]

Thank you guys for the clarifications.

I received a strange request for this difference in the corporate network.
But with your help, I handled the case.

Best Regards.