Deploying and Configuring the Cisco 9800 Virtual Wireless Controller for the First Time

Deploying the new Cisco 9800-CL wireless controller is fast and easy, and by using the built-in workflows, a new wireless network can be deployed in only a few minutes. In this post, I’ll review how to deploy the virtual wireless LAN controller in VMware ESXi and stand up a very simple WLAN. We’ll also take a look at some potential gotchas and some noteworthy differences between how the new WLC is configured compared to the AireOS WLC.

Cisco identifies the 9800-CL as the cloud platform, but really what that means is that you can deploy it in AWS or locally in ESXi, KVM, etc. It’s important to remember that there’s feature parity between the vWLC and the traditional hardware appliances (the 9800-40, the 9800-80, and the 9300 switch platforms). To me, that means that I now have much more flexibility in how I can deploy a wireless controller.

Cisco has released some documentation on the initial deployment of the virtual appliance along with several documents for various configuration scenarios. With some online searching you can also find some very brief videos and additional documentation, but so far I’ve found that the body of work Cisco has released isn’t exhaustive or very focused just yet. I expect this to get much better in time, of course.

You should also watch the Networking Field Day 19 videos which provide a great starting point for an overview of the platform and its main differences from AireOS.

 

DEPLOYING the Cisco 9800-CL in VMware ESXi

Cisco has fully tested the vWLC in ESXi 6.0 Update 2. This is the version I’m running in my lab, and I can confirm it works just fine. I haven’t tried deploying in 6.5 yet, though. It’s easier to use the OVA which you download from Cisco, but there is an ISO you can use as well.

 

1. From the vSphere client, deploy the 9800-CL OVF from template.

 

 

2. For my lab, I chose the smallest configuration.

 

3.Before powering on the VM, make sure your networking is set up correctly. In my lab, I started with a flat network, but you have to make sure the vSwitch interface to the new VM is a trunk and the security settings are set to Accept Promiscuous mode, MAC address changes, and Forged transmits.

Someone I just started following on Twitter wrote about making sure to Accept Forged Transmits because that’s a setting which is often changed by sysadmins.

Also make sure to check the box to Accept Promiscuous mode. I forgot to do this and couldn’t get any client connectivity until I did. 

Be careful when you create multiple vWLCs with these settings because it’s easy to create a loop and lock yourself our of ESXi. Depending on your lab setup, you may need to disable the second and third network adapters. 

 

4. Power on the virtual machine and open the console. From here you have a few options:

a. allow the VM to obtain an IP address from DHCP, then log in to the GUI to use the Day 0 configuration

b. run through the initial configuration wizard on the command line via the console

c. bypass the initial configuration and start configuring the device from scratch.

I’ve done all three methods, and since this is such an easy platform to get up and running, I’ve found that bypassing the initial configuration wizard and starting from scratch adds very little complexity and time if you’re already familiar with the IOS-XE command line. After becoming familiar with the vWLC, this method allows you to configure most of the settings very quickly before even logging into the GUI for the first time.

When prompted, type no to bypass the initial configuration dialog and then yes to terminate autoinstall. You’ll then be brought directly to the familiar IOS-XE command line interface.

 

 

INITIAL CONFIGURATION

This is the IOS-XE command line, so simply run through your best practice configurations that we do on all our switches and routers such as creating crypto keys, configuring the console and vty lines, create usernames, a hostname, ACLs, etc.

After those initial configurations are done, there are some WLC-specific configuration items that are needed before moving forward.

 

1. Configure interface GigabitEthernet 1 as a trunk.

2. Configure a management VLAN and corresponding SVI for device management.

3. Configure a wireless management VLAN (used for joining APs) and SVI. This IP address can be added to DNS tied to CISCO-CAPWAP-CONTROLLER just like we did with our AireOS deployments.

 

NOTE: In my lab, I started with a flat network and have only VLAN 1. In my case, I didn’t create any new VLANs and simply gave the IP address 192.168.1.25/24 on the VLAN 1 SVI.

You can also assign an IP to GigabitEthernet1 and use it as a routed interface. There are several design options depending on your need for out-of-band management, SSO, etc.

 

4. Next, assign a country code, create a wlc trustpoint, and explicitly configure the WLC to use the appropriate interface for wireless management. APs will not join until these steps are complete.

a. To configure a country code, first disable the radios. Then configure your specific country code.

b. Next, identify the wireless management interface you’d like to use.

c. Now create the certificate and trustpoint. The password must be 8 characters in order for the command to be effective. If it’s not sufficiently long you’ll get a warning message.

This is the command (without a password configured):

This is the warning message if your password isn’t acceptable:

d. When a sufficiently long password is used, you’ll see some output breeze across the screen as the certificate is created. When it’s done, verify using the following command:

 

 

A NEW INTERFACE AND WORKFLOW

Now you can log into the GUI. Because we configured these last few items already, the platform skips the Day 0 wizard and brings you directly to the Dashboard.

The dashboard is intuitive and clean, and I like that I can drill down into various components such as clients and access points from this one spot. After getting used to where things are, I’ve grown to prefer this interface over AireOS.

 

The Cisco 9800 uses a different workflow than AireOS. It uses a modular approach utilizing standalone policies and tags which are tied together in different combinations to create the specific WLAN behavior we want.

The controller has two built-in workflows you can follow to create a new wireless network very quickly, or you can build the components and tie them together on your own.

You can find the advanced built-in workflow generator by navigating to Configuration -> Wireless Setup -> Advanced. From this screen, select “Start Now” at the bottom in order to begin the guided workflow. There is also a “Basic” setup wizard which gathers only very basic information and creates the policies for you behind the scenes.

 

