February 20, 2026

DHCP bekommt keine IP: Troubleshooting von Layer 2 bis Layer 7

Wenn ein Client meldet „DHCP bekommt keine IP“, ist das in Unternehmensnetzen selten ein einzelner „Server ist down“-Fehler, sondern häufig ein Zusammenspiel aus Layer-2-Transport, VLAN/SSID-Zuordnung, Relay-Konfiguration, Scope-Kapazität und Sicherheitsrichtlinien. Das Tückische: DHCP ist so grundlegend, dass sich Folgeprobleme überall zeigen können – vom „Kein Internet“ bis zu Anmeldeproblemen, weil DNS, Proxy und Domain-Services ohne gültige IP nicht sauber funktionieren. Gleichzeitig ist DHCP technisch klar strukturiert: Der Client sendet Broadcasts, der Server antwortet (direkt oder über Relay), und am Ende muss ein Lease in einem passenden Subnetz vergeben werden. Genau diese Struktur macht DHCP-Troubleshooting über das OSI-Modell so effektiv. In diesem Leitfaden führen wir Sie Schritt für Schritt von Layer 2 bis Layer 7 durch eine praxistaugliche Diagnose: Welche Prüfungen liefern harte Beweise, welche Symptome sind typisch, welche Fehlerquellen sind in der Realität am häufigsten, und wie dokumentieren Sie das Ergebnis so, dass NOC, Netzwerk- und Serverteams schnell weiterarbeiten können.

Table of Contents

DHCP in 30 Sekunden: Der Ablauf, den Sie im Kopf behalten müssen

Die meisten DHCP-Probleme lassen sich schneller lösen, wenn Sie den Standardablauf als Checkliste verstehen. Klassisch besteht DHCP aus vier Nachrichten (DORA): Discover, Offer, Request, Acknowledge. Daraus ergibt sich eine sehr klare Diagnosefrage: Welche dieser vier Nachrichten fehlt?

Discover: Client sucht per Broadcast nach einem DHCP-Server.
Offer: Server (oder Relay) bietet eine IP an.
Request: Client fordert die angebotene IP explizit an.
Acknowledge (ACK): Server bestätigt und vergibt Lease, Gateway, DNS usw.

Wenn Sie per Capture oder Log sehen, dass Discover rausgeht, aber kein Offer zurückkommt, suchen Sie zuerst Transport/Relay/Policy. Wenn Offer kommt, aber kein ACK, sind Server/Scope/Policy oder Konflikte wahrscheinlicher. Eine fundierte technische Grundlage zu DHCP bietet der Anchor-Text RFC 2131 (Dynamic Host Configuration Protocol).

Typische Fehlerbilder: Was bedeutet „keine IP“ konkret?

„Keine IP“ ist als Tickettext zu ungenau. In der Praxis sehen Sie meist eines dieser Muster:

APIPA/Link-Local (z. B. 169.254.x.x): Client hat keinen DHCP-Lease erhalten und fällt zurück.
Alte IP bleibt stehen: Renewal scheitert, Client nutzt den alten Lease bis zum Timeout.
IP kommt, aber falsches Subnetz: Falsches VLAN, falsche Scope-Zuordnung oder falscher Relay.
IP kommt, aber ohne Gateway/DNS: Option-Set fehlerhaft, falsche Policy, falscher Scope.
Nur bestimmte Clients betroffen: MAC-basierte Policies, 802.1X, NAC, Reservations, Geräteklassen.
Nur in WLAN oder nur am Kabel: SSID-to-VLAN-Mapping, Trunk/Access-Mismatch, Port-Security.

Vorgehen im NOC: Schnell entscheiden, ob es lokal oder zentral ist

Bevor Sie tief in Protokolldetails gehen, sparen Sie Zeit mit zwei Scope-Fragen: Ist es ein Einzelfall oder ein Segmentproblem? Ist es standortbezogen oder global?

Ein Gerät betroffen: Client-Stack, Kabel/WLAN, Port-Security, lokale Firewall, falsches Profil.
Ganzes VLAN/SSID betroffen: VLAN/Trunk, Relay (ip helper), DHCP-Server erreichbar, ACLs.
Mehrere Standorte betroffen: zentrale DHCP-Infrastruktur, Core-Policies, Routing/VRF, Firewall.
Nur ein Standort betroffen: lokaler Switch/Access-Edge, Standort-WAN, lokaler Relay.

