Just had a case about this where the anchor did not release because the DHCP expiration was not yet passed. I found it a little odd.   When the lease expires when the client is offline and the client gets online again, then it should get an ip address from the correct vlan, no anchor.    Anchor expiration is 30 seconds from what i've read, and DHCP mostly much longer 😉   I got this reply from Meraki: The anchor AP is the AP to which client traffic will be tunneled, if tunneling is required as a result of L3 roaming. "A client's anchor AP will timeout after the client has left the network for 30 seconds” indicates that the AP to which client traffic will be tunneled can change. However this is not referring to a change in broadcast domain (VLAN) for the client. The broadcast domain for the client can remain the same, whilst its anchor AP changes. The next sentence in the KB indicates this - "If the client disconnects from the network for 45 seconds, as an example, it may connect back to a new anchor AP on the same broadcast domain..." When a client associates to an AP, the AP looks in the distributed database for an entry related to that client. If the AP finds one, it tries to use the VLAN associated with that client. The KB then says - " The distributed database expiration timer for a client is the DHCP lease time. This effectively determines how long a client’s broadcast domain binding is remembered in the distributed database. If a client disconnects from the network, and then reconnects before the DHCP lease time has expired, then the client will still be bound to its original broadcast domain."     ... View more