However, after going through these built-in workflows several times and learning how the pieces fit together, I’ve found that doing it manually takes no time at all. It takes some time to get used to the new method, of course, but once you do, it’s easy to manually create the few policies you need and tie them together with tags.

There are several items which are necessary to configure and several you really don’t need to touch for most typical wireless deployments. For example, whether you create custom ones or use the built-in ones, you need an AP Join Policy, a WLAN, a Policy Profile, and a Policy Tag.

But you really don’t need to touch the built-in Flex policy (unless you’re using Flexconnect), and you seldom need to touch the built-in RF policy which are the built-in radio policies.

 

CONFIGURING THE CONTROLLER

I’ve learned that the first 16 WLANs you create are automatically added to the default policies making setting up simple wireless networks extremely easy. You don’t have to actually use the default policies, but there’s no reason to change it for a very simple deployment such as ours.

In this section, my goal is to get us familiar with the new WLC interface and its components, join an access point, and connect a wireless client to a new WLAN. I’m going to use the default built-in policies and no authentication on the WLAN, which I’ll call “TEST.” Also, remember this is a flat network, so everything is on VLAN 1.

 

1. First, make sure your radios are re-enabled by going to Configuration -> Radio Configurations -> Network. Check the box next to 5GHz Network Status, and then do the same for 2.4.

 

2. Next,  navigate to Configuration -> Tags and Profiles -> Policy, and select default-policy-profile. Within this policy, start with the General tab and make sure the policy is enabled by sliding the “status” slider to the right/green.

 

3. Now, under the Access Policies tab, enter the correct VLAN for your test wireless clients – in this case I’m using VLAN 1. Notice the default is “default.” If you don’t change this, clients won’t be able to connect and you’ll see a “VLAN Failure message” in the log output.

In most scenarios you’d have multiple SSIDs and multiple VLANs, so what you’d do is create a custom Policy Profile for each WLAN and assign the appropriate VLAN under the Access Policies tab.

 

4. Next, navigate to Configuration -> Tags and Profiles -> WLANs. Here you’ll create the test WLAN. The built-in workflow has a different order of operations, but I’ve found my simple workflow gets the job done in the fewest number of steps.

Click Add in the upper left to open the WLAN dialog box.

 

Fill in the appropriate information and make sure to enable the WLAN.  Then, under the Security tab, enter the security you wish to use for this wireless network. For initial testing, I’m using None for the Layer 2 Security Mode. You’ll see that the options are very similar to the AireOS WLAN options.

 

5. Now that we have an enabled WLAN, navigate to Configuration -> Tags and Profiles -> Tags, and select default-policy-tag.

Since we’re not using any custom policies, we don’t need to change anything here. However, if we were using custom policies, this is one of the main locations we’d tie together many of the components with a Policy Tag.

For now, though, we can close this screen.

 

TYING IT TOGETHER

If your access point was plugged into the network on the correct VLAN (VLAN 1 in my case), it would likely have downloaded its new firmware and joined the WLC by now. You can check that on the dashboard under Access Points.

From what I’ve read, there hasn’t been a change to how APs find and join controllers. I may be wrong, but I haven’t seen any documentation yet that says otherwise. If your WLC and APs are on the same VLAN, the APs will find the WLC using a simple broadcast. You can also use DNS, option 43, or primed APs.

The test WLAN with the “TEST” SSID should now be visible to your wireless devices.

Connect your device to the network. Debugs for wireless clients aren’t as readily available on the IOS-XE wireless controller, but there are some traces that can be done to capture client association traffic.

I kept terminal logging turned on to see the process in real time, and this helped in a couple situations. For example, the first time I tried connecting a wireless device, the log output said there was a VLAN failure and the client would be put into an exclusion list.

After a few minutes I found this was because the incorrect VLAN was configured in the Policy. I had left it as “default” instead of configuring it as “1.”

 

THINGS TO BE AWARE OF

There were a few things that stood out as seemingly minor configurations that would be easy to miss but would prevent the the AP to join or clients to associate.

First, make sure you allow Promiscuous mode in your ESXi host networking configuration. I struggled for hours one day wondering why VLAN 1 would not come up. Then I realized this small oversight. Thankfully, this is explicitly stated in one of the Cisco docs, so it was just a matter of going through their step-by-step process again.

Second, make sure that the correct VLAN is configured in the Policy under Configuration -> Tags and Profiles -> Policy. I figured this one out more quickly because I had a logging output to guide me.

Third, don’t forget to actually enable a Profile Policy and your WLAN. When creating new WLANs and new policies,  they are disabled by default.

Fourth, disable VTP on the WLC or at the very least put it into transparent mode. This is the first bug I experienced in which learning VLANs via VTP breaks things in the controller. Thankfully Cisco is already aware of this and included it in their documentation.

Fifth, give the AP a little bit more time to join than you’re used to. This could just be something weird in my small home lab environment, but I found that APs took quite a bit longer to join the controller than they do with an AireOS platform.

 

MOVING FORWARD WITH THE 9800

The basic components of how wireless works are the same as AireOS. The difference lies in the way the pieces are put together to create your wireless networks. After getting used to the interface and getting your first test WLAN up and running, I think you’ll see that it’s not difficult to create more complex WLAN environments with sophisticated security, custom RF profiles, and external authentication sources such as Cisco ISE (assuming you’re already familiar with AireOS).

The next steps for me are to tie the vWLC to Cisco ISE, experiment with SSO, and create a mobility group with an AireOS controller. Until then, I hope this post helps get you started with the Cisco 9800-CL virtual wireless controller.

Thanks,

Phil