Das lernst du
- MAC-Adresse und DHCP-Clientkennung unterscheiden.
- Reservierungen bei Hardwarewechsel und geklonten Geräten reparieren.
Voraussetzungen: G05 · Statisch, dynamisch, automatisch, reserviertF06 · Optionen und Vererbung
Eine Reservierung sieht nur dann stabil aus, wenn der Server denselben Client zuverlässig wiedererkennt. Die sichtbare MAC-Adresse ist nicht in jedem Produkt die einzige relevante Kennung.
- Client Identifier
- Eine vom Client in Option 61 mitgesendete Kennung. Sie muss nicht mit seiner MAC-Adresse identisch sein. Ob und wie sie Reservierungen zuordnet, bestimmt die Serverkonfiguration.
Die Kennung muss zum Reservierungsschlüssel passen
Grafik vergrößern
Was identifiziert den Client?
chaddr trägt die Hardwareadresse des verwendeten Interfaces im BOOTP-Feld. Option 61 kann eine eigene Clientkennung enthalten. RFC 4361 beschreibt eine auf DUID und IAID beruhende Variante für DHCPv4. Ein Server kann daher eine andere Identität als die reine MAC als Schlüssel verwenden.
Windows-DHCP-Reservierungen arbeiten mit ClientId; häufig entspricht sie der Geräte-MAC in der erwarteten Schreibweise. Kea unterstützt unterschiedliche Host-Identifier und eine konfigurierbare Suchreihenfolge. Eine Reservierung mit hw-address ist keine pauschale Vorgabe für jede Kea-Installation.
Identität verändert sich
Ein Netzwerkkartentausch, MAC-Randomisierung im WLAN oder das Klonen einer VM kann eine Kennung ändern bzw. verdoppeln. Bei zwei identischen Clientkennungen kann der Server beide Geräte als einen Client behandeln. Das ist kein Problem, das ein größerer Pool löst.
Vor einer Reparatur tatsächliche Kennung aus Lease und Paket aufnehmen. Zuordnung ändern, vorhandene Nutzungsrechte berücksichtigen und anschließend neu beziehen. Eine Änderung auf dem Server zwingt einen Client nicht automatisch dazu, eine noch gültige alte Adresse sofort aufzugeben.
Identität als Datensatz statt Gerätename behandeln
Der Server benötigt eine wiedererkennbare Kennung für seine Zuordnungen. Die MAC-Adresse in chaddr ist ein wichtiger Kandidat; eine gesendete Client-Identifier-Option kann jedoch eine andere Identität ausdrücken. RFC 4361 beschreibt dafür unter anderem eine Kennung aus IAID und DUID. Ein reservierter Anzeigename wie „Drucker Empfang“ ist lediglich Verwaltungstext und ersetzt diesen Paketinhalt nicht.
Vergleiche deshalb die tatsächlich übertragenen Bytes mit dem Format, das das Produkt für Reservierungen erwartet. Ein Präfix oder eine andere Kodierung kann relevant sein. Zwei ähnlich aussehende Zeichenketten sind nicht automatisch dieselbe Identität. Bei mehreren Netzwerkschnittstellen muss außerdem klar sein, welche Schnittstelle die Reservierung nutzen soll; der gleiche Laptopname garantiert keine gemeinsame Lease.
Identitätswechsel kontrolliert durchführen
Beim Ersatz einer Netzwerkkarte bleibt die alte Lease möglicherweise noch gültig, während das neue Gerät mit neuer Kennung fragt. Übernimm nicht einfach die alte Zuordnung, ohne die tatsächliche Nutzung der Adresse zu prüfen. Ein geplanter Wechsel beendet oder berücksichtigt die alte Nutzung, aktualisiert die Reservierung und prüft danach einen neuen Bezug mit der neuen Identität.
Bei virtuellen Maschinen kann ein geklontes System umgekehrt dieselbe Clientkennung wie sein Ursprung mitbringen. Dann sieht der Server unter Umständen keine zwei sauberen unabhängigen Teilnehmer. Prüfe vor der Schuldzuweisung an den Pool sowohl Hardwareadressen als auch Client-Identifier. Reservierungen schaffen Vorhersagbarkeit, sind aber keine Authentisierung: Eine bekannte Kennung kann prinzipiell nachgeahmt werden.
Drucker mit neuer Netzwerkkarte
- Reserviert: Kennung 02:00:00:00:10:50 → .150. Nach Tausch sendet der Drucker 02:00:00:00:10:51 und bekommt eine andere freie Adresse.
- Paket und Serverlease vergleichen; bestätigen, dass wirklich nur die Kennung geändert wurde.
- Reservierung auf die neue Kennung anpassen. Prüfen, ob .150 noch durch einen anderen gültigen Lease belegt ist. Nicht blind eine zweite Reservierung mit derselben IP anlegen.
- Drucker neu beziehen lassen. Erwartet: .150, richtige Optionen, keine doppelte Zuordnung. Eine VM mit geklonter Kennung separat bereinigen.
Ergebnis: Die Behebung basiert auf der tatsächlich übertragenen Identität, nicht auf einem geratenen Namen im Inventar.
Typische Fehler
- Hostname und Client Identifier sind nicht dasselbe.
- MAC-Randomisierung kann Reservierungen umgehen, ohne dass DHCP fehlerhaft ist.
- Reservierung ändern löscht nicht automatisch jeden aktiven Lease.
Praktisch anwenden
Offizielle Quellen
Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.
- RFC 4361 · DHCPv4 Client Identifier ↗DUID/IAID-basierte Kennungen; Februar 2006
- Microsoft · Add-DhcpServerv4Reservation ↗Windows Server 2025 PowerShell
- ISC · Kea DHCPv4 Server ↗Festes Lehrprofil: Kea 3.0.2; keine Annahme, dass dies die neueste Version ist