Home / Notes / WLAN Roaming Configuration

NOTES · WLAN / ROAMING

Seamless Wi-Fi Roaming: Layer 2/3 Roaming Configuration That Actually Works

Why two APs with the same SSID don't automatically mean a client roams cleanly between them: what Layer 2 and Layer 3 roaming actually depend on, the tunnel-forward and user-gateway pattern that keeps a client's IP address stable across access-layer boundaries, the smart-roam fast-roaming trigger, the reasons roaming fails even when everything looks identical, and the commands that confirm it's working.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

Why Roaming Breaks Even When Coverage Looks Fine

Two APs, one SSID, overlapping coverage — none of that guarantees a client keeps its session moving between them.

Whether roaming is invisible to a user or shows up as a dropped VPN session and a re-authentication prompt comes down to one design decision made back when the WLAN was built: is an AP's traffic forwarded straight out at the access layer it happens to connect to (direct forward), or tunneled back to a single point (tunnel forward)? That decision is what determines whether a client's IP address — and every session built on top of it — actually survives moving from one AP to another.

Below is the configuration this is based on — the tunnel-forward, user-gateway pattern for an AC placed off to the side of an aggregation switch, which is what lets a client keep the same IP address and default gateway as it roams to an AP whose uplink lands on a different device — plus the smart-roam trigger that pushes a client to actually leave a weakening AP instead of hanging on and dragging performance down for everyone nearby.

Roaming Principles: What Layer 2 and Layer 3 Roaming Actually Mean Here

It's not about how far apart the APs are physically — it's about whether the client's IP address is guaranteed to survive the move.

Diagram labels are kept in English for engineering clarity.

Layer 2 roaming is the simple case: every AP the client might roam to shares the same VLAN and the same forwarding point, so whatever IP address DHCP handed out stays valid no matter which AP the client is actually on. Roaming here is just a re-association — invisible at the IP layer because nothing about the client's IP layer ever needed to change.

Layer 3 roaming is what happens once an AP's management and service VLANs actually terminate on a different Layer 3 device than another AP's do — a different aggregation switch, a different segment. Left alone, a client roaming onto that AP would need a new IP address, breaking any session already in progress. The pattern the source configuration uses to avoid this — its own "user gateway" special scenario — is forward-mode tunnel on the VAP profile combined with keeping the wireless service's actual default gateway upstream, on the aggregation switch, rather than on the AC itself. The client's traffic tunnels back through CAPWAP to the AC regardless of which physical AP or aggregation switch it's actually near, so its IP address and gateway never change.

Addressing

Item	Value (this example)
AP management VLAN 2 — gateway on the aggregation switch	192.168.2.0/24 · Vlanif2 = 192.168.2.1
AC's own address inside that same VLAN	192.168.2.2 (excluded from the AP DHCP pool)
Wireless service VLAN 3 — SSID employee, gateway on the aggregation switch	192.168.3.0/24 · Vlanif3 = 192.168.3.1
CAPWAP tunnel source interface on the AC	Vlanif2
Forwarding mode on the VAP profile	forward-mode tunnel

Step-by-Step Configuration

Five moves: build the VLANs where the real gateway lives, trunk them to the AC, provision AP onboarding, set tunnel forwarding explicitly, and route the AC back out through that same gateway.

Build the AP management and wireless-service VLANs on the aggregation switch that actually owns the default gateway for both — this is the device a roaming client's IP address stays anchored to, not the AC.
Trunk those same VLANs through to the AC, and point the AC's CAPWAP source interface at its own address inside the management VLAN.
Provision DTLS credentials and AP authentication as usual, excluding the AC's own interconnect address from the DHCP pool that hands out AP addresses.
Build the SSID, security and VAP profile as usual, but explicitly set the VAP profile to forward-mode tunnel instead of leaving it on the direct-forward default.
Route the AC's own traffic back out through the aggregation switch, and confirm the AP reaches a normal (nor) state before testing an actual roam.

