Woher wissen DHCP-Clients, welche von mehreren DHCPOFFERS akzeptiert werden sollen?

2802
Michael Niemand

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 je einem DHCP-Server aufgeteilt werden. Die DHCP-Server haben feste IP-Adressen, daher wissen sie offensichtlich, zu welchem ​​Teilnetz sie gehören.

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

DHCP situation

16
Vergleichen Sie [diese Frage] (https://superuser.com/q/1287263/432690) und antworten Sie dort. Kamil Maciorowski vor 6 Jahren 0
Hier ist eine weitere [verwandte Frage] (https://superuser.com/q/1367891/326546). kasperd vor 6 Jahren 0
"Ethernet Broadcast 255.255.255.255" - Dies ist die IP-Broadcast-Adresse für das lokale Netzwerk und keine Ethernet-Adresse. Die ersten DHCP-DISCOVER-Meldungen verwenden wahrscheinlich auch die Ethernet-Broadcast-Adresse ff: ff: ff: ff: ff: ff, aber das ist wirklich nicht dasselbe. ilkkachu vor 6 Jahren 1

2 Antworten auf die Frage

26
Fazer87

Einfachste Antwort - Wer zuerst kommt, mahlt zuerst.

Wenn Sie über mehrere VLANs verfügten und sich 10.10.10.0/24 in einem anderen VLAN als 10.10.20.0/24 befand, würde die Übertragung die VLANs nicht überqueren.

Wenn sich der DHCP-Server in einem separaten VLAN für die Clients befand, würde ein iphelper in der Routingschnittstelle zwischen vlans den Broadcast an den richtigen Speicherort leiten.

In Ihrem Szenario, in dem Sie zwei separate Netzwerke innerhalb desselben VLANs haben (oder nicht vorhanden sind), die verschiedene Subnetze versorgen - ist dies ein Rennen.

DHCP Served mit den folgenden Transaktionen:

  1. DHCP Discovery (DHCPDISCOVER) - Client Broadcast - "Gibt es dort einen DHCP-Server?"
  2. DHCP-Angebot (DHCPOFFER) - Server an Client - "Ja, ich bin hier und verfügbar!"
  3. DHCP Request (DHCPREQUEST) - Client an Server "Super, kann ich eine Adresse haben?"
  4. DHCP-Bestätigung (DHCPACK) - Server an Client "Sicher, hier sind eine IP-Adresse, eine Maske, ein Gateway, einige DNS / WINS-Server, ein Zeitserver und alles andere, das für Ihren Bereich konfiguriert ist"

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

Sobald Schritt 2 erreicht ist, hört der Client auf, auf die Antworten anderer DHCP-Server zu "hören". Er freut sich, wenn er sich mit dem ersten Server beschäftigt, um ihn aufmerksam zu machen.

Als Randbemerkung gibt es tatsächlich eine bekannte Serie von DoS-Angriffen (Denial of Service), die dieses Recht missbrauchen. Ein Angreifer steckt ein Gerät ein, das antwortet, sendet DHCPOFFER-Pakete aus und sendet DHCPACK nicht aus, wenn er gefragt wird ... immer und immer wieder. Es gibt auch einen anderen DoS-Angriff, bei dem "gefälschte" DHCP-Server Adressen anbieten, die nicht geroutet werden können, oder die mit anderen IPs in Konflikt stehen, die mit Netzwerken in Verlegenheit geraten.

Und deshalb die kurze Antwort auf "Wie führe ich dann mehrere Subnetze in einem einzigen Layer-2-Segment aus?" ist "** Sie tun nicht. **" (Ja, es gibt Möglichkeiten, aber das ist etwas, was Sie normalerweise nicht tun sollten. Eine Layer-2-Domäne = ein Subnetz.) grawity vor 6 Jahren 16
Danke, Leute, die haben wirklich bei mir geklickt. Ich habe mich immer gefragt, wie das möglich wäre, aber es ist einfach nicht so. Der Weg zum Mitnehmen ist also: Haben Sie einen Router / Layer 3-Switch zwischen Subnetzen oder Segmenten mit VLANs, habe ich Recht? Michael Niemand vor 6 Jahren 0
Im Allgemeinen, ja, Sie benötigen entweder VLANs oder eine physische Segmentierung. Die Freigabe einer L2-Domäne wäre nur * durchführbar *, wenn sich beide DHCP-Server auf die Verarbeitung "bekannter" Clients beschränken (z. B. nach Liste der "statischen Leases" mit zulässigen MAC-Adressen). grawity vor 6 Jahren 4
Ich denke, Sie könnten jedem DHCP-Server eine Whitelist mit MAC-Adressen geben und steuern, welcher Client auf diese Weise eine Adresse von welchem ​​Server erhält. Darren vor 6 Jahren 3
@ grawity, Sie können problemlos mehrere IP-Subnetze in demselben Layer-2-Segment ausführen, wenn die Subnetze gleich sind und es egal ist, welcher Client eine Adresse von welchem ​​Subnetz erhält. Sie haben nur einen DHCP-Server, der Adressen aus beiden Blöcken angibt, und einen Router, der für beide Blöcke als Gateway fungiert (mit jeweils einer Adresse). Erledigt. Zu sagen "nur nicht" ist eindeutig falsch. ilkkachu vor 6 Jahren 0
Wie [die Antwort von Oddthinking] (https://superuser.com/a/1370324/600133) besagt, kann der Client mehrere DHCPOFFERs gut abhören, bevor er sich entscheidet, was er tun soll. Es gibt nichts, was es zwingt, beim ersten Anhalten anzuhalten. Ich nehme an, Sie wollten die Vereinfachung basierend auf den gängigsten Implementierungen durchführen, aber wenn Sie das tun, geben Sie zumindest an, was Ihre Annahmen sind. ilkkachu vor 6 Jahren 0
@ilkkachu: Ja, ich mache das in meinem eigenen Netzwerk. Ich habe es mit einem DHCP-Server gemacht und mit zwei. Es ist immer noch nichts, was Sie tun sollten. grawity vor 6 Jahren 0
@grawity, ich sehe immer noch nicht Ihre Argumente, warum man es überhaupt "nicht" tun sollte. ilkkachu vor 6 Jahren 0
9
Oddthinking

Die vorhandene Antwort von @ Fazer87 ist in der Praxis weitgehend korrekt und ich empfehle, sie zu bestätigen und zu akzeptieren. Diese Antwort untersucht ein kleineres Detail etwas genauer.

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

Ein DHCP-Client kann sie auf der Grundlage "first come, first served" akzeptieren. Dies ist jedoch nicht erforderlich.

RFC2131 spezifiziert:

Der Client empfängt eine oder mehrere DHCPOFFER-Nachrichten von einem oder mehreren Servern. Der Client kann auf mehrere Antworten warten. Der Client wählt einen Server aus, von dem Konfigurationsparameter angefordert werden sollen, basierend auf den in den DHCPOFFER-Meldungen angebotenen Konfigurationsparametern.

Wenn also der zweite DHCP-Server eine längere IP-Adressreservierung anbietet oder einen Zeitserver anbietet, auf dem der andere nicht oder möglicherweise ein benutzerdefiniertes Feld hatte, das der Client so programmiert hat, dass er bevorzugt wird, akzeptiert er möglicherweise das zweite Angebot.

In der Regel erhalten Sie bei einem "first come, first served" -Ansatz ein Angebot, das noch nicht mehrere Hops (BOOTP rebroadcasts) durchlaufen hat. Daher ist es ein gutes Protokoll, wenn Sie keinen Grund zur Sorge haben.

Ich war an einem Projekt, bei dem ein benutzerdefiniertes Gerät einen DHCPOffer vorziehen würde, der einen TFTP-Server enthielt, auf dem aktualisierte Firmware gefunden werden konnte.

... oder wenn ein Server eine Adresse anbot, die der Client bereits zuvor verwendet hatte und behalten wollte ilkkachu vor 6 Jahren 0
@ilkkachu: Ja, theoretisch, aber es gibt bessere Mechanismen dafür (sowohl das Erneuern einer Reservierung vor dem Ablauf mit dem alten DHCP-Server als auch das Senden eines DHCPDiscovery, bei dem die alte IP-Adresse angefordert wird), so dass es in der Praxis unwahrscheinlich ist. Oddthinking vor 6 Jahren 0

Verwandte Probleme