Cosa considera un client DHCP la risposta "migliore"?

Abbiamo sale di formazione in cui è installato normalmente Windows XP (tramite PXE). La "normale" infrastruttura DNS / DHCP sono server Windows. La sala di formazione ha una propria VLAN (diversa dai server Windows), quindi è più probabile un supporto IP per le richieste DHCP attive sul router Cisco a cui sono collegati tutti i PC di quella stanza.

Ora volevamo invece convertire alcuni dei PC in Linux. L'idea era: metti il ​​nostro laptop con un server DHCP nella VLAN della stanza e ignora la risposta DHCP "normale". L'idea era che ciò avrebbe funzionato, dal momento che un server DHCP direttamente collegato in quella VLAN dovrebbe avere un tempo di risposta più veloce rispetto al "normale" server DHCP che si trova ad alcuni passi da quella VLAN.

Si è scoperto che questo non ha funzionato. Abbiamo dovuto rilasciare manualmente il contratto di locazione sul server DHCP originale per farlo funzionare.

Sul portatile abbiamo visto il client che richiedeva l'IP e il "nostro" dhcp stava inviando NACK alla richiesta IP di Windows, prima che offrissimo la nostra risposta.

Vecchia domanda: perché questo non ha funzionato come previsto? Cosa sta facendo recuperare al PC il vecchio contratto di locazione?

Aggiornamento 08-08-2012:

Il problema di riconquista è stato spiegato nel DHCP-RFC. Ora questo spiega perché il PC riacquista il suo vecchio contratto di locazione.

Ora rilasciamo l'IP dal server DHCP di Windows prima di riprovare.

Ancora una volta: il server DHCP di Windows vince.

Ho il sospetto che esista un algoritmo per il client dhcp che determina la "migliore" risposta dhcp per il client. La nuova domanda è:

In che modo il cliente sceglie la risposta "migliore"?

È il fornitore, anche specifico del firmware, come reagisce un client a più risposte DHCP.

Le varianti che ho visto negli anni sono:

1) Accetta il primo indipendentemente dal fatto che sia un ACK o un NACK.

2) Prendi il primo ACK, ignora completamente NACK.

3) Prendi l'ultimo ACK ricevuto entro un determinato intervallo di tempo (di solito 5-10 secondi).

Esempio: alcuni anni fa abbiamo riscontrato problemi con la stampante multifunzione Ricoh.
Avevamo 2 server DHCP. Uno ha fornito gli indirizzi, l'altro solo opzioni DHCP aggiuntive. Il 2 ° server ha sempre risposto per primo.
La variante utilizzata da Ricoh 1) anche se la prima offerta conteneva solo opzioni DHCP. Ricoh l'ha cambiato nella variante 2) con un aggiornamento del firmware dopo aver spiegato loro il problema.

Supponendo che il router stia ancora fungendo da inoltro DHCP e inoltri la richiesta al server originale, la ragione per cui lo ha fatto è semplicemente perché quel server DHCP di Windows gli ha detto di andare avanti e utilizzare l'IP. In questo caso, DHCPNACK dal nuovo server è irrilevante, poiché un client DHCP prenderà in considerazione tutte le risposte e, poiché ha ricevuto un'offerta dalla casella DHCP di Windows, è perfettamente felice di usarlo.

PC: Oh ciao mondo, posso usare 192.168.1.123?

Nuovo DHCP: dico di no.

Vecchio DHCP: dico di sì.

PC: Qualcuno ha detto di sì! Dolce, lo userò!

Se non altro aiuta - RTFM (leggi il manuale). In questo caso il primo è stato il successo.

RFC 2131 delinea le operazioni DHCP.

La sezione 1.6 afferma che DHCP deve :

Mantieni la configurazione del client DHCP al riavvio del server e, quando possibile, a un client DHCP dovrebbero essere assegnati gli stessi parametri di configurazione nonostante il riavvio del meccanismo DHCP,

Ora la domanda interessante è come questo obiettivo di design viene raggiunto su un cliente che non ha conoscenza del suo passato. Sezione 3.2 delinea:

3.2 Interazione client-server - riutilizzo di un indirizzo di rete precedentemente assegnato

Se un client ricorda e desidera riutilizzare un
indirizzo di rete precedentemente assegnato , un client può scegliere di omettere alcuni dei passaggi
descritti nella sezione precedente. Il diagramma temporale nella figura 4
mostra le relazioni di temporizzazione in una tipica interazione client-server per un client che riutilizza un indirizzo di rete precedentemente assegnato.

1. Il client trasmette un messaggio DHCPREQUEST sulla sua sottorete locale. Il messaggio include l'indirizzo di rete del client nell'opzione "indirizzo IP richiesto". Poiché il client non ha ricevuto il suo indirizzo di rete, NON DEVE compilare il campo 'ciaddr'. Gli agenti di inoltro BOOTP trasmettono il messaggio ai server DHCP non sulla stessa sottorete. Se il client ha utilizzato un "identificativo client" per ottenere il proprio indirizzo, il client DEVE utilizzare lo stesso "identificativo client" nel messaggio DHCPREQUEST.

2. I server con conoscenza dei parametri di configurazione del client rispondono con un messaggio DHCPACK al client. I server NON DOVREBBERO verificare che l'indirizzo di rete del client sia già in uso; il client può rispondere ai messaggi di richiesta echo ICMP a questo punto.

Quindi un server DHCP con un contratto di locazione attivo ha la precedenza usando un collegamento nel protcol.

1. Cliente: DHCREQUEST (indirizzo MAC, broadcast, verrà trasmesso nel dominio di trasmissione locale - qui la VLAN locale e tramite IP-helper al server DHCP di Windows)
2. Server DHCP-portatile: DHCPOFFER
3. Windows-DHCP-Server: Ehi, ti conosco già, DHCPACK
4. Cliente: Oh - Ho ricevuto due risposte. Uno che già mi conosce. Bene, lo prenderò

Da quel momento in poi il Laptop-DHCP-Server viene ignorato dal Client.

Quindi la soluzione nel nostro caso sarà probabilmente (lo aggiornerò quando lo testeremo effettivamente):

1. Assicurarsi che il client sia spento
2. Disattiva DHCP-Server su Laptop, falso Client-MAC su Laptop, DHCP-Request
3. Rilascio IP
4. Ripristina IP e MAC originali, attiva DHCP-Server
5. Accendi il client ed esegui un avvio PXE ...

La nuova domanda dovrebbe probabilmente trovarsi in una domanda diversa: il titolo della domanda non si adatta affatto alla maggior parte del corpo della domanda.

In ogni caso, per quanto riguarda il modo in cui un client sceglie quale offerta scegliere, nel caso in cui non abbia un contratto di locazione corrente: dipende dal client, ma in ogni implementazione client DHCP di cui sono a conoscenza, è una corsa semplice .

RFC 2131 copre questo:

I client DHCP sono liberi di utilizzare qualsiasi strategia nella selezione di un server DHCP tra quelli da cui il client riceve un messaggio DHCPOFFER.

Esiste una bozza IETF che sembra morta che avrebbe aggiunto la configurabilità al processo di selezione e menziona anche le implementazioni client poco brillanti (di oltre un decennio fa, ma non è cambiato molto):

In pratica, l'implementazione della politica della maggior parte dei fornitori qui è molto semplice (es. Prima offerta ricevuta o prima offerta accettabile ricevuta) ed è "hard-coded" (cioè non configurabile).

Avere due server DHCP che forniscono servizi alla stessa rete con una configurazione diversa porta solo a gare, il che non è desiderabile dal punto di vista dell'affidabilità o della prevedibilità. Non c'è davvero alcun motivo per cui non è possibile ottenere il tuo singolo server DHCP per fornire ciò di cui hai bisogno.