Woher wissen DHCP-Clients, welche der mehreren DHCP-ANGEBOTE akzeptiert werden sollen?

Stellen Sie sich vor, wir haben ein Netzwerk wie auf dem Bild. Sechs Hosts in einem Layer 2-Netzwerk, keine VLANs. Das Netzwerk soll in zwei Subnetze mit jeweils einem DHCP-Server unterteilt werden. Die DHCP-Server haben feste IP-Adressen, sodass sie offensichtlich wissen, zu welchem Subnetz sie gehören.

Dann werden neue Clients angeschlossen. Sie wissen nichts darüber, in welchem Subnetz sie sich befinden sollen, und senden ihren DHCPDISCOVER an den Ethernet- Broadcast 255.255.255.255, sodass er an beide DHCP-Server gesendet wird. Beide Server antworten mit einem Angebot. Hier ist meine Frage: Woher weiß der Client, welches DHCPOFFER er akzeptieren soll?

networking dhcp

— Michael Niemand
quelle

Vergleichen Sie diese Frage und Antworten dort.

— Kamil Maciorowski

Hier ist eine andere verwandte Frage .

— Kasperd

"the ethernet broadcast 255.255.255.255" - Dies ist die IP-Broadcast-Adresse für das lokale Netzwerk, keine Ethernet-Adresse. Die anfänglichen DHCP DISCOVER-Nachrichten verwenden sehr wahrscheinlich auch die Ethernet-Broadcast-Adresse ff: ff: ff: ff: ff: ff, aber das ist nicht dasselbe.

— Ilkkachu

Antworten:

Einfachste Antwort - Wer zuerst kommt, mahlt zuerst.

Wenn Sie mehrere VLANs hatten und 10.10.10.0/24 in einem anderen VLAN als 10.10.20.0/24 war, würde die Übertragung nicht die VLANs kreuzen.

Wenn sich der DHCP-Server in einem von den Clients getrennten VLAN befindet, leitet ein Iphelper auf der Routing-Schnittstelle zwischen vlans die Übertragung an den richtigen Ort.

In Ihrem Szenario, in dem Sie zwei separate Netzwerke innerhalb desselben VLANs (oder eines fehlenden) haben, die unterschiedliche Subnetze bedienen, ist dies ein Rennen.

DHCP wird mit den folgenden Transaktionen ausgeführt:

DHCP Discovery (DHCPDISCOVER) - Client Broadcast - "Gibt es einen DHCP-Server?"
DHCP-Angebot (DHCPOFFER) - Server an Client - "Ja, ich bin hier und verfügbar!"
DHCP Request (DHCPREQUEST) - Client an Server "Super, kann ich bitte eine Adresse haben?"
DHCP-Bestätigung (DHCPACK) - Server an Client "Sicher, hier sind eine IP, eine Maske, ein Gateway, einige DNS / WINS-Server, ein Zeitserver und alle anderen für Ihren Bereich konfigurierten Informationen."

All dies geschieht auf den UDP-Ports 67 für den Server und 68 für den Client.

Sobald Schritt 2 erreicht ist, hört der Client auf, die Antworten anderer DHCP-Server zu "lauschen". Er freut sich, wenn er sich mit dem ersten Server befasst, der ihm etwas Aufmerksamkeit schenkt.

Als Randnotiz - es gibt tatsächlich eine bekannte Reihe von DoS-Angriffen (Denial of Service), die dieses Recht missbrauchen. Ein Angreifer steckt ein Gerät ein, das antwortet und DHCPOFFER-Pakete sendet und DHCPACK dann nicht sendet, wenn er gefragt wird ... immer und immer und immer wieder. Es gibt auch eine andere DoS-Attacke, bei der "gefälschte" DHCP-Server Adressen anbieten, die nicht geroutet werden können oder die mit anderen IP-Adressen in Konflikt stehen, die es schnüffelt, um mit Netzwerken in Konflikt zu kommen.

— Fazer87
quelle

