DHCP Hochverfügbar

Diese Seite beschreibt die verschiedenen Optionen, die Vergabe von IP-Adressen per DHCP "hochverfügbar" zu machen. Denn ohne IP-Adressen geht in einem LAN nichts und wer keine statischen Adressen pflegen will, wird um DHCP nicht herum kommen. Also müssen wir überlegen, was ein ungeplanter Ausfall aber auch eine geplante Wartung für die Funktion bedeutet und wie wir damit umgehen.

DHCP Server installieren

Die Einrichtung eines DHCP-Servers unter Windows ist schon seit vielen Jahren eine einfache Aufgabe:

  1. DHCP-Rolle addieren
    Die Rolle kann auf einem Member-Server oder Domain Controller installiert werden
  2. DHCP-Server "autorisieren
    Ein Server, der Active Directory Mitglied ist, stellt ein DHCP-Server seine Funktion nur bereit, wenn er von einem Administrator autorisiert wurde. Nur DHCP-Server auf einem Arbeitsgruppen-Server können DHCP ohne Autorisierung anbietet aber erkennen, wenn es schon einen anderen DHCP-Server gibt
  3. Scope einrichten
    In der einfachsten Variante richten Sie dann einen einfachen Scope ein und konfigurieren z.B. die Optionen für "Default Gateway", DNS-Server und DNS-Zone
  4. Optional DHCP-Relay und weitere Scopes
    Die benötigen Sie, wenn Sie mehrere VLANs mit entsprechend unterschiedlichen Subnetzen betreiben und ein Router die Pakete umsetzt. Die meisten Router können auch DHCP-Relay sein, d.h. empfangen die DHCP-Anfragen im jeweiligen Subnetz und leiten Sie mit Angabe des Subnetzes an den DHCP-Server weiter, der dann aus dem passenden Scope eine IP-Adresse anbietet.

Im Grund macht auch eine Fritz!Box zuhause nichts anderes. Sie verteilt IP-Adressen und weitere Informationen (Gateway, DNS-Server) per DHCP an die Clients. Wenn hier die Fritz!Box ausfällt, dann ist auch der Internet-Anschluss weg und im Homeoffice gibt es normal keine Hochverfügbarkeit.

In einem komplexen Firmennetzwerk ist dies aber keine Option und wenn der DHCP-Server nicht mehr antwortet, dann werden die bestehenden Clients zwar weiter funktionieren, so lange sie ihre IP-Adresse noch behalten dürfen aber neue Clients kommen nicht mehr ins Netzwerk.

Übrigens: Bei IPv6 braucht es nicht zwingend einen DHCP-Server. Der Client wartet einfach auf ein Paket eines Routers um das "Netzwerk" zu kennen und eine Host-Adresse kann er sich aus den 2^64 Varianten selbst bestimmen. DNS kann eine Multicast-Adresse sein.

Bei IPv4 gibt es aber solche ein "Auto Config"-Verfahren nicht und ohne DHCP-Angebot wird der Client vermutlich eine IP-Adresse aus dem besonderen Bereich 169.254.0.0/16 auswählen. Damit kommt er natürlich nicht weiter.

Leasedauer

Ein Client, der aber schon eine IPv4-Adresse per DHCP bekommen hat, weiß auch die Gültigkeitsdauer dieser "Leihe" und nutzt die Adresse bis zum Ablauf der Gültigkeit einfach immer weiter. er versucht natürlich die Adresse immer wieder zu verlängern aber einige Zeit kann er sich damit schon über Wasser halten. Damit stellt sich natürlich auch die Frage nach der passenden "Lease-Dauer". Je länger die Lease-Dauer ist, desto weniger Clients werden bei einem längeren Ausfall des DHCP-Servers davon betroffen sein. Genau genommen merken nur die Clients den Ausfall, bei denen die Lease-Dauer abgelaufen ist oder die neu eingeschaltet wurden und eine ganz neue Adresse beziehen müssen. Aber was ist nun dir richtige Dauer? Dazu schauen wir uns ein paar Aspekte an.

  • Knappe IP-Adressen
    Wenn Sie in einem Subnetz schon viele Clients haben und es immer wieder wechselnde Endgeräte gibt, dann ist eine kürzere Lease-Dauer interessant. So werden IP-Adressen wieder in den Pool als "Frei" zurückgegeben, wenn der Client
  • Pseudo-statisch
    Eine zu kurze Zeit kann aber auch bedeute, dass ein über Nacht ausgeschalteter Client am morgen wieder eine andere Adresse bekommt. Das kann eine Auswertung und Logs u.a. erschweren. Vielleicht möchten Sie schon, dass ein Client zumindest ein paar Tage, z.B. auch nach einem langen Osterwochenende die alte Adresse weiter nutzt. Dann wäre eine Lease-Dauer von vielleicht 8 Tage interessant, was zufällig auch der Windows 2012R2 Default ist.
  • DHCP-Last
    Wer eine Lease-Dauer von wenigen Minuten einstellt, zwingt die Clients zu sehr häufigen "Renew"-Pakete. Das wird einen normalen DHCP-Server nicht überlasten aber wenn der Server zum patchen nicht verfügbar ist, dann stört dies. Die minimale Dauer von Windows 2012R2 DHCP ist 1 Minute.
  • DHCP als Endpunkt-Datenbank
    Der DHCP-Server speichert sich die Zuordnung der per DHCP vergebenen Adressen anhand der MAC-Adresse des Client und der IP-Adresse. Je länger die Lease-Dauer ist, desto länger können Sie z.B. Anhand einer MAC-Adresse ein früheres Gerät identifizieren. Wobei ein DHCP-Server kein Netzwerkmanagement ersetzt, welches sich auch merkt, an welchen Switch-Ports welche MAC-Adressen gelernt wurden.
  • Statische Reservierungen
    Ein Sonderfall sind dauerhafte Reservierungen, die sie im DHCP-Server hinterlegen können. Damit bekommt ein Client mit einer MAC-Adresse immer wieder die gleiche Adresse. So können Sie mittels DHCP quasi "statische" Adressen auch an Server verteilen. Dann ist aber die Funktion von DHCP erst recht wichtig.

