topic Re: 9800-CL upgrade path from 17.9.3 to 17.15.5 - Peer Review! in Wireless

9800-CL upgrade path from 17.9.3 to 17.15.5 - Peer Review!

Jordan M — Fri, 29 May 2026 16:08:35 GMT

Hey everyone,

We have a 9800-CL and about 3000ish AP's (Models: 2802, 3802, 9115, 9130, 1562, 9124, 9164). We are preparing to upgrade from IOS XE 17.9.3 to 17.15.5. Wireless is absolutely mission critical for us, I am just asking for a sanity check to make sure I am not missing anything.

Per the doc below, we are going to upgrade first to 17.12.7a, then from there to 17.15.5. The driver for this is that we are migrating form 9800-CL to new CW9800H1 hardware units, for which the TAC recommended release is 17.15.5 (and does not support older code such as 17.12.x). We are purely going to 17.12.7a to hop directly to 17.15.5.
Source: Upgrade Path to 17.15.5

Question: Please take a look at the rough outline for my plan below. I'd appreciate any input, recommendations, or for anyone to look in my blind spot here, as I want to ensure this goes as smoothly as possible. I have seen some bugs (CSCwf25731/CSCwf37271 in particular, and FN74109).
Also - CSCwj73634 "Full or partial 9800 configuration loss after HA SSO failover" which DOES affect our current version 17.9.3. We are using N+1 Upgrade rather than ISSU, but our primary WLC is still in HA-SS0. How to avoid this when we upgrade that cluster?

Plan of action:
- Predownload firmware on all AP's. Due to FN74109 (which doesn't look like it affects 17.9.3, but just want to be safe as all AP's will download over WAN via CAPWAP) I will pre-download firmware to AP's. I'll SSH to a AP's at a test location and run "Sh image integrity" to validate. I'll increase CAPWAP image size to roughly 15 to see if this helps speed things along and will give myself plenty of time before the maintenance window.

- While we have HA-SSO on our primary WLC, we also have redundant WLC's. I will avoid ISSU upgrades due to the warning in the image below and utilize "N+1 Hitless Rolling Upgrades."

- After verifying AP's have pre-downloaded image, I will utilize the 'site filter' feature to upgrade a certian # of sites at a time, validate, then move to the next group of sites. To my knowledge, this is based off of site-tags. I'll use the 'Fallback' method as well to automatically migrate AP's back to the primary WLC once the upgrade is complete.

- Once AP's are migrated off Primary WLC, Upgrade it and allow AP's to migrate back.

- Repeat process for 17.15.5, but utilize pre-download via HTTPS (w/fallback to CAPWAP) & "Efficient Image Upgrade" to optimize image downloads to AP's over WAN links.

Re: 9800-CL upgrade path from 17.9.3 to 17.15.5 - Peer Review!

aleabrahao — Fri, 29 May 2026 16:36:05 GMT

It seems like a good plan; if you do it in stages there's nothing to worry about. If you're still unsure, test with one or two APs first.

But the update itself is relatively simple. I honestly never checked the image integrity beforehand, as the WLC itself does that during the update process.

Re: 9800-CL upgrade path from 17.9.3 to 17.15.5 - Peer Review!

Mark Elsen — Fri, 29 May 2026 17:35:40 GMT

@Jordan M Personally and because of the dollar value of the new equipment and the importance of the
project I would fallback to TAC as an authoritative master peer reviewer.
I read through it, there could be pitfalls and I perhaps didn't notice them

You can also consult a 9800 specialist from the reseller you bought the CW9800H1
There are a multitude of arguments for going that way and being 'business solid'.
Let alone if it goes wrong ; you can always say; it was not me boss , it was them.... (smile)

It comes down to : The Community is to weak to give the green light

Re: 9800-CL upgrade path from 17.9.3 to 17.15.5 - Peer Review!

Stefan Mihajlov — Fri, 29 May 2026 17:40:05 GMT

@Jordan M plans look solid.. for CSCwj73634 trigger is sso failover itself- so backup ur cfg + show tech; then remove standby from HA pair before u reload active 🙂 with no failover event, bug cant fire,repair standby once both are on target code.. so stage ur predownload in small per-model bacthes first to baseline CAPWAP-overWAN timing rather than firing all 3000 at once :).. but its looks u have already covered most blind spots

Re: 9800-CL upgrade path from 17.9.3 to 17.15.5 - Peer Review!

aleabrahao — Fri, 29 May 2026 17:51:21 GMT

@Mark Elsen , please forgive me, but I'm actually a Cisco Wireless solutions specialist and have done hundreds of migrations over the years, so I wouldn't underestimate the community like that.

Re: 9800-CL upgrade path from 17.9.3 to 17.15.5 - Peer Review!

Leo Laohoo — Sat, 30 May 2026 02:23:36 GMT

First, I have no idea what research have been done but we have been told by Cisco TAC Wireless that they will guarantee 80% FAILURE RATE (conservative) for any upgrades with ISSU starting from 17.3.X, 17.6.X, and 17.9.X.

Let me repeat that again: 80% FAILURE RATE with ISSU.

