MikroTik Roaming: 802.11r/k/v, Band Steering e Sticky Client su RouterOS 7

Quando si installano più access point in casa, in ufficio o in una struttura più grande, la prima esigenza è quasi sempre la stessa: avere una sola rete Wi-Fi e potersi spostare da una zona all'altra senza dover cambiare SSID manualmente.

La configurazione di base è relativamente semplice. I problemi iniziano quando si vuole che il roaming funzioni bene anche nella pratica.

Un client può continuare a rimanere collegato a un access point lontano nonostante ne abbia uno molto più vicino. Un telefono può restare sul 5 GHz con -75 o -80 dBm pur avendo disponibile un 2,4 GHz decisamente migliore. Oppure può ricevere una richiesta di roaming dall'access point e semplicemente ignorarla.

In questa guida vediamo come abbiamo configurato una rete MikroTik con RouterOS 7 utilizzando 802.11r, 802.11k, 802.11v e le funzioni di steering del nuovo stack /interface wifi, e soprattutto come abbiamo affrontato alcuni problemi incontrati durante i test.

Per semplicità utilizzeremo due nodi: un router MikroTik hAP e un wAP ax collegato via Ethernet. La stessa impostazione è stata sperimentata anche su infrastrutture con oltre 30 nodi. Con due apparati è però molto più semplice capire cosa sta succedendo e riprodurre la configurazione.

Mesh o rete multi-AP?

Prima una precisazione.

Quella descritta in questa guida viene spesso chiamata genericamente "rete mesh", ma tecnicamente stiamo realizzando una rete Wi-Fi multi-AP con roaming assistito e backhaul Ethernet. Il collegamento tra gli access point avviene cioè via cavo, non attraverso una radio Wi-Fi dedicata al mesh backhaul.

Quando è possibile portare Ethernet agli access point, questa soluzione è generalmente preferibile: non si consuma capacità radio per trasportare il traffico tra i nodi e ogni AP dispone del collegamento cablato verso la LAN.

Dal punto di vista dell'utente, però, il risultato desiderato è quello tipicamente associato a una mesh: un unico SSID e la possibilità di spostarsi tra le varie celle Wi-Fi senza intervenire manualmente.

La topologia utilizzata

La configurazione di esempio è molto semplice:

Internet -> hAP -> Ethernet -> wAP ax

Entrambi gli apparati trasmettono:

• SSID: Yapsie
• Bande: 2,4 GHz + 5 GHz

Il router rimane responsabile di DHCP, routing, firewall e accesso a Internet. Il wAP lavora sostanzialmente come access point e bridge verso la LAN.

È importante evitare di creare accidentalmente una seconda rete sul wAP con un proprio DHCP o NAT: tutti i client devono appartenere alla stessa LAN indipendentemente dall'AP al quale sono associati (vedi anche i fondamenti del networking su IP e subnetting se questi concetti non sono familiari).

Non fidatevi di wifi1 e wifi2

Una delle prime cose che abbiamo verificato durante la configurazione è apparentemente banale, ma può creare parecchia confusione.

Su due MikroTik differenti wifi1 e wifi2 non necessariamente rappresentano la stessa banda. Nel nostro caso avevamo:

hAP:

• wifi1 = 5 GHz
• wifi2 = 2,4 GHz

wAP:

• wifi1 = 2,4 GHz
• wifi2 = 5 GHz

/interface wifi print

Quindi comandi copiati alla cieca da un apparato all'altro avrebbero modificato radio differenti. Prima di fare qualsiasi configurazione conviene verificare SSID, banda, frequenza e master interface.

Quando si lavora con più modelli MikroTik è molto meglio ragionare sulla radio effettiva che sul nome wifi1 o wifi2.

Un unico SSID

Per il roaming abbiamo creato un SSID comune, Yapsie, trasmesso sia a 2,4 sia a 5 GHz e da entrambi gli access point.

