Das lernst du
- Legitime Mehrservernetze von unkoordinierten Pools unterscheiden.
- Die Rolle der Serverkennung bei der Angebotsauswahl erklären.
Voraussetzungen: F02 · DHCP-Nachrichten lesenG06 · Subnetz, Scope und Pool
Zwei DHCPOFFER in einem Mitschnitt sind nicht automatisch ein Angriff oder ein Fehler. Redundanz, Migration und getrennte Adressbereiche können mehrere legitime Server hervorbringen.
Die Entscheidung steht im REQUEST
Grafik vergrößern
Auswahl durch den Client
Der Client kann Angebote vergleichen. Das Auswahlverfahren wird nicht als allgemeine Regel „immer schnellster Server“ festgelegt. Das anschließende REQUEST bei Angebotsauswahl nennt über Option 54 den gewählten Server; andere empfangende Server erkennen, dass ihr Angebot nicht angenommen wurde.
Der gewählte Server bestätigt geeignete Parameter. yiaddr ist die angebotene Clientadresse. Die Serverkennung ist nicht mit siaddr oder der Gatewayoption gleichzusetzen. Ein Relay kann die IP-Absenderadresse im beobachteten Abschnitt beeinflussen; deshalb immer auch das DHCP-Feld prüfen.
Wer kennt welche Belegung?
Zwei unkoordinierte Server mit überlappenden Pools können dieselbe Adresse verschiedenen Clients anbieten und bestätigen. Ein disjunktes Split-Scope verhindert diese konkrete Überschneidung durch Planung, synchronisiert aber keine Lease-Zustände.
Ein zustandssynchronisierendes Failover braucht ein Produktprotokoll, klare Partnerrollen und Ausfallregeln. DHCPv4 allein macht aus zwei Servern kein HA-Paar. Bei mehreren Relayzielen können beide Server Anfragen sehen; doppelte Weiterleitungen und Plattformverhalten müssen geprüft werden.
Den Gewinner im Capture bestimmen
Angenommen, Server A bietet .120 und Server B bietet .180 an. Beide Antworten können dieselbe Clienttransaktion betreffen. Die Entscheidung ist erst am anschließenden REQUEST erkennbar: Option 50 nennt .120, Option 54 die Kennung von A. B erkennt daraus, dass sein Angebot nicht ausgewählt wurde. Die bloße Reihenfolge der Pakete an einem einzelnen Messpunkt beweist die Auswahlentscheidung noch nicht.
Die Serverkennung bezeichnet den DHCP-Anbieter, nicht das angebotene Standardgateway. Würde A Gateway .1 und B ebenfalls Gateway .1 senden, wären die Anbieter trotzdem verschieden. Halte in der Auswertung daher Anbieter, angebotene Adresse, Lease-Dauer und Optionen getrennt fest. Ein unerwartetes zweites Angebot wird anschließend mit der Liste autorisierter Dienste abgeglichen.
Verfügbarkeit braucht auch ausreichende Restkapazität
Zwei disjunkte Teilpools verhindern eine bestimmte Form doppelter Vergabe, garantieren aber nicht die Versorgung beim Ausfall eines Servers. Wenn A und B je 50 Plätze bereitstellen und 80 Clients neue Konfiguration benötigen, kann ein allein erreichbarer Teilpool mit 50 Plätzen den Bedarf nicht decken. Bereits gültige Leases und neue Vergaben müssen dabei separat betrachtet werden.
Für eine belastbare Architektur prüfst du deshalb Normalbetrieb, einzelnen Dienstausfall, verlorenen Netzpfad und Wiederkehr des Dienstes. Bei einem synchronisierenden HA-Produkt gelten zusätzlich dessen Zustands- und Übernahmeregeln. Zwei identische Konfigurationsdateien ohne abgestimmte Leaseverwaltung ersetzen diese Regeln nicht. Insbesondere die Wiederinbetriebnahme mit veraltetem Bestand kann neue Konflikte verursachen.
Unkoordinierte Pools reparieren
- Server A vergibt .100–.179, B .150–.229. Die Schnittmenge .150–.179 umfasst 30 potenziell doppelt vergebene Adressen.
- Vor einer Änderung vorhandene Leases beider Server vergleichen. Einfaches Ändern der Poolgrenze entfernt keine bereits gültige Nutzung.
- Entweder ein unterstütztes Failover planen oder disjunkte Bereiche mit ausreichender Kapazität und Übergangsplan verwenden. Testclients müssen beide vorgesehenen Server erreichen.
- Danach anhand von Serverkennung und Lease-Daten nachweisen, wer eine Adresse tatsächlich bestätigt hat.
Ergebnis: Mehrere Server sind zulässig. Unkoordinierte Überschneidung und fehlender Übergangsplan sind das Problem.
Typische Fehler
- Ein Client wählt nicht zwingend immer das zuerst sichtbare OFFER.
- Split-Scope ist keine Lease-Synchronisierung.
- Zwei Relayziele konfigurieren noch kein Failover.
Praktisch anwenden
Offizielle Quellen
Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.
- RFC 2131 · DHCPv4 ↗Protokollbasis, insbesondere §§ 3 und 4; März 1997
- Microsoft · DHCP-Failover ↗Windows Server 2025; DHCPv4, nicht DHCPv6
- ISC · Kea High Availability ↗Kea 3.0.2, libdhcp_ha.so