Eventi radar DFS su Cisco Meraki, HPE Aruba e Ruckus: una checklist diagnostica per i cambi di canale

Per diagnosticare e risolvere gli eventi radar DFS su reti WiFi Cisco Meraki, HPE Aruba o Ruckus che operano secondo lo standard IEEE 802.11h, analizza i log del controller alla ricerca di rilevamenti radar. Una volta rilevato, l'access point deve liberare il canale a 5GHz entro 10 secondi e rimanerne fuori per 30 minuti.

Come si presenta un evento radar DFS sulla tua rete a 5GHz?

La Dynamic Frequency Selection (DFS) consente al WiFi di condividere parti della banda a 5GHz con i radar. Lo standard IEEE 802.11h definisce questo meccanismo. Gli enti regolatori stabiliscono le tempistiche: la FCC ai sensi del 47 CFR Parte 15.407 negli Stati Uniti, e l'ETSI EN 301 893 in tutta Europa. Nelle regioni ETSI, i canali da 52 a 64 e da 100 a 140 sono canali DFS. Le regole FCC aggiungono il canale 144.

Quando un access point (AP) rileva un radar, la sequenza è prestabilita:

1. Rilevamento. La radio confronta un pattern di impulsi sul suo canale operativo con una firma radar.
2. Channel switch announcement (CSA). L'AP aggiunge un elemento CSA ai suoi beacon, comunicando ai client il nuovo canale e il conto alla rovescia per lo spostamento.
3. Spostamento di canale. La radio deve interrompere la trasmissione su quel canale entro 10 secondi.
4. Periodo di non occupazione. Il canale è vietato per almeno 30 minuti.
5. Channel availability check (CAC). Prima che un canale DFS entri in servizio, la radio rimane in ascolto per almeno 60 secondi. Nelle regioni ETSI, i canali 120, 124 e 128 (5600 - 5650 MHz) sono condivisi con i radar meteorologici e il controllo in questo caso dura 10 minuti.

L'esperienza degli utenti ospiti dipende dai loro dispositivi. I client che rispettano il CSA seguono l'AP con una breve pausa. I client che lo ignorano perdono la connessione, eseguono una nuova scansione e si riassociano, spesso sulla banda a 2.4GHz o su un AP vicino. Se l'AP si sposta su un canale DFS che non ha superato il controllo, la radio a 5GHz può rimanere silenziosa per un minuto o più.

Il pattern da cercare è il seguente:

• Ogni client su un AP, o su un gruppo di AP vicini, si disconnette nello stesso momento.
• L'AP si riattiva su un canale diverso, spesso un canale non DFS compreso tra 36 e 48.
• Il cambiamento avviene al di fuori della finestra di ottimizzazione dei canali programmata.
• Gli stessi AP ripetono il pattern, a volte in orari simili della giornata.
• Il carico sulla banda a 2.4GHz aumenta improvvisamente mentre i client a 5GHz scompaiono.

Cosa causa solitamente i cambi di canale DFS?

Radar reali

I radar meteorologici nella gamma 5600 - 5650 MHz sono una fonte reale comune in Europa. Negli Stati Uniti, il Terminal Doppler Weather Radar (TDWR) dei principali aeroporti utilizza la stessa gamma. La linea visiva conta più della distanza. Gli AP esterni, i piani superiori e le facciate vetrate rilevano radar che gli AP al piano terra non vedranno mai.

La sola vicinanza non è un fattore predittivo affidabile. Molti radar di sorveglianza aeroportuale e di navigazione marittima operano in altre bande, ben al di fuori dei 5GHz. Una struttura situata accanto a un porto potrebbe non registrare mai un singolo evento radar. Il registro degli eventi è la tua prova, non la mappa.

Falsi positivi

Un falso positivo DFS è un rilevamento radar in assenza di un radar reale. La radio interpreta un picco di energia come un pattern di impulsi radar. I fattori scatenanti tipici includono:

• interferenze non-WiFi a impulsi provenienti da collegamenti video wireless o apparecchiature difettose;
• trasmissioni forti da un AP vicino o da un collegamento point-to-point su un canale adiacente;
• difetti radio o firmware, che i fornitori correggono nelle versioni del software.

L'indizio chiave è l'isolamento. Un AP registra eventi ripetuti su vari canali mentre i vicini con la stessa visuale del cielo non ne registrano alcuno.

I canali ampi aumentano l'esposizione a rilevamenti sia reali che falsi. Un canale a 80 MHz copre quattro sottocanali a 20 MHz e un rilevamento su uno qualsiasi di essi sposta l'intero canale.

