Das lernst du
- Circuit ID und Remote ID als Herkunftsinformationen einordnen.
- Vertrauensgrenzen für Relayinformationen planen.
Voraussetzungen: F09 · DHCP-Relay und giaddrE01 · Paketaufbau bis auf Byteebene
giaddr beschreibt eine wichtige Layer-3-Herkunft. In größeren Zugangsnetzen möchte die Administration zusätzlich wissen, über welchen Anschluss oder welchen Relay ein Client kam.
- Option 82
- Zusätzliche Herkunftsinformationen eines DHCPv4-Relays, etwa zum Zugangskreis. Sie können serverseitige Regeln unterstützen, sind aber ohne kontrollierte Vertrauensgrenze kein Identitätsnachweis.
Herkunft bekommt einen kontrollierten Absender
Grafik vergrößern
Was Option 82 ergänzt
Die Relay Agent Information Option enthält Unteroptionen. Circuit ID bezeichnet einen vom Relay identifizierten Zugangskontext, Remote ID einen weiteren Relay-/Teilnehmerbezug. Die Werte sind keine universell formatierten VLAN- oder Portnummern; ihre Struktur und Auswertung hängen von Gerät und Konfiguration ab.
Ein Server kann diese Informationen für Auswahl und Richtlinien verwenden. Das bedeutet nicht, dass jeder DHCP-Server jede gewünschte Option-82-Policy unterstützt. Die Antworten werden entsprechend der Erweiterung behandelt; der vertrauenswürdige Relay übernimmt das Entfernen/Verarbeiten vor der Auslieferung an den Client.
Vertrauen ist Teil der Architektur
Herkunftsangaben helfen nur, wenn sie aus einer kontrollierten Quelle stammen. An Zugangsports dürfen beliebige Clients nicht als vertrauenswürdige Relays auftreten. Plane, ob eingehende Relayinformationen verworfen, ersetzt oder nur auf definierten Uplinks akzeptiert werden.
Mehrere Relaystufen, redundante Router und herstellerspezifische Ergänzungen können unerwartete Kombinationen erzeugen. Vergleiche Rohbytes am Server mit der Dokumentation und einem bekannten funktionierenden Anschluss. Keine Policy auf einer geratenen Zeichenkettendarstellung aufbauen.
Herkunft vom Eingangsport bis zur Policy verfolgen
Circuit ID und Remote ID sind durch den Relay gelieferte Kontextdaten. Angenommen, zwei Anschlüsse gehören zum gleichen IPv4-Subnetz, sollen aber unterschiedliche Geräteprofile erhalten. giaddr kann bei beiden identisch sein, während Circuit ID den Zugang unterscheidet. Eine unterstützte Serverpolicy kann diesen zusätzlichen Kontext auswerten. Vorher muss jedoch geprüft werden, wie genau der Relay die Werte kodiert und ob das Format über Neustarts oder Konfigurationswechsel stabil bleibt.
Vergleiche die Anfrage vor und nach dem Relay sowie am Server. Im Rückweg muss die Erweiterung gemäß Relayverhalten wieder behandelt werden; der Client soll nicht selbst die Herkunftszuordnung bestimmen. Eine hexadezimale Darstellung in einer Oberfläche und eine Textdarstellung in einer anderen können dieselben Bytes meinen, aber auch unterschiedliche Werte. Baue Regeln auf dokumentierten Rohwerten statt auf optisch ähnlichen Anzeigen.
Eine negative Gegenprobe gehört zur Vertrauensgrenze
Eine Policy ist erst sinnvoll geprüft, wenn ein berechtigter Anschluss das gewünschte Profil erhält und ein anderer Anschluss es gerade nicht erhält. Ergänze außerdem den Fall fehlender oder unerwarteter Relayinformation. Der Server muss dabei eine bewusst gewählte Standardbehandlung besitzen, etwa einen begrenzten Bereich oder keine Vergabe; welches Verhalten geeignet ist, folgt aus den Anforderungen.
Auf dem Zugangsnetz muss verhindert werden, dass unkontrollierte Quellen glaubwürdige Relaydaten einschleusen. Das ist eine Geräte- und Topologieentscheidung, keine Eigenschaft der Option allein. Bei mehreren Relaystufen dokumentierst du zusätzlich, wer Informationen setzt, weiterreicht oder entfernt. Sonst kann eine gut gemeinte Zwischenkomponente die Voraussetzungen einer serverseitigen Regel unbemerkt verändern.
Ein Client landet in der falschen Geräteklasse
- Standort A meldet Circuit ID als binäre Portkennung, Standort B nach einem Update in einer anderen Darstellung. Eine stringbasierte Policy trifft nur auf A zu.
- Capture an beiden Relays und am Server vergleichen. Prüfen, ob Option 82 hinzugefügt, verändert oder entfernt wurde.
- Eine dokumentierte, produktspezifisch unterstützte Matchingregel erstellen und mit mindestens einem passenden sowie einem nicht passenden Anschluss testen.
- Für unbekannte Herkunft eine bewusst definierte Standardbehandlung wählen. Das Verhalten und die Vertrauensports dokumentieren.
Ergebnis: Option 82 liefert Kontext, keine automatische Authentizität. Funktionsunterstützung und Vertrauensgrenze müssen zusammen abgenommen werden.
Typische Fehler
- Circuit ID ist nicht zwingend eine lesbare Portnummer.
- Ungeprüfte clientseitige Option-82-Werte sind keine sichere Identität.
- Die Browser-Relayfunktion bildet diese Erweiterung nicht nach.
Praktisch anwenden
Offizielle Quellen
Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.
- 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
- Cisco · DHCP Snooping ↗Catalyst 9300, IOS XE 17.13.x; Kommandos nicht auf beliebige Switches übertragen