Durante i test abbiamo utilizzato interfacce virtuali, lasciando temporaneamente attive le reti precedenti. È una soluzione molto comoda quando si interviene su una rete già utilizzata: permette di sperimentare il nuovo roaming senza modificare immediatamente gli SSID in produzione.

Sul nostro hAP le virtual interface sono state create sulle rispettive master:

/interface wifi add master-interface=wifi2 name=yapsie-2g configuration.ssid="Yapsie" security=sec-home disabled=no
/interface wifi add master-interface=wifi1 name=yapsie-5g configuration.ssid="Yapsie" security=sec-home disabled=no

Sul wAP le master erano invertite:

/interface wifi add master-interface=wifi1 name=yapsie-2g configuration.ssid="Yapsie" security=sec-home disabled=no
/interface wifi add master-interface=wifi2 name=yapsie-5g configuration.ssid="Yapsie" security=sec-home disabled=no

Le interfacce devono naturalmente essere inserite nel bridge LAN. Nel nostro caso:

/interface bridge port add bridge=bridge-LAN interface=yapsie-2g
/interface bridge port add bridge=bridge-LAN interface=yapsie-5g

Il nome del bridge dipende dalla configurazione del singolo impianto.

Security identica

Perché il roaming funzioni correttamente, SSID e configurazione di sicurezza devono essere coerenti tra i diversi BSSID.

Nel nostro caso abbiamo utilizzato WPA2-PSK/WPA3-PSK.

Una cosa interessante ci è successa proprio durante questa fase: dopo alcune modifiche relative al Fast Transition, alcuni iPhone visualizzavano "password errata" o "impossibile connettersi alla rete", nonostante la password fosse corretta.

Riscrivere la passphrase e riapplicare il security profile ha riallineato la configurazione e i dispositivi hanno ricominciato ad autenticarsi normalmente. È quindi importante non dare automaticamente la colpa al client quando, dopo una modifica a FT o alla security, compare improvvisamente un errore di password.

802.11r: Fast Transition

802.11r riduce il tempo necessario per autenticarsi quando un dispositivo passa da un BSSID all'altro della stessa rete.

Sul nuovo stack WiFi di RouterOS abbiamo abilitato Fast Transition:

security.ft=yes
security.ft-over-ds=yes

La configurazione va mantenuta coerente sugli AP che partecipano alla stessa rete.

802.11r non decide però quando effettuare il roaming. Serve soprattutto a rendere più veloce la transizione una volta che il client ha deciso di spostarsi. Questa distinzione è importante.

802.11k, 802.11v e steering

RouterOS permette di utilizzare RRM e WNM per assistere i client nella scelta degli access point.

Abbiamo creato un profilo di steering:

/interface wifi steering add name=steer-yapsie rrm=yes wnm=yes transition-threshold=-67 transition-threshold-time=3s transition-request-period=5s transition-request-count=unlimited

e lo abbiamo associato alle interfacce Yapsie.

Nota tecnica: -67 dBm è il valore che abbiamo usato in questa installazione, non una soglia raccomandata da MikroTik in modo universale. Va scelta osservando la rete reale in cui si opera.

Quando il segnale di un client rimane sotto -67 dBm per almeno tre secondi, RouterOS lo considera un candidato alla transizione e può inviargli periodicamente BSS Transition Management Request 802.11v.

Il client viene quindi informato dell'esistenza di alternative migliori. Ma c'è un dettaglio fondamentale: non è l'access point a decidere il roaming. È il client.

Una BSS Transition Request è un suggerimento. Il dispositivo può accettarlo oppure ignorarlo. Ed è qui che abbiamo incontrato il problema più interessante.

Lo sticky client sul 5 GHz

Durante le prove abbiamo preso un iPhone e ci siamo spostati progressivamente lontano dall'access point.

Dalla registration table potevamo seguire in tempo reale BSSID, banda e RSSI:

/interface wifi registration-table print

