Una scuola che è sopravvissuta alla prima settimana di settembre per la prima volta

La rete wireless della scuola funzionava adeguatamente per gran parte dell'anno e andava in crisi puntualmente nella prima settimana di settembre. Era successo per tre anni di fila, ed era stato portato all'attenzione del consiglio d'istituto.

Lo schema era specifico: il primo lunedì del trimestre, a partire dalle 08:40 circa, i dispositivi si associavano e poi non riuscivano a ottenere un indirizzo o ad autenticarsi. Entro mercoledì le cose miglioravano. Dalla seconda settimana la rete funzionava bene.

Tre precedenti round di indagine avevano concluso che servivano più access point.

Cosa stava realmente succedendo

Tre problemi separati che arrivavano nello stesso momento.

Esaurimento del pool DHCP. La VLAN degli studenti aveva un /22 — circa 1.000 indirizzi utilizzabili — con un lease di 24 ore. Novecento studenti arrivati con due dispositivi ciascuno, più lo staff, più ogni dispositivo che era stato spento per sei settimane e richiedeva un nuovo indirizzo, lo esaurivano prima della prima pausa. Il pool restava poi esaurito perché i lease non scadevano.

Saturazione RADIUS. Il server di autenticazione era una singola macchina virtuale dimensionata anni prima. Duemila autenticazioni 802.1X simultanee alle 08:40 producevano una coda, timeout e client che ritentavano — il che aumentava ulteriormente il carico.

Problemi di capacità genuini in due spazi. La sala principale e il centro del sesto anno erano genuinamente sotto-dimensionati, ed erano gli unici posti dove la diagnosi "servono più access point" era corretta.

Due dei tre problemi non erano affatto problemi wireless. Si presentavano semplicemente come "il Wi-Fi non funziona", perché è quello che vede uno studente.

Prima le correzioni poco affascinanti

• Pool DHCP ampliato a un /21 e durata del lease ridotta a 4 ore durante l'inizio del trimestre, tornando a 12 ore in seguito. Questa singola modifica ha rimosso la modalità di guasto più grande.
• RADIUS scalato orizzontalmente a due istanze dietro un load balancer, con il timeout di autenticazione alzato e l'intervallo di ritentativo del client regolato in modo che una risposta lenta non producesse una tempesta di ritentativi.
• EAP-TLS basato su certificati per i dispositivi gestiti dalla scuola, in sostituzione di PEAP-MSCHAPv2. Questo ha eliminato del tutto i guasti legati alle password e il carico helpdesk associato per quella classe di dispositivi.
• PSK per dispositivo per il parco BYOD degli studenti, che non può usare un certificato. Ogni dispositivo studente riceve una chiave legata al proprio profilo e atterra sulla VLAN studenti.

Il lavoro wireless

• 16 access point aggiuntivi, 11 dei quali nella sala principale e nel centro del sesto anno dove la capacità era genuinamente insufficiente.
• Sala principale riconfigurata da una griglia a soffitto a un layout direzionale frontale e laterale per uso assembleare, con canali a 20 MHz durante gli eventi di tutta la scuola.
• Larghezze di canale ridotte a 20 MHz negli spazi didattici, con 40 MHz mantenuto solo nelle aree a bassa densità.
• Velocità base minima alzata a 12 Mbps, e 2,4 GHz disabilitato su circa il 60 percento degli access point.
• Due edifici vincolati gestiti con canaline a vista e access point in posizioni approvate dalla sovrintendenza, il che ha vincolato il posizionamento e richiesto due unità aggiuntive per compensare.

La prova generale

La modifica che tutti hanno trovato più utile non era tecnica. Due settimane prima del trimestre, l'IT ha condotto una prova di carico: 40 dispositivi dello staff più uno script che generava carico di autenticazione sintetico, nella sala principale, su larga scala.

Ha trovato un attributo RADIUS mal configurato che avrebbe fatto fallire ogni dispositivo studente il primo giorno.

Prima settimana di trimestre: 22 ticket helpdesk contro i 287 dell'anno precedente. Nessun esaurimento DHCP. Gli errori di autenticazione di picco sono scesi da 410 a 11 al giorno.

L'utilizzo del canale nella sala principale durante l'assemblea di tutta la scuola è sceso dall'84 al 38 percento.

La misura della scuola stessa è stata che la rete non è stata discussa alla prima riunione del consiglio d'istituto dell'anno, cosa che non era mai successa prima.

Il conto onesto

Delle quattro modifiche che hanno contato di più, tre non erano modifiche wireless. Il pool DHCP, la scalatura RADIUS e il metodo di autenticazione insieme hanno spiegato la maggior parte del miglioramento.

I tre anni precedenti di indagine si erano concentrati sul livello di accesso perché il sintomo appariva lì. È l'errore diagnostico più comune nel wireless, e una scuola a settembre è l'ambiente più propenso a metterlo in evidenza.