Keine Adresse vom DHCP-Server, und jetzt?

Das Symptom richtig einordnen

Bevor du an einem Gerät etwas änderst, lies das Symptom genau. Es gibt drei Grundfälle, und jeder schließt bereits einen Teil der Ursachen aus. Prüfe das unter Windows mit ipconfig /all, unter Linux mit ip -4 addr und unter macOS in den Netzwerkeinstellungen.

• Adresse aus 169.254.0.0/16

  Der Client hat keine Antwort bekommen. RFC 3927 reserviert diesen Bereich für selbst vergebene Link-Local-Adressen und legt fest, dass Hosts nur Adressen von 169.254.1.0 bis 169.254.254.255 wählen. Unter Windows heißt das Verfahren APIPA. Der Link ist meist da, die Anfrage oder die Antwort ist unterwegs verloren gegangen.

• Adresse aus dem falschen Netz

  Ein DHCP-Server hat geantwortet, aber nicht der richtige, oder der Port steht in einem anderen VLAN als gedacht. Die Infrastruktur funktioniert grundsätzlich, nur die Zuordnung stimmt nicht.

• Gar keine IPv4-Adresse

  Der Adapter hat keinen Link, ist deaktiviert oder der Client versucht noch. Prüfe zuerst die physische Ebene und den Zustand des Ports, bevor du nach DHCP suchst.

Der DORA-Ablauf und wo er abbrechen kann

DHCP nach RFC 2131 läuft in vier Nachrichten. Der Client sendet ein Discover per Broadcast von UDP-Port 68 an Port 67, und ein Server antwortet mit einem Offer. Der Client bestätigt mit einem Request, und der Server schließt mit einem Ack ab. Lehnt der Server den Request ab, sendet er ein Nak; erkennt der Client, dass die Adresse bereits belegt ist, sendet er ein Decline.

Der Client wiederholt sein Discover, wenn keine Antwort kommt. RFC 2131 sieht dafür eine Wartezeit vor, die bei 4 Sekunden beginnt und sich bis 64 Sekunden verdoppelt. Wie lange ein Client es versucht, bevor er auf eine Link-Local-Adresse ausweicht, hängt vom Betriebssystem ab.

Steht der Server in einem anderen Netz, nimmt der Relay-Agent am Gateway das Discover entgegen, trägt seine eigene Interface-Adresse in das Feld giaddr ein und schickt die Anfrage per Unicast an den Server. Der Server wählt anhand von giaddr den passenden Scope und antwortet an den Relay, der das Offer ins Client-Segment weitergibt.

Schicht 1 und 2: Link, Port Security, Access-VLAN und PortFast

Die meisten DHCP-Probleme an einzelnen Arbeitsplätzen liegen am Port. Prüfe zuerst, ob der Port verbunden ist, in welchem VLAN er steht und ob er Fehler zählt. Ein Port im Zustand err-disabled ist abgeschaltet, auch wenn das Kabel steckt, und Port Security ist die häufigste Ursache.

Danach kommt das Access-VLAN. Nach einem Umzug oder Patchfehler landet ein Client in einem VLAN, für das es kein Gateway mit Relay gibt, oder im Gast-VLAN mit anderem Adressbereich. show interfaces switchport zeigt das konfigurierte Access-VLAN, und show mac address-table interface bestätigt, dass die MAC-Adresse des Clients dort gelernt wird.

Zuletzt Spanning Tree: Ohne PortFast wartet ein Access Port nach dem Link-Up, bevor er Pakete weiterleitet. Frühe Discover-Nachrichten verpuffen, und manche Clients geben in dieser Zeit schon auf.

show interfaces GigabitEthernet1/0/12 status
show interfaces status err-disabled
show port-security interface GigabitEthernet1/0/12
show interfaces GigabitEthernet1/0/12 switchport | include Access Mode VLAN
show mac address-table interface GigabitEthernet1/0/12
show spanning-tree interface GigabitEthernet1/0/12 portfast
!
! Access Port richtig konfigurieren
interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 20
 spanning-tree portfast
 spanning-tree bpduguard enable

Relay: ip helper-address, Option 82 und die Firewall dazwischen

Ein DHCP-Discover ist ein Broadcast und verlässt das eigene Segment nicht. Auf Cisco IOS und IOS XE macht erst ip helper-address auf der SVI oder dem Router-Interface das Gateway zum Relay-Agent. Fehlt der Befehl in einem neuen VLAN, kommt keine Anfrage beim Server an. Bei zwei DHCP-Servern trägst du beide ein, jede Adresse in einer eigenen Zeile. ip helper-address leitet neben DHCP standardmäßig auch einige andere UDP-Broadcasts weiter, etwa für TFTP und NetBIOS; mit no ip forward-protocol udp schaltest du das für einzelne Dienste ab.

Option 82 nach RFC 3046 ist die Relay Agent Information, mit der ein Relay oder ein Switch mit DHCP Snooping Informationen zu Port und Gerät anhängt. Der klassische Konflikt entsteht, wenn ein Access-Switch mit DHCP Snooping Option 82 einfügt, aber giaddr auf 0 lässt, weil er kein Relay ist. Der Relay-Agent am Distribution-Switch sieht dann ein Paket mit Option 82, aber ohne Relay-Adresse, an einem nicht vertrauenswürdigen Interface und verwirft es. Ob ein Catalyst Option 82 einfügt, zeigt show ip dhcp snooping in der Zeile zur Option 82; auf Catalyst-9000-Switches ist die Einfügung laut Cisco standardmäßig eingeschaltet, sobald DHCP Snooping aktiv ist.