Cambiamenti non dovuti al radar che sembrano identici

I pianificatori di canali spostano le radio per interferenze e carico. Meraki Auto RF, Aruba ARM e AirMatch, e Ruckus ChannelFly e BackgroundScanning cambiano tutti i canali senza radar. Anche i riavvii degli AP e i cambi di alimentazione disconnettono i client. Questi guasti richiedono soluzioni diverse, quindi conferma il motivo prima di escludere qualsiasi cosa.

Come si stabilisce se l'interruzione è stata causata dal radar?

Segui questa lista di controllo in ordine:

1. Individua il reclamo. Ottieni l'orario al minuto e la stanza, il piano o la zona.
2. Estrai gli eventi di cambio canale per gli AP che servono quell'area, un'ora prima e un'ora dopo.
3. Leggi il motivo registrato. Un motivo radar o DFS conferma la causa. Un motivo di interferenza, rumore o ottimizzazione lo esclude.
4. Nota il canale. Gli eventi raggruppati su 120, 124 e 128 indicano radar meteorologici.
5. Conta gli AP interessati. Diversi vicini insieme suggeriscono un radar reale. Un solo AP suggerisce un falso positivo.
6. Cerca un pattern settimanale. Ripetizioni regolari suggeriscono un radar con una pianificazione o scansione fissa.
7. Controlla l'ampiezza del canale. Gli eventi che appaiono solo su canali a 80 o 160 MHz rendono l'ampiezza parte del problema.
8. Leggi le note di rilascio del firmware per le correzioni di rilevamento DFS sul tuo modello di AP.

Se utilizzi Purple Guest WiFi, i volumi di accesso per sede ti offrono una verifica incrociata. Un calo improvviso in un sito che coincide con un evento radar conferma l'impatto sugli ospiti.

Come si risolvono gli eventi DFS su Meraki, Aruba e Ruckus?

Fornitore	Dove appaiono gli eventi radar	Pianificatore di canali	Dove si limitano i canali
Cisco Meraki	Registro eventi wireless filtrato per eventi DFS; pagina dello spettro RF per AP	Auto RF	Elenco dei canali del profilo RF, applicato agli AP interessati
HPE Aruba	Cronologia ARM sul controller o cluster Instant; eventi AirMatch in AOS 8 e Aruba Central	ARM (AOS 6, Instant), AirMatch (AOS 8, AOS 10)	Elenco dei canali consentiti nel profilo radio per un gruppo di AP
Ruckus	Eventi e allarmi SmartZone per il rilevamento radar	ChannelFly o BackgroundScanning	Impostazioni radio per una zona dedicata o un gruppo di AP

Cisco Meraki

Meraki registra il rilevamento radar nel registro eventi come eventi DFS, indicando l'AP e il canale. Filtra per tipo di evento e per la finestra temporale della segnalazione. La pagina dello spettro RF per ciascun AP mostra l'utilizzo e l'interferenza, separando il radar dalla congestione. Per evitare che il problema si ripeta, rimuovi i canali problematici da Auto RF in un profilo RF. Applica quel profilo solo agli AP interessati. La documentazione DFS di Meraki copre i passaggi esatti.

HPE Aruba

La cronologia ARM elenca ogni cambio di canale con il relativo motivo, e il rilevamento radar appare come una causale distinta. AirMatch definisce il piano dei canali a livello centrale, ma un rilevamento radar costringe l'AP a spostarsi immediatamente. Un cambio non pianificato nel bel mezzo del pomeriggio su un canale DFS è quindi un forte indizio. Limita i canali nel profilo radio per un gruppo di AP contenente solo gli AP interessati. Se gli ospiti vengono reindirizzati a una pagina di login dopo essersi riconnessi, si tratta di un errore diverso: consulta la guida HPE Aruba captive portal troubleshooting: redirect, certificate and walled garden checklist.

Ruckus

SmartZone genera un evento quando un AP rileva un radar, indicando l'AP e il canale. Controlla gli eventi e gli allarmi per la finestra temporale interessata, quindi confrontali con l'attività di ChannelFly o BackgroundScanning. Un cambio di canale DFS Ruckus senza un evento radar associato è una decisione di pianificazione del sistema, non una conseguenza del DFS. Rimuovi i canali problematici nelle impostazioni radio per una zona dedicata o un gruppo di AP.

Su tutte e tre le piattaforme, modifica solo gli AP interessati. Un'esclusione a livello di intero sito riduce la capacità su AP che non hanno mai rilevato segnali radar.

