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.

8 Replies to “Introducing the Cisco Catalyst 9800 Wireless Controllers”

  1. Is there any session sync between controllers while doing the upgrade and while making clients jump from controller to controller?

    I mean, will my real time voice/video sessions, ftp downloads, ssh sessions etc seamlessly move on while upgrading?

    1. If your client supports 802.11v, it would be considered a standard inter-controller roam. You shouldn’t lose a connection, but the client would have to re-auth in the background. But if your client doesn’t support 802.11v, you likely would notice a drop. It’s important to note that the hitless upgrade is only supported in an N+1 controller configuration, so the client state is not synced between controllers.

  2. Forgive me for asking here, but you are fortunate enough to already have this thing already in test for a while. Otherwise I have to wait for Cisco Live EMEA to ask these technical questions 😉

    The release notes of the current software image state:
    “AP connection over network address translation (NAT) and port address translation (PAT) is not supported.”

    Does this apply to controller, or access point, or both?
    Because this can make OEAP unusable.
    If the AP is meant (AP can not be behind NAT/PAT), OEAP will not work in 99,9% of places, because the typical install at home is 1 IP with some sort of PAT router.
    If the controller is meant (and it is not possible to configure a NAT IP, as the aireos allowed to), the controller will have to have a public IP on management, which makes things tricky.
    Or is it possible, to place it in multiple networks, all allowing to join APs (like in the old days, multiple “ap manager” interfaces, not just the management itself?)

    Thank you for some insight, if you have the time.

    1. I was a beta tester for the Catalyst 9800-CL, which gave me early access to the software. That’s how I was able to run it before its public release. Unfortunately, I don’t have an answer for you on the OEAP NAT question, as I don’t have an easy way to test this. It’s been years since I deployed OEAP, but I do remember the concepts. Although possible, it is usually not a great idea to use the same controller for internal APs and OEAPs. APs must join via the management interface, so there is no way to mimic the old ap-manager interfaces. If the controller supports OEAP, there must be a way to configure a NAT address to include in the AP Join response. Hopefully someone else with OEAP experience on Cat9800 can respond with some insight.

      1. Thank you anyway!
        The 9800-CL is intriguing in that context. I like to have an appliance for the heavy lifting, but the CL separate for external APs might not be a bad idea. Should be easy with smart licensing.
        If the sessions at Cisco Live in Barcelona will not clear everything up – I booked a Meet-The-Engineer to question on design specifics. That should (hopefully) clear this and all other remaining questions up.

  3. I have two 9800-40’s running 16.12.1s. One is up and running as a test and working with two AP’s connected. I can’t get Prime to work with it 100%. AP Discovery status says not yet completed and telemetry status says Failed, prime sees the 2 AP’s but says they are not registered but they are to the 9800. TAC has been less than helpful so far. Anyone have any ideas?
    Good article by the way.

Leave a Reply

Connect with:




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