Site icon bintorosoft.com

DHCP Troubleshooting: Relay, Option 82, Snooping und Lease-Probleme

Red Snapper

Close-up of network equipment with cables in a modern server room.

DHCP Troubleshooting gehört zu den häufigsten Aufgaben im Netzwerkbetrieb, weil DHCP (Dynamic Host Configuration Protocol) am Anfang fast jeder Client-Kommunikation steht: Ohne gültige Lease gibt es keine IP-Adresse, kein Default Gateway, keine DNS-Server – und damit „geht gar nichts“. Gleichzeitig sind DHCP-Fehler berüchtigt, weil sie sich je nach Architektur unterschiedlich äußern: Im einen VLAN bekommen Clients gar keine Adresse, im nächsten nur sporadisch, an einem Standort laufen Leases aus, an einem anderen werden falsche IPs verteilt. In modernen Netzen ist DHCP zudem selten „nur ein Server“: Relay-Agenten in SVIs, Anycast-Gateways, VRFs, zentrale DHCP-Cluster, Option 82 (Relay Agent Information), DHCP Snooping, Dynamic ARP Inspection und Port Security greifen ineinander. Genau diese Kombination erzeugt im Incident Stress – und viele False Leads („Firewall blockt“, „Switch kaputt“, „Client spinnt“). Dieser Artikel zeigt ein professionelles, evidenzbasiertes Vorgehen für DHCP Troubleshooting: Wie Sie den DHCP-Handshake sauber nachweisen, wie Relay und Option 82 wirklich funktionieren, welche Snooping-Fallen es gibt und wie Sie Lease-Probleme, Pool-Exhaustion und Konflikte schnell isolieren – ohne Blindflug und ohne Sicherheitsmechanismen vorschnell abzuschalten.

DHCP-Grundlagen, die Sie im Troubleshooting wirklich brauchen

DHCP ist ein Broadcast-basiertes Protokoll (im lokalen Segment), das über einen klaren Vier-Schritt-Ablauf arbeitet. Dieser Ablauf ist Ihre wichtigste mentale Checkliste, denn jede Störung lässt sich einer Phase zuordnen: Discover erreicht den Server nicht, Offer kommt nicht zurück, Request wird verworfen, Ack kommt nicht an oder wird nicht akzeptiert.

Die Spezifikation für DHCPv4 ist in RFC 2131 beschrieben, die Options-Liste in RFC 2132. Für DHCPv6 gilt u. a. RFC 8415 (wichtiger Hinweis: DHCPv6 unterscheidet sich konzeptionell von DHCPv4, insbesondere weil IPv6 zusätzlich Neighbor Discovery/SLAAC nutzen kann).

Warum die Richtung im DHCP-Flow zählt

DHCP ist nicht „nur Broadcast“. In vielen Designs geht der Discover lokal als Broadcast raus, aber die Antworten (Offer/Ack) laufen als Unicast zurück – und zwar abhängig von Client- und Relay-Verhalten. Genau deshalb sind VLAN/Trunk-Fehler, ACLs und Security-Features häufig nur in eine Richtung wirksam. Ein Klassiker: Discover ist sichtbar, Offer wird geloggt, aber der Client sieht nie ein Ack.

High-Signal Symptome: So erkennen Sie DHCP-Probleme schnell

Bevor Sie tief in Konfigurationen springen, klassifizieren Sie das Symptom. Das spart Zeit, weil es die wahrscheinlichste Fehlerdomäne eingrenzt.

Methodik: DHCP Troubleshooting als Beweiskette

Der schnellste Weg zur Lösung ist eine Beweiskette entlang des Pfads: Client-Segment → Access/Distribution → Relay (SVI/Gateway) → Routing/VRF → DHCP-Server → Rückweg. Jeder Schritt liefert Evidence, die Hypothesen bestätigt oder ausschließt.

PCAP als Schnelltest (gezielt, nicht großflächig)

Ein kurzer Capture ist oft der schnellste Beweis: Sie sehen Discover/Offer/Request/Ack inklusive Optionen und Relay-Felder. Nutzen Sie Filter (z. B. UDP 67/68) und capturen Sie möglichst nah am Problem (Clientport oder SVI/Relay). Praxisreferenzen sind die Wireshark-Dokumentation und die tcpdump-Manpage.

