DHCP-Optionen jenseits der Adresse (Gateway, Namensserver, Relay)

Ein Gerät hat eine Adresse aus dem richtigen Bereich, antwortet auf Anfragen aus dem eigenen Netzabschnitt und ist trotzdem für die Hälfte der Anlage tot. Adresse geprüft, Adresse in Ordnung — und der Fehler sitzt in derselben Antwort ein paar Zeilen später.

Denn ein DHCP-Server übergibt einem Gerät einen ganzen Satz Konfigurationsangaben, von denen die Adresse nur eine ist. Steve Alexander bei Silicon Graphics und Ralph Droms an der Bucknell University haben diese Angaben 1997 als nummerierte Optionen festgelegt: Netzmaske, Standardrouter, Namensserver, Domänenname, Zeitserver und rund zweihundert weitere, von denen im Wohnhaus eine Handvoll zählt.

Was mit der Adresse mitkommt

Die Angaben, die im Wohnhaus praktisch immer eine Rolle spielen, sind diese fünf:

Bei Option 3 und 6 verlangt die Festlegung ausdrücklich, dass die Einträge in der Reihenfolge der Bevorzugung stehen. Das ist keine Formalie: Ein Gerät arbeitet die Liste von oben ab, und ein an erster Stelle eingetragener, aber abgeschalteter Namensserver erzeugt genau die Verzögerungen, die als „das Netz ist langsam" gemeldet werden.

Der Server drängt diese Angaben nicht auf. Das Gerät gibt in seiner Anfrage eine Liste der Optionen an, die es haben möchte, aufgeführt nach Kennziffern — die Parameter Request List. Was dort nicht steht, bekommt es im Zweifel auch nicht, selbst wenn der Server es anbieten könnte. Wer also eine Option einträgt und danach nichts beobachtet, hat womöglich beides richtig gemacht und trotzdem keine Wirkung erzielt.

Warum das Fehlerbild wie ein Adressproblem aussieht

Alle diese Werte stammen aus einem einzigen Vorgang. Wenn er schiefgeht, prüft jeder zuerst die Adresse — sie ist sichtbar, sie steht im Gerätemenü, und sie stimmt.

Drei Bilder wiederholen sich in der Inbetriebnahme:

• Standardrouter falsch oder fehlt. Das Gerät ist von jedem Rechner im selben Abschnitt erreichbar. Sobald die Steuerung aus einem anderen Segment kommt oder das Gerät eine Lizenz prüfen will, ist Schluss. Der Befund lautet dann meistens „das VLAN ist schuld", und die Trennung ist unschuldig.
• Namensserver falsch. Alles, was über Adressen läuft, arbeitet; alles, was über Namen läuft, nicht. In AV-Anlagen trifft das zuerst Streaming-Dienste und Herstellerportale, während die Bedienung im Haus weiterläuft — ein Zustand, den niemand mit dem Netz in Verbindung bringt.
• Netzmaske falsch. Das seltenste und unangenehmste Bild, weil es einseitig auftritt: Zwei Geräte im selben Abschnitt erreichen einander in einer Richtung und in der anderen nicht.

Die Prüfung dauert eine Minute und gehört an den Anfang jeder Fehlersuche: neben der Adresse auch ansehen, welchen Router und welchen Namensserver ein Gerät dazu bekommen hat.

Herstellerspezifische Optionen

Zwei Optionen arbeiten zusammen und lösen ein Problem, das Geräte allein nicht lösen können: Wie findet ein Gerät die Gegenstelle, zu der es gehört, wenn die nicht im selben Netzabschnitt steht?

Das Gerät meldet in seiner Anfrage mit Option 60 eine Kennung seines Typs — den Vendor Class Identifier. Erkennt der Server sie, gibt er in der Antwort unter Option 43 eine für diesen Typ hinterlegte Angabe zurück, meist die Adresse eines Verwaltungsservers. Die Festlegung regelt beides sauber: Der Hersteller wird über die Vendor-Class-Kennung angezeigt, Server ohne passende Interpretation müssen die Angabe ignorieren, und wer antwortet, soll die herstellerspezifische Information nur über Option 43 zurückgeben.

Für die Planung ist daran eines wichtig: Diese Optionen muss jemand eintragen können. Provider-Router bieten das häufig nicht an, und dann entscheidet eine scheinbare Nebensache — wer im Haus den DHCP-Server betreibt — darüber, ob eine Geräteklasse überhaupt in Betrieb geht. Die Frage gehört deshalb in die Konzeptphase und nicht auf die Baustelle.

