Pourquoi deux AP portant le même SSID ne garantissent pas qu'un client itinère proprement entre eux : ce dont dépendent réellement l'itinérance de couche 2 et de couche 3, le schéma de transfert par tunnel et de passerelle utilisateur qui maintient stable l'adresse IP d'un client à travers les frontières de la couche d'accès, le déclencheur d'itinérance rapide smart-roam, les raisons pour lesquelles l'itinérance échoue même quand tout semble identique, et les commandes qui confirment que cela fonctionne.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Deux AP, un seul SSID, une couverture qui se chevauche — rien de tout cela ne garantit qu'un client conserve sa session en se déplaçant entre eux.
Que l'itinérance soit invisible pour l'utilisateur ou se traduise par une session VPN interrompue et une invite de ré-authentification dépend d'une décision de conception prise dès la construction du WLAN : le trafic d'un AP est-il transféré directement au niveau de la couche d'accès à laquelle il se connecte (transfert direct), ou tunnelisé vers un point unique (transfert par tunnel) ? Cette décision détermine si l'adresse IP d'un client — et chaque session qui en dépend — survit réellement au déplacement d'un AP à un autre.
Voici la configuration sur laquelle ce billet s'appuie — le schéma de transfert par tunnel et de passerelle utilisateur pour un AC placé en dérivation à côté d'un commutateur d'agrégation, ce qui permet à un client de conserver la même adresse IP et la même passerelle par défaut lorsqu'il itinère vers un AP dont la liaison montante aboutit sur un autre appareil — ainsi que le déclencheur smart-roam qui pousse un client à réellement quitter un AP en affaiblissement plutôt que de s'y accrocher et de dégrader les performances de tout le monde à proximité.
Il ne s'agit pas de la distance physique entre les AP — il s'agit de savoir si l'adresse IP du client est garantie de survivre au déplacement.
Les légendes du schéma restent en anglais pour la clarté technique.
L'itinérance de couche 2 est le cas simple : tout AP vers lequel le client pourrait itinérer partage le même VLAN et le même point de transfert, de sorte que l'adresse IP attribuée par le DHCP reste valide quel que soit l'AP sur lequel se trouve réellement le client. L'itinérance ici n'est qu'une ré-association — invisible au niveau IP car rien dans la couche IP du client n'a jamais eu besoin de changer.
L'itinérance de couche 3 se produit lorsque les VLAN de gestion et de service d'un AP se terminent réellement sur un appareil de couche 3 différent de celui d'un autre AP — un commutateur d'agrégation différent, un segment différent. Sans intervention, un client itinérant vers cet AP aurait besoin d'une nouvelle adresse IP, interrompant toute session déjà en cours. Le schéma que la configuration source utilise pour éviter cela — son propre scénario spécial de « passerelle utilisateur » — consiste en forward-mode tunnel sur le profil VAP combiné au maintien de la passerelle par défaut réelle du service sans fil en amont, sur le commutateur d'agrégation, plutôt que sur l'AC lui-même. Le trafic du client transite en tunnel via CAPWAP vers l'AC, quel que soit l'AP physique ou le commutateur d'agrégation dont il est réellement proche, de sorte que son adresse IP et sa passerelle ne changent jamais.
Adressage
| Élément | Valeur (cet exemple) |
|---|---|
| VLAN de gestion des AP 2 — passerelle sur le commutateur d'agrégation | 192.168.2.0/24 · Vlanif2 = 192.168.2.1 |
| Adresse propre de l'AC au sein de ce même VLAN | 192.168.2.2 (excluded from the AP DHCP pool) |
| VLAN de service sans fil 3 — SSID employee, passerelle sur le commutateur d'agrégation | 192.168.3.0/24 · Vlanif3 = 192.168.3.1 |
| Interface source du tunnel CAPWAP sur l'AC | Vlanif2 |
| Mode de transfert sur le profil VAP | forward-mode tunnel |
Cinq étapes : créer les VLAN là où réside la véritable passerelle, les faire transiter en trunk vers l'AC, provisionner la mise en service de l'AP, définir explicitement le transfert par tunnel, et router l'AC en retour via cette même passerelle.
<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] returnLes invites de PSK DTLS, de nom d'utilisateur/mot de passe FIT AP et de PSK de VAP de gestion hors ligne déclenchées par capwap source interface correspondent au même flux interactif détaillé étape par étape dans notre note sur le déploiement WLAN — abrégées ici pour se concentrer sur ce qui diffère réellement : forward-mode tunnel et l'emplacement de la passerelle par défaut.
Le transfert par tunnel décide si un client conserve son IP en itinérant — smart-roam décide quand un client commence réellement à chercher un meilleur AP.
[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] quitIl s'agit de la fonctionnalité smart-roam de Huawei : un client est incité à chercher un AP plus puissant dès que son rapport signal/bruit sur l'AP actuel passe sous le seuil configuré — 15dB dans cet exemple — plutôt que de s'accrocher à un signal en affaiblissement jusqu'à une déconnexion pure et simple.
Ceux qui font paraître l'itinérance cassée même quand chaque élément pris isolément semble correctement configuré.
SYMPTOMforward-mode tunnel est configuré, mais un client obtient toujours une nouvelle adresse IP — et perd sa session — en se déplaçant entre deux AP.
CAUSELe transfert par tunnel change uniquement l'endroit où les trames d'un client sont commutées — vers l'AC via CAPWAP — il ne garantit pas en soi que la passerelle par défaut du client soit le même appareil sur tout le réseau. Si les VLAN de service des deux AP se terminent réellement sur deux passerelles différentes, le client a toujours besoin d'une nouvelle IP sur l'une d'elles.
FIXGardez la passerelle par défaut réelle du service sans fil sur un seul appareil de couche 3 cohérent — le commutateur d'agrégation dans cet exemple — vers lequel tunnelisent en retour tous les AC/AP du domaine d'itinérance, conformément au schéma de passerelle utilisateur propre à la configuration source, plutôt que de simplement basculer le mode de transfert.
SYMPTOMActiver smart-roam et définir un seuil SNR n'empêche pas les sessions de s'interrompre lorsqu'un client itinère.
CAUSEsmart-roam roam-threshold snr 15 contrôle uniquement le moment où un client est incité à chercher un meilleur AP — cela n'a rien à voir avec le fait que le client conserve ou non son adresse IP une fois arrivé. C'est une question de mode de transfert et d'emplacement de passerelle, traitée séparément.
FIXConsidérez smart-roam comme un réglage d'ajustement du déclencheur, pas comme un substitut à une conception correcte du transfert par tunnel et de la passerelle en premier lieu.
SYMPTOMLes clients 2,4 GHz s'éloignent d'un AP faible comme prévu ; les clients 5 GHz sur le même AP s'accrochent à un signal en affaiblissement.
CAUSELe profil RRM doit être référencé individuellement à la fois par radio-2g-profile et radio-5g-profile — ne le lier qu'à l'un des deux prive les clients de l'autre radio de tout déclencheur smart-roam.
FIXAppliquez rrm-profile wlan-rrm à la fois sous radio-2g-profile et radio-5g-profile, en confirmant chaque avertissement d'interruption de service au fur et à mesure.
SYMPTOMAppliquer un profil RRM à un profil radio déclenche un avertissement d'interruption de service qu'il est facile de confirmer par réflexe.
CAUSEModifier les liaisons de profil au niveau radio peut affecter momentanément les clients déjà associés sur cette radio — la configuration source le signale explicitement à chaque fois.
FIXAppliquez les modifications RRM et d'itinérance pendant une fenêtre de maintenance où une brève interruption sur cette radio est acceptable, pas en pleine journée chargée sur une radio en production.
[WAC1-wlan-radio-2g-prof-wlan-radio2g] rrm-profile wlan-rrm
Warning: This action may cause service interruption. Continue?[Y/N]ySYMPTOMUn AP échoue occasionnellement à obtenir une adresse utilisable, ou un conflit d'adresse apparaît sur le segment de gestion — dans une conception censée être prête pour l'itinérance.
CAUSEL'adresse propre de l'AC au sein du VLAN de gestion (192.168.2.2 dans cet exemple) se trouve dans le même pool que celui utilisé par le commutateur d'agrégation pour adresser les AP. Si elle n'est pas exclue, elle peut finir par être attribuée à un AP, brisant le tunnel même dont dépend la conception de l'itinérance.
FIXExcluez-la explicitement sur le commutateur d'agrégation, exactement comme le fait la configuration source : dhcp server excluded-ip-address 192.168.2.2.
L'état nor confirme que l'AP a rejoint — confirmer qu'une itinérance reste réellement transparente nécessite d'observer un vrai client se déplacer.
[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 -
----------------------------------------------------------------------------------------------------Cette note s'appuie sur une seule configuration testée : un AC placé en dérivation à côté d'un commutateur d'agrégation, transférant en tunnel un seul service sans fil vers une passerelle par défaut résidant sur ce commutateur, ainsi que le déclencheur smart-roam/RRM issu d'un cas de couverture à haute densité distinct. Elle ne couvre pas l'itinérance à transition rapide 802.11r/802.11k, l'itinérance en mesh ou distribuée agile (RU + AP central), ni l'itinérance entre plusieurs AC indépendants sans aucune passerelle amont partagée. Elle suppose également que l'initialisation de l'AC et la mise en service de l'AP, déjà couvertes dans notre note sur le déploiement WLAN, sont effectuées — commencez par là si vous n'avez pas encore mis un AP en service.
Tirées des mêmes cas de configuration sur lesquels s'appuie cette note.
L'itinérance de couche 2 signifie que tout AP vers lequel un client pourrait itinérer partage le même VLAN et le même point de transfert, si bien que l'adresse IP du client reste valide quel que soit l'AP sur lequel il se trouve — l'itinérance est invisible au niveau IP. L'itinérance de couche 3 signifie que les VLAN de service des AP se terminent réellement sur des appareils de couche 3 différents ; sans transfert par tunnel et un emplacement de passerelle cohérent, le client aurait besoin d'une nouvelle adresse IP sur chacun d'eux.
Non. Cela change l'endroit où le trafic du client est commuté, pas automatiquement l'emplacement de sa passerelle par défaut. Une itinérance transparente à travers une frontière de couche 3 nécessite le transfert par tunnel combiné au maintien de cette passerelle sur un seul appareil cohérent vers lequel tunnelisent en retour tous les AC/AP du domaine d'itinérance — le schéma de passerelle utilisateur sur lequel se fonde cette note.
Il définit le rapport signal/bruit en dessous duquel un client est incité à chercher un AP plus puissant plutôt que de rester associé à un AP en affaiblissement. 15dB est la valeur utilisée dans le propre cas de couverture à haute densité de la configuration source — le seuil approprié pour un site donné dépend de la densité des AP et de la tolérance des applications utilisées à une brève itinérance.
Pas dans cette architecture. Comme le transfert est centralisé en retour vers l'AC et l'appareil passerelle via le tunneling CAPWAP et la conception de passerelle utilisateur, il n'y a pas de concept séparé de groupe de mobilité à configurer comme l'exigent certains autres fournisseurs — les liaisons ap-group, profil VAP et rrm-profile décrites ci-dessus en tiennent lieu.
La cohérence du mode de transfert sur chaque AP du domaine d'itinérance, si la passerelle par défaut réelle se trouve sur un seul appareil cohérent, si le rrm-profile est lié aux profils radio 2,4 GHz et 5 GHz, et si le SSID et le profil de sécurité sont configurés de façon identique sur chaque AP à portée.
Indiquez-nous votre disposition AC/AP et si la couche d'accès entre eux est routée, et nous vous aiderons à obtenir le bon mode de transfert et le bon déclencheur d'itinérance.