Warum DHCP-Server scheinbar so viel CPU verbrauchen

28.09.2026 · 5 Min. Lesezeit

Wer sich etwas intensiver mit Netzwerken beschäftigt, macht früher oder später eine überraschende Beobachtung: Ein Router, eine Firewall oder ein SD-WAN-Gateway langweilt sich im normalen Betrieb bei 10 bis 20 % CPU-Auslastung. Aktiviert man jedoch den integrierten DHCP-Server, steigt die Last plötzlich deutlich an. In meinem Fall sprang die Auslastung eines Juniper SSR von dauerhaft etwa 15 bis 20 % auf Werte um die 85 %. Nach der Auslagerung der DHCP-Funktion fiel die Last sofort wieder ab.

Die offensichtliche Schlussfolgerung wäre: DHCP muss ein besonders komplexes oder rechenintensives Protokoll sein.

Die Realität ist allerdings deutlich interessanter.

DHCP ist eigentlich erstaunlich simpel

Betrachtet man das eigentliche Protokoll, dann gehört DHCP zu den einfachsten Diensten in modernen IP-Netzen. Ein typischer Ablauf besteht lediglich aus vier Nachrichten – dem klassischen DORA-Handshake (Discover, Offer, Request, Ack):

sequenceDiagram
    participant Client
    participant Server as DHCP-Server

    Client->>Server: DISCOVER
    Server-->>Client: OFFER
    Client->>Server: REQUEST
    Server-->>Client: ACK

Der Server muss dabei lediglich:

• eine freie Adresse finden,
• einige DHCP-Optionen ergänzen,
• die Lease speichern,
• eine Antwort senden.

Verglichen mit Routing-Protokollen, Stateful Firewalls, TLS-Offloading oder IDS/IPS-Systemen ist das praktisch trivial. Schon sehr kleine Linux-Systeme können problemlos tausende Leases verwalten. Die eigentliche DHCP-Funktion erklärt daher die hohe CPU-Last nicht.

Das eigentliche Problem: Broadcasts

Der erste Kostenfaktor liegt in der Art, wie DHCP arbeitet. Ein Client besitzt beim Start noch keine IP-Adresse. Deshalb kann er keine normale Unicast-Kommunikation aufbauen. Stattdessen sendet er einen Broadcast:

0.0.0.0 -> 255.255.255.255
DHCPDISCOVER

Broadcasts sind auf vielen Netzwerkgeräten ein Sonderfall. Während normales Routing oder Switching heute fast vollständig von Hardware-ASICs erledigt wird, müssen Broadcasts häufig von der Control Plane verarbeitet werden – also direkt von der CPU.

flowchart LR
    Pkt["Eingehendes Paket"]
    Class{"Unicast &<br/>bekannte Route?"}
    Fast["Fast Path<br/>Hardware-ASIC"]
    Slow["Slow Path<br/>Control Plane / CPU"]

    Pkt --> Class
    Class -- ja --> Fast
    Class -- "nein (Broadcast, z. B. DHCP)" --> Slow

Das führt zu einem kuriosen Effekt: Reines Durchroutieren skaliert hervorragend, ein Broadcast-lastiger Dienst wie DHCP dagegen belastet gezielt den langsamsten Pfad im Gerät.

Nicht weil DHCP schwierig wäre, sondern weil die Pakete den langsamen Softwarepfad statt des hardwarebeschleunigten Datenpfads durchlaufen.

DHCP erzeugt oft deutlich mehr Arbeit als vier Pakete

Die vier DHCP-Pakete sind nur die sichtbare Spitze des Eisbergs. Viele DHCP-Server führen zusätzliche Prüfungen durch, bevor eine Adresse vergeben wird – typische Beispiele:

• ARP-Probe
• Duplicate Address Detection
• Gratuitous ARP
• Lease-Verifikation

flowchart TD
    DORA["DORA-Handshake<br/>(4 Pakete)"] --> Vergabe["Adresse wird vergeben"]
    Vergabe --> Probe["ARP-Probe /<br/>Duplicate Address Detection"]
    Vergabe --> GARP["Gratuitous ARP"]
    Vergabe --> Verify["Lease-Verifikation"]
    Vergabe --> DB["Lease-Datenbank<br/>aktualisieren"]

Der Server versucht damit sicherzustellen, dass die ausgewählte Adresse tatsächlich noch frei ist. Aus einem simplen DHCP-Vorgang entstehen dadurch schnell mehrere weitere Netzwerkoperationen. In kleinen Netzen fällt das kaum auf. Bei hunderten oder tausenden Clients kann der Nebenaufwand jedoch höher sein als die eigentliche Lease-Verwaltung.

Die Anzahl der VLANs ist selten das Problem

Oft wird vermutet, dass viele DHCP-Pools oder VLANs die Last verursachen. In Wirklichkeit ist meist die Anzahl der aktiven Clients entscheidend. Jede Lease bringt zusätzliche Verwaltungsarbeit mit sich:

