2

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. Now, each client in the WLAN network has its own MAC address.

When a client moves from the area of one access point to another, it has to perform an access point change because its signal level went down. AFAIK, the MAC address of the client does not change during this procedure.

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? Let us assume that there is a mostly quiescent TCP connection that has data transfer only in the downlink direction at 10-second intervals, with no keepalive. Of course, there will be uplink ACKs but only as a response to the downlink data.

When the client has performed an access point change, if there's no uplink data, my understanding is that the switches will direct the downlink TCP data to an incorrect access point until the (MAC address, port) pairs in the switches expire.

Is there some kind of dummy uplink packet sent after an access point change to inform the switches in the network that the MAC address has moved to a new switch port?

Or is there some kind of mechanism where the old access point will redirect the packet to the new access point?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 16 '17 at 23:03
2

So, first of all, TCP is two-way protocol. If there's data travelling one way, you'll have data travelling the other way as well even if only just for the ACKs. You are correct however, that client MAC doesn't change.

The AP association/reassociation/leaving are quite interesting, and it's actually very chatty before AP and Your host assume they have a 'link up' between each other - sometimes it's 'only' four frames being exchanged, but with more security, it's usually whole discussion taking place over wireless. Take a look here for technical description of the process from 802.11 side: http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116493-technote-technology-00.html

Roaming itself became also quite complex process, with natural push to provide seamless mobility for the host roaming. Take a look at 802.11r if You're interested in the details: https://en.wikipedia.org/wiki/IEEE_802.11r-2008

1

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.

0

When the client move to AP, there is two possibilities:

  • In case the new AP connected to the same switch of the old AP, the switch will update its CAM table with the first packet sent from the client to the new AP port.
  • In case the new AP connected to a different switch, the old switch will learn that MAC has moved with the first broadcast Packet send by the client.

Normally the client will send a broadcast packet directly after connecting to the network for ARP, DHCP..etc

  • The first unicast packet sent by the client will update all switches on the way to its destination - presumably the server it's talking to - ie. all relevant switches are updated regardless of cast type. The first broadcast packet will update all switches. – Zac67 Jun 26 '17 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.