I'm in an environment where the vast majority of my 65 sites do not have vlan's defined. Everything is Procurve, defined in VLAN 1, and ulitmately plugged into an access port on a cisco 6513 that is in the VLAN I desire. From there DHCP requests are sent to my servers and a correct IP is handed out.
I've been deploying wireless in these buildings and as I have I've been creating wireless vlan's and seperating out the wireless traffic from regular user traffic and also implementing two vlans at each site. This appers to work great with my LWAPP's are connected directly to the controller and all the traffic is tunneled and I've created a dynamic interface on the WLC for the subnet in question.
The problem is -- In buildings were I have not been able to configure vlans as of yet and LWAPPs are deployed the AP's will hand out addresses to my clients in the subnet that the management interface is in. This subnet is unfortunately only a /24 and Addresses run out quickly. I've been experimenting with useing H-REAP to do central authentication and local switching but this does not seem to help. The clients either get NO address at all (0.0.0.0) or an address in the /24 of the management interface.
This is causes massive outages all over the enterprise due to the fact that when these new AP's are being installed they are unable to get IP's not matter what I do.
It should be said I work for a k12 and we had 200+ LWAPP's thrown on us without warning at 30 different sites. So there was zero time to plan for any of this. I'm in a pickle.
When this first happened our management interface was untagged while the native vlan was set the /24 where the management ip resides. One of the last things I have tried is to TAG the managment interface with the proper vlan ID and set the native vlan so some off-the-wall huge /16 I setup. I was hoping the clients would start getting IP's from THAT range if they were plugged into a building that was sitting in VLAN1 but had H-REAP enabled.
I'm at a total loss. I cannot explain why these damn clients are getting the IP's in the /24 of the manage interface. ANOTHER odd thing is that at -SOME- sites without any reason at all AP's plugged into VLAN1 switches are able to do central auth/central switching without ANY of this dhcp madness.
The aps tunnel all client traffic back to the controllers. The vlan, aka dynamic interface, where the clients land is configured in the WLAN page. By default, the WLAN config uses the management interface. You'll want to make sure to specify the right vlan here.
Do you have a controller at each site? Do you have your controllers located at a single site and the APs connect over a wan? Are the controllers configured to proxy dhcp requests? Are you trying to override the interface dhcp proxy config in the wlan config (dhcp override)?
The other thing you can try to do is to "anchor" all your clients to controller/location with a secondary vlan. A mobility anchor means that when a client associates, they connect to controller one, but then get handed off to controller two. That way, all of your clients get stuck on the same network. We use this feature at U of O for our guest network. Example: the "guest" ssid is configured on all of our controllers (even the ones at our remote sites). The "guest" wlan is configured to anchor all clients back to a controller that's firewalled. When any client accosiates to "guest", they always end up on the anchor controller in the same vlan. It's just like roaming, except you can force them to a particular controller.
If I understand you correct, you have a site that has a flat network (only one vlan). So in order to have clients obtain a dhcp address not on that sites management vlan, you need to either leave the ap in local mode or H-REAP using central authentication and central switching. Local mode, you will have the ssid mapped to a dynamic interface, in H-REAP, you will have the client tunnel back to the controller and the ssid will be mapped to a dynamic interface also. Depending on your WAN, H-REAP migth be the way to go.