• Ablaufzeit überwachen
• Renewals bearbeiten
• Datenbankeinträge pflegen
• Konflikte erkennen
• Statistiken aktualisieren

Zehn VLANs mit jeweils fünf Clients sind praktisch bedeutungslos. Zehn VLANs mit jeweils mehreren hundert Clients sehen dagegen ganz anders aus. Entscheidend ist also nicht die Anzahl der Pools, sondern die Anzahl der Leases und deren Änderungsrate.

Logging ist oft der heimliche Ressourcenfresser

Ein besonders unterschätzter Faktor ist das Logging. Viele Appliances protokollieren jede relevante DHCP-Aktion:

• Lease vergeben
• Lease erneuert
• Lease freigegeben
• Lease abgelaufen

Wird jede dieser Meldungen zusätzlich lokal gespeichert, auf Flash geschrieben, per Syslog versendet und in eine Telemetrie-Datenbank übernommen, entsteht schnell mehr Aufwand durch Ein- und Ausgabeoperationen als durch die eigentliche DHCP-Verarbeitung.

flowchart LR
    Event["Ein DHCP-Event<br/>(z. B. Lease vergeben)"]
    Event --> Local["Lokal speichern"]
    Event --> Flash["Auf Flash schreiben"]
    Event --> Syslog["Per Syslog versenden"]
    Event --> Telemetry["Telemetrie-Datenbank"]

Gerade Embedded-Systeme und Appliances reagieren auf solche I/O-Last oft empfindlicher als auf reine Rechenarbeit.

Software-Architekturen machen einen großen Unterschied

Der vielleicht wichtigste Punkt: Nicht jede Plattform behandelt DHCP gleich. Bei klassischen Enterprise-Switches und Routern werden viele Aufgaben vollständig von spezialisierter Hardware übernommen. Anders sieht es bei modernen SD-WAN-, Security- oder Service-Routern aus. Dort laufen zahlreiche Funktionen im Software-Datenpfad:

• Session Tracking
• Telemetrie
• Analytics
• Security Policies
• Service Chains

flowchart TD
    subgraph Klassisch["Klassischer Switch/Router"]
        L1["DHCP-Lease"] --> H1["Weitgehend in<br/>Hardware erledigt"]
    end

    subgraph Modern["SD-WAN / Security Router"]
        L2["DHCP-Lease"] --> S1["Session Tracking"]
        L2 --> S2["Telemetrie"]
        L2 --> S3["Analytics"]
        L2 --> S4["Security Policies"]
        L2 --> S5["Service Chains"]
    end

Wenn DHCP in diese Architektur integriert ist, kann jede Lease zusätzliche Software-Komponenten berühren. Die CPU-Auslastung steigt dann nicht, weil DHCP komplex wäre, sondern weil jeder DHCP-Vorgang zahlreiche weitere Prozesse auslöst.

Lease-Stürme als Sonderfall

Besonders spektakulär werden die Auswirkungen nach größeren Neustarts, zum Beispiel wenn:

• ein WLAN-Controller neu startet,
• ein Access Point die Verbindung verliert,
• ein kompletter Switch rebootet,
• ein Stromausfall auftritt.

flowchart LR
    Trigger["Auslöser<br/>(Reboot, Stromausfall, ...)"]
    Trigger --> C1["Client 1"]
    Trigger --> C2["Client 2"]
    Trigger --> C3["Client 3"]
    Trigger --> Cn["... Client n"]
    C1 & C2 & C3 & Cn -->|DISCOVER/REQUEST| Server["DHCP-Server"]
    Server --> Spike["Kurzfristiger<br/>CPU-Spike"]

Plötzlich melden sich hunderte oder tausende Geräte gleichzeitig. Der DHCP-Server erhält innerhalb weniger Sekunden eine Flut von Discover- und Request-Paketen. Dieser sogenannte Lease Storm kann selbst leistungsfähige Systeme kurzfristig stark belasten, obwohl die durchschnittliche Last im Regelbetrieb sehr gering ist.

Fazit

DHCP selbst ist nicht ressourcenintensiv.

Das Protokoll gehört zu den einfachsten und leichtgewichtigsten Diensten im IP-Netzwerk. Wenn eine Appliance durch die Aktivierung eines DHCP-Servers plötzlich massiv höhere CPU-Werte zeigt, liegt die Ursache meist woanders:

• Broadcast-Verarbeitung in der Control Plane
• ARP- und Konflikterkennung
• Logging und Telemetrie
• ineffiziente Implementierungen
• zusätzliche Software-Komponenten der Plattform
• große Mengen gleichzeitiger Renewals oder Lease-Anfragen

Die CPU-Zeit wird also häufig nicht für DHCP verbraucht, sondern für die Infrastruktur rund um DHCP.

Wenn ein Gerät beim Aktivieren eines DHCP-Servers plötzlich 70 Prozentpunkte mehr Last erzeugt, sagt das meist mehr über die Architektur des Geräts aus als über DHCP selbst. Das Protokoll ist selten das Problem. Die Art, wie die Plattform es implementiert, dagegen oft schon.