Layer 2: Ohne saubere L2-Basis gibt es kein DHCP

DHCP beginnt fast immer als Broadcast im lokalen Segment. Wenn Layer 2 nicht stimmt, kommt nicht einmal der Discover sauber am Relay oder Server an.

VLAN/Port-Zuordnung und „falsches Netz“

Access-Port im falschen VLAN: Client landet im falschen Subnetz und bekommt entweder gar keinen Lease oder den falschen.
Trunk-Tagging fehlt: VLAN wird nicht über den Uplink transportiert; DHCP-Broadcasts bleiben stecken.
SSID-to-VLAN-Mapping falsch: WLAN-Client ist in einem anderen VLAN als erwartet.

STP, Loops und Broadcast-Probleme

STP-Topology-Changes: können kurzfristig Broadcasts beeinträchtigen, besonders bei instabilen Links.
Broadcast-Storms: DHCP kann im Lärm untergehen oder Switch-CPU belasten.
MAC-Flapping: Clients „springen“ zwischen Ports, DHCP wird unzuverlässig.

Port-Security, 802.1X und NAC

Viele Unternehmen erzwingen Sicherheitsregeln auf Access-Ports. Diese können DHCP direkt blockieren oder den Client in ein Quarantäne-VLAN schieben.

802.1X nicht erfolgreich: Client bleibt in „unauthorized“ oder landet im Guest-VLAN.
Port-Security MAC-Limit: Switch blockiert Frames, wenn zu viele MACs gelernt werden.
NAC-Policy: DHCP-Requests werden nur zugelassen, wenn Endpunkt compliant ist.

Layer 3: DHCP über Subnetze hinweg – Relay, Routing und ACLs

Sobald der DHCP-Server nicht im gleichen Broadcast-Domain sitzt, benötigen Sie DHCP-Relay (z. B. „ip helper“) und eine funktionierende Layer-3-Konnektivität zwischen Relay und Server. Viele „keine IP“-Fälle sind genau hier verankert.

DHCP-Relay fehlt oder zeigt auf falsche Server

Kein Relay konfiguriert: Discover bleibt im VLAN, Server sieht ihn nie.
Relay auf falsche IP: Requests gehen ins Leere oder zum falschen DHCP-Server.
Mehrere Relays inkonsistent: In redundanten Setups ist nur ein Gateway korrekt konfiguriert, der andere nicht.

Routing/VRF-Segmentierung

DHCP-Server in anderer VRF: Ohne VRF-Leak/Route-Target/Policy kommt der Traffic nicht an.
Rückroute fehlt: Server antwortet, aber die Antwort findet den Weg zurück zum Relay nicht.
Asymmetrischer Pfad: Antworten laufen über eine Firewall, die den State nicht kennt.

ACLs/Firewall-Regeln für DHCP

DHCP verwendet UDP und spezielle Ports. Blockiert eine ACL DHCP zwischen Client, Relay und Server, sehen Sie typischerweise Discover ohne Offer oder Offer ohne ACK (je nach Blockpunkt).

Client-Segment: DHCP-Client sendet von UDP 68 an UDP 67 (Server/Relay).
Relay zum Server: Relay nutzt UDP 67/UDP 67 (abhängig von Implementierung), wichtig ist: DHCP muss in beide Richtungen erlaubt sein.
Broadcast/Unicast-Mix: Antworten können als Broadcast oder Unicast kommen; Policies müssen beides berücksichtigen.

Für eine belastbare Port-/Protokollreferenz ist der Anchor-Text IANA Service Name and Transport Protocol Port Number Registry hilfreich.

Layer 4: UDP ist „still“ – genau deshalb ist Beweisführung wichtig

DHCP läuft über UDP. UDP hat kein eingebautes Retransmission-/Handshake-Verhalten wie TCP. Deshalb sieht der Fehler häufig wie ein „Timeout ohne Grund“ aus. Hier hilft die Logik: Wenn UDP-Pakete gesendet werden, aber keine Antwort kommt, ist entweder der Pfad/Policy blockiert oder der Server verarbeitet nicht.

Was Sie auf Layer 4 prüfen sollten

