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

April 12, 2021 by Leave a comment

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.

Filed under 6GHz, 802.11ax (Wi-Fi 6), Wireless

So long, and thanks for all the great times

January 30, 2021 by 7 Comments

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.

Filed under 802.11ac, 802.11ax (Wi-Fi 6), Access Points, Cisco, Meraki, Wireless, WLC

Cisco 802.11ax site survey (single AP method)

December 3, 2019 by 9 Comments

You may already be familiar with my Survey with Wi-Fi 6 APs workaround blog post previously where we used an AireOS WLC running on a second AP to do a site survey. Now that Cisco has launched the Embedded Wireless Controller (based on the CAT9800 platform), we can now use that functionality to do an APoS battery powered survey with a single AP! This is known as the Embedded Wireless Controller on Catalyst 9100 Access Points (or eWC for short). This is similar to 802.11ac wave 2 APs in that the WLC software runs on the AP after boot time, but the config model is notably different.

Prerequisites:

• Production 802.11ax (Wi-Fi 6) Access Point
This is unlikely to be an issue for most of you, but it should be noted that if you’re using a pre-production AP, it may not have the proper certificates required for this process. If you have issues with APs joining, please make sure you’re using a production AP.
• Local power source for your Access Point (this guide uses the Ventev VenVolt site survey battery pack)
• TFTP server (this guide uses the TFTP server Transfer from Adrian Granados)
• 802.11ax (Wi-Fi 6) Access Point (at the time of this writing, this is a c9115, 9117, c9120 or c9130 AP)
• A serial console cable to watch/configure your AP

Applying the correct image to the platform:

Step 1) Assuming your AP is currently in CAPWAP mode, you will first need to update the AP with the proper CAPWAP image prior to flashing it with EWC code. You MUST upgrade the CAPWAP image on the C9100 Access Points to AireOS 8.10.105.0 or IOS-XE 16.12.1s. Both these code versions are available on cisco.com.

Attach your AP to the VenVolt PoE out port. Boot your AP with the serial cable attached. Wait until you get to the AP prompt and configure the APs IP address to be on the same subnet as your workstation (192.168.1.2/24) using the following command:

AP7069.5A76.5460#capwap ap ip 192.168.1.2 255.255.255.0 192.168.1.1

Statically assign an IP address to your workstation (192.168.1.3/24). Put the update files into your TFTP server directory. Attach your workstation to the Ethernet port on the VenVolt. Run the following command to convert your AP to eWC mode:

For the 9115/9120:

ap-type mobility-express tftp://192.168.1.3/ap1g7 tftp://192.168.1.3/C9800-AP-iosxe-wlc.bin

For the 9117:

ap-type mobility-express tftp://192.168.1.3/ap1g6 tftp://192.168.1.3/C9800-AP-iosxe-wlc.bin

If you’re using a different AP, ensure you’re using the proper image file name (ap1gx) for your upload here. Once the AP has finished downloading the requisite code, it should reboot. At this point, you should be able to do all management from the GUI, although CLI commands for reference will be included later.  If by chance you run into the following messages, it is likely your code was corrupted:

 

AP2CF8.9B21.50C8#EWC-AP in Recovery Mode...
Please use 'archive download-sw ewc-ap' to upgrade or rollback the controller image.
Please use 'show flexconnect ewc-ap launch-log' to check EWC-AP launch log.
 EWC-AP in Recovery Mode...

Download the code again and run the following command:

archive download-sw ewc-ap tftp://192.168.1.3/C9800-AP-iosxe-wlc.bin

Once the code has pushed successfully you should see the typical WLC config prompts.

        --- System Configuration Dialog ---

Would you like to enter the initial configuration dialog? [yes/no]:
Num of cpu cores     4
Maximum number of AP's supported   100

Step 2) Wait for the CiscoAirProvisioning SSID to show up in your networks list. It should be noted that in the first builds, this site survey mode may take a while (15 minutes) to show up for the first time. You may need to be patient during this part of the setup. Once the SSID shows up, it will include a unique SSID based on the MAC address of the AP to prevent confusion when multiple ME APs are being setup. Find the SSID that matches your AP and join it using the PSK “password”.

Step 3) Open up a new web browser – if the Day-0 web page doesn’t open up, go to https://mywifi.cisco.com/ and accept the self-signed certificate warnings. Log in using:

Username:       webui
Password:        cisco

Step 4) Define the following values in the webui. For site survey functionality, it is recommended to use:

Username:       admin
Password:        Cisco123
IP Address:     192.168.1.1
Subnet Mask:  255.255.255.0

Click + Add, and define a site survey SSID:

Click the Finish button.

Click Yes.

Step 5) Wait for the eWC to apply the configuration. In the eWC product, the WC code does not reload, but rather immediately applies the configuration. The radios should come immediately available.

Step 6) Once the SSID comes up, join it using your defined PSK, and open your web browser to https://192.168.1.1/ . To set the transmit power and channel of the radio, navigate to Configuration -> Access Points -> 5 GHz radio or 2.4 GHz radio -> select the AP. From here you can change the channel and transmit power of your APs radio by changing the Assignment Method from Global to Custom, setting the required values, then clicking ‘Update & Apply to Device”:

Step 7) Do your survey!

CLI reference:

For those of you that are more comfortable with the CLI method of configuration, once you finish Step 5 above, you can connect to the WLC by either a serial console session or by ssh. Once you’re at the CLI and have enabled, you should rename the AP as shown below for simpler CLI config:

WLC7069.5A76.5460#show ap sum

Number of APs: 1

AP Name                            Slots    AP Model  Ethernet MAC    Radio MAC       Location                          Country     IP Address                                 State        

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

AP7069.5A76.5460                     2      9115AXI   7069.5a76.5460  6cab.0562.e680  default location                  US          192.168.1.2                                Registered   

WLC7069.5A76.5460#ap name AP7069.5A76.5460 name ap

WLC7069.5A76.5460#show ap summary

Number of APs: 1

AP Name                            Slots    AP Model  Ethernet MAC    Radio MAC       Location                          Country     IP Address                                 State        

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ap                                   2      9115AXI   7069.5a76.5460  6cab.0562.e680  default location                  US          192.168.1.2                                Registered   

WLC7069.5A76.5460#

You can then change the channel and tx power of the AP radio using the following commands:

ap name ap dot11 24ghz channel X
ap name ap dot11 5ghz channel X
ap name ap dot11 24ghz txpower X
ap name ap dot11 5ghz txpower X

For FRA mode APs, you can change the channel of the dual-band radio using:

ap name ap dot11 dual-band channel 1
ap name ap dot11 dual-band channel 140

Filed under 802.11ax (Wi-Fi 6), Access Points, Cisco, Surveying

APoS survey with Cisco 802.11ax APs

May 24, 2019 by 5 Comments

In case you hadn’t heard, Cisco has launched new Wi-Fi 6 (802.11ax) APs. This generally presents issues for those on the bleeding edge of doing Wi-Fi designs – especially if you rely on empirical data for your AP locations before hanging your APs. Cisco has a tendency to get gear out the door and usually enables site survey through autonomous (on 802.11ac wave 1 or earlier APs) or Mobility Express (read my writeup on 802.11ac wave 2 APs here) at a later date. The new Catalyst 9115, 9117, and 9120 APs are no exception. We know that Mobility Express is coming on these platforms, but between now and the time that we get Mobility Express for site survey mode, we’re very much out of luck.

We have a few customers that rely on empirical validation of their APs using APoS so we had to come up with a workaround. No, it’s not graceful, yes it’s a touch on the cumbersome side, but it works – and until we get the fully baked Mobility Express from Cisco, it’ll have to do…

Things you’ll need:

  • A real WLC running AireOS 8.9 code to support 802.11ax hardware (temporarily)
  • A wave 2 AP that can be dedicated to Mobility Express
  • 2x Site survey batteries
  • A console cable and this guide
  • Some network cables to hook it all up

This guide will walk you though configuring your 802.11ac wave 2 AP as a Mobility Express controller, then joining your 802.11ax AP to it so you can bring it’s radios up. Leveraging the built in WLC on the wave 2 APs running AireOS based Mobility Express, you can then configure radio power levels, channels, etc – all as needed for your AP on a Stick designs. You’ll need to carry two APs (and site survey batteries) with you, but for now – it’s what we have.

Start with a WLC running 8.9.100.0 (or a newer build that supports 802.11ax APs) and join your two APs to it. Ensure that your APs have the build on your WLC as both their primary and secondary images. Verify this using the ‘show ap image all’ command. This is important do to because once you have this all built out, you’re not going to have a lot of opportunity for monkeying with AP release images and you could save yourself some heartache if one of your APs decides to boot off of it’s secondary image. If you’re image numbers are different, use the ‘archive download-sw capwap <ap_image>’ command on your APs console to get it to update properly and reboot.