Bedenken Sie bei der Lease-Dauer auch die Intervalle, bei denen ein Client seine IP-Adresse erneuert.

Lease Beschreibung

0-50%

Keine Aktivität des Clients. Das bedeutet aber auch, dass eine Konfigurationsänderung so lange nicht vom Client übernommen wird.

50-87,5%

RENEW Client erbittet Verlängerung vom gleichen DHCP Server der bestehenden IP-Adrese.

87,5-100%

DISCOVER Client fragt per Broadcast nach beliebigen DHCP-Server, der ihm eine IP-Adresse anbietet aber nutzt seine Adresse weiter

100%+

Der Client hat keine IP-Adresse mehr und versucht als "0.0.0.0" weiter per DISCOVER eine IP-Adresse zu erhalten

Wenn also ein Lease z.B. 4 Tage gültig ist, dann macht der Client erst nach 2 Tagen die ersten RENEW-Versuche, am Tag 3 dann ein Discover und nach 4 Tagen arbeitet er nicht mehr. Bei einem DHCP-Ausfall nach 47h bedeutet dies, dass Sie immer noch bis zu 2 Tage "Restlaufzeit" des Clients haben. Die "Überlebenszeit" für bestehende Clients ist also nicht die Lease-Dauer sonder nur 50% davon. Neue Clients bekommen bei einem DHCP-Ausfalls natürlich keine neue Adressen und sind sofort betroffen.

Über verschiedene Subnetze und VLANs können Sie mit unterschiedlichen Werten für die Lease-Dauer die Verfügbarkeit unter Berücksichtigung der Freigabe anpassen, z.B.

Servernetz: sehr lange Leasedauer von mehreren Tagen oder Wochen, kombiniert mit Reservierungen
ClientNetz: mehrere Tage
Gäste-WLGäste-WLAN: z.B. 1 Tag, damit die Adresse nicht lange belegt wird

Windows DHCP schlägt eine Lease-Dauer von 8 Tagen vor, was für die meisten Firmen auch passen sollte. Wer bis zu 4 Tage keine IP-Adressen per DHCP verteilen kann, sollte sein Betriebskonzept überprüfen.

DHCP vergibt ja nicht nur IP-Adressen, sondern kann auch umfangreiche Konfigurationsdaten verteilen, z.B. Provisioning-Informationen für Telefone u.a. DHCP ist also schon wichtig und ein Single Server ist für eine Firma vielleicht zu wenig. Wenn sie keinen "Small Business Server" betreiben, dann haben Sie ja meist auch zwei oder mehr Domain Controller und zwei DNS-Server. Größere Firmen haben im Netzwerk dann auch zwei Router, die sich die Arbeit "IP-Routing" aber auch "DHCP-Relay" teilen können etc.

Rogue Server

Ohne weitere Konfiguration kann quasi jeder Mitarbeiter einfach einen Router oder Client an einem Switch anschließen. Nur mit 802.1x und eingeschränkt per MAC-Adressen können Sie solche fremden Geräte den Zugang erschweren. Wenn Sie aber einmal im LAN sind, dann können Sie sich nicht nur per DHCP eine IP-Adresse besorgen, sondern sogar selbst DHCP-Server spielen. Sie glauben gar nicht, wie oft Mitarbeiter bei Kunden z.B. einem LTE-Router einfach mal angeschlossen haben oder einen eigenen WLAN-AccessPoint aufbauen wollten, der dann IP-Adressen im LAN angeboten hat.

Im Nachhinein können Sie die Fehler relativ schnell finden, da Sie auf einem Client mit einer falschen IP-Adresse per "IPCONFIG /ALL" zuerst die abweichende IP-Adresse erkennen und über die IP-Adresse des DHCP-Servers auch dessen MAC-Adresse und darüber dann wieder den Switch-Port ermitteln können. Das dauert aber Zeit und erfordert entsprechende Kenntnisse und Zugänge. Da ist es besser, die DHCP-Server-Funktion auf den Switchports komplett zu unterbinden. Ein besserer Switch kann z.B. ein DHCPOFFER anhand des Paketinhalts erkennen und solche Paket von einem Client-Port abblocken. Ein Client darf dann nur noch ein DHCPDISCOVER und ein DHCPREQUEST senden.

Diese Funktion wird häufig "DHCP Snooping" genannt.

Eine solche Konfiguration gehört aber auch zum zuverlässigen Betrieb einer DHCP-Umgebung.

Sollten Sie eine Umgebung ohne Active Directory nutzen, dann können Sie dennoch zwei Windows DHCP Server betreiben. Sie sollten dann aber sicherstellen, dass die Rogue-Erkennung deaktiviert ist.

Das geht über einen Eintrag in der Registrierung des DHCP-Servers:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters]
"DisableRogueDetection"=dowrd:00000001

Achtung:
Damit entfernen Sie wissentlich die Schutzfunktion des DHCP-Servers, in einer Umgebung mit einem AD-Forest nur dann aktiv zu werden, wenn er autorisiert ist.

DHCP und Dubletten

