Wi-Fi 6e, 6GHz and the Wi-Fi Professional: an introspection

As I post this blog from a computer with a Wi-Fi 6e adapter, connected to a Wi-Fi 6e Access Point over 6GHz, I’m struck at just how far behind the times the average Wi-Fi Professional is. It goes without saying that the COVID-19 pandemic changed the landscape of our world, and the uptake of Wi-Fi in the home environment for production/corporate/commercial use has obviously skyrocketed. What does this have to do with the average Wi-Fi Professional being behind the time? Let me rewind the clock just a few weeks. I fielded an escalation from a corporate executive that was working from home. This is obviously nothing new given the Work From Home adaption that we’ve all had to accommodate, but this executive in particular was fed up with his experience at home and went out and bought a new router to go with his newly issued corporate laptop. After unboxing and setting it up, he was having issues and so did the most obvious thing – engaged his support team. Here’s where things go south quickly. His new laptop has an Intel AX210 Wi-Fi 6e client (which has been available for months at the time of this writing) and his new router sported “the fastest Wi-Fi connections available” – yes, over 6GHz. Fast forward to today and I’m saddled with a support case for an executive that is using technologies that I don’t have access to or tools to troubleshoot (much less design). I did what any dutiful Wi-Fi Professional would do in this case, I bought the same things he did and got to wrenching. The experience of troubleshooting a Wi-Fi connection without tools is one that I thought was long behind me. Having no Spectrum Analyzer, no channel scanner, no packet captures, no nothing – means that I was basically taking shots in the dark trying to figure out what was going on. This is the inverse of what happened to me the first time I saw a channel scanner, saw an CCK spectral mask on a spectrum analyzer, captured my first 4 way handshake – the elation of visibility came crashing down around me so rapidly, it was like someone turned off every light in my vicinity and left me wandering in the dark.

A Wi-Fi Professional is only as good as their tools. Yes you need learning, yes you need to understand what your tools tell you, yes you need to train on them so you can learn them properly, and yes – that skill contributes to a Wi-Fi Professionals overall efficacy, but what do you get when you have a Professional that knows what should be going on, knows where to look for the problem, but is left without being able to do so? You have a lame Wi-Fi Professional. Unfortunately, the Wi-Fi Professional has suffered a few significant blows in recent memory. The first was when Work From Home really started to kick in and we realized that none of our tools were built for supporting that kind of environment – and now, 6GHz isn’t just “coming soon”. It’s not coming next year, not coming next quarter, not coming next month. It’s here today and real people are using it for real work. The world has changed and adapted, but we haven’t. The Wi-Fi Professional is hurting today and for all the bluster of the marketing around Wi-Fi 6e – the only real strategy we have is to stick our heads in the sand and recommend that people do not adopt 6Ghz solutions because we’re not ready. This puts us behind the curve, and for a group of professionals that are proud to be on the leading edge of market trends and supporting those around us that are passionate about technology, it’s embarrassing.

So long, and thanks for all the great times

Cisco posted the EOS notices for their stalwart Wireless LAN Controllers yesterday, covering the 5520 and the 8540 (and VM). This, coupled with the EOS notice for the 3504 model just the week prior marks the end of all of the hardware/virtual AireOS controllers from Cisco. It’s worth noting that the embedded AireOS (called Mobility Express) is not included in this months announcements. Mobility Express aside, this marks an ending of an era that began with the Aironet acquisition by Cisco in 1999. 22 years of service out of an acquisition is a pretty good run if you ask me. As I reflect on the past two decades, we’ve seen a ton of changes – not only on the Cisco front, but industry wide. We saw 802.11 evolve from hotspot networks of connivence to being mission critical, redundancy focused, pervasive solutions that our business critical applications rely on. We’ve also seen an industry where every single enterprise WLAN only manufacturer has been absorbed by those looking to address “access layer” technologies all in, regardless of physical medium. We saw Cisco mature the Wi-Fi portfolio with some pretty significant milestones:

  • Migration of APs running VxWorks to Cisco IOS
  • Cisco acquire meraki for their Cloud infrastructure offering
  • Rolling some pretty awesome tech from Navini into the core product offering (Beamforming)
  • Turning “real” spectrum analyzers from Cognio into everyday table stakes (CleanAir still can’t be beat!)
  • 26 major WLC releases in the AireOS family (more on this below)
  • Converged Access (although we largely gloss over this milestone)
  • Cisco APs migrate from IOS to AP-COS (with it’s heritage in ClickOS from the meraki acquisition)
  • WCS to NCS to Prime Infrastructure to DNA Center management platforms
  • Merchant silicon from the 1242 days to custom silicone in Marvell radios, and back again to QCA/BCM based solutions intermixed with custom RF ASIC
  • Driving fixes back into 802.11 through custom Wi-Fi extensions in the CCX program (802.11r and others)
  • Countless forays into industrial and outdoor Wi-Fi solutions along with some pretty cool innovations (PRP over Wi-Fi, FSR, MRC, and on and on…)
  • Cisco transitioning their core WLC architecture over to IOS-XE and not screwing it up (frankly, like everyone expected them to do)

