DHCP Troubleshooting: Wenn Clients keine IP-Adresse bekommen

DHCP Troubleshooting ist einer der häufigsten Einsätze im IT-Alltag, weil ohne IP-Adresse praktisch nichts funktioniert: Kein Zugriff auf interne Systeme, kein Internet, keine Anmeldung, keine Drucker, kein VoIP – und im WLAN wirkt es für Nutzer oft wie „WLAN verbunden, aber ohne Netz“. Besonders tückisch ist, dass DHCP-Probleme nicht immer als kompletter Ausfall auftreten. Manchmal bekommen Clients nur sporadisch eine Adresse, manchmal nur in bestimmten VLANs, und manchmal erhalten sie eine falsche IP aus einem unerwarteten Netz (Rogue DHCP). Um solche Störungen schnell und sauber zu lösen, braucht es einen strukturierten Ablauf: Sie prüfen zuerst den Client (Link, VLAN, Adapter, bestehende Lease), dann den DHCP-Handshake (Discover, Offer, Request, ACK), anschließend den DHCP-Pfad (Broadcast-Domäne, Relay/IP Helper, Trunks), und zuletzt DHCP-spezifische Themen wie Scope-Auslastung, Reservierungen, Optionen, Snooping/Policy und Servergesundheit. Dieser Leitfaden erklärt Schritt für Schritt, wie DHCP funktioniert, welche Ursachen in der Praxis am häufigsten sind und wie Sie mit klaren Tests und Beweisen die Fehlerquelle zuverlässig finden – vom Einsteiger bis zum Profi, direkt geeignet als Standard-Runbook für IT-Teams.

DHCP in 60 Sekunden: Was passiert beim Adressbezug?

DHCP (Dynamic Host Configuration Protocol) vergibt IP-Adressen und Netzparameter automatisiert. Der typische Ablauf in IPv4 ist der sogenannte DORA-Prozess: Discover, Offer, Request, ACK. Ein Client sendet zunächst einen Broadcast (Discover), ein DHCP-Server antwortet mit einem Angebot (Offer), der Client fordert dieses Angebot an (Request), und der Server bestätigt die Vergabe (ACK). Zusätzlich liefert DHCP wichtige Optionen wie Default Gateway, DNS-Server, Domain-Suffix oder NTP.

• Discover: Client sucht DHCP-Server (Broadcast im VLAN).
• Offer: Server bietet IP + Optionen an.
• Request: Client fordert eine konkrete IP aus dem Offer an.
• ACK: Server bestätigt, Lease startet.

Die technischen Grundlagen sind in RFC 2131 (DHCP) und den DHCP-Optionen in RFC 2132 (DHCP Options) beschrieben.

Typische Symptome: Woran Sie DHCP-Probleme sofort erkennen

Wenn Clients keine IP-Adresse bekommen, ist das Symptom meist eindeutig. Trotzdem lohnt es sich, das Fehlerbild sauber zu klassifizieren, weil die Ursache je nach Muster stark variiert.

• APIPA/Link-Local: Windows fällt oft auf 169.254.x.x zurück (kein DHCP erreicht).
• „Verbunden, kein Internet“: im WLAN häufig DHCP- oder Gateway-Option-Problem.
• Nur in einem VLAN: VLAN-Transport/Relay/Scope spezifisch fehlerhaft.
• Nur einzelne Clients: MAC-Filter/NAC/Port-Security, statische IP, Treiber, fehlerhafte Lease.
• Falsches Netz: Client erhält IP aus unerwartetem Subnetz (Rogue DHCP oder falsches VLAN).
• Sporadisch: Flapping, Broadcast-Störungen, DHCP-Snooping/DAI, Overload am Server oder WLAN.

Die häufigsten Ursachen in der Praxis

In der Realität wiederholen sich DHCP-Ursachen erstaunlich stark. Wenn Sie diese Liste im Kopf haben, sparen Sie bei jedem Incident Zeit.

