cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
320
Views
3
Helpful
24
Replies

C9350 Stack Ring Closure Caused Stack Reload – Expected Behavior?

athan1234
Level 8
Level 8

Hi everyone,

I experienced an issue yesterday with a Cisco C9350-48T stack running IOS XE version 17.18.03a.

The stack consists of 7 members. During the initial installation, I was unable to fully close the stack ring because the available stacking cable was not long enough. As a result, the stack has been running in production with an open ring topology.

Yesterday, I attempted to close the ring by connecting a new 1-meter stack cable. However, as soon as I connected the cable to the first switch, the entire stack reloaded unexpectedly.

Is this normal behavior when closing a stack ring on a live production stack?

I am aware that Cisco recommends performing stack cabling and ring formation while the stack is powered off, but I would like to understand whether a stack reload is expected in this scenario or if this could indicate another issue.

Has anyone experienced something similar?

Thanks in advance.

24 Replies 24

found this (old) document: https://community.cisco.com/legacyfs/online/legacy/9/8/4/83489-stackwise_wp_0321.pdf
where it is mentioned that a loopback is formed in the ASIC

pieterh_1-1784137473664.png

 

 

Yea, basically, that's saying, when a stack port connection is lost, the data that would have been sent across it, is now redirected to the single remaining path.  I.e. everything still functions.  Although, with loss of a stack port connection, possibly, more likely to encounter congestion.

One important thing, to keep in mind about a StackWise ring, both directions are available, although one ring direction might have more congestion and/or latency reaching another switch.  (That's another "feature" of "Smart Stacking", it can choses the "best" path between two switch members.)

Again, though, you physically lose on of the stack port connections, you only have one physical path between a pair of switch stack members.

Remember, whenever a vendor touts "features", they sometimes make them sound much more useful then they actually are, in many cases.  (It sort of reminds me when full duplex Ethernet started to enter the market.  From vendor literature, like Cisco's, they emphasized you now had twice the bandwidth, which was true.  But host A sending data to host B, didn't transfer the data twice as fast!)

>>> walk me through how a ring is provided. <<<
Hi @Joseph W. Doherty , I cannot locate the document that describes that the ring is closed internally.
only that Cisco describes the "dasy-chain" as a "half ring"  compared to a "full-ring" , So  I still  think you must consider this a ring.


@pieterh wrote:

>>> walk me through how a ring is provided. <<<
Hi @Joseph W. Doherty , I cannot locate the document that describes that the ring is closed internally.
only that Cisco describes the "dasy-chain" as a "half ring"  compared to a "full-ring" , So  I still  think you must consider this a ring.


@pieterh if you do come across such a document, please let me know, as I'm really curious how this might be accomplished without a physical ring.

My belief "half-ring" is just Cisco speak for a broken ring, i.e. one that has become a daisy-chain topology.  Sure, switches with two active stack ports have access to twice the stack bandwidth vs. switches limited to just one active switch port, but, again, you still lose half the potential bandwidth between any pair of switches.

BTW, the Cisco Live document I referenced, does make clear, there appears to be many improvements within "Smart Stacking"., new on a couple of the latest 9K switches, like the c9350.  It appears Smart Stacking might also support stacking via the front ports, possibly in addition to the dedicated stack ports.  If both can be used in combination, and/or the front port side supports more than two links, well then, as seems to be alluded to, you might support some form of mesh topology.  If so, you wouldn't necessary lose stack redundancy with loss of just one physical set of stack ports.  (BTW, again, some/many of the "new" Smart Stacking features, were in play, almost a decade ago on some of Brand J's stackable switches.)

aleabrahao
Meraki Community All-Star
Meraki Community All-Star

@athan1234 

A full stack reload is not considered normal or expected behavior simply because you close an open StackWise ring on a running Catalyst 9300 stack.

The reload could have been caused by various factors. I suggest you take a look at this document:
https://www.cisco.com/en/us/support/docs/switches/catalyst-9300-series-switches/217684-verify-and-troubleshoot-stackwise-on-cat.html

I am not a Cisco employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

 


@aleabrahao wrote:

The reload could have been caused by various factors. I suggest you take a look at this document:
https://www.cisco.com/en/us/support/docs/switches/catalyst-9300-series-switches/217684-verify-and-troubleshoot-stackwise-on-cat.html


When I try your link, I get:

JosephWDoherty_0-1784041404279.png

 

aleabrahao
Meraki Community All-Star
Meraki Community All-Star

That's strange, try it again please.

Verify and Troubleshoot Stackwise on Catalyst 9200/9300 - Cisco

I am not a Cisco employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

That one works.

PS:

From that reference:

Add or Replace a Member

Several factors must be considered when you implement a new stack or add a member to an established stack.  Importantly, never connect a powered-on switch into a powered-on stack. Connect new member(s) while powered-down to avoid a stack-merge.  These are other points to consider:

henry-collins
Visitor
Yes, this can happen. When you close a Cisco StackWise ring on a live stack, the stack has to renegotiate the topology and may trigger a reload depending on the platform, IOS XE version, and how the existing stack is handling the change. Cisco’s recommendation to cable the ring while powered off is mainly to avoid exactly this kind of production impact. The reload does not automatically mean there was a fault, but  check the stack logs (show logging), show switch stack-ports summary, and the reload reason to confirm it was a topology change and not a hardware/cable issue.

henry-collins
Visitor

Yes, this can happen. When you close a Cisco StackWise ring on a live stack, the stack has to renegotiate the topology and may trigger a reload depending on the platform, IOS XE version, and how the existing stack is handling the change. Cisco’s recommendation to cable the ring while powered off is mainly to avoid exactly this kind of production impact. The reload does not automatically mean there was a fault, but  check the stack logs (show logging), show switch stack-ports summary, and the reload reason to confirm it was a topology change and not a hardware/cable issue.