WLC Code Upgrade Challenges

Rowell Dionicio

The writing is on the wall for on-premises wireless LAN controllers (WLCs). In the past, enterprises needed to purchase a wireless LAN controller to deploy, manage, and configure access points.

With the shift to cloud technologies, a WLC is no longer required. WLCs brought in additional overhead. WLCs are complex and challenging to manage. There is a high cost to purchasing a controller – the physical appliance and the licensing required to manage access points.

Let's dive into some specific challenges induced by on-prem wireless LAN controllers.

On-Prem WLC

Not Enough Time

Business moves quickly. End-users are frustrated with technology that impedes their work. A significant amount of planning and preparation goes into upgrading a WLC.

A network engineer must peruse release notes to identify bugs and vulnerabilities with a specific WLC software version.

After identifying the desired software version, scheduling a maintenance window is also a challenge. The network engineer must wake up at an ungodly hour to perform the upgrade.

Upgrading a WLC involves upgrading the software on the access points. While the software can be pre-downloaded, sometimes it is forgotten. The time required to upgrade hundreds and even thousands of access points can take too long.

A WLC can only handle so many file downloads from access points at a given time. The network engineer crosses their fingers and prays to the wireless gods that the WLC comes back online as they wait for it to respond to pings.

The exact process applies to access points, hoping that not many will need replacing due to bad flashing or other boot-up issues.

Dealing With Open Caveats

Upgrading WLC software involves taking a calculated risk. An upgrade only occurs for a good reason. Either there is a bug to fix or a vulnerability to plug.

But open caveats are another reason to tread carefully with WLC software upgrades.

Sometimes, new bugs are introduced. Some create a high impact.

These new bugs cause headaches for network engineers and increase frustration for end-users.

Access Point Support

Don't act too quickly on upgrading to the latest WLC version of the software.

Take inventory of which access points will be unsupported with the desired software version for large deployments.

Unsupported access points are usually due to age. They'll be left stranded after the upgrade, unable to join the WLC.

An organization may be limited to a specific WLC software version.

The High Cost of High Availability

Network architecture requires redundancy and high availability. WLC falls under this category. If a sole WLC fails, all access points stop providing service to devices.

WLCs solve the single point of failure with N+1 to provide redundancy.

Often, one WLC serves the access points, with the other sitting idle as a backup.

The organization purchases two controllers—a waste of money. Higher cost to buy, higher costs to maintain and deal with licensing headaches.

Each WLC is independent of the other and managed separately.

The Efficient Way

Now's the time to embrace cloud-native and cloud-managed Wi-Fi.

The time to deploy and be connected is instantaneous. Access points download their configuration from the cloud after acquiring Internet access.

Eliminate controllers. No more spending early morning maintenance windows to upgrade controllers and access points. Schedule software upgrades for access points without waking up at 3 am. And updates are under continuous development. A network operator can get new features, bug fixes, and security fixes faster.

Access points software is configurable to specific versions, so an access point won't be left stranded no matter what “version” the cloud is using.

Controllers are no longer needed. High availability is in the cloud provider. Look for cloud-native technologies used, not just a cloud controller.

Make a move to cloud-native and cloud-managed Wi-Fi today!

4 thoughts on “WLC Code Upgrade Challenges

  1. Let’s not forget this cycle: upgrade today, fallback tomorrow, escalation build, escalation build, fall back. Get fed up. Don’t upgrade again for 10 years because the vendor can’t figure out ANYTHING.

  2. I agree with your points and there’s often still a need to terminate CAPWAP / DTLS / GRE / IPsec data plane tunnels on-premises. This means still buying one or more (for HA) on-premises data plane tunnel terminators, e.g., what is seen with Juniper / Mist. The disruption from APs needing to download (ALWAYS pre-download if at ALL possible!) and reboot to upgrade their code is still a thing regardless of Cloud-native control and management planes. I’d say the more the AP code upgrades can be granularly controlled by an administrator, e.g., via AP groups, and the more Cloud-native architecture feature, like microservices, vs. monolithic embedded code in the APs, the better.

    1. Good points, Michael. Although I will go out and say that most environments do not need any tunnels but if the requirement is there then yes, I agree. Code upgrades are getting easier but are still limited by on-prem. We have granularity with AP code upgrades going to cloud-managed APs. And we’ve just made it there now with on-prem controllers.

Leave a Reply

Your email address will not be published. Required fields are marked *