DHCP Relay Troubleshooting: giaddr, VRF und Rückweg

In gerouteten Netzen sitzt der DHCP-Server meist nicht im gleichen Broadcast-Domain wie die Clients. Dann übernimmt ein DHCP Relay Agent (meist das SVI/Default Gateway) die Aufgabe, Broadcasts in Unicast zum Server zu übersetzen. Entscheidend ist dabei das Feld giaddr (Gateway IP Address): Es signalisiert dem Server, aus welchem Subnetz/Interface die Anfrage kommt, damit der richtige Pool gewählt wird.

Typische Relay-Fehlerbilder

Evidence, die Relay-Probleme schnell beweist

Option 82 Troubleshooting: Wenn Policy gegen Betrieb arbeitet

Option 82 (Relay Agent Information Option) ergänzt DHCP um Kontext: Der Relay kann Informationen wie Circuit-ID (Port/VLAN) und Remote-ID (Switch-ID) einfügen. Das ist extrem nützlich für IPAM, Standortzuordnung, Security und feste Zuweisungen (z. B. „Port A bekommt immer Range X“). Gleichzeitig ist Option 82 eine häufige Incident-Ursache, wenn Server-Policies strikt sind oder wenn Relay-Informationen inkonsistent werden.

Option 82 ist u. a. in RFC 3046 beschrieben.

Typische Option-82 Fehlerbilder

Option 82 sicher interpretieren

DHCP Snooping: Schutz vor Rogue DHCP – und Quelle vieler False Positives

DHCP Snooping ist ein Switch-Feature, das DHCP-Server-Antworten (Offer/Ack) nur über trusted Ports zulässt. Damit wird verhindert, dass ein Rogue DHCP Server im Access Netz IPs verteilt. Gleichzeitig erstellt Snooping häufig eine Binding Table (IP↔MAC↔Port↔VLAN), die später für Dynamic ARP Inspection (DAI) genutzt wird. Falsch konfiguriert blockt Snooping legitime DHCP-Antworten – und dann wirkt DHCP „kaputt“, obwohl der Server korrekt arbeitet.

Typische Snooping-Fallen

High-Signal Evidence bei Snooping-Problemen

Lease-Probleme: Pool Exhaustion, Renewal, Konflikte und „Stale State“

Nicht jedes DHCP-Problem ist ein „Transportproblem“. Sehr häufig ist der Server erreichbar, aber die Lease-Logik bricht: Pools sind leer, Leases werden nicht erneuert, Reservierungen sind falsch, oder es gibt Konflikte durch Duplicate IPs.

Pool Exhaustion: Wenn der Scope leerläuft

Renewal-Probleme (T1/T2): Wenn es nach Stunden/Tagen kippt

Duplicate IP und Konflikte

Rogue DHCP erkennen: Wenn ein falscher Server „hilft“

Ein Rogue DHCP Server ist eine der gefährlichsten Ursachen, weil er scheinbar „Lösungen“ liefert: Clients bekommen IPs – nur eben falsche (falsches Gateway/DNS), und dadurch ist das Netz „halb kaputt“. DHCP Snooping ist das Gegenmittel, aber ohne Snooping muss man Rogue DHCP aktiv nachweisen.

DHCP und VLAN/Trunk: Die stille Abhängigkeit

Viele DHCP-Incidents sind eigentlich VLAN/Trunk-Probleme: Discover bleibt im falschen VLAN, oder der DHCP-Server ist zwar erreichbar, aber die Rückantwort kommt nicht ins richtige Segment zurück. Besonders häufig bei Allowed VLANs, Native VLAN Mismatch, QinQ oder AP/SSID-Mapping.

Praktische Trennmessungen: Schnell zur Fehlerdomäne

Trennmessungen helfen, die Ursache in Minuten statt Stunden einzugrenzen. Sie benötigen dafür nicht zwingend große Tools, sondern kluge Vergleichspunkte.

Runbook-Baustein: DHCP Troubleshooting in 15 Minuten

Stabile Betriebs-Baselines: So wird DHCP „langweilig“

DHCP ist am besten, wenn es langweilig ist. Dafür brauchen Teams Baselines und Guardrails, die nicht nur Sicherheit, sondern auch Betriebssicherheit erhöhen.

Weiterführende Quellen für Standards und Praxis

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version