C9350 Stack Ring Closure Caused Stack Reload – Expected Behavior?

[athan1234]

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.

[henry-collins]

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]

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.