Le 10 principali cause di timeout DHCP sulle reti wireless ad alta densità

Benvenuti alla serie di Technical Briefing di Purple. Sono il vostro ospite e oggi approfondiremo uno dei problemi più frustranti — e, francamente, più spesso diagnosticati in modo errato — nelle reti wireless aziendali: i timeout DHCP sulle reti ad alta densità. Se gestite il WiFi in un hotel, in un centro congressi, in una catena di negozi o in uno stadio, e i vostri ospiti o il vostro personale si scontrano con quel temuto indicatore di caricamento "acquisizione indirizzo IP in corso", questo episodio fa al caso vostro. Esamineremo le dieci cause principali, come diagnosticare ciascuna di esse e cosa dovreste fare al riguardo proprio ora. Iniziamo a inquadrare la situazione. Il DHCP — il Dynamic Host Configuration Protocol — è il meccanismo attraverso il quale ogni dispositivo che si connette alla rete riceve un indirizzo IP, una subnet mask, un gateway predefinito e le informazioni sul server DNS. Si tratta di un handshake in quattro passaggi: Discover, Offer, Request, Acknowledge — quello che gli ingegneri chiamano il processo DORA. Sembra semplice, e su una rete di piccole dimensioni lo è. Ma quando ci sono cinquecento dispositivi che tempestano una singola VLAN al banco di registrazione di una conferenza, o diecimila tifosi che aprono contemporaneamente l'app dello stadio, il DHCP diventa un collo di bottiglia critico. E quando fallisce, gli utenti non possono andare online. Punto. Entriamo quindi nel dettaglio delle dieci cause. Numero uno: esaurimento del pool di IP. Questa è la causa più comune ed è del tutto prevenibile. Il vostro scope DHCP — l'intervallo di indirizzi IP che il vostro server è autorizzato a distribuire — ha una dimensione finita. Una sottorete slash-24 offre 254 indirizzi utilizzabili. Sembrano molti, finché non si considera che i dispositivi mobili spesso mantengono i lease anche dopo la disconnessione, che i dispositivi IoT si stanno moltiplicando nella vostra struttura e che il vostro scope è stato dimensionato per un'occupazione normale, non per un evento sold-out. La soluzione è semplice: dimensionare correttamente gli scope. Per gli ambienti ad alta densità, utilizzate sottoreti slash-22 o slash-21. In questo modo avrete a disposizione oltre mille indirizzi per VLAN. Monitorate l'utilizzo e impostate un avviso all'ottanta percento della capacità — non lasciate mai che raggiunga il novanta. Numero due: tempi di lease eccessivi. Questo è il killer silenzioso. Se il tempo di lease del DHCP è impostato su ventiquattro ore — che è il valore predefinito su molti sistemi — e gestite una struttura in cui gli ospiti vanno e vengono durante il giorno, quegli indirizzi IP rimangono occupati da dispositivi che se ne sono andati ore prima. Non sono disponibili per nuove connessioni. Per il WiFi ospiti in ambienti ad alta rotazione — hotel, retail, eventi — impostate il tempo di lease tra trenta e sessanta minuti. Per le reti del personale aziendale in cui i dispositivi rimangono connessi tutto il giorno, sono appropriati tempi da otto a dodici ore. Non utilizzate mai il lease predefinito di ventiquattro ore su una rete ospiti. Numero tre: errata configurazione del DHCP relay agent. In qualsiasi implementazione aziendale con più VLAN, il server DHCP si trova quasi certamente su una subnet diversa rispetto ai client wireless. Il DHCP relay agent — solitamente configurato sullo switch Layer 3 o sul router — è responsabile dell'inoltro dei broadcast DHCP dai client al server. Se il relay è configurato in modo errato — indirizzo helper errato, interfaccia errata o se il relay manca del tutto in una nuova VLAN — i client non riceveranno mai una risposta al loro DHCPDISCOVER. Questa è una delle cause più comuni di errore DHCP dopo una modifica della rete o l'implementazione di un nuovo SSID. Verifica sempre la configurazione del relay quando aggiungi VLAN ed effettua un test con un packet capture prima di andare online. Numero quattro: interferenza da broadcast storm. I messaggi di discovery DHCP sono broadcast di Layer 2. In una rete piatta di grandi dimensioni con centinaia di access point tutti sulla stessa VLAN, un broadcast storm — causato da un loop di commutazione, una porta configurata in modo errato o un dispositivo malfunzionante — può sovraccaricare la rete con traffico broadcast al punto da causare la perdita o il ritardo dei pacchetti DHCP. Lo Spanning Tree Protocol dovrebbe essere la prima linea di difesa, ma nelle implementazioni wireless ad alta densità, dovresti anche abilitare la soppressione dei broadcast sui controller wireless. La maggior parte delle piattaforme aziendali — Cisco, Aruba, Juniper Mist — supporta funzionalità di DHCP proxy o filtraggio dei broadcast che convertono i broadcast DHCP in unicast, riducendo significativamente l'overhead. Numero cinque: singolo punto di errore — nessuna ridondanza DHCP. Se il tuo server DHCP è un singolo Windows Server o un singolo router, rappresenta un singolo punto di errore. Quando si arresta per l'applicazione di patch, si blocca o perde la connettività di rete, ogni nuovo tentativo di connessione sulla rete fallirà. Nelle implementazioni aziendali, dovresti eseguire il failover DHCP — in modalità failover DHCP di Windows Server o tramite un'appliance DHCP dedicata con ridondanza attivo-passivo o attivo-attivo. Per le reti gestite in cloud, molte piattaforme offrono ora un DHCP distribuito in cui il controller gestisce i lease, ma è comunque necessario comprenderne le modalità di guasto. Numero sei: server DHCP non autorizzati (rogue). Questo problema può essere particolarmente insidioso. Un server DHCP rogue è un qualsiasi dispositivo non autorizzato sulla rete che risponde ai messaggi di DHCP discover. Potrebbe trattarsi di un hotspot personale collegato da qualcuno, di una macchina virtuale configurata in modo errato o, nel peggiore dei casi, di un attacco intenzionale. I server DHCP rogue distribuiscono indirizzi IP errati, informazioni di gateway errate o server DNS che puntano a infrastrutture dannose. Il risultato varia dalla totale assenza di connettività per gli utenti a un attacco man-in-the-middle. La mitigazione consiste nel DHCP snooping — una funzionalità disponibile su quasi tutti gli switch gestiti che consente le risposte DHCP solo da porte attendibili e designate. Abilitala. Non è opzionale in un'implementazione professionale. Numero sette: firewall e ACL che bloccano le porte UDP sessantasette e sessantotto. Il DHCP opera sulla porta UDP sessantasette per il traffico da server a client e sulla porta sessantotto per il traffico da client a server. Se sono presenti liste di controllo degli accessi o regole di firewall che bloccano queste porte — forse a seguito di un intervento di rafforzamento della sicurezza o di una policy configurata in modo errato — il DHCP fallirà in modo silenzioso. Questo accade di frequente dopo una migrazione del firewall o un aggiornamento delle policy. Verificare sempre che le porte UDP sessantasette e sessantotto siano esplicitamente consentite tra le VLAN wireless e il server DHCP. Utilizzare l'acquisizione dei pacchetti sull'interfaccia del server per confermare che il traffico stia effettivamente arrivando. Numero otto: errata configurazione della VLAN. I guasti DHCP sono spesso il sintomo di un problema di VLAN piuttosto che di un problema di DHCP. Se un client wireless è associato a un SSID che mappa sulla VLAN trenta, ma la porta di uplink sull'access point non trasporta la VLAN trenta come VLAN taggata, il DHCP discover non raggiungerà mai il livello di distribuzione. Allo stesso modo, se l'ambito DHCP è definito per la sottorete errata, o se l'ambito non è attivato, i client non riceveranno alcuna risposta. Ogni volta che si esegue la risoluzione dei problemi DHCP, verificare il tagging della VLAN end-to-end: dall'uplink dell'AP, attraverso lo switch di accesso, attraverso lo switch di distribuzione, fino all'interfaccia del server DHCP. Un solo tag VLAN mancante in qualsiasi punto di quella catena causerà un fallimento totale. Numero nove: bug del firmware dell'access point. Questo è meno comune ma merita di essere segnalato, in particolare nelle distribuzioni su larga scala in cui si esegue un ambiente firmware misto. Ci sono stati casi documentati — tra cui un bug UniFi U7 molto pubblicizzato all'inizio del 2026 — in cui il firmware dell'access point interrompeva in modo intermittente il terzo pacchetto dell'handshake DHCP: il DHCPREQUEST. Il client invia il discover, riceve un offer, invia il request — e l'AP lo scarta. Il client non riceve mai una conferma. La soluzione è semplice: mantenere aggiornato il firmware dell'AP e, quando si esegue la risoluzione di problemi DHCP intermittenti che non corrispondono a nessun altro pattern, controllare la versione del firmware e l'elenco dei problemi noti del fornitore. Numero dieci: problemi di roaming del client. Negli ambienti ad alta densità, i client eseguono costantemente il roaming tra gli access point. Quando un client passa da un AP all'altro — in particolare se attraversa un confine di VLAN o si sposta su una sottorete diversa — potrebbe dover ottenere un nuovo lease DHCP. Se l'evento di roaming non viene gestito correttamente, il client potrebbe tentare di rinnovare il lease esistente su una sottorete a cui non è più connesso, causando un timeout. Lo standard IEEE 802.11r — fast BSS transition — è progettato per velocizzare il roaming, ma presenta problemi di compatibilità noti con alcuni dispositivi client. La soluzione più affidabile per il roaming Layer 3 consiste nell'utilizzare le funzionalità di tunneling dei client o di anchor AP del controller wireless, che assicurano che il client appaia sempre sulla stessa sottorete, indipendentemente dall'AP a cui è associato. Ora parliamo di implementazione. Se oggi dovessi consigliare un cliente su come proteggere la propria infrastruttura DHCP per una sede ad alta densità, ecco cosa gli direi. In primo luogo, verificate immediatamente i vostri scope. Estraete un report sull'utilizzo del DHCP e analizzate l'occupazione nei momenti di picco. Se uno scope raggiunge l'ottanta percento di utilizzo durante le normali attività, è necessario ampliarlo prima del prossimo evento ad alto traffico. Utilizzate una subnet /22 o superiore per le reti ospiti. In secondo luogo, impostate i tempi di lease in modo appropriato per ciascun segmento di rete. WiFi ospiti: da trenta a sessanta minuti. WiFi del personale: otto ore. IoT e infrastruttura: ventiquattro ore o prenotazioni statiche. In terzo luogo, implementate il DHCP snooping su ogni switch di accesso. Si tratta di un'attività di configurazione una tantum che elimina completamente il rischio di server DHCP non autorizzati. In quarto luogo, implementate il failover DHCP. Se utilizzate Windows Server, configurate la funzionalità di failover integrata. Se utilizzate una piattaforma gestita in cloud, verificate da dove viene erogato il servizio DHCP e cosa succede in caso di guasto di tale componente. In quinto luogo, abilitate la soppressione dei broadcast sul controller wireless. Convertite i broadcast DHCP in unicast dove supportato. Questo riduce significativamente il sovraccarico negli ambienti densi. In sesto luogo, documentate la mappatura tra VLAN e scope DHCP. Ogni VLAN deve avere uno scope documentato, una configurazione del relay agent e un proprietario designato. In caso di guasto, questa documentazione riduce il tempo medio di risoluzione da ore a minuti. Ora passiamo alle domande rapide. Domanda: Come faccio a sapere se il mio pool DHCP è esaurito? Risposta: Eseguite "show ip dhcp pool" su un dispositivo Cisco o controllate la console di gestione del server DHCP. Cercate "no free leases" nel syslog. Configurate avvisi di monitoraggio all'ottanta percento di utilizzo. Domanda: Qual è il modo più rapido per diagnosticare un errore DHCP? Risposta: L'acquisizione dei pacchetti sull'interfaccia lato client. Se vedete DHCPDISCOVER senza alcuna risposta DHCPOFFER, il problema è tra il client e il server. Se vedete DHCPOFFER ma nessun DHCPACK, il problema risiede nello scambio di richiesta-conferma. Domanda: Dovrei usare IP statici invece del DHCP per gli ambienti ad alta densità? Risposta: No. La gestione degli IP statici su larga scala è operativamente ingestibile. La risposta corretta è un DHCP ben progettato, con dimensioni degli scope, tempi di lease e ridondanza adeguati. Domanda: Il DHCP snooping influisce sulle prestazioni? Risposta: In modo trascurabile. Sui moderni switch gestiti, il DHCP snooping opera a livello hardware e non ha un impatto misurabile sul throughput. In sintesi: i timeout DHCP sulle reti wireless ad alta densità sono quasi sempre causati da una di queste dieci cause principali: esaurimento del pool, tempi di lease eccessivi, errata configurazione del relay, tempeste di broadcast, mancanza di ridondanza, server non autorizzati, blocchi del firewall, errate configurazioni delle VLAN, bug del firmware o problemi di roaming. Ognuna di esse presenta un percorso diagnostico chiaro e una soluzione precisa. Nessuna di queste richiede costosi aggiornamenti hardware. Richiedono solo una corretta configurazione, un monitoraggio adeguato e una documentazione accurata. Se gestisci una piattaforma WiFi per ospiti come Purple, hai l'ulteriore vantaggio di avere visibilità sugli eventi di connessione, sui flussi di autenticazione e sui dati di sessione che possono aiutarti a correlare i guasti DHCP con dispositivi specifici, SSID o finestre temporali. Questa telemetria è preziosa per l'analisi delle cause principali. I tuoi prossimi passi: esegui oggi stesso un audit dei tuoi scope DHCP, implementa il DHCP snooping se non l'hai ancora fatto e configura il monitoraggio dell'utilizzo con relativi avvisi. Non aspettare il prossimo evento per scoprire che il tuo pool è esaurito. Grazie per aver ascoltato la serie Purple Technical Briefing. Per ulteriori guide, riferimenti all'architettura e best practice di implementazione, visita purple.ai.