When I started my Wi-Fi career in the reselling space, I thought the challenging part of Wi-Fi was the deployment and configuration of the equipment. Anyone could just let the controller I just deployed sit there and do what I configured it to do.
As it turns out, operating the network is a lot harder than I had initially thought. Upgrades, updates, and epic compatibility matrices can be needed to keep it all straight. As time has gone by, I see more of what I do as architectural and operational tasks and less configuration and deployment.
Cisco’s Airespace wireless platform has historically been challenging concerning operational features. However, with the release of the new Catalyst 9800 platform, Cisco is giving us dramatically more flexibility in how we operate and maintain our equipment.
Recently Sujit Ghosh presented at Mobility Field Day 4 (MFD4) where he did an excellent overview of upgrade and high availability features. You can watch the video below.
Let’s break down some of the different features.
Hot Patching (SMU)
Being able to live install patches on the controller for bugs without requiring a reboot of the system or restarting a client-impacting service. Hot patching should be for non-client impacting patches. SMU installs are designed for controller hardware.
Cold patching (SMU)
For patches that do require a restart of the system or service that would impact clients, cold patching gives you the ability to patch the system incrementally.
AP Service Pack
AP service packs are designed to be patchable for the AP software. These patches are designed to patch the AP independent of the controller software version. One of the most exciting parts of this new architecture for me is that we are decoupling the AP software from the controller software.
Per site AP patches
When testing new software, rarely is the answer to roll it out campus-wide. There have been many times when features like Per-Site AP patching would have made my life easier. Let’s roll this AP patch out only to the IT building giving us a chance to test it in a controlled environment.
Rolling AP restarts
For events when APs do need to reboot you can have APs reload sequentially to take down a small number of APs at a time to minimize the impact.
The idea here being able to support a new series of access points without having to move off of the current software you are on. Instead, deploying a device pack allows the current code to be able to support new models at a current feature level.
Additional HA features
Additionally, 9800 also supports the things we have come to know from a high-availability perspective. Traditional HA architectures such as SSO, N+1 and Primary/Secondary/Tertiary failover are all still present.
It’s excellent seeing Cisco investing in options that bring some flexibility in terms of how we operate and maintain networks. Looking back over the last decade, I can’t count high enough the number of times these features would have saved me time or made my job easier.
That said, I can’t help be a bit skeptical. Having been burned by ISSU, EFSU, SSO type upgrades in the past, I’m hopeful that Cisco has the kinks worked out. I also worry that we have too many options in terms of upgrading, patching, etc. Adding so many options also brings with it some complexity. I fully expect customers to struggle a bit of “which upgrade method do I use, and how do I upgrade my controllers with that method.” What I don’t want to see is the Prime Infrastructure “Order of how to apply device packs, service packs and patches” we’ve had in the past.
If we can get past that overall complexity, I see some substantial improvements over what we have had historically. With this platform being build on Cisco’s IOS-XE software, there’s no worry that Cisco won’t be investing in it long term.
Interested on another delegates take? Check out Scott Lester’s blog (prior to him selling out) about these new high availability features.