The Cisco 9800 WLC comes in a range of options, from the high throughout 9800-80 down to the cloud based virtual WLCs.
The controller has a number of built in features that help increase the uptime of the controller – something you’d expect with a high-end wireless controller from Cisco.
There are a range of features that go into building a HA environment – in this blog, we are going to look at three of these, which are shown in the image above.
ASSOCIATED BLOGS:
When you set out your Wi-Fi Design Business Requirements, one of the key acronyms to get across is SSO. This stands for Stateful Switchover.
There have been a range of different versions of HA over the years with Cisco WLCs, with the older controllers providing a failover which allowed for the AP to determine the controller had failed and switch itself over.
This though does mean that you have an interruption while the AP reparents to the secondary controller. Enter SSO, where the controller itself switches over and provides a seamless failover, which is so fast, the AP will not detect a failed controller at all.
SSO is useful for a few reasons. In the event something catastrophic happens to your controller, the second controller takes over. This could be a power failure in a rack that has taken a controller offline, or a software bug that the primary controller has failed, and it is reloading.
ASSOCIATED BLOGS:
One of the bugbears in AireOS wireless LAN controllers was the requirement to reload the controller when you apply new code. This leaves you with a period of uncertainty while the code is applied, the controller reloads and comes back online.
With ISSU though, a range of updates do not need to reload the controller - if the patch doesn’t touch the kernel of the operating system, it will do an inline upgrade, with no interruption (known as a hot patch).
For more major upgrades – that do affect the operating system kernel – the controller will initiate a failover, before rebooting the WLC, which greatly minimises the downtime.
ASSOCIATED BLOGS:
ISSU though doesn’t though explain how you explain all the APs – they’ll need to reload with the new code.
Access points though do need to reload to apply new code. For quite a while you have been able to load a second image to the AP, which if pre-loaded does reduce the time it takes to do a code upgrade.
To cover this, the WLCs can undertake a rolling process of AP upgrades. They will gradually work through the APs, upgrading and moving them between the two WLCs, to eventually move all APs and reload the standby WLC on the new code.
This of course could leave you in the situation that a client is dropped and has no adjacent AP to move to – Cisco have taken this into account though, so adjacent APs the client would roam to are not upgraded and reloaded at the same time.
ASSOCIATED BLOGS:
While SSO was available in the older controllers, the use of the software upgrades which can be applied without needing a reload are a major advancement in uptime.
If you’ve ever had to do a software upgrade in a critical facility, such as a hospital, which type of software patching is a major improvement. The ability to undertake rolling AP upgrades minimises downtime, as a random APs are reloaded – clients will typically just roam to an adjacent AP, meaning even with the requirement for an AP reload, the interruption can be minimised.
The code is continually evolving though, so this is just a snapshot in time, as well as only a subset of the available features. Hopefully this was a useful introduction to the HA features on the 9800 WLC.
ASSOCIATED BLOGS: