Archivi tag: DHCP Server

DHCP e lease time: alcune considerazioni

Dopo la recente migrazione di un server DHCP da un dispositivo di tipo embedded ad un server dedicato (nella fattispecie un domain controller), mi sono soffermato sulla corretta configurazione del lease time.

dhcplease

Premesso che non esiste una configurazione “corretta” a prescindere, ma che essa dipende strettamente dal tipo di network su cui il servizio DHCP è in ascolto, occorre trovare la giusta quadra tra un tempo di lease ragionevole e l’utilizzo delle risorse locali del server (tenendo in cosiderazione, ovviamente, anche l’eventuale traffico previsto sulla rete).

Infatti, di per sè, il servizio DHCP (soprattutto quello messo a disposizione da Microsoft, almeno fino alla versione Windows Server 2008, secondo quanto riportato qui), prevede un uso “intensivo” del disco (leggasi I/O rate), in quanto il database con le associazioni IP/MAC viene consultato ogni volta che un nuovo dispositivo si “presenta” in rete oppure intende rinnovare il proprio tempo di lease. Ciascun client DHCP tenterà un rinnovo del tempo di lease allo scadere del 50% dello stesso (passando dallo status BOUND a quello RENEWING). Se tale attività non andrà a buon fine, verrà tentato un rinnovo allo scadere dell’87.5% del lease time (passando dallo status RENEWING a quello REBINDING). Se anche in questo caso non si otterrà l’estensione del suddetto tempo di lease, il client entrerà in status INIT per richiedere un nuovo indirizzo IP. E’ palese che tali tentativi sono tanto più frequenti quanto il tempo di lease è ridotto.

Ora, un tempo di lease “basso” è comunque una scelta corretta quando si ha a che fare con una rete che prevede la connessione di un numero abbastanza elevato di dispositivi (Wi-Fi), pur essendoci a disposizione un pool DHCP (leggasi scope) non molto esteso (ad esempio una classe /25). In questo caso un lease time di 360 minuti (6 ore) sembra abbastanza ragionevole. Invece, se si ha a che fare con network in cui il numero di dispositivi è piuttosto ridotto, va bene mantenere il lease time di default (pari a 8 giorni per il DHCP server di casa Microsoft).

Una volta impostato il lease time conviene sempre e comunque tenere sotto controllo lo stato del servizio DHCP, poichè un’errata configurazione dello stesso potrebbe portare all’impossibilità, da parte dei client, di connettersi alla rete (DHCPNAK ad ogni nuova richiesta per via dello scope ormai saturo).

Qui trovate un link in cui sono presenti le varie icone (con relativo significato) che possono comparire sullo “status” del server DHCP Microsoft.

E’ tutto. Alla prossima.

Cisco RV016 e firmware 4.2.3.03-tm: problemi con il server DHCP integrato

Premesso che il router Cisco RV016 sembrava uno dei migliori oggetti presenti sul mercato dedicato agli abienti SOHO, ho riscontrato, durante il suo normale utilizzo, tutta una serie di bug che ne inficiano il funzionamento e che mi hanno fatto ricredere sulla sua effettiva qualità.

Uno di questi bug riguarda il server DHCP integrato, il quale, di punto in bianco, ha smesso di rilasciare gli indirizzi IP (compresa subnet mask, gateway e nameserver) ai client connessi in rete.

Ho deciso di andare a fondo alla questione e, armato di sniffer (tcpdump), ho salvato le relative tracce, che si possono riassumere in quanto segue (nell’immagine seguente sono riportate le 4 fasi principali relative al “normale” funzionamento del protocollo DHCP) :

dhcp1) Il client invia in broadcast un messaggio del tipo DHCPDISCOVER, alla ricerca dei server DHCP in ascolto sulla porta UDP 67:

15:03:00.463759 IP (tos 0x0, ttl 128, id 29956, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 74:e6:e2:0e:3d:a0 (oui Unknown), length 300, xid 0x24dc5170, Flags [none]
          Client-Ethernet-Address 74:e6:e2:0e:3d:a0 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 7: ether 74:e6:e2:0e:3d:a0
            Hostname Option 12, length 10: "ClientPC"
            Vendor-Class Option 60, length 8: "MSFT 5.0"
            Parameter-Request Option 55, length 13:
              Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server

2) Al suddetto messaggio fa seguito un DHCPOFFER, inviato dal server al client (unicast), il quale contiene tutta una serie di informazioni, come l’indirizzo IP che intende assegnare al dispositivo che lo ha appena contattato:

15:03:00.470460 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 332)
    dhcpserver.domain.local.bootps > 192.168.18.203.bootpc: BOOTP/DHCP, Reply, length 304, xid 0x24dc5170, Flags [none]
          Your-IP 192.168.18.203
          Client-Ethernet-Address 74:e6:e2:0e:3d:a0 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: dhcpserver.domain.local

3) Il client risponde al server accettando l’Indirizzo IP e gli altri parametri di rete che gli sono stati proposti, utilizzando un apposito messaggio denominato DHCPREQUEST (in broadcast):

15:03:00.473016 IP (tos 0x0, ttl 128, id 29957, offset 0, flags [none], proto UDP (17), length 345)
 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 74:e6:e2:0e:3d:a0 (oui Unknown), length 317, xid 0x24dc5170, Flags [none]
 Client-Ethernet-Address 74:e6:e2:0e:3d:a0 (oui Unknown)
 Vendor-rfc1048 Extensions
 Magic Cookie 0x63825363
 DHCP-Message Option 53, length 1: Request
 Client-ID Option 61, length 7: ether 74:e6:e2:0e:3d:a0
 Requested-IP Option 50, length 4: 192.168.18.203
 Server-ID Option 54, length 4: dhcpserver.domain.local
 Hostname Option 12, length 10: "ClientPC"
 FQDN Option 81, length 13: "ClientPC"

4) Infine, il server, mediante un DHCPNAK (in broadcast), declina la suddetta richiesta inoltratagli dal client:

15:03:00.477422 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 278)    dhcpserver.domain.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 250, xid 0x24dc5170, Flags [none]
          Client-Ethernet-Address 74:e6:e2:0e:3d:a0 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: NACK
            Server-ID Option 54, length 4: dhcpserver.domain.local

Il malfunzionamento è proprio questo, ovvero il server continuerà a rispondere con dei DHCPNAK (anzichè i DHCPACK), inibendo l’ottenimento dei parametri di rete a tutti i client.

Ho risolto “migrando” il server DHCP dal router al Domain Controller.

Per ulteriori info sui messaggi DHCP potete consultare questa pagina.

Alla prossima.

PS: tale bug sembra essere strettamente correlato alla versione del firmware (4.2.3.03-tm), infatti con la versione immediatamente precedente (4.2.2.08) non ho mai riscontrato malfunzionamenti in tal senso.