XPLN/Lernbereiche

F04 · DHCPv4 · Protokoll / Modell

Das Client-Zustandsmodell

Kapitel in dieser Lernstufe

Das lernst du

  • Zustandsübergänge durch Ereignisse statt durch Auswendiglernen erklären.
  • Neustart, Erneuerung, NAK und Ablauf im Zeitverlauf verfolgen.

Voraussetzungen: F02 · DHCP-Nachrichten lesenG08 · Lease: Nutzung auf Zeit

Ein Clientzustand beschreibt, welche Adresse der Client bereits verwenden darf und welche Nachricht als Nächstes sinnvoll ist. Derselbe REQUEST hat deshalb je nach Zustand eine andere Bedeutung.

Zustände haben Hinwege und Rückwege

Der Zustand folgt dem EreignisINITSELECTINGREQUESTINGBOUNDRENEWINGREBINDINGDISCOVERAuswahl+ REQUESTACK +PrüfungT1T2Ablaufohne ACKACK → BOUNDACK → BOUNDAusschnitt: Neustart und Wiederholungen siehe Text.
Grafik vergrößern
Der Zustand folgt dem EreignisINITSELECTINGREQUESTINGBOUNDRENEWINGREBINDINGDISCOVERAuswahl+ REQUESTACK +PrüfungT1T2Ablaufohne ACKACK → BOUNDACK → BOUNDAusschnitt: Neustart und Wiederholungen siehe Text.
Ausschnitt der DHCPv4-Zustandsmaschine: DISCOVER führt von INIT zu SELECTING, die Auswahl mit REQUEST zu REQUESTING. Ein geeignetes ACK und erfolgreiche Konfliktprüfung führen zu BOUND. T1 und T2 führen ohne zwischenzeitliches ACK über RENEWING nach REBINDING. Ein geeignetes ACK führt jeweils zurück nach BOUND; Ablauf ohne Bestätigung führt zu INIT. Neustartpfade und Wiederholungen sind hier ausgelassen.
Clientzustände · interaktives Lehrmodell mit acht Stunden Lease
INITSELECTINGREQUESTINGBOUNDRENEWINGREBINDINGINIT-REBOOTREBOOTING

Zustand INIT · Laborzeit 0 h

    Vereinfachung: keine Zufallswartezeiten, alle ACKs setzen eine neue Acht-Stunden-Lease. Der Praxisbereich simuliert Lease-Daten separat.

    Vom Start zur Nutzung

    INIT besitzt keine nutzbare Konfiguration. Nach DISCOVER folgt SELECTING: Angebote werden gesammelt. Nach Auswahl und REQUEST wartet REQUESTING auf Bestätigung. Ein geeignetes ACK und eine erfolgreiche Konfliktprüfung führen zu BOUND. Ein erkannter Konflikt führt zu DECLINE und erneutem Start, nicht zur normalen Nutzung.

    Hat der Client nach Neustart eine gespeicherte Adresse, beginnt er in INIT-REBOOT und sendet einen REQUEST zur Wiederbestätigung; während des Wartens ist er in REBOOTING. Ein ACK kann ihn zurück nach BOUND führen. Ein NAK verwirft die gespeicherte Konfiguration. Bei ausbleibenden Antworten greifen Wiederholungs- und Rückfallregeln; Neustart ist nicht zwingend ein vollständiger DORA-Ablauf.

    Zeitgesteuerte Übergänge

    Bei T1 wechselt BOUND nach RENEWING und fragt den bisherigen Server. Ohne Bestätigung geht es bei T2 nach REBINDING, um verfügbare Server zu erreichen. Ablauf ohne ACK beendet die Nutzung und führt zu INIT. Ein geeignetes ACK erneuert die Fristen und führt zurück nach BOUND.

    Die interaktive Darstellung zeigt einzelne Ereignisse und Laborzeit. Sie ist ein Lehrmodell: Zufallsjitter, parallele Angebote und alle Clientimplementierungen werden nicht nachgebildet. Im Praxislabor verändert Zeit dagegen den tatsächlichen modellierten Lease-Bestand und die Clientzustände.

    Zustände besitzen Bedingungen, nicht nur Namen

    BOUND bedeutet, dass eine verwendbare Konfiguration mit laufender Gültigkeit existiert. RENEWING und REBINDING behalten dieses Nutzungsrecht zunächst bei: Der Client versucht schon zu verlängern, obwohl die bisherige Lease noch nicht abgelaufen ist. REQUESTING beim Erstbezug hat diese Grundlage dagegen nicht. Das erklärt, warum ein fehlendes ACK je nach Ausgangszustand sofort fehlende Konnektivität oder zunächst nur eine ausstehende Erneuerung bedeutet.

    Ein Zustand lässt sich daher durch drei Fragen beschreiben: Gibt es eine gültige Adresse? Welcher Server darf angesprochen werden? Welches Ereignis beendet das Warten? Für REQUESTING sind Bestätigung, Ablehnung und Timeout relevant; für RENEWING zusätzlich T2; für REBINDING insbesondere Ablauf. Diese Bedingungen helfen beim Lesen von Logs, die keine vollständige grafische Zustandsmaschine anzeigen.

    Neustart ist keine Zeitreise zu einer frischen Lease

    Eine lokal gespeicherte Adresse kann nach einem Neustart noch bekannt sein, ohne am neuen Anschluss gültig zu sein. INIT-REBOOT dient der Prüfung dieser bekannten Konfiguration. Ein Laptop im anderen VLAN darf nicht allein aus dem gespeicherten Wert schließen, dass Gateway und Netz weiterhin passen. Ein NAK liefert hier eine ausdrückliche negative Entscheidung; ausbleibende Antworten liefern diesen Beleg nicht.

    Im Betrieb müssen auch Uhrzeit, beobachteter Anschluss und frühere Leaseinformationen zur Rekonstruktion passen. Ein Capture, das erst nach dem Neustart beginnt, kann einen REQUEST ohne vorheriges DISCOVER völlig korrekt zeigen. Markiere deshalb fehlende Vorgeschichte als unbekannt, statt eine unvollständige Aufnahme zu einem angeblich fehlerhaften DORA-Ablauf zu erklären.

    DURCHGEARBEITETES BEISPIEL

    Ein Ausfall ab 12:00 Uhr

    1. 09:00 ACK, Lease acht Stunden, T1=vier und T2=sieben Stunden. Zustand BOUND.
    2. 12:00 Serverdienst aus. Die bereits gültige Adresse bleibt nutzbar.
    3. 13:00 RENEWING; keine Antwort. 16:00 REBINDING; weiterhin keine Antwort. 17:00 Ablauf: Adresse nicht weiterverwenden.
    4. Wird der Dienst um 16:30 wieder erreichbar und bestätigt einen REQUEST, beginnt eine neue Lease. Die alte Ablaufzeit 17:00 ist dann überholt.

    Ergebnis: Serverzustand und Clientzustand sind verschiedene Größen. Zeitpunkte ohne erfolgreiche Zwischenbestätigung lassen sich vorausberechnen.

    Typische Fehler

    • NAK ist nicht gleich Paketverlust.
    • Ein NAK beendet die erlaubte alte Nutzung früher als der ursprüngliche Ablauf.
    • Ein bloßer Seitenaufruf bewegt keinen echten Clientzustand.

    Praktisch anwenden

    Offizielle Quellen

    Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.