Und daher die kurze Antwort auf "Aber wie kann ich dann mehrere Subnetze in einem einzelnen Layer-2-Segment ausführen?" ist " Sie nicht. " (Ja, es gibt Möglichkeiten, aber es ist nicht etwas, das Sie im Allgemeinen tun sollten. Eine Layer-2-Domain = ein Subnetz.)

— Grawity

Danke Jungs, das hat mich wirklich beeindruckt. Ich habe mich immer gefragt, wie das möglich ist, aber das ist es einfach nicht. Zum Mitnehmen: Hat ein Router / Layer 3-Switch zwischen Subnetzen oder Segmenten mit VLANs recht?

— Michael Niemand

Ja, im Allgemeinen benötigen Sie entweder VLANs oder eine physische Segmentierung. Die gemeinsame Nutzung einer L2-Domäne wäre nur möglich, wenn beide DHCP-Server auf die Verarbeitung "bekannter" Clients beschränkt wären (z. B. anhand einer Liste von "statischen Leases" mit zulässigen MAC-Adressen).

— Grawity

Ich denke, Sie könnten jedem DHCP-Server eine Whitelist mit MAC-Adressen geben und so steuern, welcher Client von welchem Server eine Adresse erhält.

— Darren

@grawity, Sie können problemlos mehrere IP-Subnetze in demselben Layer-2-Segment ausführen, wenn die Subnetze identisch sind, und es ist Ihnen egal, welcher Client eine Adresse von welchem Subnetz erhält. Sie haben nur einen DHCP-Server, der Adressen von beiden Blöcken angibt, und einen Router, der als Gateway für beide Blöcke fungiert (mit jeweils einer Adresse). Erledigt. Nur "du nicht" zu sagen ist einfach falsch.

— Ilkkachu

Die bisherige Antwort von @ Fazer87 ist in der Praxis im Großen und Ganzen richtig, und ich empfehle, sie zu unterstützen und zu akzeptieren. Diese Antwort untersucht ein kleines Detail etwas genauer.

Beide DHCP-Server antworten möglicherweise mit einer DHCPOffer-Nachricht.

Ein DHCP-Client akzeptiert sie möglicherweise nach dem Prinzip "Wer zuerst kommt, mahlt zuerst". Es ist jedoch nicht erforderlich, diesen Ansatz zu wählen.

RFC2131 spezifiziert:

Der Client empfängt eine oder mehrere DHCPOFFER-Nachrichten von einem oder mehreren Servern. Der Client kann sich dafür entscheiden, auf mehrere Antworten zu warten. Der Client wählt einen Server aus, von dem Konfigurationsparameter angefordert werden sollen, basierend auf den Konfigurationsparametern, die in den DHCPOFFER-Nachrichten angeboten werden.

Wenn also der zweite DHCP-Server eine längere IP-Adressreservierung anbietet oder einen Zeitserver anbietet, auf dem der andere keine IP-Adresse hat, oder möglicherweise ein benutzerdefiniertes Feld hat, für das der Client den Vorzug gegeben hat, akzeptiert er möglicherweise das zweite Angebot.

In der Regel erhalten Sie bei einem "Wer zuerst kommt, mahlt zuerst" -Ansatz das Angebot, das noch nicht über mehrere Geräte hinweg durchlaufen wurde (BOOTP-Re-Broadcasts). Es ist daher ein gutes Protokoll, das befolgt werden sollte, wenn Sie keinen Grund haben, sich darum zu kümmern.

Ich war an einem Projekt beteiligt, bei dem ein benutzerdefiniertes Gerät ein DHCPOffer bevorzugen würde, das einen TFTP-Server enthält, auf dem aktualisierte Firmware gefunden werden kann.

— Merkwürdig
quelle

... oder wenn ein Server eine Adresse anbot, die der Client bereits zuvor verwendet hatte und behalten wollte

— ilkkachu 26.10.18

@ilkkachu: Ja, theoretisch, aber es gibt bessere Mechanismen dafür (sowohl eine Reservierung zu erneuern, bevor sie mit dem alten DHCP-Server abläuft, als auch eine DHCPDiscovery zu senden, die die alte IP-Adresse anfordert), sodass dies in der Praxis wahrscheinlich nicht sinnvoll ist.

— Oddthinking