Riservazioni DHCP, problemi di lease e diagnostica client in ambienti eterogenei

DHCP (Dynamic Host Configuration Protocol) è la base automatica per l’assegnazione di IP, gateway e DNS. Quando le riservazioni DHCP non vengono applicate, i lease „rimangono appesi“ o i client improvvisamente usano indirizzi errati, spesso si verificano disservizi estesi: il VoIP perde la registrazione, le stampanti non vengono più trovate, i client VPN finiscono sui server DNS sbagliati. Questo runbook riassume cause pratiche, sequenze di verifica e strategie di fallback, in modo che possiate procedere in modo strutturato in ambienti misti Windows-, Linux- e appliance.

Cosa conta davvero nel DHCP

Comprendete brevemente la meccanica pratica: lo scambio DHCP si svolge classicamente come DORA (Discover, Offer, Request, Ack). Determinante per le riservazioni è l’identità del client: in molti casi non è l’indirizzo MAC, ma il DHCP Client Identifier (Option 61). I lease hanno tempi di rinnovo T1/T2; se il rinnovo fallisce, si manifesta come un’interruzione improvvisa.

Riservazioni DHCP: pratica e diagnostica

Raccomandazioni concrete per le riservazioni in esercizio: configuri la riservazione sull’identità che il client effettivamente invia. Molti sistemi operativi e dispositivi moderni usano, invece dell’indirizzo MAC hardware, un Client Identifier (Option 61), UUID o ID specifiche del vendor; gli strati di virtualizzazione possono inoltre modificare gli indirizzi MAC durante le operazioni di clonazione. Documenti ogni riservazione nel suo IPAM (gestione degli indirizzi IP) e inserisca un registro delle modifiche: chi ha creato la riservazione, quando e con quale dispositivo target.

Sintomi frequenti e loro probabili cause

La riservazione viene ignorata

Spesso dipende da identità errata (Client Identifier vs. MAC), riservazione nello scope/VLAN sbagliato, oppure un secondo server DHCP sta offrendo un’altra offerta. Virtualizzazione, NIC‑teaming o feature per la privacy possono modificare le identità. Verifica rapida: una cattura dei pacchetti mostra quali campi invia il client.

Lease problematici dopo cambio di rete (WLAN, VPN, dock)

Le cause sono: lease residuo nella cache del client, opzioni DHCP diverse per rete, configurazione mancante del relay o problemi con i suffissi DNS via VPN. Problemi di MTU o di routing possono aggravare la situazione e causare frammentazione dei pacchetti.

IP duplicate (conflitto di indirizzi)

Solitamente causato da indirizzi IP statici nel pool dinamico, riservazioni dimenticate o macchine virtuali clonate. Anche VRRP/HSRP o dati IPAM gestiti in modo errato possono portare a conflitti. Controlli gli ARP cache e le tabelle MAC degli switch per identificare gli host attivi.

Coinvolto solo un VLAN/sito

Sono sospetti qui relay/IP‑helper, ACL, DHCP Snooping o porte di accesso/WLAN‑SSID‑VLAN assegnate in modo errato. Verifichi che la GIADDR sul server corrisponda alla subnet prevista.

Ordine di verifica strutturato (passi brevi e prioritari)

Segua la catena: 1) livello fisico/VLAN (gateway, trunk, ACL), 2) servizio di rete (relay/IP‑helper, Option 82, DHCP Snooping), 3) server (scope, riservazioni, lease, failover), 4) client e dispositivi speciali. Questo ordine evita interventi inutili sul client e riduce il rischio.

Verifiche di rete: switch, relay e snooping

Verificare DHCP Snooping e binding degli switch

DHCP Snooping (una funzionalità che blocca risposte DHCP non autorizzate) previene i rogue server, ma richiede definizioni corrette delle porte trusted. Con una configurazione errata, server legittimi possono essere esclusi. Su Cisco IOS/IOS‑XE controlli i binding e lo stato:

# Cisco IOS Beispiel: Status und Bindings prüfen
show ip dhcp snooping
show ip dhcp snooping binding
show running-config | include ip dhcp snooping

La tabella di binding contiene le assegnazioni MAC→IP→VLAN; se è vuota, manca connettività o lo switch non vede traffico DHCP.

Relay (IP Helper) e Option 82

L’agente relay (IP Helper) imposta GIADDR (Gateway IP Address) e può aggiungere Option 82 (Relay Agent Information). Se il server utilizza Option 82, cambia il matching di riservazioni e policy. Verifichi se il server elabora o ignora Option 82 e, in caso di problemi, provi temporaneamente a rimuovere Option 82.

Diagnosi lato server e verifiche specifiche

Windows DHCP Server: ricerca di discrepanze d’identità

Windows memorizza il ClientId nel database DHCP. Se i dispositivi usano Option 61, la riservazione potrebbe non comparire dove la si aspetta. Crei le riservazioni con i Get/Set‑Cmdlets e verifichi i Leases:

