My company is working on a deployment of Brocade wireless access points that will be used for guest access only. To support this, I deployed a Server Core 2008 R2 Read Only Domain Controller out into our DMZ (where the APs sit) with the intention of providing DHCP and LDAP for 802.1x authentication.

The Brocade APs are model AP7131. Although a Brocade community post mentions that autoconfiguration of the APs via DHCP options was not possible; later in that same thread (after a software upgrade), someone mentions it IS possible, and Brocade’s documentation confirms (check page 480, 492 in the pdf) that.

In particular, the following DHCP options are needed, at least:

Option 189 – Controller IP, as a String
Option 192 – Autoconfiguration enable, a String, either 1 or 2

Without Option 192, the AP’s will NEVER attempt to autoconfigure, as the PDF mentions above (on the same page).

Originally, I simply defined options 189 and 192 correctly in the AP subnet. However, no autoconfiguration or AP adoption was occurring.

Using Wireshark on my server core install (for excellent instructions on how to do that, see here, but pay particular attention to the first comment), I saw the following in the DHCP request from the AP (IP addresses removed, obviously):

Basically, the AP was requesting a list of options to return; normally this set of requested options includes the likes of option 003 (the default router or gateway) and option 006 (a list of DNS servers). The AP is coded to ALSO request options 43, 191, 186, 187, 188, and 189.

Wait a second, what about 192? How is it supposed to autoconfigure without requesting option 192? I have defined it for the subnet, but as you can see from the next image, the server was dutifully NOT returning it because it wasn’t asked for:

Note: clearly the packets are longer; but you’ll have to trust me that there was nothing else relevant.

Well that’s not very useful.

The Easy(er) Way

I began searching the Internet. In particular, the documentation from several places (also in the PDF linked above) mentions that all of this can be encoded into sub options of DHCP Option 43. However, nowhere did it give me the encoding FOR that value, specific to Brocade 7131 APs (there is a lot of information out there with regards to using it for Cisco Aironet APs and Microsoft Lync 2010, but NOTHING for Brocade APs specifically). Sidenote: If I had bothered to read the Cisco link a bit closer, I might have deciphered what otherwise took me a while to get below. The Lync link (ha) was a bit more enlightening, but too specific to Lync and again, I read it too fast).

I’ll give you the easy way out; for more information on how the whole thing works, scroll down “The Hard Way” below.

Something else had been catching my eye (bothering me?) since I looked at the packet capture; and that was Option 60, as sent by the AP itself, with the Vendor Class Identifier listed as BrocadeAP.br7131. Since I was configuring this whole thing via the command line using netsh (remember, this is a Server Core 2008 R2 DHCP server), I had to do some more reading on things, and discovered adding a Vendor Class.

netsh dhcp server add class "Mobility7131 Options" "Options for Brocade 7131 APs" BrocadeAP.br7131 1

From my more reading link, that breaks down into: add class ClassName [ClassComment] [Data] [[IsVendor=]{0 | 1}]; or:

ClassName: Mobility7131 Options
ClassComment: Options for Brocade 7131 APs”
Data: BrocadeAP.br7131
IsVendor: 1

Note that the Data is converted into Hex by the server automatically.

Also note that in some of the documentation I found (including the PDF above), it states (possibly incorrectly) that the Vendor Class returned by the clients is Brocade.71xx, and in some cases even different from that. I’m not sure if this would have worked, had I used the provided Vendor Class. The value used comes RIGHT from the request made by the APs themselves. The downside to this is that if, for example, the Vendor Class listed by the documentation allows for multiple types to all be “caught” by a single vendor class definition on the server, then there’s less configuration to do as a whole for a multi-AP scenario. However, this doesn’t seem to be the case, and I’ve hard-coded the vendor class the APs are currently using into the server. Note that it could also cause problems if they ever decide to change the Vendor Class returned by the APs in the DHCP request.

For completeness, this is what it would look like if you did that using the GUI in server 2008:

