topic Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation in Wireless

9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Gehrig_W — Mon, 15 Sep 2025 08:23:15 GMT

Hello Cisco-WLAN experts,

we are running the following boxes, which I like to upgrade, in this big hospital:

A HA-pair of 9800-L-C v17.6.3 for Guest-Access
A HA-pair of 9880-80 v17.9.5 with around 2500 APs (Mainly 9130/2800/3800 and handful of 2702i/3702i)
A Backup of two 5520-WLCs and two 2504 Guest-WLCs.

I would like to upgrade the 9800-L-C first and woud like to know:

Is it possible to upgrade a 9800-L-C without APs directly from 17.6.3 to 17.15.3 without having 9130-APs connected directly?

Because I would like to upgrade the 9800-80 also, which needs to be upgraded to a 17.9.6 or later or 17.12.x, I'm thinking about the best SW-combination for both devices , because I would like to upgrade only one box in one maintenance window.

Can I combine a future 9800-L-C Guest-HA-WLC v17.15.3 with a 9800-80-HA-WLC still on 17.9.5 for a while ?

Or better wait for the following to be resolved:

17.15.4 has been removed for download from cisco.com due to an mDNS gateway regression (Cisco bug ID CSCwr09565

17.12.6 has been removed for download from cisco.com due to an mDNS gateway regression (Cisco bug ID CSCwr09565

A revised version with the fix will be posted.

The Software-Quality and Software-Testing of Cisco 9800-WLC is not very customer-friendly and confidence-inspiring by the way.

Please check and come back with recommendation for SW-Upgrade.

Nice Greetings from Wuerzburg, Frankonia, Bavaria, Germany

Wini

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Mark Elsen — Wed, 10 Sep 2025 12:28:19 GMT

- @Gehrig_W >...Is it possible to upgrade a 9800-L-C without APs directly from 17.6.3 to 17.15.3 without having 9130-APs connected directly?
Yes

In my opinion there shouldn't be a 'SW-combination for both devices' ; and a good plan is to use the same
software version on all 9800 controllers for uniform management , experiences and problem handling , if needed.
But yes you can combine a 9800-L-C Guest-HA-WLC v17.15.3 with a 9800-80-HA-WLC still on 17.9.5

For the MDNS regression bug avoidance (upgrade planning) ; depends on if you need that functionality.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

balaji.bandi — Wed, 10 Sep 2025 14:19:36 GMT

as per i know 17.15.3 you need to go step upgrade read the release notes if you have 9130 AP.

https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-15/release-notes/rn-17-15-9800.html

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

MHM Cisco World — Wed, 10 Sep 2025 14:23:27 GMT

You need plan

1- check compatibility between new ver and AP

2- check compatibility of new ver with ISE since you mention guest and I think you use CWA

After above you can decide which ver is OK or maybe dont upgrade if there are alot of incompatibility

MHM

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Leo Laohoo — Fri, 02 Jan 2026 02:49:09 GMT

@Gehrig_W wrote:
A HA-pair of 9800-L-C v17.6.3
A HA-pair of 9880-80 v17.9.5

1. All the APs hosted by the 9800 will need to be rebooted before the WLC reboots. I have a high degree of confidence that all the APs are affected by CSCwe15172, CSCwe97901, CSCwm08044, CSCwm07499, CSCwm72142, CSCwo05017. IF the APs are not rebooted (and the WLC gets rebooted to the new version), the APs will join the WLC and will be in a constant "Download" loop.

2. If the upgrade will be using ISSU, I strongly recommend raising a pro-active TAC Case 15 minutes before the start of the ISSU upgrade and the TAC engineer is WebEx into the controller(s). If something should ever go wrong with the ISSU upgrade, the TAC engineer can quickly intervene.

@Gehrig_W wrote:
The Software-Quality and Software-Testing of Cisco 9800-WLC is not very customer-friendly and confidence-inspiring by the way.

I do not believe Cisco test their software nowadays. It is up to customer to test them and, with valid Service Contract, raise a TAC Case to report any issue(s) encountered or a collective face-palm sans Service Contract. I have observed that the quality (control) has deteriorated since the introduction of IOS-XE version 16.X.X.

Going forward, I strongly recommend a daily reboot of APs as part of the "wellness" of the wireless network.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Saikat Nandy — Thu, 11 Sep 2025 17:14:05 GMT

You can go for 17.15.3 irrespective of the fact whether it is Anchor WLC or 9800-L/80.. The re-spin images of 17.15.4 and 17.12.6 will take apprx another 2 weeks time to get released. Even though it gets released, we are not going to mark it as recommended. SO keeping that in mind 17.15.3 + Applicable SMU/APSP is the best option at this point.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Rich R — Thu, 11 Sep 2025 23:28:30 GMT

Remember the TAC Recommended code doc (link below) should be your main reference for code versions.

The Wave 1 IOS APs are not supported in 17.15.x - last supported in 17.12.x.

The release notes always include the Upgrade Path:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-15/release-notes/rn-17-15-9800.html#Cisco_Concept.dita_59a2987f-2633-4630-8c7b-a8e8aecdeaf7
Since you don't have 9124 or 9130 you can upgrade directly to 17.15.x.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

balaji.bandi — Fri, 12 Sep 2025 06:45:02 GMT

@Saikat Nandy - can you just confirm upgrading from 17.9.5 to 17.15.3 - will the below Bug will be effecting the environment, when we doing ISSU upgrade, is the AP will upgrade based on rollup upgrade 15% or they crash and reboot all AP ?

https://quickview.cloudapps.cisco.com/quickview/bug/CSCwm08044

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Leo Laohoo — Fri, 12 Sep 2025 07:15:40 GMT

CSCwe97901, CSCwm08044 &/or CSCwm72142 are present in 17.3.X, 17.6.X, 17.9.X and17.12.X.

Our controllers are currently on 17.12.5 and I have witnessed several 9130/9166 with error messages about the unable to clear out the /tmp directory.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Gehrig_W — Fri, 12 Sep 2025 12:20:29 GMT

Leo, that is interesting because the Release-Notes state that CSCwm08044 is resolved in Version 17.12.5

Thank You very much for all Your comment and recommendations.

The Release-Notes also contain the following advice:

When you upgrade from Cisco IOS XE 17.9.5 or 17.12.2 to Cisco IOS XE 17.15.x, the controller WebUI does not support images greater than 1.5 GB. Workaround:
• Upgrade using the CLI commands, or,
• Upgrade to a fixed release first, and then upgrade to 17.15.x.

Does anybody know which SW-Release fixed this WebUI-Bug regarding images greater 1.5GB ?

Thank You

Kind regards

Wini

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

vkokila — Fri, 12 Sep 2025 12:51:10 GMT

Fix is available from 17.9.6 / 17.12.3 onwards - CSCwi36624

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Leo Laohoo — Wed, 25 Mar 2026 22:57:44 GMT

@Gehrig_W wrote:
the Release-Notes state that CSCxx12345 is resolved in Version 17.12.5

To be frank, I am skeptical to what Cisco TAC/developers promise. Specifically what version Bug XYZ is fixed in. For example: CSCwn92827. From the Bug ID, I can see the following:

Date in the customer-provided logs: 09 January 2025
Firmware version of the controller: 17.12.4
Customer Name: Austral

So far so good? Now cast your eye on another bug: CSCwr09991

Date in the customer-provided logs: 03 September 2025
Firmware version of the controller: 17.12.5
Customer Name: Austral

Now read the details in both bugs. Now imagine what the internal case notes to both TAC Cases would read like. To me, it would read like this:

TAC (in response to CSCwn92827): Upgrade the firmware to 17.12.5 and the bug will be fixed.
Customer: OK.

Customer goes off and upgrade the HA SSO to 17.12.5 ... 8 months later, the pair crashes. Customer raises another TAC Case.

TAC (in response to CSCwr09991): Upgrade the firmware to 17.12.6 ... Oh, wait. 17.12.6 has been removed because of a catastrophic mDNS bug. Maybe upgrade to 17.15.4 ... Oh, wait ...

These kind of bugs reinforces my opinion that IOS-XE is buggy and memory leaks like a sieve. Because of this, I have opined:

1. Reboot APs ~~weekly~~ daily;
2. Reboot the WLC every 6 to 8 months;
3. Apply APSP &/or SMU only when it matter, i. e. Do not apply APSP &/or SMU "just because" -- There have been several Bug IDs where the Workaround has been "do not apply APSP <NUMBER>".
4. For multi-WNCD controllers, i. e. 9800-40/-80, 9800M, H1/H2, keep 50% AP scale, i. e. If the controller is advertised as capable of supporting 6k APs, keep the actual number of APs to <50%. (Refer to CSCwn36778)
5. For multi-WNCD controllers, keep <50% wireless client numbers. (Refer to CSCwn36778)
6. No fancy SSID authentication -- Keep it simple: Open SSID or PSK only.
7. No web authentication
8. HA SSO: We found out that HA SSO is only stable on paper. In practice, we had to reboot ours every 3 to 4 months so we converted them to N+1.
9. "telemetry" (a euphemism for DNAC), gRPC, API, NMSP, etc: TURN TELEMETRY OFF.
10. Wireless clients constantly attempting to join the SSID (due to wrong settings, expired certificates, wrong passwords, etc): Keep them off the WiFi. Constant bombardment of wireless clients attempting to join the SSID will break/crash on the controller.  CSCwq73135, Cisco IOS XE Software TLS Memory Exhaustion Denial of Service Vulnerability
11. APs constantly leaving and joining the controller: Take them off because they will break/crash the controller.
12. Religiously monitor the control-plane memory utilization because DNAC will not and a lot of SNMP products do not either.

sh platform software status con brief

Ideally, the value should stay <40%. If the value goes up to 80%, reboot the controller immediately.

13. Religiously monitor the TMPFS because DNAC will not.

sh platform software mount 0 | include tmpfs.*tmp

Normal value is <10%. If the value >45%, the controller will start sending out logs. Do not wait until TMPFS hits 80% because things (and performance) will start going downhill very fast (CSCwo50092).

Hope this helps.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Leo Laohoo — Fri, 12 Sep 2025 13:03:33 GMT

@Leo Laohoo wrote:
If the value goes up to 80%, reboot the controller immediately.

Question: Why "reboot the controller immediately"? Why not get TAC involved?
Answer: TAC may be competent but, at the end of the day, will recommend only one of two options: Reboot the controller or "upgrade" the controller firmware to an XYZ version to "fix" the memory leak.

Upgrading the controller version serves only one purpose: Reboot the controller. The chance that the bug causing the memory leak (or whatever issue) will be really, really fixed in XYZ version is 50%. However, the chance of encountering a new and different kind of bug is about 80%.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Rich R — Fri, 12 Sep 2025 13:35:11 GMT

@balaji.bandi CSCwm08044 clearly shows affected versions include 17.9.5:

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

balaji.bandi — Sat, 13 Sep 2025 07:25:04 GMT

@Rich R thank you yes i have seen it, but my surprise here is each Cisco engineer of TAC have different views. (one claim to be )

Definitely Cisco need to improve their transparency to customer, and tell the fact if you upgrading, you have service outage, not claiming that zero service interruption.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Rich R — Sat, 13 Sep 2025 09:28:23 GMT

The point is that those versions are vulnerable to being affected. It does not mean that every AP will be affected every time, just that they could be.

So you can either try upgrading and then only power cycle those that are affected during the upgrade because the upgrade will fail and they get into endless download cycle. This will waste time and prolong the upgrade and outage time.

Or you can reboot all the APs in advance to ensure that none of them have the problem when you do the upgrade.

AP reload (impossible to upgrade AP software without a reload) has never been zero service interruption and I've never seen anybody claim that. 9800 does try to minimise impact by allowing you to do the phased upgrades which works if the site has enough APs with enough coverage. If a site only has one AP then there is no way to avoid a service interruption.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

balaji.bandi — Sat, 13 Sep 2025 10:27:41 GMT

never been zero service interruption and I've never seen anybody claim that. 9800 does try to minimise impact by allowing you to do the phased upgrades which works if the site has enough APs with enough coverage.

This very interesting, this what i was referring, but most of the Cisco ISSU upgrade Zero downtime when the Client steering take place when you do Roll up upgrade(cisco approved design guide of deployment and best practice we considering here).

Its not make any send 1 AP in the network and expect no downtime in service (point that is noted )

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Leo Laohoo — Mon, 22 Sep 2025 23:51:17 GMT

17.15.04b is now out.

17.12.06 in the next few days.

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

UKW-NK-Cisco — Mon, 09 Feb 2026 12:46:16 GMT

test 17.9.8

Re: 9800-L-C v17.6.3 and 9800-80 v17.9.5 upgrade recommendation

Gehrig_W — Mon, 09 Feb 2026 12:55:15 GMT

Hello Leo,

Customers using Cisco IOS XE versions 17.12.4, 17.12.5, and 17.12.6 on platforms C9124, C913X, and CW916X are affected by another issue where cnssdaemon log file in the /storage partition grows continuously. This log file can grow approximately 5MB per day (~1.8GB per year uncompressed), which can fill the part2 partition and prevent upgrades when part1 is the active partition.The cnssdaemon.log file in /storage cannot be deleted via the Cisco CLI.

Install APSP for the release with this fix, and check documentation for instructions on how to check AP available storage space before performing an upgrade.

Here is the official Tech-Note:

Validate and Recover Catalyst APs on 17.12 Impacted by Upgrade Failure

https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/225443-validate-and-recover-catalyst-aps-on.html

Kind regards

Wini

This issue does not impact versions prior to 17.12.4, or if the Access Point is running any release after 17.12.6a, for example 17.15.x and it has never installed any of the impacted versions.