How-To: Controller Discovery

In this post I will share my experience with controller discovery in the network. You will get many information on how the AP can discover the controller and what network requirements needs to be meet to do that. I will cover the following topics:

  • Where to place the AP’s in the network
  • How the discovery process works
    • L2 controller discovery or the simple way
    • DHCP based controller discovery
    • DNS based controller discovery
    • Provisioned based controller discovery
  • DHCP configuration with windows server
  • DHCP vendor specific options

Before we start, this post will only cover the non-cloud AP’s. For the Cloud based AP’s I will write a separate post, as soon as I get my hands on those new AP’s

Where to place the AP’s

As mentioned in earlier posts, I fully agree with the idea of putting AP’s in a separate VLAN. from my point of view, this has a lot of benefits

  1. When using encryption on the Unified Controller, you can specify a specific IP segment from which requests are coming and you can disallow the request from other IP segments
  2. You can specify, which controller to use, as AP’s needs to get the controller IP from somewhere in the network (I will describe how below) and will not just connect to the one, answering first
  3. Traffic to the AP’s can be restricted for security reasons
  4. As the AP did not answer to snmp requests or other management requests at all, you can exclude the whole segment from the management system, which will preserve licenses
  5. For troubleshooting it is helpful if you have your AP’s in a separate VLAN without any other clients doing some sort of traffic.
  6. I’ m a friend of putting things with the same function in the same VLAN and separate it from the rest.

Putting AP’s in a VLAN specifically for AP’s is just my best practice, you can also put them in other existing VLAN’s, but you will lose some of the benefits above. You can also put the controller in the same VLAN as the AP’s, but this is not always possible, as the controller normally has to stay in the datacenter, where as the AP’s are located in the campus and you can’t extend your campus VLAN to the datacenter.

 How the discovery process works

When putting the AP in separate a VLAN or having the AP in the branch you need to make sure, that the AP can find the controller and the controller discovery process works. To do that, there are 3 methods available and I will explain how they work and what the benefits are. Actually there are 4 methods to discover the controller, but the first one, is the standard method via L2 which is not available when following my suggestion above.

Nevertheless, I will  also describe how the L2 discovery process works.

 L2 controller discovery or the simple way

When doing L2 controller discovery, the AP and the controller needs to be in the same VLAN. Therefore it is good for very small environments, but in most of the larger deployments, this is not possible.

The process itself is very simple. The AP is getting an IP address, either from the controller or an external DHCP server. Afterwards, the AP is sending out a UDP broadcast to the broadcast address. As the controller and the AP are within the same VLAN, the controller (or the controllers) will receive the broadcast.

When dealing with MSM controllers, the controller will answer the request and the AP will connect to the first controller which answers the request.

When working with the Unified controller, the controller will only answer to the controller discovery request from the AP, when the AP is configured. There are other scenarios, where it is not a requirement to preconfigure the AP on the controller, which will be described in a later post.

This is the process. Very simple and fast. The broadcast method will always be used when the AP is starting. When there are more than one VLAN connected to the AP port, the AP will try all VLAN’s one by one.

When no controller answers the request, the AP will start trying the other methods.

 DHCP based controller discovery

When using the DHCP based discovery method, the AP can find very fast the corresponding controller. The AP will ask for an IP address and DHCP option 43. The DHCP server needs to be configured to provide also option 43 to the AP. I will explain the details later. When the AP gets an IP address and the option 43, which is the IP address of the controller, the AP will immediately connect to this address, without doing L2 controller discovery. This is a very fast and streamlined process.

When having more than one controller, option 43 should contain all IP addresses. For teamed controllers, you need to send the physical IP addresses of all members. Sending the team IP address will not work.

DNS based controller discovery

This is a very handy method, when you can not change the VLAN, the AP will be placed into or you want to be very flexible where to connect your AP’s. The AP will get an IP address from a DHCP server and will start L2 controller discovery. As this will fail, the AP will try to get the controller IP via DNS.

When working with MSM controllers, the AP will try to resolve those names:


It is not necessary, to resolve all the names. Just on for every controller and you are fine.

When you have a unified controller, the AP will try to resolve a different name, which is:


If you have more than one controller, you should resolve all IP addresses from that name. Doing it that way, with a round robbing algorithm at the DNS server, will lead to a good sharing of AP’s between those controllers.

Keep in mind, that all AP’s will come with a MSM image, even when you have a unified controller and even after a hard reset, the AP will boot up with a MSM boot code. This mean, you should always put both name formats into your DNS system.

Provisioned based controller discovery

This method is based on a manual configuration of each AP, therefore I did not recommend using this method, as it means a lot of management overhead. For those who still want to do this, here is how it works.

When working with MSM controllers use the steps below

When you get a new AP, you can connect this AP to your network. Make sure, the AP is getting an IP address. Now you can use your browser of choice and open the web gui of the AP and login with the standard credentials, which is “admin” for username and password. You will get the screen below:


Press the “Provision…” button to get to the provisioning settings:


Make sure, that you check the check boxes for “Discovery” and “Discovery using IP address”. Now add the IP of your controller, click “Save” and reboot the AP from the gui.

After the AP reboots, it will directly connect to the controller IP, which was previously configured. After the AP is up and running, you have to configure provision based controller discovery on the controller, otherwise the AP will not find the controller after the next reboot.


You have to enable provisioning globally, by following the link in the top yellow square. Afterwards go back to this screen and configure it as showed in the screenshot, but replace my controller IP with yours and click “Save”.

When working with unified controllers the process is different

The process above will not work with unified controllers, as during the controller discovery, the controller will load a new software on the AP which will erase the provisioning settings. When you get a new AP which is running MSM code, you have to connect this AP to the unified controller, using one of the methods above, but not provisioning based controller discovery. Than you can configure the needed provisioning settings on the controller. The command below will configure a static controller IP on the AP.

wlan ap ap01 model MSM430-WW id 1
 serial-id CN31DWZ53K
 ac ip <--
 vlan untagged 1
 radio 1
 radio 2

The marked line will tell the AP to discover the controller at Then, this is saved to the AP with the command:

[Unified_Controller_Master-wlan-ap-ap01]save wlan ap provision all
Are you sure that the provision configurations of all APs are correct? [Y/N]:y
Info: The operation takes effect only on APs in the running state.

The first line will save the provisioning settings to all running AP’s. Now you can disconnect and put the AP to the final location. But be aware, resetting the AP to factory default, will lead to the same situation as described above. The AP will boot up with an MSM boot image and no provisioning settings.

Therefore I do not recommend this method. Because if this and because of the management overhead.

DHCP configuration with Windows Server

As described above, my personal preferred way for controller discovery is the DHCP based controller discovery as this is faster than the DNS based discovery, due to the elimination of the L2 based controller discovery and offers much more control, as I can decide which controller IP will be advertised in which subnet.

As also mentioned, to do this, you need to configure some vendor specific options on the DHCP server. I will explain how to configure those options with Windows Server 2008R2 below.

Before we start, I need to explain a bit about those options. In the former MSM days, the vendor specific option where quite easy. There was just one vendor code, used by the AP’s. In contrast, in the old H3C days, they used a specific vendor code for each AP and a complete different format for option 43. With the unified code, we still have the MSM vendor code for all AP’s and the unified vendor code for each AP, but option 43 has the same format, which makes it much more simple. To make it even more simple for you, I will publish all AP specific vendor codes at the end of this post.

We will start with the configuration for the MSM code, as this is needed for both controller types, even when the AP, controlled by an unified controller only need this option before conversion to the unified code occur.

Back to the Windows Server. Open the DHCP management console:


Select your IPv4 server and with a right-click, open “Define Vendor Classes…”:


Click “Add…” to add a new vendor class:


The display name and the description can be filled with something meaningful for you, but the part in the ASCII column needs to be exact this value: “Colubris-AP”.

Click “OK” and then “Close” to return to the DHCP management console. Again right-click on “IPv4” and now select “Set Predefined Options”. Select your created vendor class as “Option class” and click “add”:


Give it a “Name” and select as “Data type” “IP Address” and check “Array”. The “Code” must be “1”. The “Description” is free of choice. Click two times “OK” to return to DHCP management console.

Now expand the “Scope” of choice and right-click on “Scope Options” and select “Configure Options”:


Select the “Advanced” tab and as “Vendor class” your created vendor class. Check the created option and “Add” your controller IP address or if you have more than one, simply add all and press “Apply”.

You are done for the MSM part. Now, all request from AP’s with MSM code, which sends “Colubris-AP” as the vendor id, will answered including option 43. And surprise surprise, option 43 will have the configured IP’s included.

When working with unified controllers, you need to configure the stuff above and you also have to create some more vendor classes. To be specific, you have to configure a vendor class for every AP type in your environment. A full list will be at the end of the post.

I will describe the necessary configuration steps for the MSM460, but the same steps applies to all the other AP’s. Starting point is again the vendor class. So, add a new “Vendor Class”:


This time, the vendor class is just for the MSM460-WW. Therefore the ASCII code is “HP. HP MSM460-WW”. Return to the DHCP management console and add the predefined option for this new class:


This is the same as with the MSM vendor class. Now return to the DHCP management console and go to the “Scope” of choice to configure the scope options:


This is the same as before with the MSM vendor class. so strait forward. Your done now, for all MSM460-WW models in this scope. Repeat this for other AP types in your environment and the last part for all scopes where AP’s are placed.

The DHCP server is now configured to respond to specific vendor classes, option 60 in the DHCP request, with a corresponding option 43 and send the correct IP address of the controller to the AP.

DHCP vendor specific options

As we discovered in the part above, there is a vendor specific class for every AP I would like to make it as easy as possible for you to create those classes. Therefore I created the list below to help you creating those classes. I will keep them up to date and expand the list when new AP’s arrive.

AP Type Vendor-Class Vendor-Class (HEX)
HP 417-AM HP. HP 417-AM 48502e204850203431372d414d
HP 417-WW HP. HP 417-WW 48502e204850203431372d5757
HP 425-AM HP. HP 425-AM 48502e204850203432352d414d
HP 425-IL HP. HP 425-IL 48502e204850203432352d494c
HP 425-JP HP. HP 425-JP 48502e204850203432352d4a50
HP 425-WW HP. HP 425-WW 48502e204850203432352d5757
HP 525-AM HP. HP 525-AM 48502e204850203532352d414d
HP 525-IL HP. HP 525-IL 48502e204850203532352d494c
HP 525-JP HP. HP 525-JP 48502e204850203532352d4a50
HP 525-WW HP. HP 525-WW 48502e204850203532352d5757
HP 527-AM HP. HP 527-AM 48502e204850203532372d414d
HP 527-IL HP. HP 527-IL 48502e204850203532372d494c
HP 527-JP HP. HP 527-JP 48502e204850203532372d4a50
HP 527-WW HP. HP 527-WW 48502e204850203532372d5757
HP 560-AM HP. HP 560-AM 48502e204850203536302d414d
HP 560-IL HP. HP 560-IL 48502e204850203536302d494c
HP 560-JP HP. HP 560-JP 48502e204850203536302d4a50
HP 560-WW HP. HP 560-WW 48502e204850203536302d5757
HP MSM430-AM HP. HP MSM430-AM 48502e204850204d534d3433302d414d
HP MSM430-IL HP. HP MSM430-IL 48502e204850204d534d3433302d494c
HP MSM430-JP HP. HP MSM430-JP 48502e204850204d534d3433302d4a50
HP MSM430-WW HP. HP MSM430-WW 48502e204850204d534d3433302d5757
HP MSM460-AM HP. HP MSM460-AM 48502e204850204d534d3436302d414d
HP MSM460-IL HP. HP MSM460-IL 48502e204850204d534d3436302d494c
HP MSM460-JP HP. HP MSM460-JP 48502e204850204d534d3436302d4a50
HP MSM460-WW HP. HP MSM460-WW 48502e204850204d534d3436302d5757
HP MSM466-AM HP. HP MSM466-AM 48502e204850204d534d3436362d414d
HP MSM466-IL HP. HP MSM466-IL 48502e204850204d534d3436362d494c
HP MSM466-JP HP. HP MSM466-JP 48502e204850204d534d3436362d4a50
HP MSM466-R-AM HP. HP MSM466-R-AM 48502e204850204d534d3436362d522d414d
HP MSM466-R-IL HP. HP MSM466-R-IL 48502e204850204d534d3436362d522d494c
HP MSM466-R-JP HP. HP MSM466-R-JP 48502e204850204d534d3436362d522d4a50
HP MSM466-R-WW HP. HP MSM466-R-WW 48502e204850204d534d3436362d522d5757
HP MSM466-WW HP. HP MSM466-WW 48502e204850204d534d3436362d5757

This table was updated on 2015-02-24.

For more information on the products go to

