Cisco 802.11ax site survey (single AP method)

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

APoS survey with Cisco 802.11ax APs

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!

The Wi-Fi 6 elephant in the room

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.