• Layer 1/2 Problem: Port down, VLAN falsch, Trunk erlaubt VLAN nicht, STP/Loop/Storm.
• DHCP-Server nicht erreichbar: Server down, Dienst gestoppt, Firewall blockt UDP 67/68.
• DHCP-Relay falsch: IP Helper fehlt oder zeigt auf falschen Server, VRF/Interface falsch.
• Scope erschöpft: Keine freien Leases, zu kleiner Pool, Leases zu lange.
• Rogue DHCP: Privater Router/Hotspot im LAN vergibt falsche IPs.
• DHCP-Snooping/Policy: Untrusted Port blockt Offers, Bindings fehlen, Security-Features droppen DHCP.
• WLAN-spezifisch: SSID→VLAN Mapping, AP-Uplink nicht als Trunk, Broadcast/Multicast gefiltert.
• Optionen falsch: falsches Gateway (Option 3), falsche DNS-Server (Option 6), falsche Domain.

Der Standard-Workflow: DHCP Troubleshooting Schritt für Schritt

Der folgende Ablauf ist bewusst so aufgebaut, dass Sie in wenigen Minuten entscheiden können, ob das Problem beim Client, im VLAN/Trunk, beim Relay oder am DHCP-Server liegt. Wichtig ist: Jede Stufe liefert einen klaren „Ja/Nein“-Beweis.

Schritt: Client-Grundlagen prüfen

• Link aktiv? (LAN-Link-LED, WLAN verbunden, kein Flugmodus)
• Ist der Client im richtigen Netzsegment (SSID/VLAN)?
• Hat der Client eine alte statische IP oder eine „hängende“ Lease?
• DHCP-Client-Dienst aktiv? (besonders bei gehärteten Images oder Spezialgeräten)

Unter Windows ist ipconfig der schnellste Einstieg, um IP, Gateway, DHCP-Status und Lease-Infos zu prüfen.

Schritt: Ist es ein Einzelproblem oder ein Segmentproblem?

• Betroffen ist nur ein Client: Test mit zweitem Gerät am selben Port/SSID.
• Betroffen sind viele Clients im gleichen VLAN: Fokus auf VLAN/Trunk/Relay/Scope.
• Betroffen ist ein kompletter Standort: Fokus auf WAN/Edge/Relay/zentralen DHCP-Dienst.

Schritt: DHCP-Pfad logisch prüfen (Broadcast vs. Relay)

DHCP Discover ist ein Broadcast im lokalen VLAN. Wenn der DHCP-Server im gleichen VLAN steht, muss der Broadcast ihn erreichen. Wenn der Server in einem anderen Netz steht, braucht es DHCP Relay (IP Helper) auf dem Gateway des VLANs. Dieser Unterschied ist entscheidend, weil er den Prüfort vorgibt.

• DHCP lokal im VLAN: Switch/VLAN muss Broadcast sauber transportieren.
• DHCP zentral/extern: SVI/Router muss Relay korrekt durchführen.

Schritt: VLAN- und Trunk-Themen ausschließen

• Access-Port im richtigen VLAN?
• Trunks/Uplinks erlauben das VLAN (Allowed VLANs)?
• Native VLAN/Tagging korrekt (keine „Geister“-untagged Frames)?
• Keine Broadcast Storms/Loops (STP Topology Changes, MAC Flapping)?

Schritt: DHCP-Relay (IP Helper) prüfen

Wenn DHCP nicht lokal ist, ist Relay eine Top-Ursache. Prüfen Sie: Ist der Helper auf dem richtigen Interface (SVI/VLAN-Interface) gesetzt? Zeigt er auf die richtigen DHCP-Server? Greift die richtige VRF? Blockiert eine ACL den UDP-Verkehr?

• Helper-Adresse(n) korrekt?
• SVI/Gateway des VLANs up und erreichbar?
• Firewall/ACL erlaubt UDP 67/68 (und ggf. Relay-spezifische Pfade)?
• Rückweg vorhanden: DHCP-Server kann den Relay/Gateway zurück erreichen.

Schritt: DHCP-Server prüfen (Dienst, Scope, Logs)

• Dienst läuft? Server erreichbar?
• Scope aktiv und korrekt (Subnetz/Netzmaske)?
• Pool hat freie Adressen oder ist erschöpft?
• Konflikterkennung, Reservierungen, Exclusions korrekt?
• Server-Logs: kommen Discover/Request an, werden Offers gesendet?

Schritt: Security-Features prüfen (DHCP Snooping, Port Security, NAC)

Viele Enterprise-Netze nutzen DHCP Snooping, um Rogue DHCP zu verhindern. Dabei werden „untrusted“-Ports so behandelt, dass DHCP-Angebote von dort blockiert werden. Das ist richtig – führt aber zu Problemen, wenn Uplinks/Serverports fälschlich untrusted sind oder wenn Bindings/Policies falsch sind.