Il telefono è arrivato a circa -75/-77 dBm sul 5 GHz. Nella stessa posizione era disponibile il 2,4 GHz dello stesso SSID con un segnale sensibilmente migliore.

Ci aspettavamo quindi un passaggio abbastanza rapido al 2,4 GHz. Non è avvenuto. L'iPhone continuava a rimanere sul 5 GHz.

Il comportamento del roaming non dipende esclusivamente dall'RSSI: il client considera anche tecnologia Wi-Fi, banda e caratteristiche dei candidati. Il risultato pratico è che un dispositivo può rimanere attaccato al 5 GHz molto più a lungo di quanto ci aspetteremmo osservando solamente i dBm.

Il primo tentativo: forzare la transizione

RouterOS mette a disposizione transition-time. Abbiamo quindi provato:

transition-time=20s

L'idea sembrava corretta: se il client rimane troppo a lungo sotto la soglia, dopo 20 secondi viene deautenticato.

Ha funzionato tecnicamente, ma non ha risolto il problema.

Ogni 20 secondi l'iPhone veniva disconnesso. Subito dopo cercava nuovamente Yapsie. E si collegava di nuovo al 5 GHz.

Quindi avevamo trasformato uno sticky client in uno sticky client che si disconnetteva ogni 20 secondi. Non esattamente un miglioramento.

Abbiamo riportato:

transition-time=unlimited

In questo modo RouterOS continua a suggerire la transizione senza imporre periodicamente una deautenticazione.

La soluzione: impedire un 5 GHz troppo debole

A quel punto abbiamo cambiato approccio.

Invece di cercare di convincere l'iPhone a lasciare il 5 GHz, abbiamo stabilito una soglia sotto la quale quel particolare BSSID 5 GHz non deve più essere considerato utilizzabile.

RouterOS permette di farlo attraverso /interface wifi access-list.

Abbiamo utilizzato due regole sulla sola interfaccia yapsie-5g:

/interface wifi access-list add interface=yapsie-5g signal-range=-73..0 allow-signal-out-of-range=5s action=accept comment="Yapsie 5G good signal"
/interface wifi access-list add interface=yapsie-5g signal-range=-120..-74 action=reject comment="Yapsie reject weak 5G"

La prima regola accetta il client quando il segnale è compreso tra -73 e 0 dBm. allow-signal-out-of-range=5s evita di reagire a una brevissima oscillazione del segnale.

La seconda regola rifiuta invece l'associazione sul 5 GHz quando il segnale è pari o inferiore a -74 dBm.

È importante avere entrambe le regole. Durante le prove avevamo inizialmente inserito soltanto signal-range=-73..0 con action=accept. Il telefono continuava comunque a comparire a -75/-76 dBm.

Il motivo è che una regola accept definisce cosa fare quando il client corrisponde alla regola. Non costituisce da sola un divieto generale per tutto ciò che si trova fuori dal range.

Aggiungendo esplicitamente il reject per -120..-74 il comportamento è cambiato immediatamente.

Il test

Abbiamo inizialmente applicato il reject esclusivamente al MAC dell'iPhone per evitare di modificare il comportamento degli altri dispositivi durante la prova.

Il contatore della regola ha cominciato immediatamente a salire:

match-count=8

Era la conferma che il telefono continuava a tentare di associarsi al 5 GHz debole e che RouterOS lo stava effettivamente rifiutando.

Pochi secondi dopo la registration table mostrava Yapsie su 2ghz-ax a circa -65 dBm. Il telefono era finalmente passato dal 5 GHz intorno a -75/-77 dBm al 2,4 GHz intorno a -65 dBm.

A quel punto abbiamo fatto il test opposto. Ci siamo avvicinati nuovamente all'access point. Senza alcuna ulteriore forzatura l'iPhone ha abbandonato il 2,4 GHz e si è collegato nuovamente al 5 GHz, questa volta a circa -55 dBm.

