Guest Access and IP addressing usage

Have a typical Guest set up, foreign WLC has a tunnel to a WLC in our DMZ (mobility anchor); client will get a web page, and sign on; and off to the Internet they go.

As we know, client needs an IP address first before it does anything, as the SSID is out there with no authentication. and the problem we are running into is, we are running out of IPs because we have a bunch of clients picking up IPs but then they are not moving towards authenticating (I suspect many clients simply scan for any open SSID and connect to it, thereby using up an IP. We clamped down DHCP Lease time to 30 mins, but this only helped to an extent.

Is there anything on the WLC or other wireless network devices that can limit this from happening? Is increasing the scope the only way to resolve this issue?

If you anchor your foreign controller guest WLAN to more than (1) anchor DMZ clients will automagically round robbin from the first anchor to the second amchor and then back again to the first anchor. You cant turn this off or on, it just happens this way. I did put in a "change request" to have this as an option to turn off and on. But cisco hasnt added it yet and may never .. who knows...

71 is the cap. I dont know away around that ...

Good call on the DMZ mobility group name. I do the same helps with toruble shooting and doesnt take up a tunnel on existing internal mob groups ...

Oh well now that leads to another question then! (and yw for the ratings... )Here is my deal - I currently have roughly 150 WLCS now, expanding another possible 50 in the next 12 monthsI have 6 5508's in my DMZ

but there is still the limitation of 71 tunnels that can be made (unless you tell me there is a way around that!)

Each DMZ WLC also has its own mobility group name (i.e WLC 1 is mobility name xxxGUEST_01, WLC 2 is xxxGUEST_02...etc)

you mention round robin; how would I do that, considering each foreign WLC is only tunneled to one DMZ WLC currently?

If you anchor your foreign controller guest WLAN to more than (1) anchor DMZ clients will automagically round robbin from the first anchor to the second amchor and then back again to the first anchor. You cant turn this off or on, it just happens this way. I did put in a "change request" to have this as an option to turn off and on. But cisco hasnt added it yet and may never .. who knows...

71 is the cap. I dont know away around that ...

Good call on the DMZ mobility group name. I do the same helps with toruble shooting and doesnt take up a tunnel on existing internal mob groups ...

When we changed up this year (went from a private entity to being taken over by the 'mother ship' as I like to call it; they said '2012 is the Wireless Year, we want it everywhere to be able to be used by everyone; we want it easy, and we want to start employee BYOB (to which I grumbled a bit... but oh well) And now just got news we are taking another division on board, so that number I just gave you I say add another 10 or 15 to, not to mention a few WiSMs thrown in there. We were using Guest NAC, but then it was though to be easier using a shared ID/PW with it changing weekly, which currently I manage by pushing WCS jobs out each week; and future is to use an AD backend for that instead. And this is slightly off topic- but I also broadcast the SSID for the mother ship into our network and tunnel our WLC back to an anchor on their network so users can pick up IPs from there, and then our WLCs live in their radius server.... Fun Stuff, eh?

Cool! I will check your blog for sure... I sort of bumbled figuring it out... if only I had known I would have less head dings

Yes... we have a job that pushes each week, creating a local Net user, tied to the guest profile on the anchor WLCs. The username stays the same, and the pw changes. Figuring that out was also cause for a few head dings, but works great (so far!)