Come fanno i client DHCP a sapere quali tra più DHCPOFFER accettare?

Immagina di avere una rete come nella foto. Sei host su una rete di livello 2, senza VLAN. La rete dovrebbe essere segmentata in due sottoreti, ciascuna con un server DHCP. I server DHCP hanno indirizzi IP fissi, quindi sanno a quale sottorete appartengono, ovviamente.

Quindi vengono collegati nuovi client. Non sanno nulla in quale sottorete dovrebbero essere e inviano il loro DHCPDISCOVER alla trasmissione Ethernet 255.255.255.255, quindi va a entrambi i server DHCP. Entrambi i server rispondono con un'offerta. Ora ecco la mia domanda: come fa il cliente a sapere quale DHCPOFFER dovrebbe accettare?

networking dhcp

— Michael Niemand
fonte

Confronta questa domanda e le risposte lì.

— Kamil Maciorowski il

Ecco un'altra domanda correlata .

— Kasperd,

"the ethernet broadcast 255.255.255.255" - Questo è l'indirizzo di trasmissione IP per la rete locale, non un indirizzo Ethernet. È molto probabile che anche i messaggi iniziali DHCP DISCOVER utilizzino l'indirizzo di trasmissione Ethernet ff: ff: ff: ff: ff: ff, ma quelli in realtà non sono la stessa cosa.

— ilkkachu,

Risposte:

Risposta più semplice: primo arrivato, primo servito.

Se avessi più VLAN e 10.10.10.0/24 si trovasse su una VLAN diversa da 10.10.20.0/24, la trasmissione non attraverserebbe VLAN.

Se il server DHCP si trovava su una VLAN separata per i client, un iphelper sull'interfaccia di routing tra i vlan dirigerebbe la trasmissione nella posizione corretta.

Nel tuo scenario in cui hai 2 reti separate all'interno della stessa VLAN (o la sua mancanza) che servono diverse sottoreti - è una corsa.

DHCP viene utilizzato utilizzando le seguenti transazioni:

Rilevamento DHCP (DHCPDISCOVER) - Trasmissione client - "Esiste un server DHCP?"
Offerta DHCP (DHCPOFFER) - Server to Client - "Sì, sono qui e disponibile!"
Richiesta DHCP (DHCPREQUEST) - Da client a server "Fantastico, posso avere un indirizzo per favore?"
Riconoscimento DHCP (DHCPACK) - Server a client "Certo, ecco un IP, una maschera, un gateway, alcuni server DNS / WINS, un Time Server e tutte le altre cose configurate per il tuo ambito"

Tutto ciò accade sulle porte UDP 67 per il server e 68 per il client.

Non appena viene raggiunto il passaggio 2 - il client smetterà di "ascoltare" le risposte di altri server DHCP - è contento di avere a che fare con il primo server che gli presta attenzione.

Come nota a margine: in realtà esiste una serie ben nota di attacchi DoS (Denial of Service) che abusano di questo diritto. Un utente malintenzionato collega un dispositivo che risponde e invia pacchetti DHCPOFFER e quindi non invia DHCPACK quando richiesto ... ancora e ancora e ancora. C'è anche un altro attacco DoS in cui i server DHCP "falsi" offrono indirizzi che non possono essere instradati o che sono in conflitto con altri IP che si annusa per rovinare le reti.

— Fazer87
fonte

E quindi la risposta breve a "Ma come faccio a eseguire più subnet su un singolo segmento di livello 2?" è " Tu non fai. " (Sì, ci sono modi, ma non è qualcosa che si dovrebbe in genere fare un layer-2 domini = una sottorete..)

— user1686

Grazie ragazzi, questo mi ha davvero colpito. Mi sono sempre chiesto come sarebbe stato possibile, ma semplicemente non lo è. Quindi il take away è: avere un router / layer 3 commutare tra sottoreti o segmenti con VLAN, vero?

— Michael Niemand,

In generale, sì, sono necessarie VLAN o segmentazione fisica. La condivisione di un dominio L2 sarebbe fattibile solo se entrambi i server DHCP fossero limitati alla gestione di client "noti" (ad es. Mediante un elenco di "contratti di locazione statici" con indirizzi MAC consentiti).

— user1686

Penso che potresti dare a ciascun server DHCP una lista bianca di indirizzi MAC e controllare quale client ottiene un indirizzo da quale server in quel modo.

— Darren,

@grawity, puoi facilmente eseguire più subnet IP sullo stesso segmento di livello 2, se le subnet sono uguali e non ti interessa quale client ottiene un indirizzo da quale subnet. Hai solo un server DHCP che fornisce gli indirizzi da entrambi i blocchi e un router che funge da gateway per entrambi i blocchi (con un indirizzo in ciascuno). Fatto. Dire semplicemente "no" è semplicemente sbagliato.

— ilkkachu,

La risposta esistente di @ Fazer87 è sostanzialmente corretta nella pratica e raccomando di votarla e accettarla. Questa risposta esplora un dettaglio minore in modo un po 'più preciso.

Entrambi i server DHCP possono rispondere con un messaggio DHCPOffer.

Un client DHCP può accettarli in base al principio "primo arrivato, primo servizio". Tuttavia, non è necessario adottare questo approccio.

RFC2131 specifica:

Il client riceve uno o più messaggi DHCPOFFER da uno o più server. Il cliente può scegliere di attendere più risposte. Il client sceglie un server dal quale richiedere i parametri di configurazione, in base ai parametri di configurazione offerti nei messaggi DHCPOFFER.

Quindi, se il secondo server DHCP offriva una prenotazione dell'indirizzo IP più lunga o offriva un time-server in cui l'altro non lo faceva, o forse aveva un campo personalizzato che il client era stato programmato per preferire, poteva accettare la seconda offerta.

In genere, un approccio "primo arrivato, primo servito" ti procurerà l'offerta che non è passata attraverso diversi salti tra i dispositivi (ritrattamenti BOOTP), quindi è un buon protocollo da seguire se non hai motivo di preoccuparti.

Ero su un progetto in cui un dispositivo personalizzato avrebbe preferito un DHCPOffer che includeva un server TFTP in cui si trovava un firmware aggiornato.

— Oddthinking
fonte

... o se un server offrisse un indirizzo che il client aveva già usato prima e che voleva mantenere

— ilkkachu,

@ilkkachu: Sì, in teoria, ma ci sono meccanismi migliori per questo (sia rinnovare una prenotazione prima che scada con il vecchio server DHCP, sia inviare un DHCPDiscovery richiedendo il vecchio indirizzo IP), quindi è improbabile che sia utile in pratica.

— Pensando strano il