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

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.

• DHCPDISCOVER: Client sucht einen Server (Broadcast, typischerweise 0.0.0.0 → 255.255.255.255)
• DHCPOFFER: Server bietet eine IP/Lease an
• DHCPREQUEST: Client fordert die angebotene Lease an
• DHCPACK: Server bestätigt Lease inkl. Optionen (Gateway, DNS, Domain, etc.)

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.

• Clients bekommen gar keine IP: Discover/Relay/Server-Erreichbarkeit, Snooping/ACLs, VLAN falsch
• Clients bekommen falsches Subnetz: falsches VLAN, falscher Scope, falsches Relay-Interface/VRF
• Nur manche Clients betroffen: Port-spezifische Security (Snooping, Port Security, 802.1X), Hashing/LAG, AP/SSID-Mapping
• Nach einiger Zeit bricht es: Lease Renewal scheitert (T1/T2), Server nicht erreichbar, Option 82/Policy, Pool erschöpft
• Viele „Duplicate IP“ Meldungen: Konflikte durch falsch wiederverwendete Leases, Rogue DHCP, ARP/DAI-Interaktion

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.

• Beweis 1: Sie sehen DHCPDISCOVER am Client-Segment (oder am Switchport/SPAN).
• Beweis 2: Relay setzt giaddr (Gateway-IP des Relay) oder Option 82 und leitet weiter.
• Beweis 3: DHCP-Server erhält Request und wählt korrekten Scope/Pool.
• Beweis 4: Offer/Ack kommt zurück bis zum Relay und weiter bis zum Client.
• Beweis 5: Client akzeptiert Lease und installiert IP/Gateway/DNS.

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

• giaddr falsch oder fehlt: Server kann Scope nicht zuordnen → kein Offer oder Offer aus falschem Pool
• Falscher DHCP-Server/Helper: Relay zeigt auf falsche Server-IP oder falsche VRF
• Routing/VRF-Fehler: Relay kann Server nicht erreichen oder Rückweg fehlt
• ACL/Firewall blockt UDP 67/68: Discover kommt raus, Offer/Ack kommen nicht zurück
• Anycast Gateway/Cluster-Design: mehrere Relays, aber Server-Policy erwartet nur bestimmte giaddr

Evidence, die Relay-Probleme schnell beweist

• PCAP am SVI: giaddr gesetzt? Wird Request als Unicast an Server geschickt?
• Server-Logs: sieht der Server die giaddr/Relay-IP und wählt richtigen Scope?
• Routing-Check: Kann Relay in der richtigen VRF den Server erreichen (und umgekehrt)?
• Rückweg-Check: Kommen Offers am Relay an, werden sie ins VLAN zurückgeführt?

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

• Server lehnt Requests ab: Policy erwartet Option 82, aber sie fehlt oder ist anders formatiert
• Falsche Zuweisung: Client bekommt IP aus falschem Bereich, weil Circuit-ID falsch ist (z. B. VLAN/Port geändert)
• Inkonstanz in LAG/Port-Channel: Circuit-ID schwankt je nach Member → sporadische IPs/Policies
• Mehrere Relay-Stufen: Option 82 wird überschrieben oder doppelt gesetzt

Option 82 sicher interpretieren

• Was steht drin? Circuit-ID/Remote-ID im Capture auslesen und mit Dokumentation vergleichen.
• Wer setzt Option 82? Access-Switch, Distribution, oder Gateway? Doppelte Setzung vermeiden.
• Wird Option 82 „trusted“? In manchen Designs dürfen Endgeräte Option 82 nicht selbst setzen; das muss gefiltert werden.
• Policy-Impact: Server-Policies prüfen: Wird ohne Option 82 gedroppt? Gibt es Fallback-Scope?

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

• Trusted Ports falsch gesetzt: Uplink zum DHCP-Server/Relay ist untrusted → Offers/Acks werden gedroppt
• Snooping nur auf Teilstrecke aktiv: Bindings fehlen upstream, DAI blockt später ARP → „IP bekommen, aber kein Netz“
• Option 82 Interaktion: Snooping fügt Option 82 hinzu oder erwartet sie; Server-Policy passt nicht
• Rate Limits: DHCP Snooping Rate Limit zu niedrig → bei Boot-Storm werden Requests gedroppt
• VLAN nicht aktiviert: Snooping ist global an, aber das betroffene VLAN ist nicht in der Snooping-Liste

High-Signal Evidence bei Snooping-Problemen

• Switch-Logs: „DHCP snooping drop“ mit Grund (untrusted, rate-limit, invalid)
• Binding Table: Wird der Client überhaupt eingetragen (IP/MAC/Port/VLAN)?
• PCAP: Discover geht raus, Offer kommt am Access-Switch an, wird aber nicht zum Client forwarded
• DAI-Events: ARP wird geblockt, obwohl DHCP-Lease existiert (Binding fehlt oder falsch)

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