APs with same primary and backup

APs with same primary and backup

Once you get your AP image versions matched, take your 802.11ac wave 2 AP and convert it to mobility express for site survey using the guide I wrote previously. There are one or two things you should note when you’re doing this – we’ll be eventually using your 802.11ax AP as a subordinate AP to the one you’re now converting to Mobility Express and it won’t start it’s CAPWAP process without a pingable default-gateway. In this instance, we’ll have to make sure that, when we build our DHCP scope, we tell the scope option for the default gateway to be the IP address of the WLC – yes, even though the WLC can’t actually route packets. This will ‘fool’ the subordinate AP into thinking that the default gateway is reachable and will let it complete its eventual CAPWAP join. You’ll also want to make doubly sure that you’re converting it to the same release version of Mobility Express as is on your APs.

Match your default GW and WLC address

Once you have your converted 802.11ac wave 2 AP operational, hook it up to your first site survey battery, then hook your second site survey battery to your first using the ethernet (non-POE) interfaces. One you do this, you can hook your 802.11ax AP onto your second site survey battery POE interface to allow it to boot. You’re effectively creating a chain that goes AP <-> battery <-> battery <-> AP and using the ethernet passthrough for the master AP running Mobility Express to talk to the subordinate AP. Once all of your APs are up and talking to the Mobility Express controller, I’d recommend renaming the Mobility Express AP to WLC and the 802.11ax AP to ‘ap’ for the rest of the commands in the previous blog post to work properly.

Two batteries, two APs

802.11ax temporary rig, ready to go!

If you’re concerned about battery performance of your WLC AP, you can also issue the ‘config ap disable WLC’ (after you’ve renamed it properly) to save some power and to make it’s radios not show up in your survey!

Name your APs, disable the WLC AP!

Functional site survey!

Of course we’re looking forward to a complete Mobility Express instance to allow us to do site surveys with a single battery and AP, but until then, this will do if you’ve got the necessary parts and pieces!

Filed under 802.11ac, 802.11ax (Wi-Fi 6), Access Points, Cisco, Surveying, Wireless

The Wi-Fi 6 elephant in the room

May 18, 2019 by Leave a comment

Everyone is talking about Wi-Fi 6 (802.11ax). From product launches, to technical briefings, to product technical launch briefings, it’s all the Wi-Fi space is abuzz with. Everyone loves talking about “the shiny new”, after all – it’s the technological advances that bring evolutionary and revolutionary changes to our technical lives but there is always that one person (Lee, I’m looking at you) that asks the question: at what cost? I’m not talking capital outlay, I’m not necessarily talking about operational outlay, I’m talking political cost. Our users have long memories and when we mess up (either as an industry, an implementation, or for whatever reason) the political damage that a flubbed product, widget, service, feature, or deployment gone awry can cause is pain that we don’t readily recover from. Everyone wants Wi-Fi 6, no one wants to get it wrong. Frankly speaking, one of the reasons this is so particularly painful is because the last technology ‘upgrade’ we went through (802.11ac wave 1 to wave 2) was painful for a lot of users. Even though this represented a ‘minor’ technical upgrade, in Cisco land, the pain was palpable for more users than not. In order to understand why this was the case then, and not the case now, we have to go back in time. Way back in time. Like, to 1995…

did-you-know-the-famous-microsoft-sound-in-windows-95-was-created-on-a-mac-520844-3.jpg

The venerable Windows 95!

If you have grey in your hair, you’ll remember Windows 95. It was awesome. It was great. it had a strong heritage robust peripheral support, and performed well. For its day, (OS/2 users aside) you could do no better. That is unless you were ultra-geeky and decided to spring for one of those SMP (Symmetric MultiProcessing) capable multi-CPU motherboards. In my instance, I was rocking a dual slot-1 motherboard. When the Pentium II CPUs came out, I was first on the list and once I had two of those bad boys installed in my gaming rig, I booted it up to test out some Quake… and was disappointed. You see, Windows 95 (and Windows 3.1 and DOS, etc) were single threaded Operating Systems. This meant that the OS that ran my gaming machine couldn’t see more than one CPU so no matter what I threw at it, I was never better than one CPUs worth of performance. It wasn’t until the brave of us switched to Windows NT 4.0 (don’t talk to me about NT 3.51) and later Windows 2000 – that we were able to ‘unlock’ that hardware’s potential because the Operating System itself, was now SMP capable and could not only see, but take advantage of both CPUs!

