Convalida throughput Wi-Fi : Guida al test e al monitoraggio

Introduzione

Questo documento descrive come monitorare e risolvere i problemi di throughput nelle grandi reti Wi-Fi.

Contesto

Nelle reti Wi-Fi, non sono molti i tipi di utenti finali che hanno percepito i problemi.

I problemi segnalati possono variare tra:

• i client non sono in grado di connettersi;
• i client si disconnettono improvvisamente o;
• la velocità percepita dell'applicazione sul dispositivo utente non è soddisfacente.

Dietro a questi semplici sintomi possono nascondersi centinaia di tipi di problemi, la maggior parte dei quali non coinvolge le reti Wi-Fi come i problemi DNS, i problemi di connessione a Internet e così via.

I server di gestione come Cisco Catalyst Center aiutano l'amministratore a risolvere problemi specifici e questo articolo non esamina in dettaglio i numerosi tipi di problemi quotidiani che possono essere facilmente rilevati e risolti tramite Catalyst Center. Questo documento si concentra invece sul feedback più vago da parte degli utenti finali che la rete è lenta.

Come testarlo? Come convalidare il throughput effettivo in tutta la rete? Come valutare i problemi relativi alla velocità in elementi utilizzabili per migliorare l'esperienza complessiva dell'utente finale?

Queste sono tutte domande a cui questo documento cerca di rispondere.

Definizione del throughput massimo previsto

La prima domanda in ogni rete è: qual è la velocità massima che potrebbe essere raggiunta potenzialmente e realisticamente?

Poiché Wi-Fi è un mezzo condiviso, la velocità dipende direttamente dal numero di client e dispositivi che utilizzano il Wi-Fi nello stesso momento sullo stesso canale. Pertanto, la questione della velocità massima effettiva che può essere raggiunta direttamente implica la presenza di un singolo dispositivo client e di un singolo punto di accesso in un luogo silenzioso e isolato in cui nessuno utilizzi lo stesso canale Wi-Fi. In queste condizioni, i fattori per determinare la velocità massima si riducono a:

• Protocollo Wi-Fi utilizzato (Wi-Fi 5, Wi-Fi 6, ...)
• Le capacità hardware del client e del punto di accesso (numero di antenne, numero di flussi spaziali, connessione Ethernet del punto di accesso, ecc.)
• La configurazione (larghezza del canale, ...)

La conoscenza di questi fattori consente di stimare il throughput reale massimo che si potrebbe sperare di raggiungere in condizioni di laboratorio.

Per avere un'idea rapida, è necessario verificare a quale velocità dati il client segnala di essere connesso al punto di accesso. Questa velocità dati non è il throughput effettivo che è possibile dimostrare nei test. Ciò è dovuto al fatto che Wi-Fi è un mezzo half-duplex che ha un certo sovraccarico di gestione (occorre riconoscere i frame, trasmettere i beacon) e anche brevi silenzi tra i frame per una ricezione e decodifica migliori. Ciò significa che, quando si inviano i dati, questi vengono inviati alla velocità dei dati documentata, ma i dati non sempre vengono inviati. I frame di gestione e controllo vengono inviati a una velocità di trasferimento dati molto inferiore per garantire la ricezione. Una stima è che si può prendere in considerazione il raggiungimento del 65-70% della velocità dati utilizzata in un test di throughput effettivo. Ad esempio, se il client segnala che la connessione è in corso e l'invio dei dati è a 866 Mbps, i test effettivi devono indicare una velocità di trasferimento di circa 600 Mbps.

Se si conoscono i parametri di configurazione in uso e le funzionalità hardware dei dispositivi interessati, è inoltre possibile determinare quale velocità dati massima (e quindi velocità effettiva, utilizzando il calcolo della percentuale documentato in questa sezione) deve essere raggiungibile.

In caso di mancata corrispondenza tra la velocità dati riportata e quella che si desiderava ottenere, è possibile avviare il processo di risoluzione dei problemi tramite la configurazione e verificare i vari parametri per individuare la posizione del gap.

