Il DHCP è uno dei servizi fondamentali all'interno di una rete aziendale perché permette di assegnare automaticamente agli endpoint i parametri necessari per comunicare sulla rete IP. Un server DHCP non si limita infatti a fornire un indirizzo IP, ma può distribuire subnet mask, gateway predefinito, server DNS, domain name, route e numerose altre opzioni attraverso il protocollo DHCP. Se il servizio diventa indisponibile, i dispositivi che devono ottenere una nuova configurazione di rete possono non riuscire a comunicare correttamente, con conseguenze particolarmente rilevanti in ambienti con molti PC, notebook, smartphone, dispositivi Wi-Fi, stampanti, terminali e apparati IoT. Il DHCP Failover nasce proprio per evitare che l'indisponibilità di un singolo server DHCP provochi un'interruzione del servizio di assegnazione degli indirizzi.

Come funziona il DHCP

Il protocollo DHCP utilizza un modello client-server attraverso il quale un dispositivo privo di una configurazione IP valida può richiedere dinamicamente i parametri necessari alla comunicazione. Nel caso classico, il client invia un messaggio DHCPDISCOVER in broadcast per individuare i server DHCP disponibili. Il server risponde con un DHCPOFFER contenente una proposta di configurazione, il client invia successivamente un DHCPREQUEST e il server conferma l'assegnazione attraverso un DHCPACK.

L'indirizzo IP viene assegnato attraverso un lease, cioè un periodo di validità durante il quale il client può utilizzare quella configurazione. Il server mantiene quindi informazioni relative agli indirizzi assegnati, alla durata dei lease, agli identificativi dei client e alle opzioni associate alla subnet. Questo stato deve essere gestito correttamente quando sono presenti più server DHCP, perché due server indipendenti che utilizzano lo stesso pool senza coordinamento possono assegnare contemporaneamente lo stesso indirizzo IP a dispositivi differenti.

Perché un singolo server DHCP rappresenta un punto di guasto

In una rete con un solo server DHCP, il servizio di assegnazione degli indirizzi dipende completamente dalla disponibilità di quella macchina. Un guasto hardware, un problema del sistema operativo, un riavvio, un errore del servizio DHCP o un'interruzione della connettività verso il server possono impedire ai nuovi client di ottenere una configurazione.

È importante distinguere questo scenario dagli endpoint che dispongono già di un lease valido. Un dispositivo che ha ricevuto precedentemente un indirizzo IP può continuare a utilizzare la configurazione fino alla scadenza del lease e può tentare di rinnovarlo prima della sua conclusione. Il problema diventa quindi particolarmente evidente quando entrano in rete nuovi dispositivi, quando vengono riavviati sistemi con lease scaduti oppure quando le configurazioni devono essere rinnovate e il server DHCP non è raggiungibile.

In un ambiente aziendale questo può trasformare un problema apparentemente limitato a un singolo server in un problema di disponibilità dell'intera rete.

Cos'è il DHCP Failover

Il DHCP Failover permette di configurare due server DHCP affinché collaborino nella gestione dello stesso servizio. I due server condividono informazioni relative ai lease e allo stato delle assegnazioni, consentendo al secondo server di continuare a fornire il servizio quando il primo non è disponibile.

L'obiettivo non è semplicemente avere due server DHCP installati contemporaneamente, ma mantenere una relazione di failover tra i sistemi. I server devono infatti conoscere lo stato delle assegnazioni e devono coordinarsi per evitare conflitti sugli indirizzi IP. La configurazione deve quindi prevedere una sincronizzazione dello stato DHCP e una precisa gestione delle condizioni operative dei due nodi.

In ambienti Microsoft Windows Server, il DHCP Failover può essere configurato direttamente attraverso il ruolo DHCP e consente di associare due server alla stessa configurazione di scope. L'implementazione può utilizzare modalità operative differenti a seconda delle esigenze di distribuzione e continuità del servizio.

Load Balance e Hot Standby

Uno dei modelli utilizzati nel DHCP Failover è il Load Balance, nel quale i due server partecipano contemporaneamente all'erogazione del servizio. Gli indirizzi disponibili all'interno dello scope vengono distribuiti tra i due server secondo la configurazione prevista dal meccanismo di failover.

Questo modello permette di utilizzare entrambi i server durante il normale funzionamento, distribuendo il carico delle richieste DHCP e mantenendo contemporaneamente una capacità di continuità operativa. Se uno dei nodi diventa indisponibile, l'altro può assumere la gestione delle richieste secondo lo stato di failover.

Il modello Hot Standby è invece orientato maggiormente alla ridondanza. Un server opera normalmente come principale mentre il secondo rimane disponibile per subentrare in caso di indisponibilità del nodo attivo. Questa configurazione può essere appropriata quando l'obiettivo principale è mantenere un nodo di riserva senza distribuire necessariamente il carico tra entrambi i server.

La scelta tra i due modelli deve essere effettuata considerando numero di client, distribuzione della rete, requisiti di disponibilità, architettura dei server e modalità di gestione dell'infrastruttura.

DHCP Scope e gestione degli indirizzi

La progettazione del DHCP Failover richiede una corretta configurazione degli scope. Uno scope DHCP definisce normalmente l'intervallo di indirizzi IP che il server può assegnare ai client di una determinata rete, insieme alla subnet mask, al gateway e alle altre opzioni DHCP.

La ridondanza non elimina la necessità di progettare correttamente il piano di indirizzamento. Se una rete utilizza la subnet 192.168.10.0/24, ad esempio, il servizio DHCP deve conoscere quali indirizzi possono essere assegnati dinamicamente e quali devono essere esclusi perché riservati a server, apparati di rete, stampanti o altri dispositivi con configurazione statica.

Le reservation DHCP rappresentano inoltre un elemento importante quando determinati dispositivi devono ricevere sempre lo stesso indirizzo IP. In questi casi l'associazione tra MAC address e indirizzo IP deve essere gestita correttamente anche nell'architettura di failover, affinché il comportamento rimanga coerente tra i due server.

Sincronizzazione dello stato dei lease

Uno degli aspetti tecnicamente più importanti del DHCP Failover è la sincronizzazione dello stato. I server devono conoscere quali indirizzi sono disponibili, quali sono assegnati, quali lease sono attivi e quali informazioni devono essere mantenute coerenti tra i nodi.

La sincronizzazione impedisce che entrambi i server considerino disponibile lo stesso indirizzo IP e lo assegnino a client differenti. La consistenza dello stato diventa quindi fondamentale per evitare conflitti IP e problemi di connettività.

La progettazione deve inoltre considerare cosa accade quando la comunicazione tra i due server viene interrotta ma entrambi continuano a essere operativi. Questo scenario è particolarmente delicato perché non coincide con il semplice guasto di uno dei due nodi: si tratta di una perdita della comunicazione tra sistemi che potrebbero continuare autonomamente a gestire richieste DHCP.

Split Brain e perdita della comunicazione

Il cosiddetto split brain rappresenta uno dei rischi da considerare nelle architetture ridondate. Nel caso DHCP, la situazione può verificarsi quando i due server non riescono più a comunicare tra loro ma rimangono entrambi raggiungibili dai client.

Senza meccanismi di controllo dello stato, entrambi i server potrebbero assumere decisioni indipendenti sulla disponibilità degli indirizzi. Per questo motivo i protocolli e le implementazioni di DHCP Failover prevedono stati operativi specifici e procedure per gestire la perdita della sincronizzazione.

Il comportamento in caso di perdita della comunicazione deve essere verificato durante la progettazione e non soltanto dopo un incidente reale. Una configurazione apparentemente ridondante può infatti introdurre nuovi problemi se non viene testata in condizioni di guasto.

DHCP Relay e reti VLAN

Il DHCP Failover deve essere progettato anche considerando la struttura della rete. In un'infrastruttura aziendale è frequente avere più VLAN e subnet differenti, mentre i server DHCP possono essere collocati in una rete server centralizzata.

Poiché le richieste DHCP iniziali utilizzano broadcast e i router normalmente non inoltrano i broadcast tra subnet, viene generalmente utilizzato un DHCP Relay Agent configurato sugli apparati Layer 3. Il relay riceve la richiesta proveniente dalla VLAN del client e la inoltra verso i server DHCP.

In questo scenario è importante che entrambi i server DHCP siano raggiungibili dai relay configurati sulle diverse subnet. Una configurazione nella quale il secondo server DHCP esiste ma non può essere raggiunto dai relay non fornisce una vera ridondanza.

La verifica deve quindi includere routing, ACL, firewall, porte UDP utilizzate dal protocollo DHCP e configurazione degli helper address presenti sui dispositivi Layer 3.

DHCP Failover e firewall

La comunicazione tra i server DHCP e quella tra client, relay e server deve essere compatibile con le regole firewall dell'infrastruttura. Il DHCP utilizza principalmente UDP 67 lato server e UDP 68 lato client, mentre la comunicazione tra componenti e modalità di failover può richiedere ulteriori considerazioni in base alla tecnologia utilizzata.

Un firewall configurato senza considerare il flusso DHCP può impedire il rinnovo dei lease oppure la sincronizzazione tra i server. Per questo motivo la progettazione del failover deve essere accompagnata da una verifica delle regole di rete e dei percorsi effettivamente utilizzati dal traffico.

Il monitoraggio dei log firewall e dei server DHCP può essere particolarmente utile durante la fase di test, perché permette di distinguere un problema applicativo del servizio DHCP da un problema di routing o filtraggio del traffico.

Monitoraggio del DHCP Failover

La ridondanza deve essere monitorata continuamente. Non è sufficiente sapere che entrambi i server sono accesi: è necessario verificare che il servizio DHCP sia operativo, che gli scope siano disponibili, che la sincronizzazione sia corretta e che i due nodi si trovino nello stato previsto.

Un sistema di monitoring può controllare la disponibilità delle porte e dei servizi, lo stato degli scope, l'utilizzo degli indirizzi e gli eventi relativi al failover. Un aumento anomalo del numero di lease disponibili o un esaurimento dello scope può infatti indicare un problema differente dal semplice guasto del server.

Anche l'utilizzo dello spazio indirizzi deve essere monitorato. Una subnet quasi completamente occupata può causare problemi ai nuovi dispositivi anche quando entrambi i server DHCP sono perfettamente funzionanti.

Testare realmente il failover

Una configurazione DHCP Failover non dovrebbe essere considerata affidabile fino a quando non è stata sottoposta a test controllati. È necessario verificare cosa accade quando un server viene arrestato, quando il servizio DHCP viene fermato, quando viene interrotta la comunicazione tra i server e quando il collegamento di rete verso uno dei nodi viene meno.

Durante il test bisogna verificare il comportamento dei client esistenti e dei nuovi client, il rinnovo dei lease, l'assegnazione degli indirizzi e il successivo ritorno alla condizione normale. È inoltre importante verificare la sincronizzazione dopo il ripristino del server precedentemente indisponibile.

Un test di failover deve quindi simulare condizioni realistiche senza limitarsi a controllare che il secondo server risponda a una richiesta. L'obiettivo è verificare l'intero ciclo operativo, dalla perdita del nodo fino al ripristino della configurazione sincronizzata.

DHCP Failover e continuità operativa

Il DHCP Failover rappresenta una componente importante della continuità operativa della rete aziendale, ma non deve essere considerato isolatamente. La disponibilità del DHCP dipende anche dalla rete, dai relay, dai firewall, dai server DNS e dagli altri servizi necessari alla corretta comunicazione dei client.

Una progettazione realmente resiliente deve quindi considerare l'intera catena. Avere due server DHCP collocati nella stessa macchina fisica, nello stesso host virtuale o nello stesso segmento di rete soggetto a un unico punto di guasto può ridurre significativamente il beneficio della ridondanza. I nodi dovrebbero essere progettati considerando anche l'indipendenza dai principali failure domain dell'infrastruttura.

La distribuzione fisica o logica dei server, la disponibilità della rete, la ridondanza dello storage e la possibilità di ripristinare rapidamente la configurazione DHCP sono tutti elementi che contribuiscono alla reale resilienza del servizio.

Perché implementare il DHCP Failover

Il DHCP Failover permette di eliminare il singolo punto di guasto rappresentato da un unico server DHCP e di garantire una maggiore continuità nell'assegnazione dinamica degli indirizzi IP. La sua efficacia dipende però dalla corretta progettazione degli scope, dalla sincronizzazione dei lease, dalla configurazione dei relay, dalla raggiungibilità dei server, dal controllo degli accessi di rete e dal monitoraggio dello stato del servizio.

In un'infrastruttura aziendale moderna il DHCP deve essere considerato un servizio infrastrutturale critico e non una semplice funzione automatica per distribuire indirizzi IP. La configurazione del failover, associata a un piano di indirizzamento coerente, a sistemi di monitoraggio e a procedure di test periodiche, permette di aumentare significativamente l'affidabilità della rete e di ridurre il rischio che un guasto del servizio DHCP si trasformi in un'interruzione operativa per gli utenti e per i dispositivi aziendali.