<L3> system-view
// aggregation switch — this is the device that owns the real default gateway
[L3] vlan batch 2 3
[L3] interface ge 0/0/2
[L3-GE0/0/2] port link-type trunk
[L3-GE0/0/2] port trunk pvid vlan 2
[L3-GE0/0/2] port trunk allow-pass vlan 2
[L3-GE0/0/2] quit
[L3] interface ge 0/0/24
[L3-GE0/0/24] port link-type trunk
[L3-GE0/0/24] port trunk allow-pass vlan 2 3
[L3-GE0/0/24] quit
[L3] dhcp enable
[L3] interface vlanif 2
[L3-Vlanif2] ip address 192.168.2.1 255.255.255.0
[L3-Vlanif2] dhcp select interface
[L3-Vlanif2] dhcp server excluded-ip-address 192.168.2.2
// excludes the AC's own interconnect address so it's never handed to an AP
[L3-Vlanif2] quit
[L3] interface vlanif 3
[L3-Vlanif3] ip address 192.168.3.1 255.255.255.0
[L3-Vlanif3] dhcp select interface
[L3-Vlanif3] dhcp server dns-list 114.114.114.114
[L3-Vlanif3] quit
[L3] return

<WAC> system-view
// AC — tunnels client traffic back instead of switching it locally
[WAC] vlan batch 2 3
[WAC] interface ge 0/0/1
[WAC-GE0/0/1] port link-type trunk
[WAC-GE0/0/1] port trunk allow-pass vlan 2 3
[WAC-GE0/0/1] quit
[WAC] interface vlanif 2
[WAC-Vlanif2] ip address 192.168.2.2 255.255.255.0
[WAC-Vlanif2] quit
[WAC] capwap source interface vlanif 2
// same DTLS PSK / FIT AP credential prompts as a standard bring-up — see our
// WLAN deployment note for that walkthrough in full
[WAC] capwap dtls no-auth enable
[WAC] wlan
[WAC-wlan] ap auth-mode no-auth
[WAC-wlan] display ap all
// State = nor confirms the AP joined before testing any roam
Total AP information:
nor : normal           [1]
----------------------------------------------------------------------------------------------------
ID MAC              Name Group           IP           Type               State STA Uptime  ExtraInfo
----------------------------------------------------------------------------------------------------
0 00e0-fc11-1111 area_1 default 192.168.2.208 AirEnginexxxx     nor 0 4H:49M:11S -
----------------------------------------------------------------------------------------------------
[WAC-wlan] security-profile name employee
[WAC-wlan-sec-prof-employee] security wpa-wpa2 psk pass-phrase YsHsjx_202206 aes
[WAC-wlan-sec-prof-employee] quit
[WAC-wlan] ssid-profile name employee
[WAC-wlan-ssid-prof-employee] ssid employee
[WAC-wlan-ssid-prof-employee] quit
[WAC-wlan] vap-profile name employee
[WAC-wlan-vap-prof-employee] security-profile employee
[WAC-wlan-vap-prof-employee] ssid-profile employee
[WAC-wlan-vap-prof-employee] service-vlan vlan-id 3
[WAC-wlan-vap-prof-employee] forward-mode tunnel
// this is what keeps the client's IP and gateway unchanged as it roams
[WAC-wlan-vap-prof-employee] quit
[WAC-wlan] ap-group name default
[WAC-wlan-ap-group-default] vap-profile employee wlan 1 radio all
[WAC-wlan-ap-group-default] quit
[WAC-wlan] quit
[WAC] ip route-static 0.0.0.0 0.0.0.0 192.168.2.1
// default route back out through the aggregation switch — the real gateway
[WAC] return

The DTLS PSK, FIT AP username/password and offline-management VAP PSK prompts triggered by capwap source interface are the same interactive flow covered step by step in our WLAN deployment note — abbreviated here to keep focus on what's actually different: forward-mode tunnel and where the default gateway lives.

Fast Roaming: The Smart-Roam Trigger

Tunnel forwarding decides whether a client keeps its IP when it roams — smart-roam decides when a client actually starts looking for a better AP in the first place.

Create an RRM profile and enable smart-roam, setting the signal-to-noise ratio threshold that triggers a client to look for a stronger AP instead of clinging to a fading one.
Reference that RRM profile from both the 2.4GHz and 5GHz radio profiles — binding it to only one leaves the other radio's clients without a roam trigger at all.

