Hey there! First thing’s first – Hope all is well with everyone. The past few months have seen all sorts of craziness going on in the world. I’ve been lucky in the sense that my current job role was already well set up to make an easy transition to working from home all the time. That being said, I know it hasn’t been easy for everyone – and I know quite a few people who have lost their jobs, etc.
Second thing! As I’m sure you may have already seen above – I opted to spend some of my new-found free time trying out a new format. I’ve had a couple of ideas in the past for making short videos, but never forced myself to sit down and give it a shot. So here we are – after about a month of on-and-off work – I finally have something to share. Please give it a look if you’re interested, and I would appreciate any comments & feedback. I still have a few other ideas – so if this one goes well I may pursue producing a few more of these.
Okay – Now onto the real content!
A few months ago I had the chance to pick up a pair of Cisco Catalyst 9100 series access points from work. My home network has been running on Ubiquiti APs for years – but they’re getting old and I desperately needed to replace them. So along comes the Catalyst 9100 APs, which are capable of supporting 802.11ax clients – and why not take the time to upgrade & future proof? I needed some practice anyways, as I have a few customers at work that I think will be interested in these in the near future. I ended up with two 9120AXI APs.
So in the process of trying to dive on the opportunity to play with something new – I completely missed the fact that the 9100 APs have two different product SKUs. One which ships the AP pre-configured with the standard lightweight AP code that you might use if you had an external wireless LAN controller (WLC). And a second SKU that ships the AP with the Catalyst 9800 Embedded WLC (eWLC) software loaded. Of course, I grabbed the lightweight APs without checking.
Product SKUs (Example, using 9120AXI):
- Standard Lightweight AP: C9120AXI
- Pre-load with Embedded WLC: C9120AXI-EWCI wrote in a previous blog about getting MAC address filtering set up on the Catalyst 9800 WLC. When I wrote that blog I was actually using the C9800-CL, which is a virtual machine version of the Catalyst 9800 controller software. I was originally excited to run the controller as a VM and not need a hardware appliance – but then got to thinking that maybe I should try and save VM resources as well. Which led me to looking at the 9800 eWLC.
Finding the Software Images
In order to convert an existing lightweight access point to one running the embedded WLC software – we first need to grab a copy of the software images from Cisco.com. Search for the model of your 9100 access point (in my case, the 9120AXI).
You’ll see two options for Software Type – and it may not immediately be obvious – but we’ll need to look under IOS XE Software to find the eWLC images:
Then we’ll grab the EWC AP image bundle. In my case, I was waiting on a specific feature set that wasn’t available until 17.x – so I downloaded the 17.2.1 software:
Okay – after we’ve done that – let’s drop everything onto a server/laptop/etc which has console connectivity to our AP and a running TFTP server.
Once you un-zip the contents of that AP image bundle, you’ll notice there are quite a number of files. We’ll only need two of them – one image to load onto the AP itself, and one that will get loaded for the WLC software container. Within the image bundle, there will be a readme.txt file that will tell you which image to use with your AP:
ap1g5 : AP1815, AP154x
ap1g4 : AP180x, AP183x, AP185x
ap1g7 : C9115, C9120
ap1g6 : C9117
ap1g6a : C9130
ap3g3 : AP380x, AP280x, AP156xSo in my case, I would use the file named ap1g7 since I had the 9120 APs. In addition, you should also see a file named C9800-AP-iosxe-wlc.bin which we’ll need to load the controller.
What’s with that second image? Well – the Catalyst 9100 APs include a feature called Application Hosting (also found on some of the Catalyst 9000 series switches). This is equivalent to running a Linux container or Docker container directly on the AP hardware. At time of writing, this is only available for the embedded WLC software. However, there will be a future software update that will allow you to provision other software containers as well (according to the data sheet).
Converting the Access Point
Now we can get started on the actual conversion process. If it’s a new AP, we can just go ahead and boot it up with a console cable connected. If it’s already running something, you’ll likely want to factory reset the AP first. You can find detailed instructions here, but a quick summary – power off the AP, hold the mode button while plugging the AP back in, and keep the mode button held for at least 20-30 seconds. If you’re logged into the console during this time – you’ll actually see the AP counting how long you’ve held the button for. Once that counter shows at least 20 seconds, release the mode button and allow the AP to reboot.
Once the AP is booted. The default login is Cisco / Cisco. The enable password is also Cisco. You may also want to quickly issue a show version, and take note of the current software version running on the AP (hint: we’ll need that later).
Next – it’s important to note that after we convert the AP – our default CLI will actually be the WLC, not the AP (even when connected via console). So we should configure a hostname and IP address for the AP now:
0xAP# capwap ap hostname <hostname>
0xAP# capwap ap ip <ip-addr> <netmask> <gateway>Then we can load the new AP image and WLC image. Depending on which software version you’re running today, there is a different command to load the image:
0xAP# ! If you're running software 8.9 or lower, use the following:
0xAP# ap-type mobility-express <TFTP path to AP image> <TFTP path to WLC image>
0xAP# ! If you're running anything above 8.9, use the following:
0xAP# ap-type ewc-ap <TFTP path to AP image> <TFTP path to WLC image>Once those commands are submitted, the AP will begin copying the software from the TFTP server. The AP will automatically reboot after the image load is completed.
Quick note: For one of my APs, the WLC software didn’t load correctly – and when my AP rebooted I was left with an error that said “EWC-AP in Recovery Mode”. Re-copying the WLC image fixed it without much trouble. If this happens, the AP will print out the command to re-image the WLC software, but I’ll also put it here for reference:
0xAP# ! If you end up in "EWC-AP Recovery Mode", run the following:
0xAP# archive download-sw ewc-ap <TFTP path to WLC image>Okay – Once our AP has come back from loading up all the new software, we can get on with a bit of minimal config required to access the WLC web UI.
First, we’ll configure the WLC hostname & our local user account. This can be switched over later to your choice of directory service:
0xC9800eWLC# config t
0xC9800eWLC(config)# hostname <hostname>
0xC9800eWLC(config)# user-name <admin username>
0xC9800eWLC(config-user-name)# password <admin password>
0xC9800eWLC(config-user-name)# privilege 15 Next we’ll also provide the WLC with the administrative credentials used to manage the connected APs:
0xC9800eWLC(config)# ap profile <profile-name>
0xC9800eWLC(config-ap-profile)# mgmtuser username <AP admin user> password 0 <AP admin password> secret 0 <AP admin secret>After that, we’ll go ahead and configure our basic network settings. This will be the IP address & gateway info that will be used to connect to the WLC web UI and SSH:
0xC9800eWLC(config)# interface gigabit 0
0xC9800eWLC(config-if)# ip address <managemnt IP> <Network mask>
0xC9800eWLC(config-if)# no shut
0xC9800eWLC(config)# ip default-gateway <Gateway IP address> Lastly – we’ll need to actually enable the web server. In my case, I opted to not enable the standard HTTP server. I only enabled the encrypted SSL-enabled web server:
0xC9800eWLC(config)# ! I only enabled the HTTPS server:
0xC9800eWLC(config)# ip http secure-server
0xC9800eWLC(config)# ! If you wanted to enable the plain-text / unencrypted web server:
0xC9800eWLC(config)# ip http server
0xC9800eWLC(config)#
0xC9800eWLC(config)# ! Finally - Save the config
0xC9800eWLC(config)# exit
0xC9800eWLC# wr memWhen we save our config for this first time, the AP will verify that the initial configuration pieces have been completed. There is a bit of background cleanup that is performed – which removes any factory config that assisted with provisioning. Once that’s all done – we’re free to log into the web UI!
Embedded WLC Web Interface
I won’t spend a lot of time here, as there are far too many things to cover with the new 9800 series controllers. However, I did want to point out a few things that stand out regarding the Embedded WLC.
When we log into our WLC web UI – we’ll be able to use the username & password combo that we configured previously. Then we’ll be dropped into our WLC dashboard.
If we click on the number under the Access Points heading, we’ll be taken to a quick monitoring view of the current connected APs:
Here we can see the APs we have configured, along with their IP address & status info. We will also see what our Current Active WLC controller is, and what our Current Standby / Preferred Active if we have either configured.
By default, if we boot up a second AP running the embedded WLC software, it will automatically join the WLC cluster as the secondary node. Any WLC config/settings will be copied, then it’s ready in case the primary controller fails. In the event of a failure, the secondary WLC will take over – and be accessible using the same IP & login info that we used on the primary.
In my case, I’ve also configured one of my APs as a preferred primary controller. For me, this AP is connected to a switch that has a short battery backup – so it’s less likely to experience failure. This option can be configured on the individual AP itself. In the left-hand menu, drop into the Configuration section, then click on Access Points under the Wireless header. We’ll see a very similar screen to the AP monitoring screen from above. Click on the AP that we want to make our preferred primary, then jump over to the Advanced tab. There will be a checkbox for Preferred Controller:
WLC Image Repository
Last thing – and this one is important. Normally the WLC will have dedicated storage to keep AP software images, which it distributes to new APs when they come online. Unfortunately, while we gain the flexibility and limited footprint of the embedded WLC – we also lose that dedicated storage space. As you might imagine, storage on the AP is limited.
So we’ll need to make sure that the WLC has an external image repository that it can use. This configuration can be done via teh web UI and CLI. I’ll cover both very quickly here.
From the web UI – We’ll go to Administration > Software Management:
Here we’ll see our options for where to get images, as well as an inventory of current APs & their images. In the Mode drop-down, we’ll have the option of tftp, sftp, CCO, and Desktop. TFTP / SFTP are what we’re used to. With Desktop, we would just upload images directly from our laptop / PC. Interestingly though, CCO allows us to provide our Cisco.com credentials – and the controller can pull images directly from Cisco. We’ll even have the option to enable automatic software downloads – and specify whether we want to auto-download the latest software release, or only the latest recommended release.
On the CLI side of things – we can accomplish the same using the following commands on our WLC CLI:
0xC9800eWLC(config)# wireless profile image-download <profile name>
0xC9800eWLC(config-wireless-image-download-profile)# image-download mode tftp
0xC9800eWLC(config-wireless-image-download-profile-tftp)# tftp-image-server <IP address>
0xC9800eWLC(config-wireless-image-download-profile-tftp)# tftp-image-path <path to image files> With that, any new APs that join our WLC should be able to auto-load the software necessary.
Thanks for reading!