• Symptom: Server sendet keine Offers mehr oder bietet 169.254.x.x (APIPA) auf Clients
• Ursachen: zu kleiner Pool, viele Geräte/Guests, Leases zu lang, „Zombie“-Leases durch Geräte, die nie sauber releasen
• Evidence: DHCP-Server zeigt hohe Auslastung, freie Adressen = 0; Logs melden „no free leases“
• Fix-Richtung: Pool erweitern, Lease Time anpassen, Rogue/Loop-Devices identifizieren

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

• Symptom: Clients funktionieren zunächst, verlieren später Connectivity oder wechseln IP
• Ursachen: DHCP-Server nicht erreichbar für Renew, Routing/Firewall nur zeitweise blockt, VRF-Änderungen, HA-Failover mit fehlendem State
• Evidence: PCAP zeigt DHCPREQUEST Renew, aber kein DHCPACK; Server-Logs fehlen oder zeigen Reject
• Fix-Richtung: Rückweg/ACLs prüfen, HA-Synchronisation, Relay-Quelle (giaddr) stabilisieren

Duplicate IP und Konflikte

• Symptom: IP-Konfliktmeldungen, ARP-Flapping, sporadische Erreichbarkeit
• Ursachen: statische IP im DHCP-Bereich, VM-Klon, falsch konfigurierte Reservierungen, fehlende Conflict Detection
• Evidence: zwei MACs beanspruchen gleiche IP (ARP/Logs), Switch MAC-Table zeigt Moves
• Fix-Richtung: IPAM/Reservations, DHCP Exclusions, Konfliktgerät lokalisieren

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.

• Symptom: Clients bekommen unerwartete Gateways/DNS, unterschiedliche Antworten je nach Standort/Port
• Nachweis: PCAP zeigt DHCPOFFER von einer unerwarteten Server-IP/MAC
• Fix-Richtung: Rogue isolieren (Switchport), Snooping korrekt aktivieren, Trust-Ports sauber setzen

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.

• Nur ein VLAN betroffen: Allowed VLAN fehlt auf einem Trunk oder in einem Port-Channel-Member
• Falsche IP/Subnetz: Endgerät hängt im falschen VLAN (PVID/Tagging falsch)
• DHCP geht, aber danach kein Netz: DAI/ARP wird geblockt oder Gateway-SVI stimmt nicht zum VLAN

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.

• Vergleichsclient: Funktioniert DHCP an einem anderen Port im gleichen VLAN? Wenn ja, ist es port-/access-spezifisch.
• VergleichsvLAN: Funktioniert DHCP in VLAN X, aber nicht in VLAN Y? Dann ist es VLAN/Relay/Scope-spezifisch.
• Direkt am Relay: Testhost im gleichen SVI/Segment wie Relay? Wenn dort DHCP geht, ist die Access-Strecke (Trunk/Snooping) verdächtig.
• Option 82 toggeln (kontrolliert): Wenn Policy es erlaubt, testweise Option 82 ohne Production-Impact vergleichen.
• Rate/Boot-Storm: Bei vielen gleichzeitigen Boots prüfen, ob Snooping/Server rate-limited.

Runbook-Baustein: DHCP Troubleshooting in 15 Minuten

• Minute 0–3: Symptom klassifizieren (kein Lease vs. falsche Lease vs. Renewal/Pool). Betroffenes VLAN/Subnetz und Gateway-SVI identifizieren.
• Minute 3–6: PCAP oder Switch-Sicht: sehen Sie Discover? Kommt Offer/Ack zurück? Wenn nein: Pfad eingrenzen (VLAN/Trunk/Relay/ACL).
• Minute 6–9: Relay prüfen: giaddr/VRF/Helper korrekt? Server erreicht? Server-Logs zeigen Requests? Option 82 vorhanden und erwartbar?
• Minute 9–12: Snooping prüfen: VLAN aktiviert? Trust-Ports korrekt? Drops/Rate-Limits? Binding Table korrekt? DAI blockt nach DHCP?
• Minute 12–15: Lease/Scope prüfen: Pool frei? Konflikte? Renewal-Fehler? Danach gezielter Fix (Allowed VLAN/Trust/Policy/Scope) und Verifikation (DISCOVER→ACK vollständig, stabile Connectivity).

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.

• Scope Monitoring: freie Leases, Auslastung, Conflict-Rate, Top-Requesters
• Relay Standards: Helper/giaddr/VRF konsistent, dokumentiert, change-kontrolliert
• Option 82 Governance: klare Policy, stabile Circuit-ID/Remote-ID, Umgang mit LAG/Member-Wechsel
• Snooping Templates: Trust-Ports eindeutig (Uplinks/Relays), Rate Limits passend, VLAN-Liste gepflegt
• Forensik-Ready: SPAN/Telemetry/Logs so, dass Discover/Offer/Ack im Incident schnell nachweisbar sind

Weiterführende Quellen für Standards und Praxis

• RFC 2131 für DHCPv4 (Ablauf, State Machine)
• RFC 2132 für DHCP Options
• RFC 3046 für Option 82 (Relay Agent Information)
• RFC 8415 für DHCPv6 (wenn IPv6 im Scope ist)
• Wireshark Dokumentation für DHCP/Option-Analyse und Filter
• tcpdump Manpage für effiziente Captures und BPF-Filter

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.