35 thoughts on “How-To: Controller Discovery”

  1. We have 3 x msm760 in a team and nearly 400 aps, some on our local site with some on remote sites routed back to the controller.

    Al works hunky dory until we start to using local meshing.

    On my local site i provisioned two ap's to operate in a mesh, one as master and one as slave.

    I then took them to the remote site but when plugged in the controller did not see them. I used the reset on the back of the ap and it came up with suspicious device after accepting it, it reload its config and works. i then
    connect up the other ap and the same thing happens, i accept it provisions again.

    but when i try to move it (disconnect it) to its new location it won't connect again

    any thoughts

  2. Hi Steve,

    Great question. Looks like I should write another How To for Meshing 🙂

    To my understanding, you have two AP's, one configured as master and one as slave, both where working correctly when configuring them in the main site, and you tested, that they would connect correctly, which means, after rebooting the master, the AP came back and after disconnecting the slave and rebooting the salve the AP connects through the master to the controller?
    You moved both AP's to the remote site and both did not came back?
    Which mesh profile did you used? I always recommend, not using the first one but every other one.

    Can you send me more details?

    – What did you excactly configure on the provision page
    – Which AP did not come back in new location? (slave? master? both?).
    – which firmware version did you use?

    Many thanks,

  3. Hello Florian,

    your explanation was helpful. Little typo in the last table: the ASCII and hex code for the 560 are not valid.

    Best regards,


  4. Hi, Really helpfull articule

    I have a problem maybe you can help, I have a HP 830 Unified Controller and 13 AP MSM 430-AM, they are in differents subnet, but the problem is that the AP's are not able to detect the controller even if I use DHCP opt 43. If a log in to the controller via telnet and ping to each access, I have successful ping, but ther are not able to connect each other.

    do you have any idea ? :S

    thank you so much

  5. Hi Carlos,

    Thanks for your feedback.

    Which option 43 format are you using? When you get a new AP, the AP will have MSM code and is not able to understand the unified version of the format. Which means, you should at least have the MSM version of option 43 in your subnet. As the newer code versions of the unified controller also support the MSM format, you can stay with that version and you do not need to create the unified version too.

    Hope that will help you. If not, just send me a reply with more information 🙂

    Many thanks,

  6. Hi Florian,

    At this moment I have both in the DHCP the MSM code and the 430-AM code. First I've tried only with the MSM code but didn't work.

    I have the controller in the and the AP's are in the 192.100.20.x . Is there a way to check if the DHCP server is really given the opt 43 to the AP?

    the dchp server is in the 192.100.20.x

    thank you very much.

  7. Hi Florian

    Thank you so much for your reply, this is really helpfull, you are right, there is something wrong with DHCP Server, sadly I have no access to the server at this moment, but If a compare your screenshots, this is what is going on in my scenario:

    1. AP is booting with the MSM code:
    2. Then the DHCP is responding in opt 43 with something different than your screenshots:
    3. The AP again is sending a request with the MSM vendor code:
    4. and of course the DHCP is sending a wrong value in opt 43:

    I'll check the dhcp config tommorrow and try to trace the traffic with port mirror.

    Thank you very much

  8. Hi Carlos,

    Thanks for the screenshot. I could decode the IP from option 43. Have a look at this:
    2b – DHCP Option 43
    06 – 6 bytes long
    01 – Colubris option code 1
    04 – Option Code 1 is 4 bytes long
    c0 – 192
    5a – 90
    0a – 10
    e1 – 225

    This would mean, the AP tries to reach the controller at From your comment above I think the controller is at If this is correct, the option itself is configured correctly, just the IP is wrong and needs to be changed. Please double check the IP in the advanced scope options as in this image. Do this for all scopes with AP's.

    BTW: The definition for the encoding/decoding of option 43 can be found here.

    Many thanks,

  9. Hi Florian

    Thanks, the decode really give me a good idea, but let me tell you that this mean that the opt 43 is working because the controller is in, I made a mistake given you a bad ip.

    I-ll tray to do the port mirroring, the problem is that I have no access to the switches right now.

    Greetings and thank you again

  10. Hi Carlos,

    You can also try to do the port mirror on the controller. Depending on the controller model, you can do it there and check if the packets from the AP are coming in.
    Are there any Firewalls in the path between the controller and the AP's?

    Many thanks,

  11. Hi Florian

    Yes there is a firewall between the AP and the controller, The controller is in the site A and there is 3 AP MSM 466 connected in the same subnet to the controller, but there is another 3 AP (MSM 430) in the site B. We have a vpn connection between the sites, and I can ping between different sites with no problem.


  12. Hi Carlos,

    Can you please filter the trace for the controller IP, just to see, if the AP tries to reach the controller. Maybe the firewall in the path is blocking the traffic for the ports, used by the AP to reach the controller. I will send you a trace from my lab tomorrow.

    Many thanks,

  13. Hi Carlos,

    Can you please look through your wireshark trace from the port mirroring and filter for the controller ip address "ip.addr == controller IP". You should see, that the AP tries to reach the controller on port UDP 39212. This is the port for the discovery process and should be open in your firewall.
    Afterwards, the AP connects to the controller with TCP and UDP port 1194, which also be open in your firewall.
    Can you please check, if the AP is at least sending those requests?
    Many thanks,

  14. Hi Florian,

    Again, thanks for your help. Sadly for me I can see nothing when I filter from the port mirror: what is really weird because the ip is receiving the correct options.

    but I can still see that the AP is receiving the correct information with the Colubris-AP vendor id, and the AP always is sending the same ID, never change to MSM 430.

    The ports on the firewalls are already open in both sides. (inbound and outbound)

  15. Hi Flomain

    First of all, happy new year! I finally found the problem between the AP and Controller, and for some reason the firewall was blocking the communication. We replace the firewall and everything is working well. Thank you very much for your help.

    Do you have a guide or tutorial, how to configure the AP with local switching & routing when the ap is in a remote site, but you want to have wireless access to the remote site, from the remote side and not form the remote site to the controller site? I have problem now that the ap in the remote site are routing the traffic to the controller site, not its local site.


  16. Hi Carlos,

    Happy new Year. I wish you all the best and it looks like you already got one surprise, a working AP<–>Controller connection 🙂

    Actually, I did not have a guide, which will help you in your scenario, but it should be very easy to achieve. One thing which will not work out of the box, captive portal and local traffic forwarding. If you use any other authentication mechanism than captive portal, you just need to make sure, that "Access Control" is not checked withing the VSC configuration, if that is the case, local traffic forwarding will be default and you have to tag the corresponding VLAN on every port, connected to a switch.

    I will try to get a post about local forwarding in January, depending on the workload on my daily job 🙂


  17. Hi Flomain,

    Hope everything is ok, your are right, it wasn't difficult with the local forwarding enable, but only with the default vlan "1", I'm trying to create a guest ssid, always using local forwarding, but for some reason it didnt work with a different vlan. Also I'have open a case in HP Call Center and they did a lab testing the feature and it didnt work. weird.

    did you have the same problem sometime?


  18. Hi Carlos,

    I'm fine.

    What I understand from your request, you would like to create a guest SSID with local forwarding?
    Should this SSID use the captive portal on the controller?

    Many thanks,

  19. Hi Flomain,

    No, this SSID is using a normal key. the issue is that, the "service-template" doesn't match the vlan in the remote site, so it didnt find a dhcp server.

    And Im using local forwarding with the local ssid, but this is using the default vlan and everything is working great.


  20. Hi Carlos,

    To enable local forwarding, you have to create the VLAN, which should be forwarded locally configured on the controller. When you bind a service template to an AP group, select this VLAN as an egress network and the AP will forward all clients withing this SSID into this VLAN and send the traffic taged to the switch port, where the AP is connected to.
    Can you post the configuration of the VSC and the the VSC binding, this will help to understand the problem.

  21. Hey,

    thank you for your guide.

    Also the replys to carlos where very useful.

    Very helpfull!!!

    Kind regards from Germany

  22. Hi Florian ,

    I have a situation where i have two MSM760 controllers teamed , i have around 154 AP's in my network . My problem here is that all the AP's are connected to the team manager and none to the team member . Is this a normal behavior or is this something wrong?

    I am kind of worried if my ap's will roam to the team member if the manager fails


  23. Hi Ashwin,

    Thanks for the feedback. If you are doing L2 discovery, the AP's will respond to the controller, which answers first. To test if the second controller will also see the AP's, you could try the following:
    1. select one AP to test with
    2. deny the MAC address of the AP on the uplink to the first controller
    3. bring the AP up
    4. check if the AP connect to the second controller

    You can also check by pinging the AP's from the controller first to make sure, connectivity is given.


  24. Hi Stefan,

    Correct, the MSM controllers are not comware based, which means, you only have to use the general option 43.
    Without getting a complete view of the environment, I could only guess what is going wrong.
    Did you have something configured like provisioning?
    Is the AP in he correct VLAN in the first time and is the AP using the correct IP to connect to the controller?

    You should open a support case with HP, as they are aware of any known bugs and can have a much deeper look into the configuration and log files.


  25. HI JP Nunes,

    Thanks for you comment.

    Out of my head, I have never seen this error before. I will do some tests later. What you have to do, is to set the radio in the mesh mode. This is done under "Radio Management–>Radio Configuration". The operating mode should be Local Mesh only or Access Point and Local Mash.
    That is the only thing, which came up to my mind. If could be, that you are facing a bug in the software. In this case you should open a ticket with HP to get this solved.
    If I get the time, I will setup a mesh by my self.
    Which version are you using?

    Many thanks,

  26. Florian,

    The AP's are configured as you told, i tested both operating modes (Local mesh only and Local mesh and Access point).

    I also openned 2 tickets with HP…. unfortunately helpless.

    thks for help

  27. Hello Florian,

    I just solve the problem.

    my Node Master's interface was configurated with bpduguard, this spanning-tree feature was causing an error-disable in the interface, rebooting the AP.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: