Roaming - L2 vs L3 mobility

Requirement / business driver

Let clients move between APs/controllers without dropping sessions - critical for voice/video and seamless mobility.

L2 vs L3 roaming

• L2 roaming - client moves between APs in the same subnet/VLAN; keeps its IP, simple.
• L3 roaming - client moves to an AP/controller in a different subnet; to keep the IP/session, the controllers use a mobility tunnel back to the anchor controller (the original subnet). Necessary when a single VLAN can't (or shouldn't) span the whole mobility domain.
• Mobility groups/domains define which controllers cooperate for roaming.

Fast/seamless roaming

802.11r (fast BSS transition / pre-auth key exchange), 802.11k (neighbor reports - tells the client where to roam), 802.11v (BSS transition management), and OKC. These cut re-association/re-auth time so voice survives the roam (target well under ~150 ms handoff).

Mobility groups and the guest anchor pattern

The anchoring machinery above is organised by mobility groups - the controller collections inside which roaming hand-off is seamless (client state moves with the roam); across a group boundary a roam becomes a fresh join. Design mobility groups around where clients actually roam - buildings, campuses, device roles - not the org chart, and keep them small enough that controller-to-controller state stays manageable. The same tunnel used reactively for L3 roaming can also be used deliberately: a guest anchor flags a guest WLAN so that all of its client traffic is tunnelled from whatever (foreign) controller the user associates through to one static anchor controller - typically in the DMZ - containing every guest at a single policy and inspection point regardless of physical location. It is the wireless realisation of guest segmentation (Network access control and segmentation - NAC, TrustSec, guest and BYOD): the guest VLAN exists only at the anchor, so guest traffic never touches inside subnets.

Steering clients - and the fast-secure fine print

Roaming is a client decision; the infrastructure can only assist (standards) or coerce (proprietary), and every coercion has a failure mode. Band select suppresses 2.4 GHz probe responses so dual-band clients settle on 5 GHz - it is RSSI-gated (weak clients are answered normally) but it delays discovery, so keep it off latency-critical and voice WLANs. Load balancing ("aggressive") denies association to a busy AP - status code 17 on local-mode APs; on FlexConnect the AP has already answered success locally, so the WLC must deauthenticate after the fact - where "busy" is a client-count window relative to the least-loaded audible AP or an AP-uplink utilisation threshold. Persistent clients that cannot process the denial retry into a lockout, so a denial cap exists and the feature should be off on WLANs carrying critical or real-time devices. Optimized roaming attacks the sticky client from the other side: a client passing traffic below the RSSI floor (the coverage-hole thresholds) is force-disassociated to push it toward a better AP, protecting the channel's airtime from one low-rate straggler. The standards-based assists (11k neighbour reports, 11v BSS transition) do the same job by persuasion and are the default choice.

Fast-secure fine print: FT/802.11r caches the key hierarchy so a roam completes inside the four authentication/reassociation frames - it also covers PSK (skipping even the 4-way handshake), runs over-the-air (recommended) or over-the-DS, and offers an adaptive mode for Apple clients. CCKM survives as the Cisco/CCX niche - notably the only fast-secure method IOS WGBs speak (WLAN architectures).

Recommendation / justification

Prefer L2 roaming within a bounded mobility domain (avoid stretching one VLAN everywhere - large L2 is a failure domain, Layer 2 design fundamentals); use L3 roaming with anchoring where subnets must differ. Enable 802.11r/k/v for voice/real-time roaming, paired with proper QoS (QoS design - models and strategy) and coverage overlap (RF design - coverage, capacity, high density, voice, location).

What would change this (mid-scenario twist)

• Campus-wide voice with differing subnets -> L3 roaming (anchor) + 802.11r/k/v.
• Pressure to stretch one VLAN everywhere -> resist; bound the domain, roam at L3.

Validation checks

• Is the mobility domain bounded (not one giant VLAN), with L3 roaming where needed?
• Is fast roaming (11r/k/v) enabled and is handoff fast enough for voice?

IPv6 / dual-stack note

L3 roaming must preserve both v4 and v6 addressing/state across the anchor tunnel; test v6 roam continuity explicitly.

Related

• Controller placement, HA, and tunnel optimization
• RF design - coverage, capacity, high density, voice, location
• QoS design - models and strategy

Spaced repetition

Sources

• Cisco Press, CCIE Wireless v3 Study Guide (Alcantara, Darchis, Henry, Jimenez, Ziliotto) - band select, load balancing, optimized roaming, CCKM/FT variants.
• Cisco Press, Cisco Wireless mobility design; IEEE 802.11r/k/v.

domain: Core · blueprint-ref: Core 7.2.c L2/L3 roaming · type: design-decision · status: complete · tags: [core, core/wireless, tradeoff/latency, tradeoff/operability]