UDP-Drops: Firewall Counters, ACL Hit Counts, Drops pro Interface.
Rate-Limits/Policer: Manche Geräte limitieren Broadcast/UDP, was DHCP beeinträchtigen kann.
Stateful Inspection: Obwohl UDP „stateless“ ist, tracken viele Firewalls UDP-Flows; Asymmetrie kann Antworten droppen.

Layer 5–7: DHCP-Server, Scopes, Options und Policy-Logik

Wenn Layer 2/3/4 sauber wirken und Sie Discover/Request sehen, ist der DHCP-Server (oder dessen Policy-Logik) der nächste Fokus. „Server läuft“ reicht als Aussage nicht; entscheidend ist, ob er ein Lease vergeben kann und darf.

Scope erschöpft: Keine freien Leases

Pool ist voll: Server kann kein Offer machen oder lehnt Request ab.
Zu lange Lease-Zeiten: Leases binden Adressen unnötig lange, besonders in WLAN/Guest-Netzen.
Viele „stale“ Leases: Geräte sind weg, aber Leases noch aktiv; Cleanup fehlt.

Reservations und Konflikte

MAC-Reservation falsch: Reservation zeigt auf falsches Subnetz oder kollidiert mit Exclusions.
Duplicate IP Detection: Server erkennt Konflikt (oder Client meldet ihn) und vergibt nicht.
Rogue DHCP: Ein unerwünschter DHCP-Server im Netz antwortet schneller und verteilt falsche Leases.

DHCP-Optionen: IP kommt, aber Netzwerk ist trotzdem „kaputt“

Manchmal „bekommt“ der Client eine IP, aber nicht die richtigen Parameter. Im Ticket wirkt das dann wie „keine IP“, tatsächlich ist es ein Options-Problem.

Default Gateway (Option 3) fehlt/falsch: Client kann nur lokal kommunizieren.
DNS (Option 6) fehlt/falsch: „Internet geht nicht“, obwohl Routing funktioniert.
Domain Suffix (Option 15): interne Namen lösen nicht auf, Login/Services wirken defekt.
Proxy/WPAD (Option 252) oder vendor-spezifische Optionen: können Applikationsverhalten beeinflussen.

DHCP-Snooping und Security-Features auf Switches

DHCP-Snooping schützt gegen Rogue DHCP, kann aber bei falscher Konfiguration legitime Antworten blockieren.

Trusted Ports falsch gesetzt: Uplink/Relay-Port ist nicht trusted, Offers werden gedroppt.
Option 82 (Relay Agent Information): Server oder Policies reagieren unerwartet auf Option 82.
IP Source Guard / Dynamic ARP Inspection: kann Folgekommunikation blockieren, wenn Bindings fehlen.

Beweisorientiertes Troubleshooting: Welche DORA-Phase fehlt?

Die schnellste, saubere Methode ist die DORA-Analyse. Sie ordnet das Problem eindeutig einer Stelle zu.

Fall: Discover geht raus, aber kein Offer kommt zurück

Layer 2: VLAN/Trunk/SSID, Port-Security, DHCP-Snooping (Offers gedroppt).
Layer 3: Relay fehlt/falsch, Routing/VRF, ACL blockt UDP 67/68.
Server: Server nicht erreichbar oder verarbeitet nicht (Dienst down, Policy blockt).

Fall: Offer kommt, aber kein Request oder kein ACK

Client: Client lehnt Offer ab (Policy, statische Konfig, Treiber, bereits gültiger Lease).
Server/Scope: Scope erschöpft, Reservation-Konflikt, Policy verweigert ACK.
Security: NAC/802.1X wechselt VLAN nach Offer, ACK landet „im falschen Netz“.

Fall: ACK kommt, aber danach „trotzdem keine Konnektivität“

Optionen falsch: Gateway/DNS/Suffix nicht korrekt.
Layer 2/3 Security: IP Source Guard/DAI blockt nach Lease, weil Bindings nicht stimmen.
Routing: Default Route im VLAN fehlt; DHCP ist nicht die Ursache, sondern nur der erste sichtbare Schritt.

Messkette im Betrieb: Von Client bis Server ohne Rätselraten

Wenn Sie keinen direkten Zugriff auf Switches oder DHCP-Logs haben, hilft eine Messkette in Etappen. Ziel ist, die Strecke zu isolieren, auf der DHCP „verschwindet“.