È consigliabile disattivare i canali DFS vicino a un aeroporto, porto o radar meteorologico?

Non per impostazione predefinita. Escludere ogni canale DFS in una regione ETSI lascia solo quattro canali a 20 MHz: 36, 40, 44 e 48. Le regole FCC ne lasciano nove, aggiungendo quelli dal 149 al 165. In una struttura ad alta densità, quattro canali costringono gli AP a condividere il tempo di trasmissione radio, rallentando ogni client. Lascia che siano i log a decidere.

Cosa mostrano i tuoi log	Causa probabile	Raccomandazione	Canali a 20 MHz rimasti (ETSI / FCC)
Eventi su diversi AP vicini, raggruppati sui canali 120 - 128	Radar meteorologico	Escludi i canali 120, 124 e 128 sugli AP interessati	16 / 22
Eventi sulla maggior parte dei canali DFS su molti AP, ogni giorno	Forte radar nelle vicinanze	Escludi il DFS solo sugli AP interessati; mantienilo attivo altrove	4 / 9 sugli AP interessati
Eventi ripetuti su un singolo AP, su canali diversi	Falso positivo	Aggiorna il firmware, testa o sostituisci la radio, mantieni il DFS	19 / 25
Eventi solo su canali a 80 o 160 MHz	Esposizione dovuta alla larghezza di banda	Passa a 40 o 20 MHz, mantieni il DFS	19 / 25
Cambiamenti di canale ma nessuna voce relativa al radar	Pianificatore o interferenza	Risolvi i problemi di interferenza e alimentazione, mantieni il DFS	19 / 25

Scenario pratico: un hotel vicino a un aeroporto regionale

Un hotel da 180 camere in una regione ETSI situato a 3 km da un aeroporto con un radar meteorologico. Gli ospiti dei piani superiori rivolti a ovest segnalavano disconnessioni la maggior parte dei pomeriggi. Il registro degli eventi ha mostrato 63 eventi radar in una settimana su 11 dei 46 AP, tutti sui canali da 120 a 128. Il team ha spostato questi 11 AP su un profilo che escludeva i canali meteo e ha impostato una larghezza di 40 MHz. Nelle quattro settimane successive l'hotel ha registrato zero eventi radar. I reclami per il WiFi alla reception sono scesi da 14 a due a settimana. Gli altri 35 AP hanno mantenuto tutti i canali DFS. Per saperne di più sulle installazioni alberghiere, consulta Hotels.

Scenario reale: una catena di negozi con un AP rumoroso

Una catena di negozi con 120 punti vendita ha registrato in un negozio 30 eventi radar in due settimane sui canali 52, 100 e 116. Gli AP vicini nello stesso negozio non ne hanno registrato alcuno, il che indicava un falso positivo. Le note di rilascio per quel modello di AP riportavano una correzione per il rilevamento DFS, quindi il team ha aggiornato il firmware. Gli eventi sono continuati e l'AP è stato sostituito in garanzia. Gli eventi radar nel negozio sono scesi a zero e i clienti hanno smesso di perdere la connessione nella zona delle casse. L'intera rete ha mantenuto tutti i 19 canali. Consulta Retail per l'accesso ospiti multi-sito.

Scenario reale: uffici comunali accanto a un porto

Il team IT di un comune aveva pianificato di disattivare il DFS negli uffici adiacenti a un porto commerciale. Trenta giorni di log non hanno mostrato alcun evento radar. I cambi di canale derivavano dal fatto che il pianificatore reagiva alla rete di un inquilino vicino. Il team ha mantenuto il DFS, ha abbassato la potenza di trasmissione e ha corretto la pianificazione dei canali. Le segnalazioni settimanali di disconnessione sono scese da nove a una.

Come evitare che gli eventi DFS disturbino nuovamente gli ospiti?

• Usa canali a 20 o 40 MHz in ambienti ad alta densità. Canali più stretti riducono l'esposizione e aumentano il riutilizzo.
• Escludi i canali meteo in modo mirato dove gli eventi si concentrano tra 120 e 128, solo sugli AP interessati.
• Mantieni il firmware aggiornato e leggi le correzioni DFS in ogni nota di rilascio.
• Esamina gli eventi DFS mensilmente e attiva avvisi per qualsiasi AP che ne registri più di una manciata a settimana.
• Pianifica per i 6GHz. La banda a 6GHz non richiede il DFS, quindi i client WiFi 6E e WiFi 7 evitano del tutto i cambi di canale dovuti ai radar.
• Separa la radiofrequenza dall'accesso ospiti. Purple funziona come un overlay cloud indipendente dall'hardware su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Il tuo controller gestisce la pianificazione dei canali e Purple gestisce il login degli ospiti. Purple ha gestito 440 milioni di accessi in oltre 80.000 sedi attive nel 2024 (dati Purple).