• Ist der Uplink zum DHCP-Server (oder zum Relay) als „trusted“ markiert?
• Werden DHCP Offers/ACKs gedroppt (Snooping-Logs/Counter)?
• Greift 802.1X/NAC und schiebt Clients in Quarantäne (Guest VLAN ohne DHCP)?

DORA gezielt testen: Wie Sie den Fehlerpunkt im Handshake finden

Wenn Sie herausfinden, an welchem Schritt DORA scheitert, ist die Ursache meist schnell klar. Das geht entweder über Client-Logs/Statusmeldungen oder am zuverlässigsten über einen Paketmitschnitt (z. B. am Client oder über Port-Mirroring am Switch). Ein Mitschnitt zeigt, ob Discover gesendet wird, ob Offers ankommen, und ob der Client Request/ACK korrekt verarbeitet. Als Einstieg in die Analyse ist die Wireshark-Dokumentation hilfreich.

• Kein Discover sichtbar: Client sendet nicht (Treiber/Dienst) oder falscher Adapter/Policy.
• Discover da, aber kein Offer: VLAN/Trunk/Relay/Server/Firewall – oder Snooping blockt Offer.
• Offer da, aber kein Request: Client lehnt Offer ab (Policy, falsche Parameter, Konflikt).
• Request da, aber kein ACK: Serverproblem, Scope/Policy, Konflikt, Relay/Rückweg.
• ACK da, aber Client hat trotzdem keine IP: Client-Stack/Policy, VPN/Agent, Duplicate Address Detection/ARP-Konflikt.

Scope erschöpft: Der Klassiker in stark wachsenden Netzen

Wenn ein DHCP-Scope keine freien Adressen mehr hat, bekommen neue Clients keine IP. Bestehende Clients funktionieren oft weiter, solange ihre Leases nicht auslaufen – das macht das Problem anfangs „unsichtbar“. Besonders nach Events (neue Geräte, Gäste, WLAN-Events) tritt das plötzlich auf.

• Symptom: Neue Clients bekommen keine IP, bestehende behalten ihre IP.
• Indiz: DHCP-Server zeigt „0 available leases“ oder hohe Auslastung.
• Fix: Pool vergrößern, Lease-Time anpassen, Exclusions prüfen, Rogue/Shadow-Clients entfernen, ggf. Segmentierung in mehrere Subnetze.

Rogue DHCP: Wenn Clients „falsche“ IPs erhalten

Ein Rogue DHCP ist häufig ein privater Router oder Hotspot, der im LAN steckt und Adressen verteilt. Dadurch landen Clients im falschen Netz, bekommen falsche Gateways oder DNS-Server und wirken „kaputt“. Das ist besonders häufig in Besprechungsräumen, beim Onboarding neuer Hardware oder in Außenstellen.

• Symptom: Clients erhalten IPs aus unerwarteten Subnetzen, Gateway/DNS passt nicht.
• Indiz: DHCP-Serveradresse in der Lease ist unbekannt.
• Fix: Rogue Gerät lokalisieren (MAC→Switchport), entfernen; DHCP Snooping aktivieren (sinnvoll geplant), Port Security/Policies ergänzen.

DHCP im WLAN: Warum es dort häufiger „wackelt“

Im WLAN ist DHCP besonders empfindlich, weil Broadcasts und Multicasts im Funk teuer sind (Airtime) und je nach WLAN-Design (Client Isolation, Broadcast-Filter, Multicast-to-Unicast) anders behandelt werden. Zusätzlich kommt häufig eine dynamische VLAN-Zuweisung (RADIUS/NAC) ins Spiel. DHCP-Probleme im WLAN sind daher oft kein „DHCP-Serverproblem“, sondern ein SSID/VLAN/Trunk/Policy-Thema.

• SSID→VLAN Mapping falsch: Clients landen im falschen VLAN ohne passenden DHCP-Scope.
• AP-Uplink kein Trunk: SSID-VLANs werden nicht transportiert (Allowed VLANs fehlen).
• Broadcast-Handling: Filter/Optimierungen droppen DHCP-Broadcasts (Discover/Offer).
• Roaming: Schnelle Übergänge können kurzfristige DHCP-Renews triggern, wenn L2/L3 nicht sauber ist.

Gateway/Relay/ACL: Wenn DHCP zwar läuft, aber Clients trotzdem „offline“ wirken