Ad esempio, se si dispone di un punto di accesso modello C9120 che trasmette a 20 Mhz di larghezza del canale nella banda da 5 Ghz e di un client Wi-Fi 6 tipico a 2 flussi spaziali, è possibile calcolare che, in un ambiente RF (Radiofrequenza) perfettamente pulito, con un singolo client si potrebbe sperare di raggiungere 160 a 200 Mbps in un singolo trasferimento di file.

Ulteriori informazioni sui test e la convalida del throughput sono documentate qui: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212892-802-11ac-wireless-throughput-testing-and.html.

Stabilire l'esperienza di base

È importante sapere cosa ci si può aspettare nella vostra sede in circostanze tipiche. Spesso un tecnico visita il sito vuoto prima dell'implementazione, esegue test di velocità e documenta i numeri previsti.

Poi entrano i dipendenti o i clienti, il sito diventa occupato, e l'esperienza reale è molto diversa.

Una volta avviata l'installazione, è consigliabile inviare tecnici per misurare l'esperienza effettiva in ogni area e prendere nota dell'aspetto della rete in una giornata lavorativa media.

Sono inclusi il numero medio di client per radio quando la rete funziona a un livello soddisfacente, nonché il throughput medio ottenuto con un test di velocità.

Individuare eventuali deviazioni dall'esperienza

Durante il funzionamento della rete, il monitoraggio di allarmi o dispositivi di grandi dimensioni che improvvisamente si interrompono è semplice. Questo documento si concentra sulla parte difficile: come individuare una rete wireless che funziona ancora ma che offre un'esperienza utente insoddisfacente.

Individuazione delle prove di un problema (test passivi)

La rete è stata testata personalmente; si sa che funziona correttamente e si stanno monitorando i sistemi di gestione e i dashboard. Non c'è niente che sia inattivo: puoi fare un passo indietro e rilassarti. O puoi?

Se si attendono gli echi degli utenti finali che lamentano la scarsa esperienza, è probabile che si sia troppo in ritardo. Quando gli utenti finali si lamentano, il problema persiste da molto tempo e si sentono solo i pochi utenti che sono stati abbastanza espliciti da consentirne l'ascolto.

Molti utenti sono già stati frustrati, non hanno detto nulla a voi o al vostro helpdesk, ma hanno dato una cattiva reputazione alla vostra rete.

Quindi, la domanda è: come si possono individuare le occorrenze di esperienze negative non appena si verificano?

1. Dashboard di controllo client su Cisco Catalyst Center

Nel dashboard Cisco Catalyst Center assurance è disponibile un grafico complessivo dello stato dei client.

Ci sono sempre alcuni clienti che non sono in grado di connettersi perché qualcuno ha immesso la chiave sbagliata, o il dispositivo è seduto al margine della vostra copertura, quindi non sperare di raggiungere il 100% di clienti sani, ma essere familiare con ciò che è una buona percentuale di client sani per il vostro ambiente.

Essere nel range degli anni '90 è in genere una buona notizia.

Con un'occhiata molto veloce si può vedere cosa sta succedendo ai clienti che non sono sani:

• Sono lontani dall'access point?
• È un problema di autenticazione?

In questo grafico potete facilmente vedere il rapporto di ciascuna categoria.

Nella stessa gamma di idee, è possibile scorrere fino in fondo alla pagina e filtrare per visualizzare i dispositivi client segnalati come non integri. È quindi possibile provare a individuare se esiste uno schema:

• Potenzialmente sono tutti collegati su una banda a 2,4 GHz (che in molti casi è nota per offrire un'esperienza meno soddisfacente);
• sono potenzialmente tutti segnalati con una bassa potenza del segnale;
• Potenzialmente sono tutti nella stessa area fisicamente.

2. Il dashboard di controllo della rete e il dispositivo 360 su Cisco Catalyst Center

Per individuare un'area potenziale specifica di problemi, una metrica particolarmente efficace è la pagina Network Assurance di Cisco Catalyst Center. È disponibile un widget che mostra i primi access point in base al numero di client:

Se il punto di accesso principale della rete ha 40 client connessi, si sta bene. Ciò implica che tutti gli altri access point hanno un numero di client inferiore.

D'altra parte, se si riscontra che i principali access point hanno un numero insolitamente elevato di client, è possibile indovinare che l'esperienza client è particolarmente scarsa (a meno che la maggior parte dei client non sia attiva e non stia dormendo sulla rete).

È quindi possibile passare a un'indagine "per punto di accesso" in cui si esegue lo zoom avanti sugli specifici punti di accesso superiori riportati in questo widget per comprenderne lo stato attuale.

Un altro metodo per esaminare il numero di client consiste nell'andare alle mappe nella pagina Gerarchia di rete del centro Catalyst. Nella pagina di visualizzazione a pavimento, fare clic su "Opzioni di visualizzazione" e nella sezione Access Point modificare la visualizzazione in "Assoc. Client" per visualizzare il numero di client per access point:

Il vantaggio della tecnica della mappa è che è possibile individuare dove si trova l'access point con un numero elevato di clienti e valutare se il numero elevato potrebbe essere giustificato (ci può essere una buona ragione per una folla di riunirsi in quel punto in quel determinato momento).

È anche possibile osservare i punti di accesso adiacenti: se condividono parte del carico, le cose vanno bene. Se un access point ha un numero di client eccessivamente elevato mentre i server di accesso adiacenti non hanno client, la situazione diventa più sospetta.

È possibile che si sia verificato un problema con i punti di accesso adiacenti (se il numero di client è zero) oppure che la progettazione della radiofrequenza causi che il punto di accesso in questione attragga tutti i client rispetto a quelli adiacenti (ad esempio a causa di una maggiore potenza TX e/o di antenne diverse).

La mappa fornisce una buona panoramica dei client associati su ciascun access point

Dopo aver identificato i punti di accesso potenzialmente problematici con un numero di client estremamente elevato, è possibile cercare il nome di quel punto di accesso e aprire la pagina del dispositivo 360.

Il grafico dello stato di salute fornisce una panoramica se lo stato di salute di quel punto di accesso è cattivo proprio ora o se è stato costantemente cattivo nell'ultimo giorno o più.

Nella stessa pagina è disponibile un elenco di problemi correlati a tale punto di accesso. In questo caso, è chiaro che entrambe le radio stanno registrando un elevato utilizzo.

Il visualizzatore eventi può fornire un'idea se sono stati generati eventi specifici correlati a tale punto di accesso.

Un esempio potrebbe essere rappresentato da un algoritmo RRM impostato per essere eseguito troppo frequentemente e che causa frequenti modifiche dei canali che influiscono sui client connessi, oppure da una radio che si reimposta costantemente a causa di vari problemi o interferenze.

Alla fine della pagina del dispositivo 360, è possibile impostare la vista su "RF", selezionare la radio specifica e si dispone di informazioni interessanti che consentono di valutare la fonte del problema.

Avere molti client non è necessariamente un problema: tutto dipende da quanto sono attivi.

A volte, anche con pochi clienti, l'AP potrebbe avere le mani occupate e offrire un'esperienza scarsa. L'indicatore effettivo è l'utilizzo del canale.

Quando l'utilizzo dei canali si avvicina al 100% (anche a partire dal 70%), i client iniziano a contendersi pesantemente l'accesso medio, la latenza e le collisioni.

I grafici consentono di confrontare l'utilizzo totale del canale e la parte di responsabilità di questa contabilità.

Ad esempio, se l'utilizzo del canale è dell'80%, significa che l'80% delle volte in cui "qualcuno" trasmette tramite il canale. Se l'access point mostra un utilizzo Rx del 40% e un utilizzo Tx del 40%, solo questo access point è responsabile di tenere occupato il canale (ossia, non stanno trasmettendo altri access point) ed è ben bilanciato tra la ricezione e la trasmissione. Se l'utilizzo combinato di Rx e Tx dell'access point è lontano dall'utilizzo del canale, ciò implica che un altro access point (non autorizzato o gestito) sta utilizzando lo stesso canale e causando un'interferenza dello stesso canale.

In questa schermata viene mostrato un punto di accesso in cui il canale è estremamente occupato (91%):

Il grafico mostra che solo il 7% di questo utilizzo è dovuto ad altri punti di accesso e a fonti non WiFi e che l'access point è occupato a trasmettere per l'82% del tempo e a ricevere solo il 2%.

Il numero di client e il throughput totale indicano che uno o più client stanno probabilmente scaricando file di grandi dimensioni.

Il grafico delle interferenze consente di determinare se il canale è tenuto occupato da trasmissioni Wi-Fi o da interferenze effettive (non Wi-Fi):

In conclusione, e come regola pratica, è necessario considerare gli access point con il numero più elevato di client e il più alto utilizzo dei canali. È quindi necessario valutare se questo carico è giustificato o meno e se causa una scarsa esperienza per gli utenti finali in quell'area.

3. Analisi dell'IA

L'analisi AI offre un monitoraggio più intelligente. Il monitoraggio non si basa più su soglie fisse, ma si adatta all'utilizzo previsto.

La mappa termica della rete offre un'evoluzione del numero di client, per individuare gli access point con il numero di client più alto nella settimana. È anche possibile individuare facilmente i punti di accesso che non connettono costantemente i client: anche il problema opposto è un problema.

Se la radio è bloccata (e se il riavvio dell'access point la risolve), è possibile che si sia verificato un problema fisico con questi access point (problema di montaggio, problemi con le antenne e così via) o un problema software.

La pagina Tendenze e approfondimenti fornisce un elenco di punti di accesso che mostrano regolarmente un elevato utilizzo dei canali o un'attività intensiva dei client, in modo che sia possibile eseguire facilmente controlli incrociati per verificare se corrisponde alle aree di attività o se è presente qualcosa di anormale:

Test attivi dell'infrastruttura

Quando gli utenti segnalano una scarsa esperienza in un'area specifica, si desidera testarla attivamente per confermare il loro feedback. È importante comprendere che i test tipici sono molto diversi dal traffico reale dei client.

Gli utenti in genere tentano di utilizzare l'applicazione preferita e sono felici se funziona. Trasferiscono raramente file di grandi dimensioni. La loro applicazione preferita potrebbe avere comportamenti diversi:

• Video on demand: questa modalità può occupare una quantità qualsiasi di larghezza di banda (dipende, ad esempio, dal fatto che il video sia 720p o 4K).
  • È molto tollerante al tremolio in quanto memorizza alcuni secondi o minuti di video in anticipo. Il modello ha l'aspetto di un trasferimento di file di grandi dimensioni per un breve periodo di tempo e poi silenzioso durante la riproduzione del video dal buffer fino al successivo precaricamento.
• Chiamata vocale: questa operazione consuma una quantità trascurabile di larghezza di banda ma è estremamente sensibile alla latenza e all'instabilità.
  • Ciò può potenzialmente utilizzare il tagging QoS (Quality of Service) e pertanto affrontare un'esperienza diversa (con priorità) dal traffico più efficiente.
• Dati: un'applicazione di social media scarica i dati per burst.
  • La quantità varia in base al contenuto e alla velocità di scorrimento dell'utente.

Una tipica applicazione di test del throughput massimizza il protocollo per ottenere la massima velocità di trasferimento possibile: cerca di registrare il supporto e invia il maggior numero di frame di dati concatenati possibile. Ciò non rappresenta lo stesso tipo di utilizzo delle applicazioni reali (diverse dai trasferimenti di file) che sono per natura molto frammentate.

Il test delle applicazioni reali simula il comportamento dell'utente, ma rende impossibile il confronto tra le metriche e i numeri reali. Si ha una sensazione soggettiva solo se la rete è liscia o no.

Per il test del throughput, molti siti sono popolari e forniscono un'immagine decente dell'esperienza dell'utente finale mentre testano l'intera larghezza di banda tra il client e Internet. Tuttavia, se si desidera convalidare la rete wireless separatamente dai problemi di connessione a Internet e routing e firewall, si consiglia di utilizzare uno strumento dedicato per il test della velocità di trasmissione, ad esempio Iperf: https://community.cisco.com/t5/wireless-mobility-knowledge-base/iperf-test-for-measuring-the-throughput-speed-of-a-wlan-client/ta-p/3142047.

Questo strumento consente di eseguire test specifici tra un client e un server inserito nella rete. In questo modo è possibile spostare il server in punti specifici della rete e testare il throughput su sezioni di rete più lunghe e lunghe per convalidare ogni sezione. Iniziare posizionando il server Iperf sullo stesso switch del punto di accesso in cui si trova il client wireless in caso di switching locale o wireless abilitato per fabric oppure sullo stesso switch del controller WLC (Wireless LAN Controller) (e nella VLAN del client se possibile) in caso di switching centrale.

Se si utilizza un WLC di ancoraggio, è necessario posizionare il server Iperf sullo stesso switch del WLC di ancoraggio su cui è terminato il traffico. A volte può essere interessante creare una WLAN (Wireless LAN) non ancorata per verificare se i risultati del throughput potenzialmente deludenti sono causati dall'ancoraggio stesso rispetto a una WLAN non ancorata.

Non ha senso utilizzare più client contemporaneamente per eseguire il test del throughput. Durante il test del throughput, si prevede che questo singolo client utilizzi l'intero tempo di trasmissione del canale disponibile. Pertanto, se due client eseguono un test del throughput contemporaneamente, ogni client vedrà un risultato diviso almeno in metà. Se si utilizzano più client, le collisioni iniziano a verificarsi in numeri e i risultati non sono più rappresentativi.

Esistono diversi strumenti di terze parti per automatizzare il test della rete. Tenere presente che, mentre si esegue il test del throughput in un'area, si utilizza in modo efficace tutto il tempo di trasmissione per la durata del test ed è quindi una cattiva idea testare la rete troppo spesso in quanto causa interruzioni per gli altri client.

Risoluzione di un problema di throughput

Quando si identifica un problema di throughput, è possibile esaminare diverse cose per isolare il problema:

• Isolare se prima di iniziare il test l'ambiente RF è già occupato. Maggiore è l'utilizzo del canale (al di fuori del test), minore sarà il risultato del test del throughput. Se viene identificato un problema relativo all'utilizzo del canale, controllare se nella stessa area dello stesso canale sono presenti altri access point e riconsiderare la progettazione della RF. La riduzione della larghezza del canale, l'eliminazione delle anomalie, l'utilizzo di diverse antenne con una copertura più mirata sono tutte buone opzioni. Non sempre è consigliabile aggiungere altri punti di accesso.
• Acquisite un'acquisizione over-the-air del test del throughput e verificate se vi sono molti tentativi di dati a un livello 802.11 (in percentuale di tutti i fotogrammi di dati). Un numero elevato di tentativi indica che l'ambiente RF è potenzialmente il problema. Verificare inoltre le velocità di trasmissione dei dati utilizzate, il protocollo potenzialmente non ottimale o il numero di flussi spaziali utilizzati. Un trasferimento di dati di grandi dimensioni è molto caratteristico in un'acquisizione over-the-air: si vedono decine di frame di dati con la stessa origine e destinazione e con un delta di tempo estremamente ridotto tra di loro seguito da un ACK a blocchi. Se il trasferimento è caratterizzato da un normale ACK dopo ogni frame di dati, o da un elevato numero di richieste da inviare/da inviare in chiaro, il basso throughput può essere facilmente spiegato.
• Verificare se il problema di velocità effettiva si verifica con tutti i tipi di sicurezza sulla WLAN. A volte, una specifica incompatibilità di sicurezza tra il client e l'access point può portare a un throughput inadeguato.