Sie können aber nicht einfach mal so zwei DHCP-Server installieren, denn schon bei der Konfiguration der Scopes sollten Sie sich die Frage stellen, welcher Server denn nun welche IP-Adressen verteilt, ob sich die Server die Arbeit wirklich beide aktiv teilen können oder sie vielleicht eher einen Aktiv/Passiv-Betrieb konfigurieren. Auf jeden Fall müssen Sie verhindern, dass ein DHCP-Server eine IP-Adresse anbietet, die schon ein anderer Client vom anderen DHCP-Server bekommen hat. Schon das DHCP-Protokoll ist aber darauf eingerichtet und jede DHCP-Zuweisung besteht aus vier Paketen

  1. DHCPDISCOVER Client -> Broadcast
    Der Client hat noch keine IP-Adresse und sendet mit der IP-Adresse 0.0.0.0 und seiner MAC-Adresse einen MAC-Level Broadcast (FF:FF:FF:FF:FF:FF:FF) ins Netzwerk, welcher von allen DHCP-Servern oder DHCP-Relay-Agenten im gleichen Subnetz gesehen wird. Der Relay-Agent leitet die Anfrage an einen DHCP-Server in einem anderen Subnetz dann weiter
  2. DHCPOFFER Server -> Client
    Der DHCP-Server wählt dann eine IP-Adresse aus und sendet sie direkt oder über den DHCP-Relay Agent an den Client.
  3. DHCPREQUEST
    Am Client können natürlich mehrere Angebot eingehen. Er wählt sich dann eines aus und fordert die Reservierung von diesem Server an. Die anderen Angebot kann er später immer noch ablehnen.
  4. DHCPACKNOWLEDGE
    Der Server bestätigt dem Client, dass er nun diese IP-Adresse und andere Daten hat.

Das funktioniert alles aber noch ohne IP-Adressen des Clients rein auf Layer 2. Erst nach Abschuss durch das DHCPACKNOWLEDGE hat der Client die IP-Adresse.

Diese vier Pakete stellen aber noch nicht sicher, dass es keine Dubletten gibt. Und hier gibt es unterschiedliche Aspekte. Windows Server und Client haben drei Optionen, um solche Doppelungen zu vermeiden.

  • Antwort-Delay
    Sie können beim DHCP-Server hinterlegen, dass er nicht sofort sondern etwas verzögert für einen Scope antwortet. So können Sie einen "schnellen primären DHCP-Server" bereitstellen und einen zweiten "langsameren" Server als Backup parallel betreiben
  • DHCP Ping
    Weiterhin kann ein DHCP-Server eine IP-Adresse, die er anbieten will, erst einmal per PING ansprechen. Das funktioniert natürlich nur, wenn das andere System aktiv ist und einen PING erlaubt. Bekommt der DHCP-Server eine Antwort, dann kennzeichnet er die IP-Adresse als belegt. Der ganze Prozess dauert natürlich länger und der Client muss auf die Adresse warten.
  • Client-Check
    Auch der Client sollte nach dem Angebot einer Adresse durch den Server die Verfügbarkeit einmal prüfen. Windows macht dies durch einen ARP-Request an die IP-Adresse und wenn Sie im Subnetz schon vorhanden ist, wird das andere hoffentlich sich melden.

Es sollte so kaum passieren, dass zwei Systeme die gleichen IP-Adresse haben. Der häufigste Fall ist, dass ein System eine statische IP-Adresse von seine Admin bekommen hat, und diese nicht beim DHCP-Server dann ausgeschlossen wurde. Das passiert gerne mal mit VMs von Entwicklern, die einen Testserver starten und dann die per DHCP- eingetragene IP-Adresse entgegen den Regeln einfach statisch hinterlegen. Wenn die VM dann einige Wochen aus ist und später wieder eingeschaltet wird, dann kann die IP-Adresse schon ein anderes System bekommen haben.

DHCP Redundanzoptionen

Kommen wir nun zur Frage, wie sie DHCP denn besser verfügbar machen können. Es hier durchaus unterschiedliche Ansätze. Seit Windows 2012R2 gibt es von Microsoft einen DHCP Failover Cluster. Verwechseln Sie aber den "DHCP Failover Cluster" nicht mit einem "Microsoft Cluster" (Siehe Verfügbarkeit (Exchange und Co)" oder anderen Ansätzen wie Hardware Load-Balancer oder Network Load Balancing (NLB). Aber auch früher genutzte Optionen sind heute immer noch im Betrieb,

Variante Beschreibung

Bewertung

Single Server mit VM-Failover

Heute werden die meisten Dienste virtualisiert und die entsprechende Plattform darunter bietet eigene Failover-Optionen an. Sie können damit auch einen DHCP-Server von einem VM-Host zu einem anderen VM-Host umziehen oder z.B. bei einem RZ-Ausfall auch im Ziel einfach neu starten. Technisch haben sie aber nur einen Server der dann einige Minuten "offline" ist und auch bei geplanten Wartungsarbeiten immer mal wieder nicht verfügbar ist.

o

MS Cluster

Früher konnten Sie auf einem Windows Failover Cluster mit eine Shared Storage tatsächlich einen DHCP-Service betreiben. Ein Server war dabei der aktive Server mit der Datenbank auf der Disk und wenn der Knoten ausgefallen ist, wurde die Datenbank zum anderem Knoten geschwenkt und der DHCP-Service wieder gestartet. Die Unterbrechungszeit war minimal, aber natürlich gab es Abhängigkeiten. Heute würde ich diesen Weg nicht mehr wählen

-

50/50 Server

Sie können zwei Server installieren, von denen jeder einfach die Hälfte der IP-Adressen eines Scope verteilt. Das ist einfach und schnell konfiguriert aber eine echte Gleichverteilung ist nicht garantiert. Sie können eigentlich nur die Hälfte der Clients als gesichert ansehen, wenn ein Server ausgefallen ist. Das ist jedem anderen A/A-Cluster mit zwei Servern vergleichbar, die sie auch nur mit bis zu 50% belasten dürfen, damit beim Ausfall der andere Knoten die Last mit übernehmen kann.

+
70/30 Paar
80/20 Paar
95/05 Paar

Von Microsoft  und vielen anderen Quellen präferierte Lösung ist eine asymmetrische Verteilung, bei der ein primärer Server die meisten Clients bedient und ein sekundäre Server zwar mitläuft, aber verzögert antwortet. Damit wird sein Angebot fast nie angenommen. Sie verwalten eigentlich alles auf dem primären Server. Nur wenn der primäre Server ausfällt, dann bedient der sekundäre Server die Client, die in der Zeit eine neue IP-Adresse erwarten. In Verbindung mit einer längeren Lease-Dauer sind das dann nur Clients, die ganz neu starten, denn bestehende Clients arbeiten ja 50% der Lease-Dauer weiter und versuchen dann auch noch einen RENEW. Erst nach ca. 87% der Lease-Dauer würden sie dann eine neue Adresse anfragen. Das ist ziemlich viel Zeit um als Administrator zu reagieren. Auch die Zunahme der DHCP-Vergaben auf dem sekundären Server kann per Monitoring gut überwacht werden.

+

100/100 mit Konflikt

Sie können natürlich auch einfach zwei unabhängige DHCP-Server mit dem identischen Scope installieren und darauf vertrauen, dass die Server und Clients schon alleine einen Konflikt präventiv verhindern. Ein Windows DHCP-Server kann per PING dies erkennen und die Adresse dann sperren. Allerdings verzögern solche zusätzlichen Prüfungen die Vergabe um einige Sekunden und sicher ist dies auch nicht. Ohne Replikation der Daten müssen Sie natürlich auch die Konfiguration manuell immer gleich halten, was bei den Optionen noch einfach ist aber bei Reservierungen schnell fehleranfällig wird.

-

Sicher gibt es noch weitere Optionen und speziell 3rd Party Produkte, die ebenfalls DHCP-Dienste bereitstellen, bieten erweiterte Funktionen. Aber es hat sich wohl eine Art "Primary/Secondary"-System als häufigste Lösung herauskristallisiert,  bei der ein zweiter Server die Informationen des ersten Servers repliziert und einspringt.

DHCP Failover

Seit Windows 2012R2 hat Microsoft dem DHCP-Service eine "Cluster/Failover"-Funktion eingebaut, die auch 10 Jahres später bei Windows 2022 quasi unverändert in Funktion und GUI vorhanden ist. Sie ähnelt auf den ersten Blick der Technik, die auch ein DHCPD unter Linux nutzt. Zwei Server sind über einen Kommunikationskanal verbunden und gleichen damit ihre Konfiguration ab. Sie verwalten erst einmal einen DHCP-Service mit allen Einstellungen zu Scope und Optionen, um dann pro Scope zu definieren, welcher zweite Server die Konfiguration mit bekommen soll.

Im Active Directory bereitgestellte DHCP-Server müssen natürlich autorisiert sein.

Sollten Sie im Ziel einen vergleichbaren Scope schon konfiguriert haben, dann zeigt die MMC eine Warnung an. Sie müssen dann das Ziel erst entfernen
 

Danach gilt es die Details der Partnerschaft zu definieren. Im Standard definiert Microsoft einen "Load Balance"-Betrieb, bei dem beide Server aktiv IP-Adressen anbieten.

Alternativ können Sie auch einen "Standby-Server" definieren. Der zweite Server stellt dann nur IP-Adressen bereit, wenn der erste Server nicht mehr verfügbar ist.

Microsoft orientiert sich hierbei an einem RFC

Die Bedeutung der Betriebsart und der Felder hat Microsoft selbst gut dokumentiert:

Die Herausforderung ist wie bei jedem Cluster zu erkennen, dass der Partner nicht mehr aktiv ist. Es ist schon ein Unterschied, ob der primäre Server "Down" ist und der Standby-Server übernimmt oder ob vielleicht nur die Verbindung zwischen den beiden Partnern unterbrochen ist. Microsoft unterscheidet dies mit dem Status "COMMUNICATIONS INTERRUPTED" oder "PARTNER DOWN".

Feldname Default Beschreibung

Maximum Client Lead Time (MCLT)

1h

In dem Umfeld kommt der MCLT eine Bedeutung zu. Wenn ein Client eine IP-Adresse erneuern will aber der primäre Server nicht reagiert und der Standby-Server noch nicht sicher ist, ob er komplett übernehmen soll, dann kann er den Lease quasi temporär für diese Zeit verlängern. Der Client wird in dem Beispiel nach 1h erneut einen Verlängerung anfragen und nicht mehr 50% der Lease-Dauer nutzen. Bis dahin kann der primäre ja wieder online sein oder der Standby hat richtig übernommen.

Die Dauer ist auch für den "Fall Back" relevant, d.h. wenn ein primärer Server weggefallen ist und der sekundäre übernommen hat, dann braucht der Fallback ebenfalls so lange.

"The administrator configures the MCLT parameter to determine the amount of time a DHCP server should wait when a partner becomes unavailable, before assuming control of the address range."
Quelle: Microsoft Official Curriculum for Course 20412C ("Configuring Advanced Windows Server 2012 Services"):http://www.microsoft.com/learning/en-us/course.aspx?id=20412c

Mode

Load Balance

Definiert die Funktion des Clusters.

  • Load Balance
    Beide Knoten sind aktiv und abhängig vom Hashwert der anfragenden MAC-Adresse antwortet ein Server. Die vergebenen Leases werden direkte zwischen den Servern repliziert.
  • Hot standby
    Ein aktiver Server bedient quasi alle Clients und nutzt dazu im Default bis zu 95% der IP-Adressen des Scope. Der passive Server behält 5% für den Notbetrieb, wenn er aktiv sein muss.

Beide Funktionsweisen sind möglich und jede hat ihre Vorteile und Einschränkungen.

State Switchover Interval

NA

Diese Option muss aktiv sein, wenn ein Server nach Ablauf der Zeit seit der fehlenden Kommunikation zum anderen Server dessen Funktion automatisch übernehmen soll. Ansonsten müssen Sie als Administrator manuell die Aktivierung auslösen. Es gibt keinen zuverlässigen Weg zu erkennen, ob nur die Kommunikation zwischen den DHCP-Servern ausgefallen ist oder der komplette Service auf der anderen Seite entfallen ist. Der DHCP-Cluster kennt keinen "Whitness"-Service.

A server that loses communication with a partner server transitions into a communication interrupted state. The loss of communication may be due to a network outage or the partner server may have gone offline. By default, since there is no way for the server to detect the reason for loss of communication with its partner, the server will continue to remain in communication interrupted state until the administrator manually changes the state to partner down. However, if you enable automatic state transition, DHCP failover will automatically transition to partner down state when the auto state switchover interval expires. The default value for auto state switchover interval is 60 minutes.
Quelle: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn338985(v=ws.11)

Message Authentication und Shared Secret

<bitte Secret eingeben>

Die Kommunikation zwischen den beiden DHCP-Servern ist über ein gemeinsames Geheimnis abgesichert. Windows nutzt also weder die Credentials eines Dienstkontos noch die Computernamen oder Zertifikate o.ä. zur Authentifizierung der Server untereinander.

Zuerst zeigt die MMC noch einmal die Einstellungen an

Danach konfiguriert die MMC die Partnerschaft für die ausgewählten Scopes auf beiden Servern.

Denken Sie daran, dass ein Bootp-Forwarder und DHCP-Relay-Agent seine Anfragen an beide DHCP-Server senden muss, damit Failover und Lastverteilung funktionieren.

Denken Sie daran, dass beide DHCP-Server ggfls. die Berechtigungen zu Updates von dynamischen DNS-Einträgen benötigen
DNS Record Ownership and the DnsUpdateProxy Group  https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd334715(v=ws.10)?redirectedfrom=MSDN

Bitte ändern Sie nicht die IP-Adresse eines authentifizierten DHCP-Servers. Anscheinend wird die IP-Adresse sowohl im AD aber auch in der Failover-Replikation gespeichert und nicht anhand einer DNS-Auflösung gefunden. Es kann dann durchaus sein, dass ein DHCP-Cluster sich nicht mehr zusammenfindet und Sie die Failover-Konfiguration hart löschen und wieder neu anlegen müssen.

Betrieb und Replikation

Allein die Konfiguration eines Scope als Failover nimmt ihnen nicht ein paar Aufgaben ab. Auf beiden Servern sind die Scopes "bearbeitbar" und sie sehen auch nicht, dass diese Scope irgendwie "repliziert "sind. Ich habe zum Test auf jedem Server eine statische Reservierung wie folgt addiert:

Dies war problemlos möglich und auch nach einiger Zeit wurden hier keine Daten abgeglichen. Ich musste schon manuell ein "Replicate Scope.." machen, um die Einstellungen von einem Server zum anderen Server zu übertragen:

Achtung: Dabei handelt es sich um ein "Überschreiben" im Ziel, d.h. mein "Test2"-Reservierung auf EX01 ist im dem Zuge entfernt worden.

Dies gilt übrigens auch für Änderungen per PowerShell.

Sie sollten daher Änderungen immer nur auf dem aktiven Server vornehmen UND danach die Änderungen über eine manuelle Replikation zum anderen Server übertragen. Wenn der aktive Server "Down" ist, dann können Sie zwar auch auf dem sekundären Server Änderungen vornehmen, aber müssen daran denken diese zurück zu replizieren und können ja nie sicher sein, ob jemand auf dem primären Server eine Änderung noch nicht repliziert hatte.

Microsoft hat keine "eingebaute Replikation" oder gar eine Ablage im Active Directory für die Konfigurationen vorgesehen. Allerdings gibt es mit Windows 2012R2 und höher auch ein "IP Address Management (IPAM)", welches hier unterstützt.

Changes made to failover-enabled scopes using the IPAM console are automatically replicated to the failover partner. This is a significant difference in the way that DHCP failover works compared to when you configure settings using the DHCP console or Windows PowerShell
Quelle: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn757722(v=ws.11)#managing-dhcp-failover-with-ipam

Die vom DHCP-Server vergebenen Leases werden aber sehr wohl automatisch und auch schnell repliziert.

Monitoring

Zudem sollten Sie natürlich die Funktion ihrer DHCP-Server auch in das Monitoring mit einbeziehen. Dazu gehören:

  • Grundlegende Überwachung des Servers und des DHCP-Diensts
    Die Dienste müssen natürlich laufen, der Patchstand sollte aktuell sein, CPU, RAM, DISK etc. im grünen Bereich sein.
  • Performance Counter der Scopes
    Überwachen Sie die Anzahl der vergebenen IP-Adressen und wie viel "Reserve" sie noch pro Scope haben. Es wäre schon peinlich, wenn ein "hochverfügbarer DHCP-Service" aufgrund eines falschen Auslegung, falschen Konfiguration oder aus anderen Gründen keine freien Adressen mehr hat.
  • Events
    Über das Eventlog können Sie ebenfalls auf Fehler oder Warnungen überwachen.
    DHCP Server Operational Events https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn800668(v=ws.11)
  • Aktive Tests
    Sie können sich natürlich auch auf ihr Anwender als "Sensoren" verlassen aber es gibt Programme, die eine DHCP-Anfrage (DHCPDISCOVER) starten und auf das DHCPOFFER warten.

In der DHCP-MMC sehen Sie pro Scope einen Status.

In den Eigenschaften des IPv4-Knotens werden die Failover-Partnerschaften verwaltet und hier kann auch die Konfiguration nachträglich angepasst werden, die bei der Einrichtung abgefragt wurde.

In dem Bild sehen Sie zudem den Zustand, wenn der primäre Server "Down" ist und der Status auf "CommunicationInterrupted" steht. Ohne einen automatisierten Failover (State Switchover Interval) müssen Sie hier manuell aktiv werden, damit der sekundäre Server die Funktion übernimmt.

Hinweis:
Der Rückfall zu primären Server erfolgt automatisch, nachdem der primäre Server seinen Abgleich durchgeführt und die Maximum Client Lead Time (MCLT) abgelaufen ist.

Die kompletten Statusänderungen werden von Windows auch ein ein Audit-File (%windir%\System32\Dhcp) und ins Eventlog (Applications and Services Logs\Microsoft\Windows\DHCP-Server) geschrieben. In der GUI sehen Sie am IPv4-Symbol einen kleinen Indikator zum Cluster.

Es ist nur der kleine gelbe Pfeil, der auf das Failover-Cluster hinweist. Den Status können Sie sehr einfach per PowerShell ermitteln:

if (Get-DhcpServerv4Failover).state -ne 'Normal') {
   Write-Host "Probleme beim lokalen DHCP_Service
}

So eine regelmäßige Prüfung können Sie einfach in ihre Monitoring-System einbinden oder per Taskplaner starten und Aktionen ausführen.

Weiterhin gibt es numerische Performancecounter, die Sie mit ihrer Monitoring-Lösung einfach anzapfen können.

So sollte hier die "Failover: BndUpd pending in outbound queue" immer 0" sein

Auf meinem Server gibt es drei Eventlogs:

Allerdings hat mit ein "Get-Winevent -ListLog" nur zwei Logs geliefert. Das interessante Ad,-Log mit den Cluster Failover Events konnte ich so nicht finden.

PS C:\> Get-WinEvent -ListLog *dhcp-server*

LogMode   MaximumSizeInBytes RecordCount LogName
-------   ------------------ ----------- -------
Circular             1052672           0 Microsoft-Windows-Dhcp-Server/FilterNotifications
Circular             1052672          12 Microsoft-Windows-Dhcp-Server/Operational

Über die Abfrage mit dem Provider-Name "Microsoft-Windows-DHCP-Server" wurden mir aber alle Meldungen angezeigt.

Get-WinEvent -ProviderName "Microsoft-Windows-DHCP-Server"

Ein Verlust der Verbindung auf dem primären Server, der Partner Failover und das Recovery generierte bei mir folgende Werte (aktuellster Wert oben).

PS C:\> Get-WinEvent -ProviderName "Microsoft-Windows-DHCP-Server" | fl TimeCreated,Id,Message


TimeCreated : 29.05.2024 18:27:50
Id          : 20251
Message     : The failover state of server: dc01.uclabor.de for failover relationship: dc01.uclabor.de-ex01 changed
              from: RECOVER_DONE to NORMAL.

TimeCreated : 29.05.2024 18:27:50
Id          : 20251
Message     : The failover state of server: ex01 for failover relationship: dc01.uclabor.de-ex01 changed from:
              PARTNER_DOWN to NORMAL.

TimeCreated : 29.05.2024 18:27:50
Id          : 20251
Message     : The failover state of server: dc01.uclabor.de for failover relationship: dc01.uclabor.de-ex01 changed
              from: RECOVER_WAIT to RECOVER_DONE.

TimeCreated : 29.05.2024 17:27:50
Id          : 20251
Message     : The failover state of server: dc01.uclabor.de for failover relationship: dc01.uclabor.de-ex01 changed
              from: RECOVER to RECOVER_WAIT.

TimeCreated : 29.05.2024 17:27:50
Id          : 20251
Message     : The failover state of server: dc01.uclabor.de for failover relationship: dc01.uclabor.de-ex01 changed
              from: COMMUNICATION_INT to RECOVER.

TimeCreated : 29.05.2024 17:27:50
Id          : 20259
Message     : The failover state of server: dc01.uclabor.de for failover relationship: dc01.uclabor.de-ex01 changed to
              : COMMUNICATION_INT.

TimeCreated : 29.05.2024 17:27:50
Id          : 20254
Message     : Server has established contact with failover partner server 192.168.13.10 for relationship
              dc01.uclabor.de-ex01 .

TimeCreated : 29.05.2024 17:27:37
Id          : 20251
Message     : The failover state of server: ex01 for failover relationship: dc01.uclabor.de-ex01 changed from:
              COMMUNICATION_INT to PARTNER_DOWN.

TimeCreated : 29.05.2024 17:27:14
Id          : 20252
Message     : The failover state of server: ex01 for failover relationship: dc01.uclabor.de-ex01 changed from: NORMAL
              to COMMUNICATION_INT.

TimeCreated : 29.05.2024 17:27:14
Id          : 20255
Message     : Server has lost contact with failover partner server  192.168.13.10 for relationship
              dc01.uclabor.de-ex01 .

Ansonsten stehen ihnen auch verschiedene PowerShell-Befehle zur Verfügung, die ich im nächsten Abschnitt beschreibe.

PowerShell

GUI und MMC ist zwar nett aber für die Automatisierung sind Schnittstellen gefragt. Microsoft hat mit der PowerShell gleich die passenden Module mitgeliefert. Die Konfiguration des Clusters können wir wie folgt ermitteln.

# Abfrage auf dem passiven Server
PS C:\> Get-DhcpServerv4Failover

Name                : dc01.uclabor.de-ex01
PartnerServer       : dc01.uclabor.de
Mode                : LoadBalance
LoadBalancePercent  : 50
ServerRole          :
ReservePercent      :
MaxClientLeadTime   : 01:00:00
StateSwitchInterval :
State               : Normal
ScopeId             : 192.168.13.0
AutoStateTransition : False
EnableAuth          : True

Das Feld "State" liefert und den aktuellen Status und sollte per Monitoring ausgelesen werden. Der Status ist pro Server zu ermitteln.

Status Bedeutung

Normal

Regelbetrieb

Communication Interrupted

Der DHCP-Server kann seinen Kommunikationspartner nicht erreichen.

PartnerDown

Ein Admin hat den manuellen Failover aktiviert oder die Zeit bei "State Switchover Interval" ist abgelaufen

RecoverWait

Der primäre Server ist nach einem Ausfall wieder online aber hat noch nicht wieder übernommen. Er wartet die MCLT-Zeit ab, damit er problemlos wieder mitspielen darf.

...

Es gibt noch weitere Status, die Microsoft beschrieben hat.

Beim Monitoring ist die Erfassung der freien IP-Adressen pro Scope aus meiner Sicht interessant. Auch das geht per PowerShell einfach

PS C:\> Get-DhcpServerv4ScopeStatistics -ScopeId 192.168.13.0 | fl

ScopeId                       : 192.168.13.0
AddressesFree                 : 189
AddressesInUse                : 1
PendingOffers                 : 0
ReservedAddress               : 1
PercentageInUse               : 0,5263158
SuperscopeName                :
AddressesFreeOnThisServer     :
AddressesFreeOnPartnerServer  :
AddressesInUseOnThisServer    :
AddressesInUseOnPartnerServer :

Die Werte können Sie ebenfalls direkt in ein Monitoring übernehmen. Theoretisch könnten Sie auch das Commandlet "Get-DhcpServerv4FreeIPAddress" mit einem Scope und dem Parameter "-NumAddress" nutzen, um zu sehen, wie viele Adressen noch frei sind. Aber die Daten bekommen wir mit Get-DhcpServerv4ScopeStatistics einfacher. "Get-DhcpServerv4FreeIPAddress" scheint auch einfach direkt den DHCP-Server zu fragen und keine echte DHCP-Anfrage zu simulieren. Als Monitoring-/Testwerkzeug eignet es sich nicht.

Wenn der DHCP-Server alle IP-Adressen und zugehörigen MAC-Adressen erfasst, dann kann diese auch ausgelesen und z.B. in ein Audit-Log oder Inventory übertragen werden. Zudem können Sie etwas sehen, wie die Client ihren DHCP-Server nutzen und welche Client schon länger nicht mehr nachgefragt haben.

PS C:\> Get-DhcpServerv4Lease -ScopeId 192.168.13.0

IPAddress       ScopeId         ClientId             HostName             AddressState         LeaseExpiryTime
---------       -------         --------             --------             ------------         ---------------
192.168.13.111  192.168.13.0    11-11-11-11-11-11    TEST1                InactiveReservation

Natürlich gibt es auch das Gegenstück, um z.B. statische Reservierungen in großer Menge vorzunehmen. Dies ist z.B. nützlich beim Umzug von DHCP von einem anderen System, wenn Sie die IP-Adressen beibehalten wollen.