Domande frequenti

Il Guest WiFi di Purple funziona sui nostri access point esistenti Meraki, Aruba o Ruckus?

Sì. Il Guest WiFi di Purple è un overlay cloud indipendente dall'hardware che funziona su Cisco Meraki, HPE Aruba e Ruckus, oltre a Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Mantieni i tuoi access point, controller e configurazione RF. Purple aggiunge il login degli ospiti, il consenso esplicito e i dati di prima parte. Non è necessaria alcuna sostituzione hardware e le impostazioni DFS rimangono sotto il tuo controllo.

Purple modificherà le nostre impostazioni DFS o dei canali?

No. Purple non imposta i canali radio, l'ampiezza del canale o la potenza di trasmissione. Questi parametri rimangono gestiti da Meraki Auto RF, Aruba ARM o AirMatch e Ruckus ChannelFly o BackgroundScanning. Purple gestisce l'autenticazione degli ospiti e l'acquisizione dei dati al di sopra del livello radio. Questa separazione consente di risolvere un problema DFS nella dashboard del fornitore senza toccare l'esperienza di login degli ospiti, e di modificare le impostazioni di login senza toccare le radiofrequenze.

È conforme alle normative disabilitare i canali DFS?

Sì. Le norme ETSI EN 301 893 e FCC Part 15.407 richiedono il rilevamento radar su qualsiasi canale DFS utilizzato. Nessuna delle due richiede l'uso obbligatorio dei canali DFS. Escluderli è sempre conforme. Ciò che non si deve mai fare è operare su un canale DFS con il rilevamento disabilitato. Il costo reale dell'esclusione è la capacità: nelle regioni ETSI, la rimozione di tutti i canali DFS lascia solo quattro canali a 20 MHz anziché 19.

Abbiamo bisogno di nuovi access point per evitare problemi di DFS?

Di solito no. La maggior parte dei problemi DFS si risolve con la configurazione: escludendo i canali meteo sugli AP interessati, restringendo l'ampiezza del canale o aggiornando il firmware. La sostituzione ha senso quando una radio continua a produrre falsi positivi dopo un aggiornamento del firmware, o quando si aggiunge capacità a 6GHz. La banda a 6GHz non ha requisiti DFS, quindi gli access point WiFi 6E e WiFi 7 eliminano i cambi di canale dovuti ai radar per i client che li supportano.

L'esclusione dei canali DFS danneggia il WiFi per gli ospiti in una sede affollata?

Sì, se vengono esclusi a livello di intero sito. In una regione ETSI, quattro canali a 20 MHz non possono separare decine di AP in uno stadio, in un centro congressi o in un grande hotel. Gli AP finiscono per condividere il tempo di trasmissione e la velocità di trasmissione diminuisce per ogni ospite. Escludi i canali solo sugli AP che registrano radar e mantieni il DFS ovunque. Questo approccio circoscrive il problema senza rinunciare alla capacità.

Le regole DFS variano tra Regno Unito, Europa e Stati Uniti?

Sì. Il Regno Unito e l'UE seguono la norma ETSI EN 301 893, che applica il DFS ai canali dal 52 al 64 e dal 100 al 140. Richiede inoltre un controllo di disponibilità di 10 minuti sui canali meteo 120, 124 e 128. Gli Stati Uniti seguono la norma FCC Part 15.407, che aggiunge il canale 144 e lascia nove canali non DFS. Entrambe le normative richiedono almeno 30 minuti di non occupazione dopo un rilevamento.

Può un MSP diagnosticare gli eventi DFS su un parco macchine multimarca?

Sì, ma gli eventi radar risiedono negli strumenti specifici di ciascun fornitore: il registro degli eventi Meraki, la cronologia Aruba ARM o gli eventi AirMatch, e gli eventi e allarmi SmartZone. Un MSP dovrebbe standardizzare la checklist anziché lo strumento, registrando ora, canale, conteggio degli AP e motivo di ogni incidente. Purple offre un'unica piattaforma per l'accesso degli ospiti tra tutti questi fornitori, mentre la diagnosi delle radiofrequenze rimane all'interno di ciascun controller.