Roaming across subnets

Why it happens

A roam moves the radio link. It does not move the subnet. When the next access point on a route places the client in a different VLAN, the client arrives holding an address from a network that does not exist there.

Either the network hides the move or the client takes a new address. One vendor’s controllers form roaming groups that forward a client’s traffic between subnets so it keeps its address, but a client that crosses the edge of a group is fully authenticated again. Another vendor anchors the client at the first access point it joined and tunnels it back there. If the new access point cannot reach the anchor, the client has to run DHCP on the new VLAN. An industrial design guide for EtherNet/IP takes the simplest route: plant-wide roaming equipment, such as overhead cranes, gets its own SSID on one VLAN that spans every zone it crosses.

Without a tunnel, the client asks DHCP, and DHCP was not built for speed. Archived Windows CE documentation describes a client that renews its address after every move and gets a new one when it crosses into a new subnet. The server refuses the old address, and the client restarts the full exchange. A lost message waits 4 seconds, plus or minus one¹, before the first retry. Checking a new address for conflicts can take as much as seven seconds. One vendor’s guide says a voice call that roams between VLANs without a tunnel goes quiet for several seconds.

A new address also ends every session the device had open. TCP identifies a connection by a pair of sockets, an address and a port at each end, so a new address means a new connection. An EtherNet/IP I/O connection is opened over TCP and then runs over UDP until it times out or is closed. The radio link can be back long before the application has waited out its timeout and reconnected.

You may already have fast roaming tuned and tested. That tuning covers the radio and the keys. It does nothing for an address that changes on the far side of a boundary. A route that stays inside one subnet roams at radio speed. A route that crosses one roams at DHCP speed, unless you have proven the tunnel that carries it.

How to confirm it

1. Mark every drop point on the route map, and note which access point group, controller, and VLAN serve each side of it.
2. Capture at a failing boundary and time the gap as the measurement guide describes, from the last data frame on the old access point to the first data frame after the roam.
3. Look at what follows the reassociation. A DHCP request for the old address, a refusal from the server, and then a fresh discovery mean the client changed subnets. Traffic carrying on from the old address means the network kept it.
4. Compare the client's IP address before and after the roam, on the client or in the controller's client table.
5. Check whether the device takes its address from DHCP or has a fixed one, and whether the VLAN on the far side carries that subnet.
6. Check the controller or access point logs at the drop for a mobility or anchor tunnel that failed to form, or a full authentication at the crossing.

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

Ben Rutter. "Roaming across subnets." OT Wireless, published October 8, 2026. https://otwireless.com/causes/roaming-across-subnets/

Rutter, B. (2026, October 8). Roaming across subnets. OT Wireless. https://otwireless.com/causes/roaming-across-subnets/

@misc{rutter2026roamingacrosssubnets,
  author = {Rutter, Ben},
  title = {{Roaming across subnets}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/causes/roaming-across-subnets/}},
  organization = {OT Wireless},
}