OT Wireless
Search/Menu

Search the field guide, causes, requirements, and glossary

Wired MAC tables that lag after a roam

After a roam the client sits on a new access point, but the wired switches keep sending its traffic, and traffic for every device behind a client bridge, toward the old one until something teaches them the new port.

Ben RutterIndustrial network engineer
On this page5 sections
  1. How it presents
  2. Why it happens
  3. How to confirm it
  4. The fix
  5. Prevent it at design time

Is this your problem? It presents like this

  • The client reassociates on time, but traffic to it stays down after the roam is over.
  • Downlink traffic to the client stays lost for longer than uplink traffic from it, because the wired destination of the uplink never moved.
  • A client bridge answers right after a roam while the devices behind it do not.
  • Devices that only listen, or talk rarely, stay unreachable longest.
  • Right after a roam, the switch MAC table still shows the client's address on the port toward the old access point.
Bands
2.4 GHz5 GHz5 GHz DFS6 GHz
Not sure?
Rank the likely causes from your symptoms

Why it happens

A roam finishes on the radio before it finishes on the wire. A switch forwards by destination MAC, using a table built from the source addresses it has seen on each port, and an entry lasts until it ages out, after 300 seconds, the default 802.1D recommends1. Where each access point puts client traffic onto the wire at its own switch port, as one design guide does for traffic inside a cell, a roam moves the client’s MAC to a new port. Downlink traffic keeps going to the old one until something teaches the switches otherwise.

Something usually does. The 802.11F recommended practice, approved in 2003 and withdrawn in 20062, defined a Layer 2 Update frame: a broadcast with the station’s MAC as its source, sent to update forwarding tables in layer 2 bridge devices3. The hostapd project calls it the main part of that protocol in real use, and says kernel drivers now handle it. A client that follows RFC 5227 also probes its IP address with broadcast ARP when it associates with a new base station. Both teach every switch the new port. Each carries one MAC, the station’s own.

That leaves a gap for a workgroup bridge. The bridge is one station with many MACs behind it. It learns its wired devices’ addresses on its Ethernet port and reports them to the access point. After a roam, one vendor’s bridge resends that list, and its roaming note says traffic resumes as soon as the parent processes those updates. Until then the bridge answers and the devices behind it do not. You might expect those devices to announce themselves the way a roaming client does. They have no cue to: their own cable never went down.

Silent devices take longest. A device that only listens gives the bridge and the switches no frame to learn from. Its stale entry can last the full aging time, and a bridge cannot report a device it has never heard. Count a roam as finished when traffic reaches every MAC behind the client, not when the client reassociates.

How to confirm it

  1. Take the reassociation time from the access point log or a capture.
  2. Time the gap as in the measurement guide, separately for uplink and downlink, and for the bridge and each device behind it.
  3. Right after a roam, read the MAC address table on each switch in the path for the client's address and every address behind its bridge, and note which port each one points to.
  4. Capture on the new access point's switch port for a broadcast frame from the client's address just after reassociation, such as a Layer 2 Update frame or an ARP probe.
  5. Check the access point or controller client list for the bridge's wired devices, and note how long after the roam each one reappears.
  6. Find out where client traffic enters the wired network, at each access point's switch port or at a controller, and read the MAC aging time on each switch.

The measurement guide shows how to probe, capture, and time a drop step by step.

The fix

  • Make sure the access points send a Layer 2 update for every station that roams to them, and confirm it in a capture.
  • Make each bridge report its wired devices to the new access point right after a roam, and shorten any refresh timer that delays the report.
  • Give silent devices a reason to transmit, such as a periodic heartbeat or a cyclic I/O connection, so the bridge and the switches learn them again at once.
  • Where the design allows, bring a roaming client's traffic onto the wired network at one point, so a roam does not move its address between switch ports.

Prevent it at design time

  • In acceptance tests, measure downlink to every device behind a bridge after each roam, not only to the bridge.
  • Keep a list of devices that only listen, and give each one a periodic transmission.
  • Choose bridges whose documentation says how they report wired devices after a roam and how many they carry.
  • Record MAC aging times and where client traffic joins the wire in the design documents.

Related causes

Terms on this page

About this page

Built from 6 sources: 3 standards bodies and labs and 3 vendor documents. Researched and drafted with AI assistance. How pages are made

First published
Last updated
Change history (1)
  • First published
Cite this page

Plain

Ben Rutter. "Wired MAC tables that lag after a roam." OT Wireless, published October 8, 2026. https://otwireless.com/causes/wired-mac-table-convergence-after-a-roam/

APA 7

Rutter, B. (2026, October 8). Wired MAC tables that lag after a roam. OT Wireless. https://otwireless.com/causes/wired-mac-table-convergence-after-a-roam/

BibTeX

@misc{rutter2026wiredmactableconvergenceafteraroam,
  author = {Rutter, Ben},
  title = {{Wired MAC tables that lag after a roam}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/causes/wired-mac-table-convergence-after-a-roam/}},
  organization = {OT Wireless},
}