Clients with address issues between offices

[JHarris6117]

Community (will rate),

We are encountering a situation where a client in a remote location (several hours away) disconnects from an AP in flex connect mode, and travels to another office with AP's in local mode.  When the client attempts to connect to the SSID (same SSID) they continue to be delivered the dhcp address of the first office.

Yes, roaming between flex and local is not supported, but this should be a roam, the controller should have disassociated this client a while ago?  Is there something i'm missing?

Thanks

[Scott Fella]

It’s your idle timer. Make sure it’s low enough that it expires before the time it takes from one office to another.

[JHarris6117]

Scott,

Great idea..
Our "Client user idle timeout" is checked and set to 3600 seconds (1hr). We've experienced issues where a user left an office, and traveled for 3 hours, got back to the other office and still gets the old ip address. Note: the "Client user idle threshold" is set to 0 bytes.. would this mean infinite?

On a side note: We wiresharked the DHCP session:
The client's bootp request upon getting to the 2nd office (AP's in local here) requests the old IP address
The controller responds (DHCP relay) with a DHCP ACK and gives the client the old ip address.

[Scott Fella]

If the client is in the run state, then the controller will not remove the client from its db. This will allow the client to skip the dhcp required state. I don’t know what your design or requirements are, but typically I have session timer disabled and idle timer left at default which is 300 seconds. This is for any wlans that are not using webauth. For webauth, sleeping timer is defined to reduce the risk of users having to login every time the device goes to sleep. Typically iOS devices.

You can test this by creating a test SSID, lowering the the idle timer (which has to be lower than the session timer) on that wlan and close the laptop lid. Run a debug during this time to see when the client gets removed. Once removed, the client will try to use its old ip, but the wlc will not allow it because it will be in the dhcp_req state

[JHarris6117]

Hey Scott,

I tested this by joining the flex AP (remote) then going into airplane mode, force removed my client from the controller then reconnected to a local mode AP and I still got a bad DHCP address. I'm starting to think the issue is a MS DHCP server issue. I wrote up the detail of the DHCP server issue here:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/4e93706d-bbc8-4fb1-b668-fbc521ab0952/ms-dhcp-server-2016-responding-to-dhcp-request-w-wrong-scope?forum=winserveripamdhcpdns#4e93706d-bbc8-4fb1-b668-fbc521ab0952

Appreciate any other thoughts you might have,

[JHarris6117 · Accepted solution]

We found the issue. Ended up being the controller not handling DHCP requests properly. We bypassed the controller (by disabling the DHCP Proxy mode for that interface) and allowed the SVI's IP Helper to relay the DHCP requests. All is good now.