Manchmal bekommen Clients eine IP, aber es wirkt trotzdem wie „kein Netz“. Dann ist DHCP nicht das Problem, sondern die Optionen oder der Gateway-Pfad. Besonders häufig ist ein falsches Default Gateway (Option 3) oder falsche DNS-Server (Option 6). Auch kann eine ACL zwischen VLAN und Infrastruktur-Diensten (DNS, Proxy, Auth) den Eindruck erwecken, DHCP sei kaputt.

• Falsches Gateway: Client hat IP, aber erreicht keine anderen Netze.
• Falsches DNS: IP-Verbindungen gehen, aber Namen nicht (Webseiten „laden nicht“).
• Quarantäne/Policy: DHCP funktioniert, aber ACL blockt alles außer Portal.

Für DNS-Grundlagen ist RFC 1035 (DNS) eine solide Referenz, um „DHCP vs. DNS“-Fehlerbilder sauber zu trennen.

Paketmitschnitt und Beweisführung: Der schnellste Weg bei „mysteriösen“ Fällen

Wenn DHCP nur sporadisch scheitert oder mehrere Komponenten beteiligt sind (WLAN, NAC, Relay, Firewall), ist ein Mitschnitt oft schneller als stundenlanges Raten. Der Vorteil: Sie sehen exakt, ob Offers ankommen, ob sie gedroppt werden, ob es mehrere Offers von verschiedenen Servern gibt (Rogue DHCP), und ob der Client den ACK verarbeitet.

• Am Client: schnellster Nachweis, ob Discover rausgeht und Offer zurückkommt.
• Am Switchport (Mirror/SPAN): ideal, um VLAN-Tagging und Snooping-Effekte zu sehen.
• Am DHCP-Server: zeigt, ob Requests ankommen und wie der Server reagiert.

Best Practices: DHCP-Störungen langfristig vermeiden

DHCP ist robust, wenn Design und Betrieb stimmen. Die meisten wiederkehrenden Probleme entstehen durch fehlende Standards: unklare VLAN-Transporte, zu kleine Scopes, fehlende Snooping-Strategie oder unzureichendes Monitoring. Mit den folgenden Maßnahmen reduzieren Sie Incidents deutlich.

• IPAM und Scope-Planung: Pools nicht „auf Kante“ planen, Leases passend zur Umgebung (WLAN vs. LAN).
• DHCP Snooping gezielt: Trusted Ports sauber definieren, Rogue DHCP verhindern, Ausnahmen dokumentieren.
• Trunk-Standards: Allowed VLANs konsistent, Native VLAN bewusst, AP-Uplinks korrekt.
• Monitoring: Scope-Auslastung, DHCP-Fail-Raten, Rogue-DHCP-Detektion, Relay-Health.
• Runbooks: Standardablauf wie in diesem Artikel; schnelle Datensammlung (Lease, DHCP-Server, VLAN, Port).

Checkliste: DHCP Troubleshooting, wenn Clients keine IP-Adresse bekommen

• Client prüfen: Link/WLAN, DHCP aktiv, ipconfig/Lease-Infos, APIPA ja/nein.
• Scope feststellen: Einzelclient oder mehrere im selben VLAN/Standort betroffen?
• VLAN prüfen: richtiger Access-Port/VLAN, Trunks transportieren VLAN (Allowed VLANs), kein Native-VLAN-Mismatch.
• Gateway/Relay prüfen: SVI up, IP Helper korrekt, VRF korrekt, UDP 67/68 nicht geblockt.
• Server prüfen: Dienst läuft, Scope aktiv, freie Leases, Logs/Events, Reservierungen/Exclusions korrekt.
• Security prüfen: DHCP Snooping (Trusted/Untrusted), NAC/802.1X Quarantäne, Port Security.
• Rogue DHCP ausschließen: DHCP-Serveradresse aus Lease prüfen, ggf. lokalisieren und entfernen.
• Bei Bedarf Mitschnitt: DORA sichtbar machen (Discover/Offer/Request/ACK) und Drop-Punkt identifizieren.
• Nach Fix verifizieren: Neue Lease erhalten, Gateway/DNS korrekt, Zugriff auf interne Ziele und Internet prüfen.
• Dokumentieren: Ursache, betroffene VLANs/Ports/Scopes, Änderung, Vorher/Nachher-Ergebnis, Präventionsmaßnahme.

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.