DHCP verstehen: Wie Geräte automatisch ihre IP-Adresse bekommen
Du steckst einen neuen Laptop in die Netzwerkdose. Zehn Sekunden später kannst du Webseiten öffnen und auf den Drucker zugreifen. Niemand hat eine IP-Adresse eingetragen, keine Netzmaske, kein Gateway. Woher weiß der Laptop das alles?
Dahinter steckt ein Dienst, den du in jedem Netz findest, ob zu Hause oder in der Firma: DHCP. Er hat in den letzten Beiträgen schon mehrfach eine Rolle gespielt, etwa bei der Fehlersuche mit der 169.254-Adresse und bei der Reservierung für den Drucker. Jetzt schauen wir uns an, wie er funktioniert.
Was ist DHCP?
DHCP steht für Dynamic Host Configuration Protocol. Es ist ein Protokoll der Anwendungsschicht, das Geräten beim Netzwerkstart ihre Einstellungen automatisch zuweist. Ein DHCP-Server verwaltet einen Vorrat an Adressen und verteilt sie an DHCP-Clients. Er liefert dabei nicht nur die IP-Adresse, sondern ein ganzes Paket:
- IP-Adresse,
- Netzmaske,
- Standardgateway,
- Adresse des DNS-Servers,
- Dauer der Gültigkeit (Lease-Zeit) und weitere Angaben.
Die Kommunikation läuft über UDP, wie im Beitrag TCP/IP-Modell erklärt gezeigt. Der Server lauscht auf Port 67, der Client nutzt Port 68.
Als DHCP-Server arbeiten je nach Netz sehr unterschiedliche Geräte: der Heimrouter, ein Windows Server, ein Linux-Server mit Programmen wie dnsmasq oder ein Router oder Layer-3-Switch in einem Firmennetz.
Warum nicht einfach von Hand?
Bei zehn Geräten ginge das. Bei achtzig wird es zur Fleißarbeit mit Fehlerrisiko: Eine vertippte Ziffer, eine doppelt vergebene Adresse, ein vergessenes Gateway. Dazu kommen Smartphones und Notebooks, die ständig zwischen Netzen wechseln und überall neue Einstellungen brauchen. DHCP erledigt das automatisch und verhindert Adresskonflikte, weil der Server weiß, was schon vergeben ist.
Feste Adressen von Hand bleiben für Geräte sinnvoll, die immer am selben Platz erreichbar sein müssen: Server, Drucker, Netzwerkgeräte. Diese stehen im Adressplan außerhalb des DHCP-Bereichs oder werden per Reservierung an eine MAC-Adresse gebunden. Dazu gleich mehr.
Der Ablauf: DORA
Der Ablauf besteht aus vier Nachrichten, die sich mit den Anfangsbuchstaben DORA merken lassen: Discover, Offer, Request, Acknowledge.
- Discover: Der Client sucht einen DHCP-Server. Er hat noch keine Adresse und kennt keinen Server. Deshalb schickt er die Nachricht als Broadcast an 255.255.255.255, mit der Absenderadresse 0.0.0.0 und der MAC-Adresse FF:FF:FF:FF:FF:FF als Ziel.
- Offer: Ein DHCP-Server antwortet mit einem Angebot: „Du kannst 192.168.10.205 haben, mit dieser Maske, diesem Gateway und dieser Lease-Zeit.“ Antworten mehrere Server, bekommt der Client mehrere Angebote.
- Request: Der Client sucht ein Angebot aus und fragt es verbindlich an. Auch diese Nachricht geht per Broadcast, damit die anderen Server wissen, dass ihr Angebot nicht angenommen wurde.
- Acknowledge: Der Server bestätigt und trägt die Vergabe in seine Liste ein. Jetzt darf der Client die Adresse benutzen.
Die Eigenschaften der vier Nachrichten im Überblick:
| Nachricht | Von | An | Ports | Inhalt |
|---|---|---|---|---|
| Discover | Client (0.0.0.0) | Broadcast (255.255.255.255) | 68 → 67 | „Ist hier ein DHCP-Server?“ |
| Offer | Server (192.168.10.130) | Client (per Broadcast oder direkt an dessen MAC) | 67 → 68 | Adressangebot mit Einstellungen |
| Request | Client (0.0.0.0) | Broadcast | 68 → 67 | „Ich nehme dieses Angebot.“ |
| Acknowledge | Server | Client | 67 → 68 | Bestätigung der Vergabe |
Die Broadcasts hast du im Beitrag Netzwerkadresse und Broadcast kennengelernt. Hier siehst du, warum es sie gibt: Ein Rechner ohne Adresse kann niemanden direkt ansprechen.
Lease: Die Adresse wird nur geliehen
Eine per DHCP vergebene Adresse gehört dem Gerät nicht dauerhaft. Sie wird für eine bestimmte Zeit geliehen (englisch Lease). Danach muss der Client sie erneuern, sonst wird sie wieder frei. Das verhindert, dass Adressen von Geräten blockiert werden, die längst nicht mehr im Netz sind.
Die Erneuerung läuft automatisch in zwei Stufen:
- Nach der Hälfte der Lease-Zeit fragt der Client seinen Server direkt nach einer Verlängerung.
- Antwortet der Server nicht, versucht der Client es nach 87,5 Prozent der Zeit per Broadcast bei einem beliebigen Server.
Bei einer Lease-Zeit von 8 Stunden kommt die erste Anfrage nach 4 Stunden, die zweite nach 7 Stunden. Die Lease-Zeit richtest du nach dem Netz: In einem Gäste-WLAN mit ständig wechselnden Geräten wählst du sie kurz (einige Stunden), in einem stabilen Büronetz länger (mehrere Tage). Ist sie zu kurz, belastet das den Server unnötig, ist sie zu lang, bleiben bei viel Wechsel schnell alle Adressen belegt.
Adresspool und Reservierung
Der Administrator legt auf dem Server einen Adresspool fest, den Bereich, aus dem vergeben wird. Der Bereich heißt oft auch Scope. Außerdem gibt es Adressen, die nie verteilt werden dürfen, zum Beispiel das Gateway oder feste Serveradressen.
Für Geräte, die zwar per DHCP konfiguriert werden, aber immer dieselbe Adresse bekommen sollen, richtest du eine Reservierung ein: „Die MAC-Adresse 00:1A:2B:3C:4D:20 bekommt immer 192.168.10.194.“ Das haben wir im Beitrag MAC-Adresse und IP-Adresse am Drucker durchgespielt. Der Vorteil gegenüber einer Handeintragung am Gerät: Alle Einstellungen bleiben zentral an einem Ort.
Als Beispiel das Subnetz 192.168.10.192/26 (VLAN 40: Drucker, Kameras, Telefone) mit dem Plan aus dem Beitrag zur Broadcast-Adresse:
| Adressen | Verwendung | Wer vergibt? |
|---|---|---|
| 192.168.10.193 | Gateway | Fest am Router |
| 192.168.10.194 bis .199 | Drucker | DHCP-Reservierung nach MAC |
| 192.168.10.200 bis .250 | Kameras, Telefone | DHCP-Pool, 51 Adressen |
| 192.168.10.251 bis .254 | Reserve | Nicht vergeben |
Beispiel: Ein DHCP-Server mit dnsmasq
Wie so eine Konfiguration aussieht, zeigt dieses Beispiel für den Linux-Dienst dnsmasq. Es handelt sich um einen Server, der direkt im Subnetz steht:
interface=eth0
dhcp-range=192.168.10.200,192.168.10.250,255.255.255.192,8h
dhcp-option=option:router,192.168.10.193
dhcp-option=option:dns-server,192.168.10.130
dhcp-host=00:1a:2b:3c:4d:20,192.168.10.194
Die erste Zeile legt fest, auf welcher Schnittstelle der Dienst lauscht. Die zweite definiert den Pool von .200 bis .250 mit Netzmaske und einer Lease-Zeit von 8 Stunden. Die dritte und vierte teilen den Clients Gateway und DNS-Server mit. Die letzte reserviert .194 für den Drucker mit der angegebenen MAC-Adresse. Die Schnittstellennamen und Adressen musst du an deine Umgebung anpassen.
DHCP über Netzgrenzen: Der Relay-Agent
Ein Problem ergibt sich aus dem Aufbau: Der Discover geht als Broadcast, und Router leiten Broadcasts nicht weiter. Der Server muss also im selben Netz stehen wie der Client. Bei einem Netz mit mehreren VLANs wie in der Firma würde das heißen: pro VLAN ein eigener DHCP-Server. Das wäre aufwendig.
Die Lösung ist der DHCP-Relay-Agent. Er läuft auf dem Router oder Layer-3-Switch, der in jedem VLAN das Gateway ist. Er fängt die Broadcasts im VLAN ab und schickt sie als gezielte Pakete an einen zentralen Server weiter. Dabei trägt er seine eigene Adresse in die Nachricht ein, und der Server weiß damit, aus welchem Subnetz die Anfrage kommt und welchen Pool er verwenden soll. Die Antwort läuft den gleichen Weg zurück.
Auf einem Cisco-Router oder Layer-3-Switch richtest du das auf der Schnittstelle des VLANs mit einem Befehl ein. Hier das VLAN 40, mit dem DHCP-Server im Server-VLAN unter 192.168.10.130:
Switch(config)# interface vlan 40
Switch(config-if)# ip helper-address 192.168.10.130
Die Befehle anderer Hersteller heißen anders, das Prinzip ist gleich. Auf diese Weise bedient ein einziger Server alle VLANs, mit je einem Pool pro Subnetz. Wie die VLANs aufgebaut sind, zeigt der Beitrag VLAN verstehen.
DHCP am eigenen Rechner ansehen
Unter Windows zeigt dir die Eingabeaufforderung, von welchem Server dein Rechner seine Adresse hat und wie lange sie gilt:
ipconfig /all
In der Ausgabe stehen bei dem Adapter die Zeilen „DHCP aktiviert“, „DHCP-Server“, „Lease erhalten“ und „Lease läuft ab“. Wenn du eine neue Adresse brauchst, gibst du die alte zurück und fragst neu an:
ipconfig /release
ipconfig /renew
Der erste Befehl gibt die Adresse frei, der zweite startet den DORA-Ablauf neu. Unter Linux hängt der Weg vom System ab. Mit NetworkManager genügt oft ein erneutes Aktivieren der Verbindung:
nmcli connection up "Name der Verbindung"
Auf Systemen mit dem klassischen dhclient funktionieren sudo dhclient -r zum Freigeben und sudo dhclient -v eth0 zum Erneuern. Das Programm ist nicht auf jeder Distribution installiert.
Fehlersuche: Wenn die Adressvergabe nicht klappt
| Beobachtung | Wahrscheinliche Ursache | Prüfung |
|---|---|---|
| Gerät hat eine Adresse 169.254.x.x | Kein DHCP-Server erreichbar: Kabel, VLAN, Relay oder Server aus | Link, VLAN-Zuordnung, ip helper-address, Serverstatus |
| Gerät bekommt eine Adresse aus dem falschen Netz | Port im falschen VLAN oder ein zweiter DHCP-Server im Netz | ipconfig /all: welcher Server hat vergeben? |
| Einige Geräte bekommen keine Adresse mehr | Pool erschöpft | Lease-Liste im Server, Pool oder Lease-Zeit anpassen |
| Gerät bekommt nicht die reservierte Adresse | MAC-Adresse stimmt nicht, etwa weil das Gerät zufällige MAC-Adressen nutzt | MAC am Gerät und in der Reservierung vergleichen |
| Adresse ist da, aber kein Internet | Falsches Gateway oder falscher DNS in der Vergabe | Pool-Optionen und ipconfig /all prüfen |
| Verbindungsabbrüche bei einzelnen Geräten | Adresskonflikt, etwa feste Adresse im Pool | Pool gegen den Adressplan prüfen |
Sicherheit: DHCP vertraut jedem
DHCP hat keine eingebaute Anmeldung. Jeder, der im Netz eine Discover-Nachricht schickt, bekommt eine Adresse. Und wer einen eigenen DHCP-Server ins Netz stellt, kann Clients falsche Einstellungen unterschieben, zum Beispiel ein eigenes Gateway oder einen eigenen DNS-Server, um den Verkehr mitzulesen. Man nennt das einen Rogue DHCP-Server. Oft ist es kein Angriff, sondern ein Versehen: Jemand schließt einen zweiten Router mit aktiviertem DHCP an.
Als Gegenmaßnahme gibt es auf Managed Switches DHCP Snooping. Der Administrator legt fest, an welchen Ports ein DHCP-Server stehen darf (Trusted Ports). Antworten von anderen Ports werden verworfen. So bleibt der echte Server der einzige, der Adressen verteilt.
Praxisbeispiel: Die Kamera in VLAN 40
Eine neue Netzwerkkamera wird am Switch-Port Gi0/12 angeschlossen, der VLAN 40 zugeordnet ist. Die Kamera sendet beim Start ein Discover. Der Switch-Port ist im VLAN 40, deshalb erreicht der Broadcast den Layer-3-Switch, der als Relay arbeitet. Er leitet die Anfrage an den DHCP-Server unter 192.168.10.130 im Server-VLAN weiter. Der Server erkennt am Relay das Subnetz 192.168.10.192/26, wählt den passenden Pool (.200 bis .250) und schickt ein Angebot, zum Beispiel 192.168.10.205, mit Gateway 192.168.10.193 und 8 Stunden Lease. Nach Request und ACK ist die Kamera im Netz. Genau so bekommen auch Telefone ihre Adressen, während die Drucker per Reservierung immer dieselbe Adresse bekommen.
Wäre das Relay nicht eingerichtet, würde die Kamera nie eine Antwort bekommen und nach einiger Zeit eine 169.254-Adresse nehmen. Auf diesen Fehler stößt man bei Netzen mit VLANs besonders häufig.
Typische Fehler und Missverständnisse
- Pool überschneidet sich mit festen Adressen. Der Server vergibt dann eine Adresse, die ein Server oder Drucker bereits hat.
- Zwei DHCP-Server im selben Netz. Das ergibt unvorhersehbare Einstellungen. Meist steckt ein zweiter Router dahinter.
- Relay vergessen. In VLAN-Netzen erreicht die Anfrage sonst den Server nicht.
- „DHCP vergibt auch Namen.“ Er liefert Adresse, Maske, Gateway und DNS-Server. Die Auflösung von Namen erledigt DNS.
- Reservierung auf falsche MAC. Geräte mit zufälliger MAC-Adresse umgehen sie.
- Lease-Zeit unpassend. Zu lang bei wechselnden Geräten, zu kurz bei stabilen.
- DHCP als Sicherheitsfunktion verstehen. Er ist ein Komfortdienst. Wer Zugriff auf das Netz kontrollieren will, braucht andere Mittel.
Zum Üben
- Nenne die vier Nachrichten des DHCP-Ablaufs in der richtigen Reihenfolge.
- Warum schickt ein Client den Discover als Broadcast und mit der Absenderadresse 0.0.0.0?
- Welche UDP-Ports nutzen DHCP-Server und -Client?
- Eine Lease-Zeit beträgt 12 Stunden. Nach welcher Zeit versucht der Client die Erneuerung beim eigenen Server, nach welcher per Broadcast?
- Ein DHCP-Pool reicht von 192.168.10.200 bis 192.168.10.250. Wie viele Adressen enthält er?
- Ein Gerät hat die Adresse 169.254.33.7. Welche Ursachen prüfst du zuerst?
- Wozu braucht man einen DHCP-Relay-Agent?
- Wie bekommt ein Drucker immer dieselbe Adresse, obwohl er per DHCP konfiguriert wird?
Lösungen: (1) Discover, Offer, Request, Acknowledge. (2) Er hat noch keine Adresse und kennt den Server nicht, und deshalb muss er sich an alle Geräte im Netz wenden. (3) Server: UDP 67, Client: UDP 68. (4) Nach 50 Prozent, also 6 Stunden, beim eigenen Server. Nach 87,5 Prozent, also 10,5 Stunden, per Broadcast. (5) 250 − 200 + 1 = 51 Adressen. (6) Kein DHCP-Server erreichbar: Link und Kabel, VLAN-Zuordnung des Ports, Relay-Einstellung, ob der DHCP-Server läuft und der Pool nicht erschöpft ist. (7) Router leiten Broadcasts nicht weiter. Der Relay-Agent leitet DHCP-Anfragen aus einem VLAN an einen zentralen Server weiter, sodass ein Server mehrere Subnetze versorgen kann. (8) Über eine Reservierung: Der Server ordnet der MAC-Adresse des Druckers immer dieselbe IP-Adresse zu.
Das solltest du dir merken
- DHCP verteilt IP-Adresse, Netzmaske, Gateway, DNS-Server und Lease-Zeit automatisch. Der Server lauscht auf UDP 67, der Client nutzt UDP 68.
- Der Ablauf heißt DORA: Discover, Offer, Request, Acknowledge. Discover und Request gehen als Broadcast.
- Adressen werden nur geliehen. Die Erneuerung beginnt nach 50 Prozent der Lease-Zeit.
- Feste Adressen liegen außerhalb des Pools oder werden per Reservierung an die MAC-Adresse gebunden.
- Ein DHCP-Relay leitet Anfragen über Netzgrenzen zu einem zentralen Server.
- Eine Adresse 169.254.x.x zeigt, dass kein DHCP-Server geantwortet hat.
- DHCP ist ungeschützt. DHCP Snooping verhindert Rogue-Server.
Mit der IP-Adresse allein können Menschen wenig anfangen. Wir tippen Namen wie www.beispiel.de ein. Wer übersetzt sie in Adressen? Das klärt der nächste Beitrag: DNS verstehen.