I’ll admit, it’s easy to beat up on Cisco – they’re a large target – but the fact remains that a very large percentage of Wi-Fi in the world today is driven by AireOS networks and it’s worth stopping down for a moment to acknowledge that Cisco devoted well over two decades of development and maturity into the product. Since we’re looking at the close of a generation, I wanted to share a list I’ve been working on for sometime now that marks each and every AireOS code name and the version/release it went with. It’s well known that the AireOS founder is enamored with wineries so all major release has been named after a winery – and here they all are, in alphabetical order:

ReleaseVersionCode
A3.20Amberhill
B4.00Beringer
C4.10Concannon
D4.20D-Cubed
E5.00Edgewood
F5.10Franciscan
G5.20Grgich hill
H6.00Heitz
INever built
J7.00Jwine
7.10Unnamed
K7.20Kenwood
L7.30LaReserve
M7.40Mosaic
N7.50NineHills
O7.60Oakcreek
P8.00Pineridge
Q8.10Quintessa 
R8.20Riesling
S8.30Sherry
T8.40Testarossa
U8.50Uva
V8.60Veuve
W8.70Wente
X8.80Xurus
Y8.90Yara
Z8.10Zucca
Not sure why, but this fascinates me – 8.10 being the last release, did they run out of letters or wineries?

When Cisco launched the Catalyst 9800 almost two years ago, it was well acknowledged that they actually delayed the release more than once to allow time for the product to mature – integrating 2 decades of features into a new product take time and I must admit, Cisco has done a pretty fantastic job of keeping new features rolling over the past two years in both AireOS and cat9800 platforms – something that’s difficult to do (especially as we reflect on Converged Access). With this weekends announcements, it’s safe to say that new APs from this point forward will require Catalyst 9800 WLCs. Consider yourself warned, especially as we look into 2021 and 2022 with every one eyes forward on getting to 6GHz (Wi-Fi 6e). If you’re still on AireOS, regardless of where you may be in it’s (which has been significant), the not-so-new-anymore kid on the block is the Catalyst 9800 WLC. I won’t gush on endlessly about what others have written, but suffice it to say, if you’re not getting on the 9800 bandwagon, you’re being left behind. Get up on the IOS-XE based 9800 sooner rather than later and start understanding how your migration looks, especially around models of APs that are supported. Check out the EOS notices for the 3504, 5520, 8540, and Virtual WLC at these links, and check out some of the CCIE preparedness videos I helped with here. Regardless of where you’re at on your journey, if you’ve got virtualization resources available to you – you really should be running a 9800 in a lab, or really anywhere you can.

One in one hundred and fifty three quintillion.

RRM – a common term for Radio Resource Management – or the set of algorithms that set the channel and power level of your Access Points in an automated fashion. You’ve heard it all before, “RRM is broken, RRM picked the wrong channel, RRM hates me, RRM isn’t right for my network”. The reality is that RRM:

  • Isn’t dumb
  • Doesn’t hate you
  • Doesn’t love you
  • Doesn’t feel anything for that matter

