07-13-2026 11:24 PM
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.
07-15-2026 10:45 AM
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
07-15-2026 11:06 AM
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!)
07-15-2026 10:33 AM
>>> 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.
07-15-2026 10:53 AM
@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.)
07-14-2026 07:25 AM
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
07-14-2026 08:03 AM
@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:
07-14-2026 08:22 AM
That's strange, try it again please.
Verify and Troubleshoot Stackwise on Catalyst 9200/9300 - Cisco
07-14-2026 09:05 AM - edited 07-14-2026 09:07 AM
That one works.
PS:
From that reference:
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:
07-14-2026 01:09 PM
07-14-2026 01:17 PM
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.
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