[WAC1-wlan] rrm-profile name wlan-rrm
[WAC1-wlan-rrm-prof-wlan-rrm] undo smart-roam disable
[WAC1-wlan-rrm-prof-wlan-rrm] smart-roam roam-threshold snr 15
// clients below 15dB SNR at their current AP are pushed to roam
[WAC1-wlan-rrm-prof-wlan-rrm] dynamic-edca enable
[WAC1-wlan-rrm-prof-wlan-rrm] quit
[WAC1-wlan] radio-2g-profile name wlan-radio2g
[WAC1-wlan-radio-2g-prof-wlan-radio2g] rrm-profile wlan-rrm
Warning: This action may cause service interruption. Continue?[Y/N]y
[WAC1-wlan-radio-2g-prof-wlan-radio2g] quit
[WAC1-wlan] radio-5g-profile name wlan-radio5g
[WAC1-wlan-radio-5g-prof-wlan-radio5g] rrm-profile wlan-rrm
Warning: This action may cause service interruption. Continue?[Y/N]y
[WAC1-wlan-radio-5g-prof-wlan-radio5g] quit

This is Huawei's smart-roam feature: a client is nudged to look for a stronger AP once its signal-to-noise ratio at the current AP drops below the configured threshold — 15dB in this example — rather than hanging on to a fading signal until it disconnects outright.

5 Configuration Gotchas

The ones that make roaming look broken even when every individual piece looks configured correctly.

1. Tunnel Forward Alone Doesn't Create Roaming — Gateway Placement Does

SYMPTOMforward-mode tunnel is configured, but a client still gets a new IP address — and drops its session — moving between two APs.

CAUSETunnel forwarding only changes where a client's frames get switched — back to the AC over CAPWAP — it doesn't by itself guarantee the client's default gateway is the same device network-wide. If the two APs' service VLANs actually terminate at two different gateways, the client still needs a new IP on one of them.

FIXKeep the wireless service's actual default gateway on one consistent Layer 3 device — the aggregation switch in this example — that every AC/AP in the roaming domain tunnels back toward, matching the source configuration's own user-gateway pattern rather than just flipping the forward-mode.

2. smart-roam Doesn't Fix a Bad Forwarding Design — It Only Decides When to Roam

SYMPTOMEnabling smart-roam and setting an SNR threshold doesn't stop sessions from dropping when a client roams.

CAUSEsmart-roam roam-threshold snr 15 only controls when a client is nudged to look for a better AP — it has nothing to do with whether the client keeps its IP address once it gets there. That's a forwarding-mode and gateway-placement question, covered separately.

FIXTreat smart-roam as a trigger-tuning setting, not a substitute for getting the tunnel-forward and gateway design right first.

3. Forgetting the 5GHz Radio Profile Leaves Half Your Clients Without the Trigger

SYMPTOM2.4GHz clients roam away from a weak AP as expected; 5GHz clients on the same AP hang on to a fading signal.

CAUSEThe RRM profile has to be referenced by both radio-2g-profile and radio-5g-profile individually — binding it to only one leaves the other radio's clients without a smart-roam trigger at all.

FIXApply rrm-profile wlan-rrm under both radio-2g-profile and radio-5g-profile, confirming each service-interruption warning as you go.

4. Referencing an RRM Profile Warns You It May Interrupt Service — Read It

SYMPTOMApplying an RRM profile to a radio profile throws a service-interruption warning that's easy to reflex-confirm.

CAUSEChanging radio-level profile bindings can momentarily affect clients already associated on that radio — the source configuration flags this explicitly every time.

FIXApply RRM and roaming changes during a maintenance window where a brief interruption on that radio is acceptable, not in the middle of a busy day on a live radio.

[WAC1-wlan-radio-2g-prof-wlan-radio2g] rrm-profile wlan-rrm
Warning: This action may cause service interruption. Continue?[Y/N]y

5. The AC's Own Interconnect Address Still Has to Be Excluded Here

SYMPTOMAn AP occasionally fails to get a usable address, or an address conflict appears on the management segment — in a design that's supposed to be roaming-ready.