Client-Sicht: Sieht der Client Discover/Offer/ACK? Zeigt er APIPA oder bleibt er „Pending“?
Access-Switch: Lernt der Switch die MAC? Gibt es Errors/Drops? Ist der Port im richtigen VLAN?
Gateway/Relay: Kommen Discover-Pakete an? Wird Relay ausgelöst? Gehen Relays an den richtigen Server?
Server-Sicht: Kommen Requests an? Gibt es freie Leases? Werden Offers/ACKs geloggt oder verweigert?

Quantifizierung: Wann ist ein DHCP-Problem „systemisch“?

Für Eskalationen ist es hilfreich, nicht nur Einzelfälle zu melden, sondern Quoten: Wie viele Clients scheitern pro Zeitfenster? Wie viele Leases sind noch frei? Damit lässt sich „Scope erschöpft“ oder „intermittierender Relay-Ausfall“ objektiv belegen.

$Erfolgsquote = \frac{erfolgreicheLeases}{LeaseAnfragen} \times 100 %$
$AuslastungPool = \frac{vergebeneLeases}{gesamtAdressenImPool} \times 100 %$

Typische Sonderfälle, die häufig übersehen werden

Wenn die Standardsuche nichts ergibt, sind es oft diese Sonderfälle:

Relay auf HA-Gateway nur halb konfiguriert: Bei Failover wechseln Clients auf das zweite Gateway, dort fehlt der Helper.
Option 82 bricht Policies: Der Server vergibt nur, wenn Circuit-ID/Remote-ID passt; bei Switchwechsel scheitert es.
Rogue DHCP im Netz: Clients bekommen falsche Default-Gateways oder DNS; „keine IP“ ist eigentlich „falsche IP“.
WLAN Roaming: Client wechselt AP/VLAN, DHCP-Transition nicht sauber, Lease passt nicht mehr zum Segment.
DHCP für VoIP/IoT mit Klassen: Vendor Class Identifier oder Client Identifier entscheidet über den Scope; falsch erkannt = falsches Netz.

Paketanalyse als Schiedsrichter: Wann ein Capture den Unterschied macht

Wenn Sie die Ursache zweifelsfrei belegen müssen, ist ein Paketmitschnitt am richtigen Punkt oft der schnellste Weg: entweder am Client, am VLAN-Uplink oder am DHCP-Serverinterface. Sie suchen dabei nicht „alles“, sondern gezielt DORA plus eventuelle ICMP/ARP-Folgemuster.

Client-Capture: Geht Discover raus? Kommt Offer/ACK zurück? Kommt es als Broadcast oder Unicast?
Relay-Capture: Kommt Discover im VLAN an? Schickt Relay weiter? Kommt Antwort zurück?
Server-Capture: Kommt Request an? Antwortet Server mit ACK oder NAK? Gibt es Retries?

Für eine praxisnahe Einführung in Capture-Filter und Protokollinterpretation ist der Anchor-Text Wireshark-Dokumentation geeignet, insbesondere für DHCP/BOOTP-Analysen.

Checkliste: DHCP bekommt keine IP – von Layer 2 bis Layer 7

Layer 2: Port im richtigen VLAN? Trunks tragen VLAN? SSID-to-VLAN korrekt? Port-Security/802.1X/NAC Status?
Layer 2 Security: DHCP-Snooping korrekt (Uplinks trusted)? DAI/IP Source Guard verursachen Nebenwirkungen?
Layer 3: DHCP-Relay (ip helper) vorhanden und korrekt? VRF stimmt? Rückroute zum Relay/Client-Netz vorhanden?
Layer 3/4 Policy: ACL/Firewall lässt UDP 67/68 in beide Richtungen zu? Rate-Limits/Policer auf Broadcast/UDP?
Layer 7 (DHCP-Server): Dienst läuft? Scope verfügbar (keine Erschöpfung)? Reservations/Exclusions konfliktfrei?
Optionen: Gateway/DNS/Suffix korrekt? Option 82/Client-Klassen korrekt verarbeitet?
Beweisführung: DORA-Phase identifizieren (Discover/Offer/Request/ACK) und Abbruchpunkt dokumentieren.

Outbound-Links für belastbare Grundlagen

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.