Wireless Client(s) Receive IP Address of Incorrect VLAN

[san.carlos]

Cisco Catalyst 9800-CL Wireless Controller
17.9.3

I randomly, but constantly, have clients that connect to a wireless network associated with a specific VLAN, but for some reason, get an IP address assignment from a different VLAN. This has occurred with clients that connect to the same wireless network and clients that might hop on different wireless networks. It seems to me that the controller might be caching the client's previous connection and re-associating it when the client reconnects or potentially incorrectly identifying the VLAN.  

Does anyone have any insight to what might be happening here?

[marce1000]

  - You may start with a checkup of the  9800-CL Wireless Controller's configuration with the CLI command
     show tech wireless (not simple 'show tech') and feed the output from that into Wireless Config Analyzer

  M.

[san.carlos]

@marce1000 

Thank you. I will run the show tech wireless output through the analyzer.

[Flavio Miranda]

@san.carlos 

  For central switching this is an expected behavior. When clients move around and connect to an access point and this access point  is connected to a switch that have different vlans from the privious one, the WLC is able to keep the client IP address in order to avoid reconnection. If the client had to get a new IP address, it would required a new DHCP process, authantication and  if any NAT session were in place, it would break. For an application like stream, it would be a terrible experience if clients changes the IP everytime it moves.

[san.carlos]

@Flavio Miranda 

That makes sense to me, I can see the benefits. Is there a period of time that the client IP address is cached and can a specific record be flushed out when needed?

[Flavio Miranda]

As long as the session remains active, as per cisco docs.

"Inter-Subnet Roaming

Multiple-controller deployments support client roaming across access points managed by controllers in the same mobility group on different subnets. This roaming is transparent to the client because the session is sustained and a tunnel between the controllers allows the client to continue using the same DHCP-assigned or client-assigned IP address as long as the session remains active. "

[Rich R]

Also 17.9.3 is now seriously out of date and also affected by a critical security vulnerability! 

Refer to the TAC recommended link (below) for current recommended code versions. 
17.12.3 is the currently recommended version. 
Many of us have already upgraded to 17.12.4 + SMUs and APSP for a large number of additional fixes.