Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
633
Views
1
Helpful
1
Replies

CSCwp27622 - Activation of C2960X stack switches is failing

Go to solution
FXPlusInfrastructure
Level 1
Level 1

‎06-03-2025 07:01 AM

Hi,

We are experiencing this exact same issue with distributing the c2960x-universalk9-tar.152-7.E12.tar software to switch stacks.  We are scheduling the jobs to apply the software update outside of normal working hours (autonomously), however despite the distribution part for the update working, the activation for switch stacks fails every time.

When checking the targeted switch stack afterwards we can see that the software exists on the switches (every member in the stack), the software directory is present:

  • 5 drwx 512 Jun 3 2025 12:04:18 +01:00 c2960x-universalk9-mz.152-7.E12

The .tar file is within that directory (the same as all previous IOS iterations):

  • flashX:c2960x-universalk9-mz.152-7.E12/c2960x-universalk9-mz.152-7.E12.bin  [where X is the flash of the stack member]

For whatever reason the boot path-list doesn't seem to get touched by the scheduled job. ["Show boot" output attached]

We initially started the deployment via Catalyst Center (2.3.7.6-70319) and whilst we're aware this isn't the latest version, it appears the user who submitted the bug report above is on the newer version already and is experiencing the same issue.
We've verified the md5 / sha checksum of our download and it matches that on Cisco's download website, we've also tried a new download in the event something went wrong.

We've also pre-prepped the switches to ensure there is enough free space (~80Mb per switch in stack) for the file to untar.

As we're still transitioning away from Cisco Prime (I know.  We'll get there eventually!) we still had visibility of the switches in Prime so we've also tried the software distribution from there with the same result, failed activation.

In Prime I have cobbled together a CLI template ["Prime Fix" attached] so I can schedule the activation and reload, so that the switch stack will autonomously go "live" on the E12 version, however that means each switch stack needs to be hit with a two-pronged approach which slows everything down as we have 133 stacks (albeit some are single switches).  This is what is currently the fix for us in Prime at least.

Is this release of E12 just bugged as all previous iterations we've rolled out E11, E10, E7 etc have all worked perfectly fine in a single distribution & activation job.  Can anyone help shed some light or at least confirm our thinking that there is a coding issue with this latest E12 release or that this bug is properly on the radar?

Thanks,
Phil W

Labels:
Preview file
1 KB
Preview file
1 KB
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
FXPlusInfrastructure
Level 1
Level 1

‎06-10-2025 01:41 AM - edited ‎06-10-2025 01:50 AM

For anyone reading, I have reported this to Cisco and a Cisco TAC engineer has responded:

_____

Starting with 15.2(7)E12, a change in how the .tar package is structured or processed by Catalyst Center's SWIM engine leads to stack boot variables not being updated during activation.

Why E11 and Earlier Worked:

In E11 and earlier releases, DNAC correctly parses the tarball, extracts the .bin, and updates boot system lines across all stack members.
Activation proceeds cleanly because the boot variable gets set and saved.

Why E12 Fails:

  • In E12, although the .tar is distributed and extracted successfully, the boot system command is not applied.
  • This happens only on stacked 2960X switches, not on standalone units.
  • The “activate” phase silently fails due to this missing command, leading to a reboot into the previous version (e.g., E11).

Confirmed Bug Behavior

Cisco has this internally tracked (e.g., CSCxxxxxxx or variant). The cause appears to be:

  • Regression or missed logic path in DNAC’s SWIM job handling for 2960X stacks
  • Possibly linked to changes in the .pkglist or directory structure of the E12 tarball
  • DNAC is not writing to BOOT path-list for stack members as expected

Workaround (what you're already done)
You’re scripting this via CLI template:

conf t
boot system switch all flash:/c2960x-universalk9-mz.152-7.E12/c2960x-universalk9-mz.152-7.E12.bin
end
write memory
reload

This is the only known working method until DNAC fixes the SWIM logic.

View solution in original post

1 Reply 1

Go to solution
FXPlusInfrastructure
Level 1
Level 1

‎06-10-2025 01:41 AM - edited ‎06-10-2025 01:50 AM

For anyone reading, I have reported this to Cisco and a Cisco TAC engineer has responded:

_____

Starting with 15.2(7)E12, a change in how the .tar package is structured or processed by Catalyst Center's SWIM engine leads to stack boot variables not being updated during activation.

Why E11 and Earlier Worked:

In E11 and earlier releases, DNAC correctly parses the tarball, extracts the .bin, and updates boot system lines across all stack members.
Activation proceeds cleanly because the boot variable gets set and saved.

Why E12 Fails:

  • In E12, although the .tar is distributed and extracted successfully, the boot system command is not applied.
  • This happens only on stacked 2960X switches, not on standalone units.
  • The “activate” phase silently fails due to this missing command, leading to a reboot into the previous version (e.g., E11).

Confirmed Bug Behavior

Cisco has this internally tracked (e.g., CSCxxxxxxx or variant). The cause appears to be:

  • Regression or missed logic path in DNAC’s SWIM job handling for 2960X stacks
  • Possibly linked to changes in the .pkglist or directory structure of the E12 tarball
  • DNAC is not writing to BOOT path-list for stack members as expected

Workaround (what you're already done)
You’re scripting this via CLI template:

conf t
boot system switch all flash:/c2960x-universalk9-mz.152-7.E12/c2960x-universalk9-mz.152-7.E12.bin
end
write memory
reload

This is the only known working method until DNAC fixes the SWIM logic.

Customers Also Viewed These Support Documents