Introducing the Cisco Catalyst 9800 Wireless Controllers

Catalyst 9800 – Cisco’s newest Wireless Controller Architecture

The Catalyst 9800 Wireless Controller is an exciting beast.  It is based on IOS-XE, rather than the traditional Cisco direction of releasing controllers running AireOS (from the Airespace acquisition almost 15 years ago!).  I know what you’re thinking…  The horrible 5760 was also based on IOS-XE!  Fear not, for the Catalyst 9800 code bears no relation to the 5760 controller debacle from several years ago.  The Catalyst 9800 code was developed from scratch, to meet the growing demands of wireless networks.  There is no MC/MA Converged Access complexities to worry about.  In fact, the controller can be deployed in a manner almost identical to what we’ve become accustomed to with AireOS.

Deployment Models

There are multiple Deployment Models, including a similarly-capable virtual controller!

• 9800-80 – 2RU Appliance
  • 80Gbps
  • 6000 APs
  • 64,000 Clients
  • 100Gbps Uplink Module Option!
• 9800-40 – 1RU Appliance
  • 40Gbps
  • 2000 APs
  • 32,000 Clients
• 9800-CL – Public/Private Cloud Virtual Controller
  • VMWare/KVM/AWS/GCP
  • 2Gbps of centrally-switched traffic
  • 6,000 APs
  • 64,000 Clients
  • The following features are now supported (they weren’t supported in the AireOS vWLC)
    • SSO High Availability
    • Local or Flex Mode APs
    • Guest Anchoring
• 9800-SW – Embedded 9300/9500 Switch Controller
  • 200 APs
  • 4,000 Clients
  • Indirect AP Support (APs can be connected to downstream switches)

Features

While feature parity with AireOS is not yet 100% (it is very close), there are already many things the Catalyst 9800 Controllers can do that the outgoing AireOS controllers could not.  Here are a few of the new features that I’m most excited about:

Hitless Upgrades

Some of you may be familiar with Prime Infrastructure’s ability to orchestrate “Rolling AP Upgrades” on N+1 WLCs.  This is much better than that, for a few reasons.  Without the need for Prime Infrastructure, DNA Center, or any other management platform, the controllers (in N+1 mode) are capable of performing a hitless upgrade.  This means that software on the controllers and the APs can be upgraded negligible-to-zero impact on clients.  Here is how it works:

• The controller automatically selects groups of APs that can be upgraded, while other nearby APs will still provide coverage to the clients
  • RRM is used to determine AP neighbors that can provide redundant client coverage
  • The aggressiveness of these groupings is configurable.
    • You can have many groups (few APs per group), with very minimal coverage impact, but it will take a long time to complete.
    • Or you can have fewer groups (more APs per group) with a greater chance for coverage impact, but will complete much more quickly
• The secondary (N+1) Controller is upgraded to the new software version and rebooted
• 802.11v is used to shuffle clients away from the APs in the first group, so that they can be rebooted without impacting the clients
  • Clients not supporting 802.11v will get ungracefully kicked off the AP
• The controller moves those APs to the new controller, thus upgrading the AP code when they join
  • Once upgraded and controller-joined, clients may join these APs
• The same process is automatically repeated for all successive groups of APs
• Once all APs are moved to the N+1 controller, the code is upgraded on the primary controller and it is rebooted
• Once the primary controller is back online, the APs can optionally be moved back to the primary controller

Hot Patches

Because the controller and APs run IOS-XE in this architecture, they can be hot-patched for minor software upgrades (think security vulnerability fixes).  This means an SMU (Software Maintenance Upgrade) patch can be applied to the controller without rebooting it, or taking down any client-serving services.  Think of how awesome this would’ve been for the KRACK vulnerability.

Encrypted Threat Analytics

These controllers, much like the Catalyst 9000 switches, support Encrypted Threat Analytics.  This allows you to be able to detect (with incredible accuracy) encrypted malicious traffic on your wireless network, with Stealthwatch.

Interoperability

You can create a mobility group between AireOS and Catalyst 9800 Controllers, which has a couple important benefits:

• Seamless client roaming between both controller architectures.  This is great for the transitional period you will undoubtedly find yourself in, as you adopt the new controller architecture.
• Guest Anchoring.  This will allow you to use your AireOS controller as a guest anchor for your fancy new Catalyst 9800 architecture.

Configuration

I am currently working on a separate article to outline the IOS-XE wireless configuration model.  It is a new model, as compared to AireOS as well as the never-to-be-mentioned-again 5760 controller.  It has been tough for me to adjust to, as an AireOS curmudgeon.  However, I will say that the model makes sense.  I can see why they did what they did, which is more than I can say for some other configuration models I’ve had trouble adjusting to.

There are several available migration tools to automatically convert your existing AireOS configuration to the Catalyst 9800 configuration model.

Most importantly, It works.

I have been fortunate enough to have access to one of these controllers for a number of months.  This has allowed me to do some extensive testing in my environment (8 APs, 40 clients).  I have been very impressed with how well these controllers have worked, even at the very early stages.  Simply put, there have been less-stable versions of public AireOS code in the last few years.  For a completely new architecture, I’m frankly astounded by how well it has worked and how stable it has been.  The future for Cisco Wireless is bright.