Über Segmentgrenzen: das Relay

DHCP beginnt mit einem Rundruf, denn ein Gerät ohne Adresse kann niemanden gezielt ansprechen. Rundrufe bleiben in ihrem Netzabschnitt — und damit hat jedes getrennte Segment zunächst kein DHCP.

Zwei Auswege gibt es. Entweder betreibt jedes Segment einen eigenen Server; in AV-Anlagen kommt das häufiger vor, als man denkt, weil manche Steuersysteme für ihre Endgeräte ein eigenes Netz mitbringen und darin selbst als Server arbeiten — die 4-Series-Steuersysteme von Crestron etwa vergeben in ihrem Control Subnet Adressen aus 10.0.0.0/8 und weichen auf 172.22.0.0/16 aus, wenn sich das mit dem Hausnetz überschneidet.

Oder ein Relay-Agent reicht die Anfrage über die Grenze weiter. Dabei passiert etwas, das man kennen muss: Der Relay schreibt seine eigene Adresse in das Feld giaddr, und der Server wählt daran den Adressvorrat aus. Ist giaddr null, kommt die Antwort aus dem Vorrat des Segments, aus dem die Nachricht stammt; andernfalls aus dem, der zur Adresse des Relays gehört. Ein falsch angeschlossener oder auf der falschen Schnittstelle konfigurierter Relay vergibt deshalb Adressen aus dem falschen Segment — mit passender Netzmaske, passendem Gateway und allem, was dazugehört. Das Gerät ist dann sauber konfiguriert, nur für das falsche Netz.

Michael Patrick bei Motorola hat 2001 dafür eine Erweiterung festgelegt, die in größeren Anlagen den Ausschlag gibt: Mit Option 82 fügt der Relay dem Server vertrauenswürdige Angaben über die Herkunft bei — eine Circuit ID für den Anschluss, über den die Anfrage kam, und eine Remote ID für den entfernten Client. Damit kann ein Server unterscheiden, was ihm ein Gerät über sich selbst erzählt und was das Netz über das Gerät weiß.

Unter IPv6 sieht es anders aus

Dort kommen die Adressen im Regelfall ohne Server zustande, die übrigen Angaben aber nicht von selbst. Zwei Wege stehen nebeneinander: Der Router gibt die Namensserver in seiner regelmäßigen Ankündigung mit — die Optionen dafür stammen aus einer Festlegung von 2017 —, oder ein Gerät holt sich die Angaben im zustandslosen DHCPv6-Betrieb, also mit einer Anfrage nach Konfiguration und ohne jeden Adressbezug. Wo beides zusammentrifft, stehen die über DHCP bezogenen Angaben vor denen aus der Router-Ankündigung.

Praktische Folge für eine Anlage mit beiden Verfahren: Namensserver werden an zwei Stellen gepflegt. Wer nur den DHCP-Server ändert, hat die Hälfte der Geräte erwischt.

Häufiges Missverständnis

„Das Gerät hat eine Adresse, also arbeitet DHCP richtig." Die Adresse ist der eine Wert, den man ohne Hilfsmittel sieht — und gleichzeitig derjenige, der am seltensten falsch ist. Ein Server, dessen Adressvergabe stimmt und dessen Standardrouter aus einer alten Einrichtung stammt, produziert wochenlang unauffällige Geräte, bis eines davon zum ersten Mal aus seinem Segment heraus will.

„Dann stelle ich Gateway und Namensserver am Gerät fest ein." Damit verlagert sich dasselbe Problem, das bei fest eingestellten Adressen entsteht: Die Festlegung liegt im Gerät und nicht dort, wo jemand sie lesen und ändern kann. Wechselt der Router oder der Namensserver, ist jedes so eingestellte Gerät einzeln anzufassen — und gefunden werden sie erst, wenn sie ausfallen. Wie diese Abwägung bei der Adresse selbst ausgeht, steht bei IP-Adressierung im Wohnhaus; für die übrigen Angaben gilt sie unverändert.

„Option 3 heißt Gateway." Im Standard heißt sie Router, und in Bedienoberflächen steht meistens „Standardgateway" oder „Default Gateway". Gemeint ist dasselbe. Die Namensverwirrung wäre folgenlos, wenn sie nicht die Suche erschwerte: Wer in der Dokumentation seines DHCP-Servers nach „Gateway" sucht und nichts findet, sucht unter der falschen Bezeichnung.

Nicht zu verwechseln mit