As it turns out, RRM isn’t even smart. It has no feelings, passion, hate, love, real, imagined, or otherwise. In fact, RRM is just a series of algorithms that are built to do one thing – whatever you tell it to. RRM is a framework, meant to be built, adjusted, tweaked, and tuned. To be fair, there are two major topics that tend to give RRM a bad name and they are:

1) Every vendor implements RRM differently. This is a good thing. It’s called a competitive differentiator and the hardware capabilities of some vendors are not present in other vendors equipment so they may make poorer or less-informed decisions about your network

2) Most people don’t modify the default RRM configuration. This is a bad thing which leads me to the point of my post.

I decided to put myself in the shoes of Cisco. I asked myself, if I were building RRM, and I could only set one configuration as a default out of the box, how many would I have to pick from? The answer may surprise you – if you counted every possible RRM combination exposed in the GUI on a Cisco WLC (running 8.2 code) you’d end up in the neighborhood of 53 quintillion possibilities (153042639740283000000 to be exact). Assuming my math is correct (and if it’s not, I’m actually too low), that means that some poor developer somewhere had to pick *one* default configuration to ship out of the box and if you’ve not adjusted it, there’s a couple more for you to try… Now, I can already hear the groaning – “but I don’t have time to try all those!”. You’re right – of the possible sane configurations you can try, there are a few widgets you should focus on – and you certainly don’t need to try every possible combination but much like any other auto functioning mechanism in your network (OSPF, EIGRP, VTP, Auto Updates) the defaults are likely to not be 100% optimal in your environment. When your network adopted OSPF, did you leave it at the defaults? What about Windows Updates? What about AntiVirus? What about… never mind you get the idea…

Well, you may ask, why doesn’t Cisco just change the RRM defaults to ‘fit more environments’? That’s an excellent question and in fact, Cisco has done just that! They made a neighbor threshold change in WLC release 4.1.185.0 and the overhauled the defaults with the Mobility Express setup wizard in 8.0. The question is, did you implement the changes of the new defaults or are you running an old config?

If you have an issue with the way RRM is functioning, instead of lambasting it as hateful, dumb, or otherwise ineffectual, I have one question to ask you. Which of the 153042639740283000000 combinations didn’t work for you?

-Sam

 

 

Fun fact: if every possible RRM combination was a black pixel on your shiny new 4k TV, and you were watching 120FPS content, you’d be staring at a black screen for over 160 years.

FAQ:

Q: Isn’t it easier to just static plan all channels and TX powers everywhere?

A: Not if you want to spend your life manually reacting to new neighbors, new sources of interference, or any of the myriad of other changes that could occur in your environment – including AP failures (no one ever accidentally unplugs an AP, do they?) and people moving and changing furniture or other obstructions.

Q: Do I really need to try every last one of those combinations?

A: No! Nor am I advocating that. I think you should look at some of the heavy hitters (neighbors, max/min), understand how those work and how they’re impacting your network, then decide for yourself if tuning RRM makes sense.

Q: Why doesn’t Cisco just update my network with the new RRM defaults when I update code?

A: Because, not all RRM options are safe/valid for all users – you have a configuration on your WLC and I have one on mine. If you want to implement a new feature, you should do it prescriptively – not because a manufacture thinks it’s the best thing since sliced bread.

Q: Your number is too high. Are you sure that’s real?

A: Nope! In fact, I included *all* possible combinations with the intention of seeing just how high it actually is. This includes all possible channel combinations.

Q: But everyone runs the same channel combinations, that’s an inaccurate representation of your claims!

A: Not technically a question, but fair point – except that there are many multiple channel planning recommendations – some customers use a 3 channel 2.4GHz plan in the US, some use a 4 channel 2.4GHz plan in the UK. Some folks use UNII2e, some folks don’t. Some folks say use all channels except 149 (for Apple TV issues), some don’t. The upshot is that you must know your environment’s requirements including channel requirements and adjust for them. By the way, capping with a max 3 channel 2.4GHz plan and a max using default number of 5GHz channels (12)  in my calculations still leaves 18680481146880000 possible combinations. Feel free to check my math:

WLC combinations