Era esattamente il comportamento che cercavamo: quando il 5 GHz è buono, lasciamo al client la naturale preferenza per quella banda; quando diventa troppo debole, evitiamo che il dispositivo continui ostinatamente a utilizzarlo.

La soglia -73/-74 dBm non è universale

Non bisogna prendere -73 e -74 dBm come numeri magici.

Sono valori che hanno funzionato bene nella nostra installazione e che utilizziamo qui per mostrare il metodo. In un'altra rete la soglia corretta potrebbe essere -70, -75 o -78 dBm. Dipende dalla densità degli access point, dalla loro potenza, dalla disposizione degli ambienti, dalle interferenze, dai dispositivi utilizzati e dalla qualità effettiva della connessione.

Una soglia troppo alta provoca roaming eccessivo. Una troppo bassa permette ai client di trascinarsi connessioni ormai inutilmente degradate.

Per questo conviene prima osservare la rete e poi scegliere la soglia.

Soft steering e hard limit

Alla fine abbiamo lasciato due meccanismi distinti.

Il primo è lo steering:

transition-threshold=-67
transition-threshold-time=3s
transition-request-period=5s
transition-request-count=unlimited
transition-time=unlimited

Quando il segnale peggiora, RouterOS comincia a suggerire al dispositivo che esistono candidati migliori. È il comportamento "soft".

Il secondo livello è la access-list sul 5 GHz:

-73..0      -> accept
-120..-74   -> reject

È il limite oltre il quale non vogliamo che un dispositivo continui a utilizzare quella cella 5 GHz.

Il primo cerca quindi di ottenere un roaming naturale. Il secondo interviene quando il client non collabora.

Diagnostica: guardare cosa sta facendo realmente il client

Una delle cose più utili durante la configurazione è stata smettere di giudicare il roaming guardando semplicemente l'icona Wi-Fi del telefono.

RouterOS permette di vedere cosa sta succedendo realmente. Il comando fondamentale è:

/interface wifi registration-table print
/interface wifi registration-table print where mac-address=XX:XX:XX:XX:XX:XX
/interface wifi access-list print detail
/interface wifi steering print detail
/interface wifi monitor wifi1 once
/interface wifi monitor wifi2 once

La registration table mostra interfaccia, SSID, MAC address, uptime, attività, RSSI, autenticazione e banda. Il campo match-count delle access-list è particolarmente utile per capire se una regola viene realmente intercettata. Il monitor delle radio permette invece di verificare frequenza, stato, peer e potenza TX effettivamente utilizzata.

DFS: perché il 5 GHz può sparire

Durante la configurazione abbiamo incontrato anche il messaggio "DFS channel availability check (1 min)".

Non è un errore. Su alcuni canali 5 GHz soggetti a DFS l'access point deve effettuare il Channel Availability Check prima di iniziare a trasmettere. Durante quel periodo la radio può risultare temporaneamente non disponibile.

Cambiare configurazione, canale o riavviare l'interfaccia può quindi comportare un'attesa prima che il 5 GHz torni operativo. È bene saperlo, perché altrimenti si rischia di interpretare il normale CAC come un problema della configurazione appena effettuata.

Potenza di trasmissione

Un altro errore frequente è cercare di risolvere qualsiasi problema di copertura aumentando semplicemente la potenza.

RouterOS applica i limiti previsti dal regulatory domain configurato. Nel nostro caso configuration.country=Italy.

Aumentare la potenza dell'AP non è comunque sempre una soluzione al roaming. Un access point troppo "forte" può addirittura aumentare il problema degli sticky client: il dispositivo continua a sentire l'AP lontano e ritarda il passaggio alla cella successiva.

In una rete multi-AP è spesso più importante progettare correttamente sovrapposizione delle celle, canali e soglie di roaming che cercare la massima potenza possibile. Anche la scelta del router di partenza incide su questo: se stai ancora valutando l'hardware, la nostra guida alla scelta del router Wi-Fi copre gli standard e i parametri principali da considerare.

