This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Lack of Wi-Fi Mobility Can Cripple UC
You have a full schedule, so you grab your lunch and sit down for a few minutes. There’s an important project review conference call starting just as you sit down. You take the call on your tablet and finish lunch while on the call. The next meeting is in another part of the building, so you start walking. Then your connection to the network changes and your conference call drops. ARRG!!! Why won’t the call stay connected while you’re moving? Cell phones manage to stay connected while you’re driving! What happened is that your tablet switched from one access point (AP) to another, but mobile roaming wasn’t properly configured, so your tablet now has a new IP address.
The above scenario is repeated many times a day in many organizations. While the details may be different, the result is the same: The call drops when the mobile device switches APs. Increasing the density of APs (while reducing the cell size to prevent adjacent channel interference) exacerbates the problem. In the worst case, simply walking across a classroom or auditorium could cause a switch.
Wi-Fi mobility can work. It just requires that the Wi-Fi system be configured to support mobility. There are several mobility choices and the correct selection depends on your network architecture. First, an organization might not have mobility configured at all. In this case, when a client moves between APs, the client gets a new IP address. One way to avoid address changes is to use roaming at Layer 2.
A small organization might use a single wireless VLAN per SSID, with roaming at Layer 2 (the data-link layer). There are two Layer 2 roaming situations:
- The client roams between APs connected to the same controller. The wireless controller remains the connection endpoint for the client.
- The client roams between APs that connect to different controllers. As long as both controllers are on the same subnet (i.e., the same Layer 2 domain), the client’s connection record moves from the original controller to the new controller. This is transparent to the client.
If clients are able to roam between APs in situation 1 but not in situation 2, intermittent connectivity will result. Sometimes a client will be able to roam (situation 1) and sometimes it won’t (situation 2, but the handoff isn’t working).
There’s another catch with Layer 2 roaming. We don’t recommend extending Layer 2 very far -- it creates a large failure domain when (not if) a spanning tree loop forms. Troubleshooting spanning tree loops is time consuming. You have to physically break the network into individual segments by unplugging links in order to diagnose where the fault is occurring.
The preferred configuration is to use Layer 3, placing each controller (and SSID) on a separate subnet. When the client roams to an AP that’s on the second controller, the client’s connection record is copied (not moved) to the second controller and is marked as Foreign, meaning that it has to handle packets that are forwarded from the original controller. The original controller’s record is marked as an Anchor record. Traffic to the client goes to the IP address associated with the original controller, which then forwards it to the second controller via an Ethernet-over-IP tunnel. More configuration is required and more troubleshooting when it has problems, but it’s better and safer design than stretching Layer 2 across the infrastructure.