CAUSEThe AC's own address inside the management VLAN (192.168.2.2 in this example) sits in the same pool the aggregation switch uses to address APs. If it isn't excluded, it can eventually be handed to an AP, breaking the very tunnel the roaming design depends on.

FIXExclude it explicitly on the aggregation switch, exactly as the source configuration does: dhcp server excluded-ip-address 192.168.2.2.

How to Confirm It's Actually Working

State nor confirms the AP joined — confirming a roam actually stays seamless takes watching a real client move.

Run display ap all on the AC and confirm every AP in the roaming domain shows State nor before testing anything.
Confirm the VAP profile actually shows forward-mode tunnel, not the direct-forward default — a roaming design silently reverted to direct forward is the single most common self-inflicted failure here.
Walk a client physically between two APs while it's mid-session (a ping running, a call in progress) and confirm its IP address doesn't change and the session doesn't drop — this is the only test that actually proves roaming, not just AP status.

[WAC-wlan] display ap all
Total AP information:
nor : normal           [1]
ExtraInfo : Extra information
P : insufficient power supply
Total: 1
----------------------------------------------------------------------------------------------------
ID MAC              Name Group           IP           Type               State STA Uptime  ExtraInfo
----------------------------------------------------------------------------------------------------
0 00e0-fc11-1111 area_1 default 192.168.2.208 AirEnginexxxx     nor 0 4H:49M:11S -
----------------------------------------------------------------------------------------------------

Honest Limits of This Note

Honest Limits of This Note

This note is based on one worked configuration: an AC placed off to the side of an aggregation switch, tunnel-forwarding a single wireless service back to a default gateway that lives on that switch, plus the smart-roam/RRM trigger from a separate high-density coverage case. It doesn't cover 802.11r/802.11k fast-transition roaming, mesh or agile-distributed (RU + central AP) roaming, or roaming across multiple independent ACs with no shared upstream gateway at all. It also assumes the AC initialization and AP onboarding already covered in our WLAN deployment note — start there first if you haven't onboarded an AP yet.

Five Questions Worth Having an Answer For

Pulled from the same configuration cases this note is built on.

What's the actual difference between Layer 2 and Layer 3 roaming in this design?

Layer 2 roaming means every AP a client might roam to shares the same VLAN and forwarding point, so the client's IP address stays valid regardless of which AP it's on — roaming is invisible at the IP layer. Layer 3 roaming means the APs' service VLANs actually terminate on different Layer 3 devices; without tunnel forwarding and a consistent gateway placement, the client would need a new IP address on each one.

Does forward-mode tunnel by itself make roaming seamless?

No. It changes where the client's traffic is switched, not automatically where its default gateway lives. Seamless roaming across a Layer 3 boundary needs tunnel forwarding combined with keeping that gateway on one consistent device that every AC/AP in the roaming domain tunnels back toward — the user-gateway pattern this note is built on.

What does smart-roam roam-threshold snr actually control, and why 15dB?

It sets the signal-to-noise ratio below which a client is nudged to look for a stronger AP instead of staying associated to a fading one. 15dB is the value used in the source configuration's own high-density coverage case — the right threshold for a given site depends on AP density and how tolerant the applications in use are of a brief roam.

Do I need a mobility group or something similar to other vendors' roaming designs?

Not in this architecture. Because forwarding is centralized back at the AC and the gateway device via CAPWAP tunneling and the user-gateway design, there's no separate mobility-group concept to configure the way some other vendors require — the ap-group, VAP-profile and rrm-profile bindings described above are what stands in for it.

My client disconnects and reconnects instead of roaming seamlessly — what should I check first?

Forwarding-mode consistency across every AP in the roaming domain, whether the actual default gateway is on one consistent device, whether the rrm-profile is bound to both the 2.4GHz and 5GHz radio profiles, and whether the SSID and security-profile are configured identically on every AP in range.

Clients dropping sessions when they roam between APs?

Tell us your AC/AP layout and whether the access layer between them is routed, and we'll help you get the forwarding mode and roaming trigger right.

WhatsApp an engineer →