Wireless: Initial Setup

A WAP connected to a WLC through CAPWAP.

This is the first in a series of posts about wireless networking that I’ve been learning for the last few weeks. As with anything in networking there are a lot of terms and concepts associated with any configuration. I’ll probably have a post discussing the basics of radio frequencies and how frames are actually transmitted over the wireless medium but this post documents my time setting up a wireless controller (WLC) and a wireless access point (WAP.)

Like setting up anything for the first time, there were some bumps and quirks to the process that I think are worth discussing. The first is not really a quirk but more of an unfortunate fact about purchasing used equipment: sometimes the equipment is not fully functional. For my studies, I purchased a 2504 WLC which looked perfectly normal but had a faulty console port. After reading through some documentation and forums, I discovered that luckily the initial web page for the 2504 is at 192.168.1.1 and was able to configure the basic settings that way.

One of the more confusing concepts about the controller was the different interfaces that that can be configured on it. I’ve found that the management interface is the more important one because it’s the address used for addressing the GUI. After rebooting, the GUI is only accessible via HTTPS by the way. The other major port is the service port and, according to Cisco documentation, is used for OOB management so I haven’t really been required to use it. All other ports are logical ports that are created to bind a WLAN SSID with a wired VLAN.

After setting up the WLC, I did a series of different configurations to observe the different ways that WAPs try to associate with a controller. There are some 11 different things that an access point might use and I started with DHCP. The option to set in the DHCP pool is option 43 and it can be configured in two ways. This was the other quirk that took me a bit of research to get right. The more intuitive configuration uses the IP address of the WLC. I’m using 3702I WAPs in my lab and they do not like my choice of IP for option 43.

At least while I was trying to diagnose the problem, I had ample opportunity to see exactly what the WAPs were doing to try to discover a controller. Curiously, when I peeked into the DHCP packets, option 43 contained this string: ac100a02. If you’re not fluent in hex, that number represents 172161002 or 172.16.10.2 which was the IP address I had configured for my WLC (the management interface address.) That led me directly to the other configuration for option 43 which was to use hex for the WLC IP address. The syntax is slightly strange because you need to precede the address with f1xx. The first hex pair, f1, indicates that the following input is a hex number. The xx is how many octets that will follow. You can program a list of WLC addresses at the same time and thus inputting 04 means you want to input 1 IPv4 address, 08 means 2 IPv4 addresses, etc.

For example, if you wanted to configure the DHCP server to hand out two WLC addresses, the syntax would be:

option 43 hex f108.ac10.0a02 ac10.0a05

Option 43 was configured as 172.16.10.2 but is advertised as a hex in the DHCP Offer.

Immediately after I inputted the hex version for option 43, a flurry of unicast CAPWAP messages started to pass back and forth between the WAP and the WLC. I want to note that there is another DHCP option, option 52, to provide the IPv6 address of the WLC. I haven’t tested this option yet.

Among the CAPWAP that the WAP sent were association requests with IP addresses in the 10.0.0.0/8 network that I am not currently using in my lab. Those are the addresses of the WLCs to which the WAP had previously been associated. Indeed when I later went under the configuration details for the WAP after it was associated with the WLC, there were a couple of IP addresses and names that were inputted under the high availability WLC tab that matched the IP addresses in the CAPWAP packages.

WAP trying to associate with prior WLCs. Their addresses were 10.70.125.4 and 10.70.125.5.

There were also DNS queries for CISCO-CAPWAP-WLC that the WAP sent during the discovery process. The WAP sent both A and AAAA DNS queries looking for an IPv4 and IPv6 address for a WLC. Older WAPs also use CISCO-LWAPP-WLC to search for a controller. LWAPP (Light Weight Access Point Protocol) was the Cisco proprietary protocol between WAPs and WLCs before the industry standardized CAPWAP.

The WAP trying to search for a WLC using DNS name CISCO-CAPWAP-CONTROLLER.

One of the interesting things that the WAP did after failing to contact a WLC was to release its DHCP lease and try to get a new address. My guess is that this is done to ensure that the WAP receives the WLC information as soon as the network administrator/engineer correctly inputs option 43 or option 52 on the DHCP server.

The last and easiest configuration was to place the WLC and WAP on the same subnet. One of the first packets that the WAP sends after receiving an address is an ARP broadcast looking for any WLCs and if there is one on the same subnet, the association happens quickly. I didn’t encounter any unexpected behavior.

After the WAP and WLC recognize each other, they exchange certificates with each other and if the WAP’s image needs to be updated then it downloads the information from the WLC. The CAPWAP tunnel is split into two tunnels, the data and control tunnels, and the image download uses the encrypted control tunnel. From what I captured, there were hundreds of DTLS packages that were exchanged in the process.

Success! The WAP and WLC exchange their certificates and the WAP starts to download the latest image.

I’d like to mention briefly how I configured the WLC and WAP on the wired side. For the 2504 WLC, there are four physical ethernet ports along with a console port. I’m using the leftmost port as the management port and also have another port connected. All of these ports are trunk ports. I connected the WAP to an access port on VLAN 20. Since all traffic technically gets tunneled via CAPWAP to the controller before hitting the distribution system, it makes sense for the WAP to be connected to one VLAN. The only time that the WAP connection itself is also a trunk is if Flexconnect is configured, in which case traffic from multiple VLANs will navigate through the port.

There are a series of different color lights that the 3702I model goes through that indicates its status but since that’s on a per WAP basis, the details aren’t too pertinent. Let’s just say that red is not a good indicator for any electrical equipment. After the image download, the WAP shows up on the list of associated access points in the WLC’s web management console and the real configuration begins with all the different WAP modes, WLAN SSIDs and security. I’ll be discussing all those things in other posts.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: