For the past 20 years I’ve been really keen to know what is going on around West Tasman Drive in San Jose. Why is that? Well it so happens I began my career in technology playing with Cisco gear and hold several of their certifications. As one of the major players in Wi-Fi from the start, their offer has evolved, for better or for worse, as a complete portfolio which has been rebranded under the Catalyst name in the last few months.

It was with much anticipation and excitement that I sat with my fellow MFD delegates to hear what Sugit Ghosh, Srinivas Annambhotla and Matt MacPherson had to teach us about the latest and greatest innovations at Cisco. This post will deal mostly with gear and IoT, since I had the chance of chatting one on one with Matt MacPherson, CTO of Enterprise Wireless about a topic that is not tied to gear. It is an awesome concept which will be the subject of another blog post very, very soon.

Ok-let’s get back to the gear, shall we?

First, look at this cutie. Isn’t it sweet?

This is the latest addition to the Catalyst 9800 series of controllers, a little guy who can connect through fiber or copper, handle 250 APs and 5000 clients running IOS XE. As a possible replacement of the 3504, this wlc may be part of a lot of high schools, small colleges, medium businesses and the like. With a footprint a little bigger than a Mac mini, that’s a lot of power in a tiny package.

As a matter of fact, here’s the entire controller lineup of the Catalyst Enterprise series:

The big point of the Catalyst series of WLCs is that they run IOS XE. Yep. Entire new OS, Cisco built, modular and which you may remember from other platforms. Since the initial launch of the Catalyst family in the last quarter of 2018, a few iterations of code have been published and I have not heard of epic battles with the code just yet. Of course, the Catalyst controllers are less than a year old at this point so I am assuming there’s a little bit of that into play.

Since the OS is modular, instead of upgrading the entire software, one can apply patches which will target one or a few bugs. If the services affected can be reloaded without any customer impact, then voilà, they are restarted and your clients will remain happily connected. This is something that makes me both happy and somewhat concerned all at once.

In the past, I have had very good and very bad experiences running updates, to the point where I have very very specific requirements to meet in order to upgrade, frantically bug scrubbing to make sure that I will not hit a bug. Now don’t be mistaken, I’ve encountered less of those than I can count with one hand, but every time the adventure was so epic it cannot be forgotten.

My concern though is that patching could lead to inconsistencies in versioning and may make troubleshooting much more complex for us and for TAC. How are the patches going to be documented? Will there ever be an instance where something that should be non-impacting will turn out to create issues? I guess the next few months will show us. Regardless I think the idea and the intention is good, and if you want to try it in your lab version 16.10 allows for these functionalities on the controller.

Another part of this modular vision is the AP device packages. It used to be that in order to support new AP models, one had to upgrade. Not anymore. You can use device packs to run newer APs on your infrastructure without changing versions. Of course, if your intent was to test a new feature of this AP, until you get to the minimal version you may not be able to do so. Regardless, at least your investment is not sleeping unused, it can still run its most vital functions and serve clients.

The management of patches and OS is tied both to the controller and DNA Center, the later being the prefered way of course. The plan, according to Sugit, is to allow the upgrade process simple, clear and concise so that the admin can take the best decision possible. As a matter of fact, another feature to prevent client impact is rolling AP upgrades which can be used to apply upgrades based on the RRM information (and 802.11r,k, v) to move clients if possible. That’s a nice touch. Curious to see it work in real life…

By the way, I have not had the chance to play just yet with this new series (though I am thinking maybe I could ask DH for a cute little 9800-L-C for Xmas!) but a few things have changed. Among them, the AP Group concept which is now replaced with tags. I will further blog on that topic because I am sure I’m not alone with several AP groups which are vital to our ops. I’m mentioning tags because you can now deploy software based on that, something that could allow us admins to pick a test site for a patch, mitigating the impact of a partial update while we build the confidence in “the machine”.

Before I close this post, I’d like to give kudos to Lauren and Breanna who are the fantastic ladies who are the Cisco-Gestalt liaison. Lauren happens to be involved with the Cisco Champions program and her enthusiasm about it is making me think I might try to apply this year… Breanna has been vital in the creation of my next post…can’t wait to share it with you, but it’s not ready just yet…stay tuned!