DHCP Option 43 for Meru APs (using a Cisco Router/Switch DHCP Server)

-
Meru access points, like many other controller-based APs, can use DHCP option 43 to acquire the address of the wireless LAN controller that they need to join.

In brief, controller-based APs need to find their way back to a controller to obtain their operating code and parameters. Out-of-the-box, they don't know the IP address of the controller they should be talking to. When they are hooked to a wired network, they will request an IP address via DHCP. The DHCP process can also be used to pass them the address of the wireless LAN controller they should be speaking with (in addition to the usual parameters such as IP address, mask, default gateway etc.).

DHCP option 43 is used to pass the WLC IP address information to the AP. However,  figuring out the format of the information that should be put in to the option 43 field can be something of a challenge, depending on the DHCP server you are using.

I recently had to set up a DHCP server on a Cisco switch to provide IP addressing and DHCP option 43 to some Meru APs. I thought it would be worth sharing this information, as it wasn't immediately obvious.

My setup:
  • AP Network: 192.168.20.0/24
  • WLC address: 192.168.50.12  

The option 43 string that is passed to the AP has to be constructed in the following format:
  • byte 1: '43' in hex (2b) - this is to tell the AP that we are actually using 'Vendor option 43' within the standard DHCP option 43 (I know, it's confusing...trust me, it's always 43)
  • byte 2: '13' in hex (0d) - this is the length of the vendor option payload (in bytes) that follows - this will need to vary depending on the length of the WLC IP address
  • byte 3 onwards: the remainder of the bytes are the WLC IP address string ascii characters (including '.' characters)
Putting all of this together, here is the final DHCP configuration applied to the Cisco switch which will provide an example of how to put this together:

!
! Cisco DHCP Configuration - vWLC address = 192.168.50.12
!
ip dhcp pool APs
   network 192.168.20.0 255.255.255.0
   default-router 192.168.20.254
   dns-server 8.8.4.4
   option 43 hex 2b0d.3139.322e.3136.382e.3530.2e31.32

Notes:

Option 43 break-down:

2b = Vendor option 43
0d = length of vendor option payload in bytes (13 bytes/characters in this case)
31 - ascii "1"
39 - ascii "9"
32 - ascii "2"
2e - ascii "."
...etc.

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p...
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client...
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would ...
Read more