# Beispiel: Reservierung anlegen und prüfen (Windows DHCP)
Add-DhcpServerv4Reservation -ScopeId 10.20.30.0 -IPAddress 10.20.30.42 -ClientId "01-11-22-33-44-55" -Description "Konferenzdrucker"
Get-DhcpServerv4Reservation -ScopeId 10.20.30.0 | Where-Object {$_.IPAddress -eq '10.20.30.42'}

# Scope‑Statistiken
Get-DhcpServerv4ScopeStatistics -ScopeId 10.20.30.0

Tenga presente che il ClientId spesso è nel formato 01+MAC (01 anteposto) o come stringa di testo; usi esattamente il formato mostrato sul server.

ISC dhcpd: riservazione (host) in dhcpd.conf

Con ISC dhcpd il file dhcpd.leases è la fonte di verità; le modifiche al file di configurazione devono essere controllate sintatticamente e il servizio deve essere riavviato o segnalato con HUP:

# Beispielhost‑Reservierung in /etc/dhcp/dhcpd.conf
host printer-konf01 {
  hardware ethernet 11:22:33:44:55:66;
  fixed-address 10.20.30.42;
  option host-name "Konf-Printer01";
}

# Syntaxprüfung
sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf
# Neustart (Debian/Ubuntu)
sudo systemctl RESTart isc-dhcp-server

In configurazioni HA/failover pRESTi attenzione a dati di lease incoerenti tra master/slave e eviti interventi manuali simultanei sul file delle lease.

Packet Capture: identificare i dati chiave

Un capture è la prova più affidabile: chi invia DHCPOFFER/DHCPACK, quale GIADDR/Option82 è impostata e cosa contengono Option 61/50/54? Usi tcpdump/tshark/Wireshark per analisi mirate.

# tcpdump Beispiel: DHCP Traffic mitschneiden
sudo tcpdump -i eth0 -nn -s 0 -w dhcp.pcap 'udp and (port 67 or port 68)'

# tshark: DHCP Felder extrahieren (Client Identifier, GIADDR, Server Identifier)
tshark -r dhcp.pcap -T fields -e dhcp.option.client_id -e ip.src -e ip.dst -e bootp.giaddr -e bootp.file -E header=y -E separator=,

# Wireshark Displayfilter Beispiele
bootp.option.type == 61  # Client Identifier
bootp.option.type == 82  # Relay Agent Information
bootp.option.type == 54  # DHCP Server Identifier

Interpretazione: se viene rilevata Option 61 non corrispondente al MAC atteso, deve riassociare la riservazione a quel ClientId o adeguare il client.

Lato client: misure mirate e diagnostica

Sul client verifichi prima i valori visibili, poi log/cache e infine azioni di reset mirate. Su Windows gli EventLogs forniscono indicazioni; su Linux i file di lease e systemd/journal. Per dispositivi problematici è consigliabile un test controllato in un VLAN di test isolato.

Runbook pratici: scenari e passaggi tipici

Scenario A: la riservazione non viene applicata

1. Creare una cattura pacchetti sul client interessato (o SPAN dalla porta di accesso) e verificare il Client Identifier.
2. Sul server DHCP cercare una corrispondenza per questo specifico Client Identifier.
3. Se sul server la riserva è basata sulla MAC, create una nuova riservazione per la ClientId trovata oppure modificate il client in modo che venga utilizzata la MAC (ad es. impostazione dell’adattatore di rete della VM).
4. Far rinnovare il client (ipconfig/renew oder dhclient‑Release/Renew) e controllare i log.

Scenario B: Molti client ricevono APIPA o mantengono l’IP precedente

1. Controllare l’utilizzo dello scope (Pool‑Exhaustion).
2. Verificare a livello di rete se il Discover arriva al server (cattura pacchetti sul relay/gateway).
3. Controllare il DHCP Snooping dello switch per errori; verificare ACLs/Firewall per UDP 67/68.
4. Ridurre temporaneamente il tempo di lease per il test (attenzione: aumenta il traffico DHCP) e monitorare.

Monitoring, Alerting und Automatisierung

Un’operatività stabile richiede metriche: IP disponibili nel pool, tasso di segnalazioni di Duplicate‑IP, timeout nelle richieste DHCP, e numero di Rogue‑DHCPOFFERs per ora. Se disponete di log centralizzati (Syslog, ELK, Splunk), filtrate per eventi Bootp/DHCP e definite soglie.

# ELK/Splunk Beispiel: Suche nach unerwarteten DHCPOFFERs (Pseudo‑Query)
source="/var/log/messages" OR source="/var/log/syslog" "DHCPOFFER" NOT (src_ip==10.20.30.5 OR src_ip==10.20.30.6)

Automazione concreta: se la vostra IPAM‑API è disponibile, è possibile creare e auditare le riservazioni tramite workflow PR/Change. Per Windows DHCP sono adatti script PowerShell, per ISC dhcpd le modifiche possono essere distribuite da un repository di configurazione centrale tramite CI/CD (con controllo della sintassi prima).

VPN‑spezifische Troubleshooting‑Tipps

Le configurazioni VPN richiedono attenzione specifica, perché MTU del tunnel, strategie di split‑tunnel e DNS sul tunnel possono modificare l’esperienza DHCP. Controllate sempre entrambi i lati (client locale e estremità del tunnel) e confrontate le catture.

