AP's getting wrong address from DHCP?

[Cajuntank MS]

I have had to redo my subnet addressing scheme at my schools to get ready for more devices. I created a management VLAN for my servers, switches, APs, etc... and a new VLAN for just wireless clients. According to what I understand, I untag the port connecting the AP to my management VLAN and tag the port for the VLAN my wireless clients will exist in. The problem is, all of a sudden, some of my APs are getting addresses from the wireless client VLAN even though I have plenty of addresses in the pool in the management VLAN and I am doing reservations to boot based on MAC addresses of the APs. My DHCP server is 2008, the newly created scopes are like I have done hundreds of times before, ip helper-address statements are correctly deployed on the VLAN interfaces, all other scopes process fine for DHCP clients.... I am just at a loss at the moment on why all of a sudden, some are not working with the reservations.

Any thoughts?

[Glen Willms]

I've experienced the same issue (running 5.7.0.3, but experienced in earlier versions). 

The APs keep going back to the DHCP server requesting a renewal of the IP address that is on the incorrect VLAN and is ignoring the provisioning settings for VLAN tagging. 

I have three resolutions to this problem. 

1 - Reset the AP to factory defaults. - The AP will come back fine but will be deemed suspicious. 

2 -

- On the port that the AP is on, remove all other VLAN tags except for the untagged port that you want to manage the AP from.

- Reboot the AP (I use #no interface x power to remove power from the PoE port)

-The AP will fail to renew the incorrect IP and request a new IP address on the untagged VLAN. 

-Add VLAN tagging back once the controller sees the device

3 - 

- Assign a static IP address to the AP. 

- Convert the AP to DHCP

It seems that once the APs are on the right track they continue to work. 

This issue is very repeatable. HP needs to fix this ASAP. 

[Cajuntank MS]

Thanks a bunch, I'll give it a try and post back.

[Cajuntank MS]

I tried removing the tag for the VLAN on those ports and rebooting APs. While that worked for a while; I of course, had to add that tag back and ultimately the APs found there way back into that tagged VLAN's ip subnet for their IP addresses. I had to make a call back into support for another unrelated issue that just started happening and asked the engineer about my APs getting addresses from their tagged VLAN and he had me click on Controlled APs on the left of the GUI menu, then Provisioning on the right, then under Connectivity tab. Check next to the Base Group:All and make sure that "No VLAN" is marked. Synch'd the config, then rebooted my APs in one of my groups and that seems to have worked. Will reboot my other APs tonight.

[gglater]

I believe that if you opened a case with support this could be resolved.  I encourage that support be contacted instead of or in parallel to posting here.

That said...

You should provision the APs to only use the untagged interface for discovery.  Controlled APs-> Provisioning-> Connectivity.  Check the checkbox in the upper left corner to enable connectivity provisioning and then make sure Port 1 and No VLAN are checked.

By default the APs will try to discover on the untagged interface plus any detected VLANs.  When the controller goes away (probably from a firmware upgrade), the AP goes into discovery mode.  When it can’t contact the controller on the untagged interface, it moves to a VLAN.  By that time the controller is back and if the AP can discover the controller over that interface, it will use it.

[Phrent]

I have been fighting with this for about 6 months now, and I think I finally have a solution for my scenario, which is as follows:

Controllers in a data center, APs deployed in throughout the network.

Initially I was using DNS to discover controllers, but due to some limitations with controller teaming, am now using the DHCP scope option to discover controllers.

I was having some of my APs show up in the tagged VLAN after days/weeks/months of deployment which caused the VSC that was associated to the tagged VLAN to have clients stop getting DHCP address assignments (not sure why, but the tagged VLAN for users was broken for user DHCP). This is how I would find out about the issue. If I factory defaulted the AP it would come back in the untagged management VLAN and function again. Not a feasible solution due to the number of APs that I will be working with.

I found that initially with DNS controller discovery, the AP could find the controller in any tagged VLAN that existed (as long as DNS resolution was allowed in the VLAN the AP booted into). After switching to the DHCP scope option (it is a bit of a pain to configure, but it works much better for my scenario with multiple controllers), I have the ability to prevent the APs from being able to discover the controller in any VLAN by excluding the scope option. The manual provisioning settings will still work (I never tried this but a recent call into support confirmed this for me) but also in my scenario would be a big pain. I have watched an AP that was having the issue booted into a tagged VLAN, and after removing the DHCP scope option from all the tagged VLAN DHCP scopes, a normal reboot didn't allow the AP to boot back into the untagged VLAN (I have been watching it for about 10 minutes now and it never booted back into the untagged VLAN, it just cycled back and forth in the tagged VLANs), so it still required to be factory defaulted.

I hope this gives someone another option to fix the "working as designed" issue of booting into a tagged VLAN.

-Phrent

[ONVZ]

Upgrade to v5.7.1 does not solve this issue.
Gave me a headache until I found this post.
Reset to factory defaults did the trick for me.