• DHCP-Reservierung: legt fest, welche Adresse ein bestimmtes Gerät bekommt. Über Standardrouter und Namensserver sagt sie nichts — die kommen aus den Optionen und gelten für alle im Segment.
• DHCP-Vorrat: der Adressbereich, aus dem vergeben wird. Er entscheidet über die Adresse, nicht über das, was mitkommt.
• Namensauflösung: die Arbeit, die ein Namensserver leistet. Hier geht es allein darum, wie ein Gerät erfährt, welchen es fragen soll.
• DHCP-Relay gegen DHCP-Server: Der Relay antwortet nie selbst, er reicht weiter und markiert die Herkunft. Ein Segment mit Relay hat keinen eigenen Server, und wenn die Verbindung zum Server abreißt, bekommt dort niemand mehr eine Adresse.
• Multicast-Weiterleitung über Segmentgrenzen: betrifft die Gerätesuche, nicht die Konfiguration. Beide scheitern an derselben Grenze, brauchen aber verschiedene Abhilfen — die Discovery-Seite führt das aus.

In der Inbetriebnahme

Ein Haus mit vier Segmenten, DHCP-Server im Router, Steuerzentrale und AV-Geräte im AV-Segment, Kameras und Haustechnik getrennt. Die Adressen sind geplant, die Reservierungen eingetragen, alle Geräte melden sich. Drei Wochen später ruft der Kunde an: Die Kamera-App zeigt zu Hause Bilder, unterwegs nicht, und der Kinoraum spielt lokal alles ab, findet aber keinen Streaming-Dienst.

Vor jeder Gerätefrage steht die Konzeptfrage: Welche Geräte müssen ihr Segment verlassen, und wohin? Die Kameras müssen zur Aufzeichnung, das Kinogerät ins Internet, die Steuerzentrale in alle Segmente. Aus dieser Liste ergibt sich, wo überhaupt ein Standardrouter und ein Namensserver gebraucht werden — und in welchem Segment die Antwort eine andere sein muss als im Nachbarsegment.

Die Verfahrensfrage folgt: ein Server mit Relay in jedem Segment oder ein Server je Segment? Ein Server mit Relay hält die Optionen an einer Stelle, macht aber jedes Segment vom Weg dorthin abhängig. Server je Segment sind robuster und vervierfachen die Pflege. Was hier gewählt wird, entscheidet auch, wer die Anlage später betreuen kann.

Zum Schluss die Geräte, und zwar mit einer Prüfung, die selten gemacht wird: an jedem Gerätetyp einmal nachsehen, welche Angaben er tatsächlich bezogen hat — neben der Adresse also Router, Namensserver und Domänenname. Diese fünf Minuten je Segment ersetzen den Anruf aus dem Absatz oben.

Verknüpfte Inhalte

Adressbereiche, Netzmaske, die drei Vergabewege und die Frage, welche Geräte eine feste Adresse brauchen, stehen bei IP-Adressierung im Wohnhaus; diese Seite setzt sie voraus und behandelt allein, was neben der Adresse verteilt wird. Wie dieselben Angaben unter IPv6 zustande kommen, führt IPv6 im Wohnhaus aus. Warum getrennte Segmente Rundrufe stoppen und was das über DHCP hinaus bedeutet, steht bei VLAN und Subnetz und, für die Gerätesuche, in den Heimnetzwerk-Grundlagen. Warum ein Gerät von außen zunächst nicht erreichbar ist, behandelt NAT und Portweiterleitung.

Quellen

Die Optionsnummern samt Bezeichnungen, die Vorgabe zur Reihenfolge bei Routern und Namensservern und das Zusammenspiel von Vendor-Class-Kennung und herstellerspezifischer Angabe stehen in RFC 2132 von 1997, das für diese Seite im Volltext eingesehen wurde. Dass DHCP Konfigurationsparameter über die Adresse hinaus liefert, dass Relay-Agenten Nachrichten an Server außerhalb des eigenen Subnetzes weiterreichen, dass der Server den Vorrat über giaddr wählt und dass ein Gerät seine Wünsche über die Parameter Request List anmeldet, ist in RFC 2131 aus demselben Jahr belegt. Die Relay-Erweiterung mit Circuit ID und Remote ID stammt aus RFC 3046 von 2001. Der zustandslose DHCPv6-Betrieb steht in RFC 8415 von 2018, die Namensserver-Optionen der Router-Ankündigung samt Rangfolge gegenüber DHCP in RFC 8106 von 2017. Dass ein Steuersystem in seinem eigenen Segment selbst als DHCP-Server arbeitet, ist am Handbuch von Crestron zum Control Subnet belegt.