Migrating SSID subnet

[bwestfall623]

Hey everyone,

I wanted to ask a question here because I haven't been able to find anything similar to what we're trying to accomplish. We have an SSID that is nearing the cap on available IPs in our given subnet, and due to another SSID being right next to the IP space we can't simply increase the mask space due to the direction it goes into. So...the plan is to simply migrate the subnet to an IP space that is not "touching" another, to potentially give us both more room now and more room in the future.

How I went about this during this migration was simply in the WLC migrate the IP/subnet/gateway to the other IP space with the hope that clients connected to that SSID would simply request another IP and reconnect. Sadly this was not the case and no clients were able to reconnect. I worked with staff as well to manually reconnect and it was no longer able, so I simply reverted the information in the Controller>Interfaces>(SSID) and clients immediately reconnected.

Is simply migrating the subnet and having clients automatically reconnect due to "remembering" the SSID not possible? Is there something I perhaps missed?

WLC 5520, version 8.5.140. Clients connect/authenticate via Radius which was pre set up and verified working during my testing process which I left out. If more information is needed please let me know, any help would be greatly appreciated as I'd like to tackle this again somewhat soon.

[balaji.bandi]

best i can suggest in this situation. easy to fix is. :

Take the new subnet wide range ( create a new SVI VLAN in the Layer 3 switch side)

Add that new VLAN to WLC - interface and add VLAN to Interface Group

Make sure DHCP Scope are create as before working(like same) - once that is added new IP address space will be used,

This will not have any service interupt.

[bwestfall623]

Yea that is what I tried. I did leave that part out I apologize but my testing process was to stand up the new SVI and subnet on the L3 switch, create the DHCP scope, ACLs, ect, and threw up a test SSID with that vlan assigned with proper IP/netmask/gateway information and it worked. However, moving over that same information to the currently working SSID prevented clients from connecting. I was sure that your process (my thinking as well) would have "simply worked" yet it didn't.

Ironically just this morning the neighbor subnet of the mentioned SSID is now getting full as well and I may just move the other one and play with the netmask on the mentioned SSID instead as it will now work if I move the other one.

Thanks for the reply. I don't exactly know yet what I'll be doing but I am very glad to read that my thinking was how it should work.

[Scott Fella · Accepted solution]

You need to really understand how clients function, not your fault, but folks learn from experience, as you found out the hard way.  There are client devices that want to keep their existing ip address because the devices believe it has a functioning ip address.  Depending on your environment, I'm assuming you took a downtime, I would have had the new vlan prepped which you did, but maybe shut down the SSID for 10-20 minutes.  I would then make the changes to map the SSID to the new vlan and then enabled that SSID.  When dealing with clients, you should always plan for devices that will not join, maybe because they were in sleep or hibernating mode.  I would only use vlan groups if I really need to use them, but a new subnet or increasing the mask if possible would be my choice.  

[bwestfall623]

Agreed. I don't fully understand why they wouldn't just request a new IP, as changing a vlan on a switch for example with an end device connected generally gets resolved pretty quickly in terms of the end device requesting a new IP and getting connected. I assumed it would be somewhat similar for wireless devices. I did take a downtime, however this was planned and within a maintenance window so no harm there. With your response and balaji's I think my thought process was on the right track and perhaps as you said I didn't give them enough time to re-request an IP on the new subnet. After discussing with my team we'll be simply increasing the subnet size and migrating the other subnet that this SSID would encroach into if we increase the mask, as the other subnet is simply less critical and generally for staff byod devices.

Thank you for the response.

[Scott Fella]

There are way's if you want to really spend time to do this, but again, you will get clients that are in sleep/hibernate, which do not do a dhcp request when they come out of sleep/hibernate.  We ran into this issue with users whom never reboot and come from home and open their laptop and it takes a while before the device send a dhcp request.  They had put their device into hibernate and that was consistent with a few others.  The easiest path is to inform users of the change and what they should do if they encounter network issues, or just tell them to reboot.  This way they are communicated to and will have less complaints.  If you do the work overnight, you can have folks reboot once they come in to work.  Just think it through with your peers to see what is the best route to not impact the users and being transparent to them also.

[balaji.bandi]

Agreed if the option to increate the scope, most case we dont get that option, so suggest made to add new interface with new VLAN in Group to remidiate the issue.

when we doing this increasing the scope, worth we need to remove any DHCP active from DHCP (since that will overlap or used by another SSID  - which you using part of increasing the scope)