Add-DhcpServerv4Lease `
   -IPAddress 192.168.13.115 `
   -ScopeId 192.168.13.0 `
   -ClientId 444444444444

Die MAC-Adresse wird ohne Doppelpunkte o.ä. eingegeben.

Wenn Sie mutig sind, dann können Sie über einen "geplanten Task" sogar die Replikation der Konfiguration automatisieren:

# Repliziere alle Parterschaften des Servers an seiner Partner
Invoke-DhcpServerv4FailoverReplication `
   -ComputerName dc01.uclabor.de `

# Repliziere nur die 
Invoke-DhcpServerv4FailoverReplication `
   -ComputerName dc01.uclabor.de `
   -ScopeId 192.168.13.0

Allerdings sollten Sie dann "ganz sicher" sein, dass Sie immer nur auf dem primären System die Konfiguration ändern.

Das ist natürlich nur dann eine gute Idee, wenn wirklich alle Administratoren auch immer nur auf dem primären Server Änderungen vornehmen

Wireshark:Regelbetrieb

Natürlich wollt ich wissen, was hinter den Kulissen passiert und dazu eignet sich WireShark als Analysewerkzeug. Schließlich müssen die beiden Server ja irgendwie miteinander sprechen und sich abstimmen. Sehr schnell war zu sehen, dass die Kommunikation zwischen den beiden Partnern per 647/TCP erfolgt und immer vom primären Server auf den sekundären Server aufgebaut wird. Sie sehen hier in Wireshark den TCP-Handshake (Paket 1-3) und dann ein "CONNECT" mit allen Daten im Klartext.

Danach wird ca. alle 60 Sekunden ein Statusupdate vom Master an den Client gesendet.

Weitere Einblicke sind hier aber nicht zu sehen. Sie müssen natürlich sicherstellen, dass der Port nicht geblockt ist.

Wireshark:Lease Updates

Auch die Information über vergebene Leases wird über den Port übertragen.

Es ist gut zu sehen, dass schon beim ersten DHCP-Offer sehr schnell das Update auch zum sekundären Server gesendet wird und nach der Annahme durch den Client der Lease noch einmal aktualisiert wird. Wenn ein Client eine IP-Adresse wieder zurückgibt, dann wird der Lease ebenfalls freigegeben und diese Änderung zum sekundären Server repliziert.

Wireshark: Secondary Down

Wenn ich den sekundären DHCP-Server "geordnet" beende, dann wird der primäre Server darüber durch den TCP-FIN (Paket 86-90) informiert:

Zusätzlich ist aber auch anhand der Pakete 91/93 zu sehen, dass der DHCP-Server noch einen "Multicast-Leave (IP=224.0.0.22, Group = 239.255.255.254)" sendet. Der primäre Server versucht weiterhin alle 30 Sekunden wieder die TCP-Verbindung zum Port 647 des ausgefallenen sekundären Servers aufzubauen. Er nutzt dazu übrigens immer wieder einen neuen Sourceport.

Wireshark:Lease Update Queue

In der Situation habe ich dann per DHCP vom aktiven primären Server einen Lease angefordert und erhalten. und danach den sekundären Server gestartet um zu sehen, ob und wie schnell die Daten dort ankommen. Ich habe dazu noch ein vergeblich TCP-SYN abgewartet, um etwaige Verzögerungen zu sehen.

Der sekundäre DHCP-Server startet mit einem IGMPv3 Member Join Group über die Multicast-IP-Adresse 224.0.0.22 und die Gruppe 239.225.225.254. Das triggert den primären DHCP-Server aber noch nicht an. Erst nach den bekannten "Retry-Intervall" von ca. 30 Sekunden wird die Verbindung vom primären Server zum sekundären Server über Port 647 aufgebaut und dann aber auch alle ausstehenden Updates übertragen.

Wireshark:Primary Fail

Das nächste Szenario war der Ausfall des primären Servers gefolgt von einem Client, der direkt darauf eine IP-Adresse anfordert. Der sekundäre Server hat also noch nicht die Rolle übernommen, da das "State Switchover Interval" noch nicht abgelaufen ist. Der Mitschnitt erfolgte auf dem primären Server (192.168.13.10) und sind als "Load Balancing" konfiguriert.

Die Pakete 119-122 zeigen den Abbau der Replikationsverbindung über Port 647 beim Herunterfahren des primären DHCP-Servers. Ca. 13 Sek später fordert der Client eine IP-Adresse an und erhält sie vom sekundären Server (192.168.13.16).

Der Client hatte natürlich vorher eine Adresse vom primären Server bekommen und dürfte daher erst mal auf eine Antwort gewartet haben, ehe er nach dem dritten Versuch die Adresse des sekundären Servers nimmt.

Wireshark:Primary Recover

Im vorherigen Mitschnitt stehen Sie, dass ich ca. 90 Sekunden später den primären Server wieder "online" genommen habe. Er hat sich mit dem sekundären Server über Port 647 verbunden und die zwischenzeitlich zugeteilten Leases zurückgelesen. Der primäre Server ist danach aber noch die eingestellte Zeit im Status "Recovery" geblieben, ehe er dann wieder in den "Normal"-Mode gewechselt ist.

DHCP Failover deinstallieren

Der DHCP-Failover Cluster besteht aus zwei Komponenten:

  • Die "Failover Partnerschaft" zwischen zwei Servern mit den gleichen Parametern und einem Shared Secret
    Ein Server kann durchaus mit mehreren anderen Servern eine Partnerschaft habe.
  • Die Scope-Partnerschaften
    Für jeden Scope wird ebenfalls eingerichtet, ob er Teil des Failover Cluster ist

Ich gehe zur Vereinfachung nun davon aus, dass Sie genau zwei Server haben und alle Scopes repliziert sind. Sie können über die MMC einfach auf jedem Scope ein "Deconfigure Failover" machen, worauf die MMC sich per RPC zum anderen Server verbindet und dort den Scope löscht.

Übrig bleibt ihr aktiver erster Server mit dem Scope. Wenn Sie alle Scopes entfernt haben, dann gibt es aber immer noch die Partnerschaft mit der Verbindung. Die entfernen Sie auf dem jeweiligen Server über die IPv4-Eigenschaften.

Sie können die Partnerschaft und die Scope replikation natürlich auch per PowerShell entfernen. Sollte es aber noch Scopes geben, dann müssen Sie entweder zuerst die Scope-Failover-Konfiguration entfernen oder sie nutzen "-force". Ich hole mir dazu erst einmal den Namen der Partnerschaft um sie dann zu entfernen.

Remove-DhcpServerv4Failover `
   -ComputerName DHCP01 `
   -Name "DHCP01-DHCP02" `
   -Force

Einschätzung

Vermutlich haben es viele Administratoren noch gar nicht auf dem Radar, dass es seit Windows 2012R2 schon eine einfach Möglichkeit gibt, DHCP-Dienste auch "hochverfügbar" bereitzustellen und Microsoft nutzt anscheinend die gleichen Grundlagen, die auch ein Linux DHCPD und andere Systeme verwenden. Ich habe aber nicht geprüft, ob ich einen Windows Server mit einem DHCPD auch verpartnern könnte.

Es ist aber heute eine gute Gelegenheit sich über ihre aktuelle DHCP-Konfiguration auf Basis von Windows Servern zu unterhalten und ggfls. diese anzupassen. Wer sich heute z.B. zwei Domain Controller und zwei DNS-Server betreibt, kann genauso gut auch zwei DHCP-Server bereitstellen und damit sowohl bei geplanten Wartungsarbeiten als auch ungeplanten Ausfällen die Funktion aufrecht erhalten.

Änderungen bei den Leases werden aktiv zwischen beiden Servern quasi sofort repliziert. Die Konfiguration der Scopes, Optionen aber auch statische Reservierungen sollten Sie aber immer auf einem primären Server machen und die erforderliche manuelle Replikation nicht vergessen. Sie können Änderungen sogar auf dem sekundären Server machen und dann auf den primären Server zurückschreiben. Das kann ihnen auch in einem Desasterfall helfen, wenn Sie so einen verloren gegangenen primären Server einfach wieder betanken können.

Wenn ihnen die Hochverfügbarkeit suspekt ist, dann können Sie auch einen Failover-Mode konfigurieren, bei denen ein Server die 95% bedient und ein Standby-Server im Notfall bis zu 5% übergangsweise vergeben und Renew-Anfragen ebenso kurz bestätigen kann.

Erweitern Sie aber auf jeden Fall ihre Überwachung der Dienste dahingehend, dass Sie den Status z.B. per "(Get-DhcpServerv4Failover).state -ne 'Normal'" und Eventlog überwachen. Wäre schade, wenn Probleme erst beim Ausfall des zweiten Servers bemerkt werden.

Weitere Links