Zwischen Relay und Server sitzt oft eine Firewall. Sie muss UDP 67 vom Relay zum Server und zurück erlauben, und zwar mit der Interface-Adresse der SVI als Quelle, nicht mit der Adresse des Clients. Wer im Firewall-Log nach der Client-MAC sucht, findet nichts, weil die Firewall nur Relay und Server sieht.

interface Vlan20
 ip address 10.12.20.1 255.255.252.0
 ip helper-address 10.0.5.10
 ip helper-address 10.0.5.11
 ! Nur nötig, wenn Access-Switches Option 82 mit giaddr 0 einfügen
 ip dhcp relay information trusted
!
! Auf dem Access-Switch mit DHCP Snooping
ip dhcp snooping
ip dhcp snooping vlan 20
no ip dhcp snooping information option
interface TenGigabitEthernet1/1/1
 description Uplink zum Distribution-Switch
 ip dhcp snooping trust
!
show ip dhcp snooping
show ip dhcp snooping statistics

Server: Scope erschöpft, Lease-Dauer und Reservierungen

Kommt die Anfrage beim Server an, gibt es drei typische Gründe, warum trotzdem kein Offer zurückgeht. Erstens gibt es keinen Scope für das Netz, auf das giaddr zeigt; das passiert, wenn das VLAN-Gateway eine andere Adresse hat als im Plan oder der Scope nie angelegt wurde. Zweitens ist der Scope erschöpft. Drittens filtert der Server die MAC-Adresse, etwa über eine Positiv- oder Negativliste.

Die Lease-Dauer bestimmt, wie schnell ein Scope sich nach einem Gästeansturm erholt. In Büronetzen mit festen Geräten sind mehrere Tage üblich. In Gastnetzen und Besprechungsräumen mit vielen wechselnden Geräten verhindert eine Lease-Dauer von wenigen Stunden, dass der Scope voll bleibt, obwohl die Geräte längst weg sind.

Reservierungen binden eine Adresse an eine MAC-Adresse. Bekommt ein Gerät nicht die erwartete Adresse, ist oft die MAC-Adresse falsch eingetragen, oder das Gerät nutzt eine zufällige MAC, wie es viele aktuelle Betriebssysteme im WLAN standardmäßig tun.

# Windows Server (PowerShell, Modul DhcpServer)
Get-DhcpServerv4ScopeStatistics -ComputerName dhcp01
Get-DhcpServerv4Lease -ComputerName dhcp01 -ScopeId 10.12.20.0 |
    Sort-Object LeaseExpiryTime | Select-Object -Last 10

! Cisco IOS als DHCP-Server
show ip dhcp pool
show ip dhcp binding
show ip dhcp conflict

# Linux-Client: Discover sichtbar machen
sudo dhclient -v eth0
# ... DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
# ... No DHCPOFFERS received.

Der Mitschnitt als Beweis

Ein Mitschnitt beantwortet die Frage, die jede Diskussion zwischen Netzwerk- und Serverteam entscheidet: Kommt die Anfrage an, und geht eine Antwort raus? Schneide an zwei Stellen mit, am Client oder an einem gespiegelten Access Port und am DHCP-Server. Fehlt das Discover am Server, liegt der Fehler im Netz. Geht vom Server ein Offer raus, das am Client nie ankommt, liegt er auf dem Rückweg.

In Wireshark reicht der Anzeigefilter dhcp. Ältere Versionen vor 3.0 nannten das Protokoll bootp. Mit dhcp.hw.mac_addr filterst du auf einen bestimmten Client, mit dhcp.ip.relay siehst du die Relay-Adresse, und mit dhcp.option.type == 82 findest du Pakete mit Relay Agent Information. Auf einem Linux-Server ohne Oberfläche erledigt tcpdump dieselbe Arbeit.

# Wireshark-Anzeigefilter
dhcp
dhcp.hw.mac_addr == 3c:52:82:1a:bb:07
dhcp.ip.relay == 10.12.20.1
dhcp.option.type == 82

# tcpdump auf dem DHCP-Server
sudo tcpdump -ni eth0 -e -vv 'udp port 67 or udp port 68'

Wenn der Server ausfällt: Abgrenzung zu Failover

Fällt der einzige DHCP-Server aus, bekommen neue Clients keine Adressen, und bestehende verlieren ihre Lease, sobald sie abläuft. Das ist kein Fehler im Ablauf, sondern eine Frage der Redundanz. Zwei Einträge für ip helper-address am Relay helfen nur, wenn auch zwei Server mit abgestimmten Scopes bereitstehen.

Unter Windows Server löst eine Failover-Beziehung zwischen zwei DHCP-Servern dieses Problem, entweder im Lastausgleich oder als Hot Standby. Wie du sie einrichtest und welche Fallstricke dabei auf dich warten, beschreibt der Windows-Server-Bereich ausführlich; auf dieser Seite geht es um die Fehlersuche im Netz zwischen Client und Server.