Das lernst du
- Den vollständigen Nachrichtenweg einschließlich Rückweg erklären.
- Falsches Ziel, fehlenden Bereich und falsche Netzzuordnung auseinanderhalten.
Voraussetzungen: F01 · Transport und ErreichbarkeitF08 · VLANs und mehrere SubnetzeF02 · DHCP-Nachrichten lesen
Der zentrale Server soll mehrere entfernte Clientnetze bedienen. Der Relay vermittelt die lokalen DHCP-Nachrichten und liefert dem Server Informationen zur Herkunft.
- DHCP-Relay
- Ein Dienst, der DHCP-Nachrichten zwischen Clientlink und entferntem Server vermittelt. Bei DHCPv4 hilft giaddr dem Server, Herkunftsnetz und Rückweg zu bestimmen.
Der Relay ergänzt die Herkunft des Pakets
Grafik vergrößern
Wie der Server das Netz erkennt
Ein klassischer Relay setzt giaddr auf eine geeignete Adresse seiner Clientseite und leitet die Anfrage zum Server weiter. Der Server kann daran den passenden Adressbereich auswählen. giaddr ist keine Gatewayoption für den Client, obwohl im einfachen Beispiel beide Adressen gleich sind.
Der Server sendet seine Antwort an den Relay, der sie auf dem richtigen Clientlink ausliefert. Relayziel, Routing in beide Richtungen, UDP-Freigaben und Zuordnung des Interfaces müssen zusammenpassen. Erweiterungen können die Auswahl beeinflussen; F09 beschreibt zunächst das klassische Modell.
Fehlerstellen voneinander trennen
Fehlt der Relay, bleibt ein lokaler DISCOVER im Clientnetz. Bei falschem Ziel gelangt die Anfrage zum falschen Host. Bei richtigem Ziel, aber fehlendem passenden Scope erreicht sie den Server, der keine geeignete Adresse anbieten kann.
Mehrere Relayziele können für Redundanz sinnvoll sein. Ob ein Produkt an alle Ziele sendet, wie es doppelte Relaypfade behandelt und welche Schutzregeln gelten, ist herstellerspezifisch. Eine redundante Routertopologie muss deshalb als Ganzes getestet werden.
Die vier Messpunkte eines Relaywegs
Punkt eins liegt beim Client: Dort erscheint der anfängliche Broadcast mit ciaddr=0 und noch ohne vom Relay gesetzte giaddr. Punkt zwei liegt auf dem Weg vom Relay zum Server: Jetzt ist der Server ein konkretes IP-Ziel und giaddr beschreibt den Clientlink. Punkt drei liegt am Serverausgang: Die Antwort wird an den zuständigen Relay zurückgesendet. Punkt vier liegt wieder im Clientnetz, wo der Relay die Antwort zustellt.
Vergleiche über diese Punkte hinweg insbesondere Clientidentität, xid, Nachrichtentyp und die angebotene Adresse. Äußere IP-Adressen können sich ändern, ohne dass eine neue Clienttransaktion entsteht. Fehlt Punkt zwei, untersuchst du Relayaktivierung und Hinweg; fehlt Punkt vier trotz sichtbarer Serverantwort, untersuchst du Rückweg und Auslieferung. Diese Reihenfolge reduziert die Zahl gleichzeitig plausibler Fehlerquellen.
giaddr ist weder Clientadresse noch Gatewayoption
Im Nordlicht-Büronetz kann giaddr=192.168.10.1 lauten. Der Server ordnet die Anfrage damit .10.0/24 zu, obwohl er selbst auf .20.10 läuft. Die angebotene Clientadresse bleibt zum Beispiel .10.120. Option 3 kann ebenfalls .10.1 als Standardgateway nennen, doch diese Gleichheit entsteht aus der Topologie; die Felder erfüllen verschiedene Aufgaben.
Eine falsche giaddr kann zu einem falschen Scope oder zu keiner passenden Zuweisung führen. Ein korrektes Relayziel .20.10 allein genügt deshalb nicht. Bei redundanten Routern oder mehreren Adressen auf einem Interface muss das tatsächlich verwendete Herkunftsfeld geprüft werden. Erweiterungen wie Option 82 ergänzen diesen Kontext, ersetzen aber keine überprüfte grundlegende Relayarchitektur.
Richtiges Ziel, falsches Herkunftsnetz
- Ein Büro-PC sendet im Netz 192.168.10.0/24. Der Relay erreicht 192.168.20.10, setzt jedoch fälschlich eine Adresse des Gästenetzes als Herkunft.
- Capture am Server: giaddr passt nicht zum Büro. Der Server kann dadurch den falschen Scope auswählen oder keine passende Zuordnung finden.
- Clientseitiges Relayinterface und Netzzuordnung korrigieren; nicht einfach einen Büro-Pool im Gästenetz anlegen.
- Neu beziehen, ACK und Clientmaske prüfen. Rückweg und die tatsächliche Gatewayoption separat kontrollieren.
Ergebnis: Eine korrekte Server-IP reicht nicht. Die Herkunftsinformation entscheidet mit darüber, welche Konfiguration angeboten wird.
Typische Fehler
- giaddr und Option 3 sind verschiedene Dinge.
- Ein Relay ist nicht automatisch ein zweiter DHCP-Server.
- Fehlender Scope und fehlendes Relay erzeugen beide Stille beim Client, aber unterschiedliche Beobachtungen am Server.
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
- RFC 3046 · Relay Agent Information ↗Option 82, Circuit ID und Remote ID; Januar 2001
- ISC · Kea DHCPv4 Server ↗Festes Lehrprofil: Kea 3.0.2; keine Annahme, dass dies die neueste Version ist