Open up your DHCP control panel, expand the server, and right click on IPv4 (the same may apply for IPv6, but I’ve never tried it). Click on Define Vendor Classes:

Click the Add: button:

Enter in the relevant information:

Now that this is done, you can define options 189 and 192 for this specific vendor class:

c:\> netsh
netsh>dhcp server
netsh dhcp server> add optiondef 189 Brocade-Controller-IP STRING 0 vendor="Mobility7131 Options"
netsh dhcp server> add optiondef 192 Brocade-Autoconf-Enable STRING 0 vendor="Mobility7131 Options"

The syntax for that command is inside Microsoft Technet (more reading) link above.

In GUI-land, this looks like this:

Create the new option:

Repeat for option 192.

Finally, you can enable these options and set them from the scope.

netsh dhcp server> scope
netsh dhcp server scope> set optionvalue 189 STRING vendor="Mobility7131 Options"
netsh dhcp server scope> set optionvalue 192 STRING vendor="Mobility7131 Options" 1

(Note: I’m not showing how to do this in the GUI, because I didn’t do it that way and there are lots of resources out there to show you how; likely from my GUI pictures above you could probably do it).

Within seconds of me completing these commands (recall, I actually did this FIRST, as opposed to hard-coding Option 43 in below), the network guy popped his head into my cube and asked if I had changed anything; I said I had, and he said “because all the APs are starting to auto-register”.

Having a look at the Wireshark capture, I noticed that the server was now sending an option 43:

I thought that was odd; I hadn’t defined an option 43 anywhere.

As it turns out, Microsoft’s DHCP server, upon seeing an Option 60 in the REQUEST from a client, will return anything defined in the Vendor Class definition on the server as a properly-encoded, easy to manage Option 43 in the DHCP Offer/Ack. This is significantly easier than the hard way (below), though arguably more obscure. I don’t have any documentation to back that up (if I did, I might not have taken so long to figure this out), but I can see that it’s working, because of what I tried next (aka the hard way; also the “more information about how the whole thing works” way).

The Hard Way

Option 43 is defined in the DHCP standard (RFC 2132) as Vendor Specific Information (Wikipedia). After finding the links above, it took me a while to figure out that it is defined by a Type-Length-Value string encoded in hex. You can get a FANTASTIC breakdown of how the whole thing works here (that link is what finally got me going down the right path).

An important bit to remember: Because you are encoding SUB values into option 43, you have to think like a network packet; i.e. embedded or nested TLVs. Here’s a crappy MS Paint I made showing it off (click the image to see it, my blog format is cutting it off somewhat):

So, with a bit of math (or the help of calc.exe and a hex/ascii converter) you could construct your option 43 string. This is a bit easier to explain if I show you the completed hex string:


And the breakdown:

bd: Option 189 (Decimal 189 in hex)
0c: Length 12 bytes (Decimal 12 in hex; 11 bytes of the IP address, + 1 byte of 0-padding)
31:39:32:2e:31:36:38:2e:31:2e:31: IP address of controller, converted from ASCII, in hex (
00: zero padding
c0: Option 192 (Decimal 192 in hex)
02: Length 2 bytes (1 byte of data and 1 byte of zero padding)
31: ASCII 1 in hex
00: Zero padding

Note that the length of the entire packet has been left off – this is because the server calculates it automatically. If you capture this in Wireshark, you would have seen a 2b 12 in front of it; 2b is decimal 43 in hex (i.e. option 43) and 12 is the length, in bytes, in hex (12 hex is decimal 18).

I confirmed that you can do this by entering in this string directly into an option 43 for a scope (I also removed the options from the Vendor Specific Class I defined above):

netsh dhcp server scope> set optionvalue 043 BINARY bd0c3139322e3136382e312e3100c0023100

And it works the same, however ANY client requesting option 43 will get this information, not just those offering option 60 as part of their DHCP request.

So there you have it; how to get Brocade AP7131’s to Autodiscover and adopt their controller using Windows Server Core 2008 R2 DHCP, and Option 43.