# MTU Test über Tunnel: Ping mit DF‑Flag
ping -M do -s 1400 vpn-gateway.example.com
# MSS‑Clamping prüfen: TCP‑Verbindungen beobachten, ob Fragmentierung Probleme verursacht

Consiglio: se i server VPN usano pool propri, documentate i loro profili di lease e le politiche DNS. Nei relay site‑to‑site verificate l’instradamento asimmetrico; un Offer può tornare su un percorso diverso e venire scartato dal client.

Umsetzung und Rückfallstrategie

Eseguite le modifiche DHCP in modo pianificato: backup del database/file DHCP prima della modifica, modifiche in piccoli passi per scope, monitoraggio dell’utilizzo dello scope, e criteri di rollback chiari (p. es. aumento significativo di eventi Duplicate‑IP o Pool‑Exhaustion). Inserite i passi di rollback nel vostro Change‑Ticket (who, when, how). Prassi consolidata: operate in una finestra di manutenzione/test e informate preventivamente i clienti/team interessati.

Conclusione

I problemi DHCP si risolvono in modo affidabile se si procede in modo metodico: prima il percorso (VLAN, Relay, Firewall), poi il lato server (Scope, Leases, Prenotazioni), infine i client e i dispositivi speciali. Le catture di pacchetti sono spesso la prova più rapida per problemi di identità e di relay. Un piano indirizzi pulito, regole di prenotazione documentate, profili di lease e misure di protezione attive contro i Rogue‑DHCP (DHCP Snooping con definizioni di trust chiare) sono le leve più efficaci per un funzionamento stabile in reti eterogenee. Tenete i processi auditabili e automatizzate i controlli ricorrenti per ridurre le escalation.

Prenotazioni DHCP: architettura, scalabilità e aspetti operativi

Oltre alla mera risoluzione dei guasti conviene considerare architettura e esercizio — lì risiedono molti rischi che possono causare interruzioni ricorrenti. Progettate i servizi DHCP come componente infrastrutturale critica per il funzionamento, con responsabilità chiare, auditabilità e validazione automatica.

Disponibilità e coerenza

Non scalate il DHCP limitandovi a copiare la configurazione. I servizi stateful richiedono un repository di lease coerente. Utilizzate i meccanismi di failover previsti dal produttore (Windows DHCP Failover, ISC dhcpd‑Failover‑Protocol) invece di copie manuali. Prestate attenzione ai rischi di split‑brain: se entrambi i nodi funzionano contemporaneamente come primari si generano lease duplicati e conflitti di indirizzo.

Backup, ripristino rapido e controllo delle modifiche

Un backup rapido dei dati dei lease e della configurazione è obbligatorio prima di ogni modifica. Esempio: Windows DHCP esportare, salvare i lease ISC:

# Windows: DHCP-Konfiguration und Leases exportieren
Export-DhcpServer -ComputerName dhcp01 -File C:backupsdhcp-dump.xml -Leases -Force

# ISC dhcpd: Leases sichern und Configuration in Versionskontrolle
sudo cp /var/lib/dhcp/dhcpd.leases /var/backups/dhcpd.leases.$(date +%F)
sudo rsync -a /etc/dhcp/ /var/backups/dhcp-config/

Eseguite le modifiche tramite ticket e pipeline CI/CD: controllo della sintassi, canary‑rollout su uno scope e health‑check automatizzati minimizzano il rischio di interruzioni.

Integrazione con IPAM e automazione

Collegate il DHCP al vostro IPAM tramite API, ma tenete conto delle race‑condition: due sistemi non devono rilasciare contemporaneamente lo stesso indirizzo. Le opzioni di progettazione sono: IPAM come single source of truth con modello push verso il server DHCP, oppure DHCP come fonte primaria con sincronizzazioni periodiche. Implementate azioni idempotenti e risoluzione dei conflitti (p.es. API‑locking o aggiornamenti transazionali).

Monitoraggio, Alerts und Kennzahlen

Operationalizzate le metriche: IP disponibili per scope, rapporto Offer→Ack, numero di Rogue‑Offer, numero di eventi Duplicate‑IP, errori di rinnovo lease (errori T1/T2). Definite soglie chiare, p.es. allarme se IP disponibili < 10% o eventi Duplicate‑IP > 5 entro 15 minuti.

Sicurezza e integrazione di rete

I segmenti in cui gira il DHCP devono essere nel management‑VLAN o in un control‑plane strettamente controllato. Proteggete i relay agent e le trust‑port con DHCP Snooping e documentate l’utilizzo dell’Option‑82. Per gli auditor tenete disponibili gli audit‑trail: chi ha creato le prenotazioni, quando e con quale ClientIdentifier.

Regola pratica: testate ogni modifica di configurazione prima in uno scope isolato, automatizzate le validazioni e definite criteri di rollback semplici (p.es. calo delle percentuali di ACK o aumento dei messaggi di conflitto). In questo modo il DHCP rimane una base affidabile per le vostre reti eterogenee.

Per questo tema sono inoltre importanti i lease DHCP e il troubleshooting DHCP. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa è importante nella pratica quotidiana.