Let us assume that I have a large corporate WLAN network with many access points having the same SSID. The WLAN access points are connected to each other by learning Ethernet switches.
...
My question is, how do the switches in the network learn that the client has moved to another access point if the client is only consuming downlink data?
There is no simple answer to this question as there are quite a few flavors of client "roaming." While a bit outdated, this post is still largely relevant to illustrate some of the many types of roaming on wireless. There are also many different ways that different WiFi vendors handle client roaming (possibly different ways in any number of client roaming cases). So I will stick to some generalities.
Most large corporate WLAN installations are using Cisco or Aruba/HPE and typically tunnel all wireless traffic to the controllers. As such, even when a client device roams from one AP to another, it still lands on the network over the same connection (i.e. from the controller) so there is no need to update information on the switches.
There are also a few vendors that provide some type of single or virtual cell wireless solution. In these cases, the client may be transitioned from one AP to another, but they don't actually roam. In these cases the WiFi infrastructure may handle the notification to the wired network.
If security of any type is enabled and the client is not fast roaming, the client will send a DHCP request to validate their IP is still valid after reassociation. Even if they are fast roaming they may do so. This will update the switch in these cases.
Even if a client is largely only a "consumer" of data, there are very few client devices (possibly none on any given network) that completely avoid sending data. Most client devices are actually pretty "chatty" when they are connected to a network. Some examples that cause data to be sent from the client:
- TCP is a two way communication, having a session setup/tear down process and ACKs of all sent data.
- Background processes often check for software or data updates (new mail, application notifications, page refreshes, etc).
- Often client devices will check for the presence of services on the local network (MDNS queries are common) or may advertise these services themselves.
- User interaction with a device often triggers requests to be sent to servers/services on the network/Internet.
Ultimately, if a client is truly silent, the same will happen for it that happens for a truly silent client on the wired network (when the MAC entry ages out - generally as little as 1-3 minutes). Namely the network will flood unicast traffic. APs that receive this flooded traffic will not forward it unless the destination client is actually associated to the AP.