Canali radio

Con più access point bisogna anche evitare di trasformare tutti i nodi in trasmettitori sullo stesso canale.

Sul 2,4 GHz, dove lo spettro disponibile è limitato, la pianificazione è particolarmente importante. Sul 5 GHz abbiamo più possibilità, ma entrano in gioco anche DFS e larghezze di canale maggiori.

In una rete con molti nodi la scelta dei canali diventa parte integrante della progettazione radio. Lo stesso SSID non significa che tutti gli AP debbano necessariamente trasmettere sullo stesso canale. Anzi, normalmente è preferibile il contrario.

Da due a oltre 30 nodi

La configurazione descritta utilizza due access point perché permette di capire chiaramente il meccanismo.

Con molti nodi il principio non cambia: stesso SSID, stessa politica di sicurezza, stessa LAN, 802.11r/k/v coerentemente configurati, canali pianificati, celle radio correttamente sovrapposte, steering e controllo dei client con RSSI insufficiente.

Quello che cambia è la necessità di centralizzare e standardizzare la configurazione. Su installazioni più grandi entrano quindi in gioco CAPsMAN, provisioning, profili comuni e una vera pianificazione RF.

Le soglie devono inoltre essere valutate con maggiore attenzione. Una casa con due AP e una struttura con trenta AP sono problemi radio molto diversi, anche se utilizzano gli stessi protocolli di roaming.

Cosa abbiamo imparato

La parte più importante dell'esperienza non è stata abilitare 802.11r, k o v. È stato verificare che cosa facevano realmente i client.

802.11k aiuta un dispositivo a conoscere più rapidamente i candidati disponibili. 802.11r rende più rapida l'autenticazione durante la transizione. 802.11v permette alla rete di suggerire un BSSID migliore.

Ma la decisione di roaming rimane in larga parte al client. Ed è proprio qui che nascono molti dei problemi che vengono genericamente descritti come "il mesh non funziona".

Nel nostro caso la rete suggeriva correttamente il roaming, ma l'iPhone continuava a preferire un 5 GHz ormai arrivato a circa -76 dBm. Forzare una disconnessione ogni 20 secondi non è servito: il telefono tornava semplicemente sullo stesso 5 GHz.

La soluzione è stata più semplice: lasciare al dispositivo libertà di scelta finché la connessione è ragionevole, ma impedire l'associazione a una cella 5 GHz quando il segnale diventa oggettivamente troppo debole.

Il risultato finale è stato quello che volevamo fin dall'inizio: 5 GHz quando il segnale è buono, 2,4 GHz quando offre una copertura migliore e passaggio tra gli access point senza dover cambiare rete manualmente.

Prima di chiudere: backup

Quando la configurazione funziona, fate un backup prima di continuare a sperimentare.

Noi abbiamo conservato sia il backup binario sia l'export testuale:

/system backup save name=wifi-working
/export show-sensitive file=wifi-working

Il primo permette di ripristinare rapidamente l'apparato. Il secondo è estremamente utile per leggere la configurazione, confrontarla e recuperare singole sezioni senza dover necessariamente ripristinare tutto.

Attenzione: show-sensitive inserisce nell'export anche informazioni sensibili. Il file va quindi conservato con la stessa attenzione riservata alle password della rete.

In una configurazione Wi-Fi che finalmente funziona come deve, avere entrambi i backup costa pochi secondi e può farne risparmiare parecchi dopo.

---

Nota editoriale: l'esempio in questa guida usa due nodi per chiarezza, mentre la metodologia descritta è stata sperimentata anche su infrastrutture con oltre 30 nodi. Le soglie RSSI riportate (-67 dBm per lo steering, -73/-74 dBm per l'access-list) sono valori verificati in questa specifica installazione, non soglie raccomandate universalmente da MikroTik. La configurazione è stata realizzata sul nuovo stack /interface wifi di RouterOS 7.