If someone wants to ignore the above-mentioned warning, please do not ignore the next one: Raise a pro-active TAC case. Make sure the TAC Agent or Engineer is WebEx into the WLC before the start of the ISSU. The logic behind this is simple: If-and-when something go wrong with the ISSU process, the TAC Agent or Engineer is ready to immediately intervene.

In the 17.15.X Release Notes, it is stated that:

Due to a collateral introduced in 17.15 and later versions, the ISSU process must be avoided when upgrading to versions 17.15.1 - 17.15.4d, 17.18.1, and 17.18.2 releases. This is due to CSCws19380, CSCws35670, and CSCwr15775.

Count it. That's is 3 x Bug IDs. However, read further down and it states:

The ISSU upgrade issues have been resolved in version 17.15.4d, which includes fixes for defects CSCws35670 and CSCwr15775.

So what happened to CSCws19380? I'm not risking the stability of my wireless network to find out and neither should anyone.

There is another option to do this and it is an option that Cisco refuses to let anyone know about: Upgrade Software on Catalyst 9800 with N+1 Rolling AP Upgrade

The AP Hitless Upgrade, aka Rolling AP Upgrade, has worked well with us for the last 4 years. We have several 9800-40/-80 servicing several 24x7-outage-cannot-be-tolerated health facility and we have done a lot of upgrades using this method during business hours without any impact to the wireless clients. Zero impact. During business hours.

Next, in regards to FN74109, reboot all the APs one hour before the start of the upgrade. The bug resides in the /tmp sub-directory and gets purged every time the AP reboots or crashes. Rebooting the AP before the start of the WLC upgrade guarantees that the /tmp bloatware is at a manageable level and can take the download of the new firmware successfully. Failure to heed this warning and the AP will be in a constant "Downloading" state.

Another, 17.15.5, please read the Release Notes carefully, particularly, the Open Caveats section. 17.15.5 APSP2 Release Notes is also helpful to be aware of, particularly CSCws93044/CSCwt98551. For 17.15.X itself, I would be very wary about CSCwt91818, CSCwu52200, CSCwr20303 because these bugs are very easy to trigger.

WARNING: Information found in Bug IDs are not to be taken at full face value. Most of the time, Known Affected Releases and/or Known Fixed Releases are incorrect. That's a guaranteed fact.

And finally, a warning: After several years of warning everyone in this forum about it, Cisco has (finally) started to take notice of the memory leaks in the control-plane. CSCwt53635 is one of the examples. Please make it a point to monitor the memory utilization of the control-plane daily. That is correct: DAILY.

The most helpful commands are the following:

show platform resources sh platform software status control-processor brief

If the control-plane memory utilization goes >70%, start planning for a controller reboot.

If the control-plane memory utilization is >85%, the controller needs to be reboot urgently, as in NOW.

Another command that is not "visible" is the WLC's /tmpfs sub-directory which can crash the controller if the bloatware is not monitored daily/regularly with this command:

sh platform software mount 0 | include tmpfs.*tmp

Ideally, the /tmpfs file size should not >9%. If-and-when the /tmpfs is >80% reboot the WLC urgently.

Hope these help.

Re: 9800-CL upgrade path from 17.9.3 to 17.15.5 - Peer Review!

Rich R — Sat, 30 May 2026 13:23:19 GMT

@Jordan M overall looks like a good plan to me. A few comments:
- primary WLC is still in HA-SS0. How to avoid this when we upgrade that cluster?
I don't think there is a lot you can do - just be prepared to deal with it if/when it happens. I believe we were the first customer to report this bug to TAC on 17.6 code (even though they later tried to say it's only there from 17.9 lol). When it happens the WLC loses all wireless config (it's in startup but not running) but the base IOS-XE config remains so at least you should still have management connectivity to the WLC.

- I'll increase CAPWAP image size to roughly 15 - I think you mean CAPWAP window size? 😉

- I've also never used "sh image integrity" to validate before and I have doubts about how useful it will be because the problem is that the nature of the bug(s) is that the AP itself doesn't know when the image is corrupted so it's possible that it will say the image is ok even when it isn't. Once you have all the multiple fixes for that issue then the image is actually verified correctly by the AP anyway.

- Consider reloading every AP before you start upgrades/downloads to clear the tmp partition because there are multiple bugs which cause the tmp partition to fill up which causes downloads to fail endlessly and repeatedly.

- I've disabled Efficient Image Upgrade because it caused more problems than it solved for us - but I'll be interested to know how you find it if you depend on it.

- Keep in mind a few APs might not recover after upgrade and might need to be power cycled so watch them closely. If they don't recover after power cycle then most likely need RMA.

- Remember (especially with C916x and CW917x APs) that an unterminated cable (or anything longer than 1m) plugged into the AP console port may stop the AP from booting (so your 9164's are at particular risk from this - it's caught us when doing upgrades when the installer has "helpfully" patched the console port)

Re: 9800-CL upgrade path from 17.9.3 to 17.15.5 - Peer Review!

Rich R — Sat, 30 May 2026 13:30:55 GMT

@Leo Laohoo I think you may have missed where @Jordan M said: I will avoid ISSU upgrades due to the warning in the image below and utilize "N+1 Hitless Rolling Upgrades." 😉