Hallo, Im Netz bin ich noch nicht so richtig fündig geworden, aber vielleicht kann mir hier einer den richtigen Weg zeigen. Folgende Situation: * 2 DHCP-Server im failover-Betrieb * DHCP-Client erhält IP-Konfiguration von DHCP1 (DISCOVER, REQUEST) * DHCP1 fällt aus (Unicast-REQUESTs werden nicht beantwortet) * DHCP2 springt ein und bestätigt auf ein Broadcast-DHCPREQUEST des Clients die IP-Konfiguration. Die Frage: An welchen Server muss der Client die nächte DHCPREQUEST-Unicast-Message schicken? An DHCP1, weil er derjenige war der sich beim ersten DISCOVER gemeldet hat und nun für diesen Client 'zuständig' ist oder an DHCP2, weil es der Server war, der die Konfiguration beim letzten REQUEST vergeben/bestätigt hat? Gibt es dazu irgendwo eine Spezifikation/Richtlinie oder kann das jeder machen wie er will? timpi.
Grundregel: wenn's nicht im zugehörigen RFC (oder STD) steht, ist
es nicht spezifiziert. ;-)
Ich würde das aber anders angehen: beide Server benutzen die gleiche
öffentlich sichtbare IP-Adresse (u. U. zusätzlich zu einer zweiten,
die jeder für sich hat). Über einen zweiten Link ("heartbeat")
tauschen sie sich regelmäßig den Systemzustand aus. Fällt der
heartbeat aus, dann übernimmt derjenige, der den Ausfall des
anderen feststellt, die öffentliche IP-Adresse. Damit die Clients
die damit im Zusammenhang stehende Änderung der MAC-Adresse
möglichst schnell bemerken, versendet er zusätzlich noch ein
`gratuitous ARP'.
Natürlich sollte der Statusaustausch über den Heartbeat auch und
insbesondere den aktuellen Stand der DHCP-Datenbank beinhalten, damit
der übernehmende Server im Zweifelsfalle exakt im Bilde ist, welche
Leases gerade aktiv an wen vergeben worden sind.
Ein klassischer Ansatz für redundantes DHCP sind zwei völlig voneinander unabhängige gleichzeitig aktive DHCP-Server mit getrennten IP-Ranges, also beispielsweise 192.168.177.1-100 und 192.168.177.101-200. Da muss nichts synchronisiert werden und Zuständigkeitsstreiteren gibts auch nicht. Das eignet sich natürlich weniger für explizite DHCP-Reservierungen, aber für den verbreiteteren Fall austauschbarer Adressen ist das ziemlich simpel. In gerouteten Netzen mit zentralem DHCP müssen die Router dafür in der Lage sein, mehrere Helper-Adressen einzurichten.
Danke erst einmal. Die Infrastruktur ist 'gottgegeben', unterzieht sich derzeit einem Wandel und dessen Wege sind unergründlich ;-). Und Einfluss habe ich nicht darauf. Ich möchte nur vermeiden, dass die derzeitige Lösung später nochmal Probleme bereitet und ich das Ganze anpassen muss. timpi.
oder einfach 2 windows-Server, die in einem AD sind, verwenden. Damit haben beide Server die gleiche Datenbank weil die dhcp daten mit ins AD repliziert werden.
Peter II schrieb: > oder einfach 2 windows-Server, die in einem AD sind, verwenden. Damit > haben beide Server die gleiche Datenbank weil die dhcp daten mit ins AD > repliziert werden. Welche Windows Server Version macht das? Ich kenne nur DNS AD Integriert.
> Ein klassischer Ansatz für redundantes DHCP sind zwei völlig voneinander > unabhängige gleichzeitig aktive DHCP-Server mit getrennten IP-Ranges, > also beispielsweise 192.168.177.1-100 und 192.168.177.101-200. Da muss > nichts synchronisiert werden und Zuständigkeitsstreiteren gibts auch > nicht. Nach meinem Verständnis ist das eine "dumme Idee": 1. Client sendet Broadcast 2. beide DHCPs antworten 3. Antwort von DHCP1 trifft aber ein paar us eher ein. 4. Client bekommt die IP 192.168.177.1 nach ein paar Minuten versucht er die Lease zu erneurn, diesmal kommt die Antwort von DHCP2 erster an. Client wechselt die IP auf 192.168.177.101 Oder hab ich da wo einen Denkfehler? Gruß Roland
Roland Praml schrieb: > nach ein paar Minuten versucht er die Lease zu erneurn, > die Antwort von DHCP2 erster an. Client wechselt die IP auf > 192.168.177.101 Nein, denn diese Wiederauffrischung ist kein Broadcast, sondern wird an den DHCP-Server adressiert, der die Adresse vergeben hatte. So lange der darauf reagiert gibt es keine neue Adresse. Eine neue Adresse gibt es erst, wenn dieser Server mit Ablauf der Gültigkeit nicht erreicht werden konnte. Und das ist dann ja auch der Sinn der Sache. NB: Diese Prozedur ist bereits in der Thread-Frage selbst beschrieben.
Stefan L. schrieb: > Die Frage: An welchen Server muss der Client die nächte > DHCPREQUEST-Unicast-Message schicken? Die englische Wikipedia erwähnt dieses Thema (rebinding) und verweist ansonsten auf: https://tools.ietf.org/html/draft-ietf-dhc-failover-12
A. K. schrieb: > Roland Praml schrieb: > >> nach ein paar Minuten versucht er die Lease zu erneurn, >> die Antwort von DHCP2 erster an. Client wechselt die IP auf >> 192.168.177.101 > > Nein, denn diese Wiederauffrischung ist kein Broadcast, sondern wird an > den DHCP-Server adressiert, der die Adresse vergeben hatte. So lange der > darauf reagiert gibt es keine neue Adresse. > Naja, nicht ganz. Die ersten REQUESTs (nach ½ lease time) sind Unicasts an den bekannten DHCP-Server. Antwortet der nicht, so werden (nach 87,5% lease-time) Broadcast-REQUESTs geschickt und in meinem Fall antwortet der zweite Server (der eine Kopie der leases des ersten Servers besitzt) darauf mit den passenden Parametern. Werden unabhängige IP-Bereiche benutzt, dann erhält der Client bei seinem Broadcast vom zweiten Server ein DHCPNAK, fällt zurück in den INIT-Status (Dekonfigurieren des Interfaces) und der komplette DHCP-Prozess beginnt von vorn. Sämtliche Dienste, die auf diesem Interface arbeiten (bzw, die IP des Interfaces zum Arbeiten benötigen), müssten beendet und nach Adressvergabe neu gestartet werden. > Die englische Wikipedia erwähnt dieses Thema (rebinding) und verweist > ansonsten auf: https://tools.ietf.org/html/draft-ietf-dhc-failover-12 Die RFC2131 ist da schon recht ausführlich, nur in diesem einen Punkt nicht. Und in der erwähnten Draft habe ich nichts über das Client-Verhalten in diesem Fall gefunden. Die bezieht sich mehr auf die Kommunikation zwischen den DHCP-Servern. timpi.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.