update frecuency WLC 9800

[ariask93]

Hey everyone,

I wanted to know if anyone else is concerned about how often we have to upgrade the WLC.

I mean, how do you make that decision? Based on what criteria? It's pretty hard to keep updating every six months in critical services like hospitals, banking, etc.

[balaji.bandi]

update decision based many criteria example my view

1. Cisco support on the code and EOS

2. Security bugs on the code running on the WLC

3. Feature and improvements for better performance

4. any ongoing Bugs or issue you are encounter which suggest to upgrade.

5. Cisco best practice.

Unlike old days you upgrade yearly or what ever latest release available to upgrade.

But due to new trends and new Features, you upgrade process is continuous as life cycle.

[eglinsky2012]

Upgrades here for years have been driven by bugs. Upgrade, fix that bug, another one arises, repeat. Sometimes weeks or months apart. On occasion, over the summer or winter break (we are a university), we'd upgrade for good measure, then something else would break.

Now, we're on 17.12.4 with APSP6. This worked pretty well for us this spring, so this is the first summer I haven't done any WLC code upgrades and this has been the smoothest start of fall semester we've ever had as far as WiFi goes.

We do have a couple minor remaining issues that we may upgrade to APSP10 to resolve if the need arises. But I'm planning to stay on this version as long as possible. Part of this is driven by older APs not compatible with 17.15 and partly by a fix that's on APSP6 and APSP10 that we would lose by upgrading to 17.12.5. Otherwise, factors that would prompt us to upgrade is if some not-yet discovered bug gets exposed, if there's a security vulnerability that gets fixed, or the need for new device support.

[Mark Elsen]

  - That's a very long debate to consider , often important factors are : resolving bugs  , needed support for new access point models. A current release going end of support ; your guide : https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/214749-tac-recommended-ios-xe-builds-for-wirele.html

 M.

[Saikat Nandy]

I agree with @Mark Elsen that it's a debatable question, for sure. Everytime you don't upgrade a WLC not necessarily just because of a defect, but you do upgrade when you need new feature, you need to support new APs etc etc. Now how frequently you should upgrade - well, there is no correct answer I must say. You need to track a lot of factor, including - 
1. What's your environment type and how easy to get a MW..
2. Are you running an ancient code or something which is not that old, may be just a year old...
3. Do you need some feature which is not present at this time...
4. Do you need support of new HW which is not present at the current running version...
5. Are you hitting some defect...
6. Are you running some important feature and there is a catastrophic defect already been filed by Cisco...
7. Are you running a version which used to be TAC recommended version a year ago but not anymore

... there could be more pointers but at least these are just on top my mind. So today you might be doing a code upgrade after a year..tomorrow you might have to upgrade it again just because you have encountered a defect..who knows!!!

[Stefan Mihajlov · Accepted solution]

@ariask93 

I’ve had the same concern — in my case with 9800s running in environments where downtime is a big deal. What worked for us was to stop chasing every new release and instead align upgrades with Cisco’s recommended release train. TAC publishes star-marked (recommended/extended support) versions, and those are the ones worth planning around. That way you don’t end up upgrading every six months, but you still stay on a code that gets critical fixes and security updates.

So the decision really comes down to balancing risk: if the current release is stable and still in support, we stay there; if there’s a high-impact bug, security advisory, or new feature we need, then we move. For critical verticals like healthcare or finance, sticking to an extended maintenance release and only upgrading when TAC guidance or security requires it has been the most sustainable approach.

–––
Best regards,
Stefan Mihajlov

Mark this post as Helpful if it helped you, and Accept as Solution if it resolved your question.

[ariask93]

"I think you hit the nail on the head. I appreciate all the comments and I will take all of them to create a balanced work plan for our infrastructure. Thanks, everyone

[Jonatan Jonasson]

I want to echo what others have said but also offer another perspective, since I've supported some of those critical infrastructure that you've mentioned.

To start with, the most common "sweet spot" has been similar to your every-6-months cycle:

• 2( or 3) times a year check if an upgrade is needed. (often is)
  • Based on the "recommended software" from the vendor.
• Additional upgrades when applicable to fix critical vulnerabilities.

Many of the critical services are required to maintain services up to date, at least where they can (excluding some specialized hardware), due to whatever standards they need to be compliant to (PCI-DSS/HIPAA/etc) or because of an insurance requirements.

While it's debatable if 6 months is a long or a short cycle, it offers some advantages that some of my contacts like a alot:

• You don't fall far behind.
  • Upgrading systems that haven't been upgraded for years can sometimes be a nightmare.
• You test the redundancy during each upgrade.
  • So... every 6 months you're in a position to actually test the redundancy/fault tolerance. Some of those environments try to make the most out of this maintenance window so they can be even more confident about their preparedness for failures.
• You sometimes find things that you decide could have been done better.
  • You can note them down, add to the plan, and test it out in 6 months.
• You maintain the "upgrade knowledge"
  
  • There's always some staff rotation in every team, frequent updates means you can guide the new people so they learn the process right away and aren't stuck with "this was last upgraded when X was still working here, that was 4 years ago."
  • And because last upgrade was just last spring, everyone knows the process and the expected downtime (if any)

[MHM Cisco World]

1- new 802.11 ver 

2- connect new AP

3- run feature which have bug on your current wlc ver 

All above need wlc upgrade 

Remember many engineers until.now use old airOS and it run ok no problem.

Other than this no need 

MHM

[Leo Laohoo]

There are so many reasons for the need to update the firmware of the controller.  However, there is only a handful of reasons why the update needs to be NOW.  

1.  Is the wireless network hitting a CRITICAL bug? 

2.  Critical security vulnerability currently and actively exploited in the wild?

3.  New AP models translate to new firmware requirement (unless developers can/will crank out an AP Device Pack)

Since the introduction of IOS-XE 16.X.X, I have always maintained an opinion and posture of: 

1.  Reboot all access switches every 12 months (non-Dot1X) or 6 to 8 months (Dot1x)

2.  Reboot all core and distribution switches every 12 to 18 months

3.  Reboot WLC every 12 months.  Maintain constant vigil to the control-plane memory utilization.  If the control-plane memory utilization hits >50%, reboot the controlller. 

4.  Reboot the APs daily.  No, I am not joking.  If the controller is on 17.X.X, reboot the APs daily.  

5.  For 9800 with multiple WNCD:  

• Maintain <50% AP scale
• Maintain <50% client scale
• Open authentication or PSK only.  No fancy stuff like Dot1x or Enterprise-grade authentication that requires an external authentication server. 
• Flapping clients (wireless clients failing to authenticate and constantly trying to join the controller):  Disable or block them
• Flapping APs (APs constantly trying and failing to join the WLC):  Disable or block them
• APSP or SMU:  Apply only the correct APSP/SMU because of an existing fault.  Do not unnecessarily apply APSP/SMU because one feels the need.  There are APSP and SMU that are bad and will do more damage than good.  '
• HA SSO (aka VSS):  A hard NO.  We have to tear apart two pairs of HA SSO because we have to constantly reboot the pair every 2 to 3 months due to excessive memory leak in the control-plane.  
• "telemetry":  Disable all forms of telemetry, particularly APIs.  The APIs have proven to hammer the already buggy firmware to their knees and have been proven to crash WLC, switches and routers.  SNMP is fine but other forms of "telemetry" are really bad.  

[ariask93]

Thanks! I appreciate all your comments