Screen Shot 2019-05-03 at 4.36.28 PM.png

Windows NT4.0 with SMP support showing 2 CPUs!

Fast forward to the Cisco 3702 Access Point. This is an 802.11ac wave 1 AP and sports a host CPU of a Freescale P1020 running at 800MHz as confirmed by the clock speed shown on the AP boot messages:

PowerPC CPU at 800Mhz, revision number 0x2151

While not a terribly shocking revelation, there are plenty of data sheets around that detail that the P1020 is indeed a dual-core CPU (thank you, Moores law), but what most people don’t realize is that the venerable IOS operating on the AP3700 (and all other APs back to the AP350!) is a single threaded Operating System. This then means that Cisco was building some awesome dual core capable APs for quite some time now, but was still ultimately limited by an OS that could only execute a single thread at a time. They were ultimately bottlenecked, much like Windows 95 running on my dual Pentium II machine. Now, the Cisco development team aren’t idiots. They knew about this problem and have been working on it for many years – but it reached a critical point prior to the 802.11ac wave 2 APs being launched. This was the inflection point where it because no longer possible to ignore the wasted hardware resources in the AP platform due to a deficiency in the OS. Enter AP-COS. This is Cisco’s rebuilt from the ground up Operating System for all AP platforms moving forward – starting with the 802.11ac wave 2 platforms (the 1800, 2800, 3800, and 4800s). Speaking frankly, it took Cisco some time to get this right. If you were on the leading edge of the 802.11ac wave 2 platform adoption 4 years ago (yes, the 1852 was launched in June of 2015!) you felt the pain of a newly developed Operating System. Let’s park this particular side of the conversation for a moment though…

 

ac AP boot

Cisco 2802 boot messages showing two CPUs

Now, Cisco is well known for their special sauce. Ever since the Cognio acquisition (that us old timers can’t talk enough about), they have ‘rolled their own’ radios. While not precisely true, they have licensed their Intellectual Property to Marvell, the chief supplier of the radios for Cisco for several years now. As my good friend Dave delves into in his blog post, the 802.11ax platforms from Cisco mark a departure from Cisco working with Marvell to build their own radios in their flagship APs. As of the 9120 802.11ax (thanks Pat for the correction here!) (Wi-Fi 6) Access Point, Cisco has moved their special sauce into a discreet add on card and are now using commodity radios from Broadcom and Qualcomm Atheros (QCA) for their client serving radios. The upshot of this is that Cisco is not the only manufacturer using these radios. You could see how, when Marvell was the only radio supplier, firmware, hardware, drivers, etc – all coming from a single proprietary supplier could be a bottleneck from a development perspective. What if there was a radio-reset bug? What if there was a new feature? What if there was a client issue? In short, Cisco would be the only one impacted. This created several unique scenarios where the radio may have needed some attention (for a variety of reasons) but there was only on vendor tackling the problem. Cisco’s move to commodity radios presented a notable step towards stability in the market and they lost none of their proprietary hardware functions, now that things like CleanAir were moved off to a discreet hardware component. In short, the best in stability without sacrificing the things that make Cisco, Cisco.

 

ax AP boot

Cisco 802.11ax AP boot messages with 4 CPUs

Fast forwarding to Windows 10 – I mean, Wi-Fi 6 (802.11ax) platforms from Cisco. We now have a mature Operating System on our APs. We now have radio hardware (and all of the follow-on components such as firmware and drivers, etc) that represent the industry standard in compatibility and stability. These two things mean that the major reasons that we had all of the consternation from the 802.11ac wave 2 platforms have completely disappeared. Now, Cisco is an organization comprised of people, and people are fallible, but my personal experience with the Wi-Fi 6 (802.11ax) platforms from Cisco have been nothing short of rock-solid. We always have the benefit of hindsight, but in this instance, I believe that our past is well and truly behind us. Who knows what the fully ratified 802.11ax specification will bring us (okay, those on the IEEE board do!), but there are several tangible indicators that we’re very much over our growing pains of the past – the most important of which are hands on experience which have been smooth sailing, even under some pretty significant load. If you ask me, Wi-Fi 6 (802.11ax) from Cisco represents a huge leap forward on several fronts – performance, features, compatibility, and most importantly of all, stability.

Filed under 802.11ax (Wi-Fi 6), Access Points, Cisco, Spectrum, Wireless