iperf3 troubleshooting netzwerk

iperf3 Netzwerk Geschwindigkeit: Tipps für präzise Messungen

von

Wer im Alltag „das Netzwerk ist langsam“ hört, bekommt selten eine brauchbare Fehlermeldung dazu. Ist wirklich die Leitung zu klein? Bremst ein WLAN‑Segment? Ist der Server überlastet? Oder limitiert schlicht ein einzelner TCP‑Stream durch Latenz und Fenstergröße? Mit iperf3 bekommen Sie innerhalb weniger Minuten belastbare Zahlen, statt Bauchgefühl. In diesem Guide zeige ich Ihnen praxisnah, wie Sie Netzwerk Geschwindigkeit messen, Bandbreite testen und die Ergebnisse so lesen, dass Sie daraus konkrete Maßnahmen ableiten können.

Was iperf3 misst – und was nicht

iperf3 ist ein Client‑Server‑Tool, das aktiv Daten zwischen zwei Systemen sendet und daraus den maximal erreichbaren Durchsatz ermittelt. Es unterstützt TCP, UDP und SCTP und liefert je nach Modus Kennzahlen wie Bitrate/Durchsatz, Retransmits (TCP), Jitter und Paketverlust (UDP). (github.com)

Wichtig für die Erwartungshaltung:

  • iperf3 misst Transport‑Performance zwischen zwei Endpunkten. Es ersetzt kein „echtes“ Applikationsprofiling.
  • iperf3 ist nicht kompatibel zu iperf2 (Protokoll/Handshake unterscheiden sich). (github.com)
  • Ergebnisse hängen stark von CPU, NIC‑Offloads, Window‑Sizing, MTU und der Latenz ab.

Wenn Sie eigentlich „Internet‑Speed“ gegen irgendeinen Dienst messen wollen: Das geht zwar mit öffentlichen iperf‑Servern, aber interpretieren Sie das vorsichtig (Peering, Routing, Server‑Load). Das Ubuntuusers‑Wiki nennt als Alternative für reine Internet‑Tests explizit Web‑Speedtests. (wiki.ubuntuusers.de)

Grundsetup: Server starten, Client testen

iperf3 läuft klassisch in zwei Rollen:

Server

Auf einem Messpunkt starten Sie den Server:

iperf3 -s

Das Ubuntuusers‑Wiki nutzt genau dieses Grundschema (Servermodus mit -s). (wiki.ubuntuusers.de)

Client

Auf dem anderen Messpunkt starten Sie den Client und geben Zielhost an:

iperf3 -c <server-ip-oder-dns>

Auch das ist der Standardweg aus der Praxis‑Doku. (wiki.ubuntuusers.de)

Port und Firewall

Viele Umgebungen blocken „ungewöhnliche“ Ports. In iperf3 ist der Standard‑Serverport typischerweise 5201; der Port lässt sich mit -p ändern. Im Ubuntuusers‑Artikel wird -p als Option zum Setzen des Ports beschrieben. (wiki.ubuntuusers.de)

Beispiel:

# Server
iperf3 -s -p 5201

# Client
iperf3 -c <server> -p 5201

Installation: iperf3 Windows / Linux / macOS

Linux (Debian/Ubuntu)

Unter Ubuntu installieren Sie iperf3 direkt aus den Paketquellen:

sudo apt-get install iperf3

So steht es auch im Ubuntuusers‑Wiki (Paket iperf3). (wiki.ubuntuusers.de)

macOS

Offiziell entwickelt ESnet iperf3 u. a. für macOS, neben Ubuntu Linux und FreeBSD. (github.com)

In der Praxis installieren viele Admins unter macOS per Paketmanager (z. B. Homebrew). Da ich hier im Beitrag keine unbestätigten Homebrew‑Kommandos „aus dem Kopf“ aufnehmen möchte, halten Sie sich im Zweifel an die offiziellen Download-/Build‑Infos aus dem Projekt (siehe nächster Abschnitt).

Windows

Hier wird es heikel: ESnet nennt Windows nicht als offiziell unterstützte Plattform. (github.com)

Trotzdem braucht man in gemischten Umgebungen oft iperf3 Windows. Es gibt Community‑Builds, z. B. das Repository ar51an/iperf3-win-builds, das explizit vorgebaute Windows‑Binaries bereitstellt und erklärt, dass die letzte „offizielle“ Windows‑Binary‑Release‑Version 3.1.3 (2016) war. (github.com)

Wenn Sie Windows‑Binaries produktiv einsetzen, achten Sie auf Herkunft/Vertrauen und prüfen Sie Hashes/Signaturen, sofern vorhanden. Alternativ ist WSL (Windows Subsystem for Linux) oft der sauberste Weg, weil Sie dann das Linux‑Paket nutzen.

Messstrategie: Erst „sauber“ messen, dann gezielt variieren

Wenn Sie Bandbreite testen, starten Sie nicht mit „20 Parallelstreams, Jumbo Frames, UDP 9 Gbit/s“. Sie wollen zuerst eine Baseline.

1) Baseline TCP (ein Stream)

iperf3 -c <server>

Interpretation:

  • Bitrate: Der Durchsatz dieses einen TCP‑Streams.
  • Retr (Retransmits): Hohe Werte deuten auf Loss/Buffer‑Probleme oder schlicht Überlast/Policing hin.

Warum ein Stream oft „zu wenig“ ist: TCP‑Durchsatz skaliert mit Fenstergröße und RTT. Bei höherer Latenz kann ein Stream die Leitung nicht füllen.

2) Parallelstreams, um das Limit zu finden

Mit -P starten Sie mehrere parallele TCP‑Streams. Das Ubuntuusers‑Wiki beschreibt -P als Anzahl gleichzeitiger Tests. (wiki.ubuntuusers.de)

iperf3 -c <server> -P 4

Praxisregel: Erhöhen Sie -P schrittweise (2 → 4 → 8). Wenn der Durchsatz steigt, war der einzelne Stream limitierend (RTT/Window). Wenn er nicht steigt, limitiert etwas anderes (NIC, CPU, Shaping, WLAN‑Airtime, Switch‑Port, VM‑vNIC).

3) Richtung prüfen: Upload vs. Download

Viele Fehlerbilder sind richtungsabhängig (QoS, Asymmetrien, WLAN‑Uplink, Provider‑Traffic‑Shaping). iperf3 kann die Richtung umdrehen:

# „Download“ aus Sicht des Clients
iperf3 -c <server> -R

4) Bidirektional testen (gleichzeitig)

Für realistische Last (z. B. VoIP + Filesync gleichzeitig) ist --bidir interessant: Client und Server senden und empfangen parallel. (docs.oracle.com)

iperf3 -c <server> --bidir

Hinweis: Das ist kein Ersatz für zwei getrennte Tests, weil die gleichzeitige Last sich gegenseitig beeinflusst (Queueing, Bufferbloat, CPU).

UDP in iperf3: sinnvoll einsetzen, ohne sich selbst zu täuschen

UDP misst „wie viel kommt an“ bei einer vorgegebenen Senderate. Das ist ideal, um Paketverlust und Jitter sichtbar zu machen, aber Sie müssen die Rate setzen.

  • -u aktiviert UDP.
  • -b (Bitrate) setzt die Zielsende­rate; diverse Manpages nennen als UDP‑Default 1 Mbit/s. (linuxcommandlibrary.com)

Beispiel: 200 Mbit/s UDP, 30 Sekunden:

iperf3 -c <server> -u -b 200M -t 30

In der UDP‑Ausgabe sehen Sie u. a. Jitter und Lost/Total Datagrams (Paketverlust). Stack Overflow zeigt ein typisches Summary‑Format mit Jitter und Lost/Total. (stackoverflow.com)

Typische UDP‑Fehlerquelle: zu hoch angesetzt

Wenn Sie -b höher setzen, als die Strecke kann, erzeugen Sie zwangsläufig Loss. Das ist dann kein „Bug“, sondern ein Stresstest. Nehmen Sie mehrere Stufen (z. B. 50M → 100M → 200M → 500M) und beobachten Sie, ab wann Loss einsetzt.

UDP und Paketverlust „wirkt unrealistisch hoch“

Es gibt historische Diskussionen über auffällig hohe UDP‑Loss‑Werte in bestimmten Setups/Versionen. Ein altes GitHub‑Issue beschreibt extrem hohe Loss‑Werte bei UDP‑Tests im Vergleich zu iperf2 auf bestimmter Hardware. (github.com)

Meine Praxisempfehlung: Wenn UDP‑Loss „zu absurd“ wirkt, verifizieren Sie gegen Switch‑Counters und testen Sie mit anderer Paketgröße (-l) oder anderer iperf3‑Version. Und: Prüfen Sie CPU‑Load auf Empfänger/Sendersystem.

Die wichtigsten iperf3 Befehle (Cheatsheet mit Praxis-Kontext)

Hier die iperf3 Befehle, die im Admin‑Alltag am meisten bringen – jeweils mit einem Satz, wofür ich sie nutze.

Testdauer und Intervall

iperf3 -c <server> -t 30 -i 1

Gut, um zu sehen, ob der Durchsatz stabil bleibt oder einbricht.

Interface/IP binden

Wenn ein Host mehrere NICs hat (z. B. LAN + VLAN + VPN), binden Sie den Test an eine Quelle:

iperf3 -c <server> -B 10.10.10.5

Parallelisieren

iperf3 -c <server> -P 8

Das ist oft der schnellste Weg, um „Leitung kann mehr, aber ein Stream nicht“ zu belegen.

Reverse / bidir

UDP und Bitrate

iperf3 -c <server> -u -b 100M -t 20 -i 1

JSON-Ausgabe (für Automatisierung)

iperf3 kann optional JSON ausgeben. Das ESnet‑README nennt JSON als Feature („optional JSON output“). (github.com)

Viele Manpages führen dafür -J, --json auf. (linuxcommandlibrary.com)

iperf3 -c <server> -J

Das ist praktisch, wenn Sie Messergebnisse in ein eigenes Logging, ein Ticket oder ein Monitoring‑System übernehmen.

Messergebnisse richtig lesen: typische Muster aus der Praxis

Muster 1: Ein Stream langsam, mehrere Streams schnell

Symptom:

  • iperf3 -c <server>: z. B. 150 Mbit/s
  • iperf3 -c <server> -P 8: z. B. 900 Mbit/s

Deutung: RTT/Window‑Limitierung oder Traffic‑Shaping pro Flow. Maßnahmen: Window/Buffer prüfen (-w), OS‑TCP‑Tuning, Pfad‑Latenz senken, ggf. Applikation parallelisieren.

Muster 2: Reverse deutlich schlechter als „normal“

Symptom:

  • Normal: 900 Mbit/s
  • Reverse (-R): 120 Mbit/s

Deutung: Asymmetrisches Shaping/QoS, fehlerhafte Duplex‑Aushandlung, WLAN‑Uplink, Provider‑Upload‑Limit, Firewall/IPS am Rückweg. Hier lohnt ein Blick auf Edge‑Komponenten und Policies.

Wenn Sie ohnehin Ihre Firewalls/Edge‑Geräte eng überwachen, kann Monitoring helfen, solche Richtungsprobleme schneller zuzuordnen. (In vielen Umgebungen hängt das direkt an Firewall‑Health und Interface‑Errors.) Passend dazu: In unserem Beitrag zur OPNsense-Überwachung mit Checkmk sehen Sie, wie Sie Metriken und Zustände dauerhaft sichtbar machen.

Muster 3: UDP-Loss setzt ab bestimmter Rate ein

Symptom:

  • 100 Mbit/s: 0% Loss
  • 200 Mbit/s: 0–1% Loss
  • 400 Mbit/s: 15% Loss

Deutung: Engpass/Queue‑Drops. Maßnahmen: QoS prüfen, Bufferbloat analysieren, Switch‑Queues, WLAN‑Airtime, CPU‑Bottleneck. UDP eignet sich gut, um „wo kippt es“ schnell zu finden.

iperf3 im Netzwerk-Alltag: drei Szenarien, die schnell Zeit sparen

Standortverbindung / VPN: ist es Bandbreite oder Latenz?

Bei Site‑to‑Site‑VPNs ist die „gefühlte“ Performance oft nicht nur Bandbreite. Nutzen Sie:

# TCP Upload
iperf3 -c <server-remote> -t 30

# TCP Download
iperf3 -c <server-remote> -R -t 30

# Skalierung
iperf3 -c <server-remote> -P 6 -t 30

Wenn Reverse/Normal stark abweichen, gehen Sie zuerst an Tunnel‑Policies/QoS. Falls Sie OPNsense als Edge einsetzen, passt dazu unser Praxisartikel zum OPNsense HA-Cluster, weil Asymmetrien auch durch Failover-/State-Themen sichtbar werden können.

Server zu Server (Storage/Backup): Engpass zwischen Hypervisor und VM?

Wenn VMs auf Proxmox/VMware stehen, testen Sie immer „VM↔VM“, „VM↔Host“ und „Host↔Host“. So sehen Sie, ob die virtuelle Switch‑Schicht (vNIC/vSwitch) limitiert.

Wenn Sie gerade in der Entscheidungsphase stecken, liefert unser Vergleich Hyper‑V vs Proxmox hilfreiche Einordnung für typische Betriebsmodelle.

WLAN: warum der iperf3-Wert niedriger ist als der Link-Rate-„Marketingwert“

WLAN ist Shared Medium. Eine „866 Mbit/s“ Link Rate bedeutet nicht 866 Mbit/s Nettodurchsatz. iperf3 zeigt Ihnen den real erreichbaren TCP‑Durchsatz unter den aktuellen Funkbedingungen.

Praxis‑Tipp: Testen Sie mit -P 4 und vergleichen Sie 5 GHz vs 2,4 GHz, und testen Sie zu verschiedenen Tageszeiten. Wenn -P stark hilft, ist häufig nicht „das WLAN schlecht“, sondern der einzelne Flow wird durch Latenz/Interferenzen ausgebremst.

Sicherheits- und Betriebsaspekte

  • iperf3 erzeugt echten Traffic. Fahren Sie Tests in produktiven Netzen gezielt und zeitlich begrenzt (-t).
  • Öffnen Sie Serverports (z. B. 5201) nicht unnötig ins Internet.
  • Wenn Sie iperf3 auf einem Server dauerhaft als Dienst laufen lassen, binden Sie an ein internes Interface (-B) und begrenzen Sie per Firewall.

Offiziell verweist das Projekt auch auf Download‑Möglichkeiten und Quellcode/Issue‑Tracker, falls Sie eigene Builds machen oder Versionen vergleichen müssen. (github.com)

Wenn Sie regelmäßig Netzwerktests fahren und dabei wiederkehrend dieselben Fragen zu Paketverlust, Interface‑Fehlern oder Traffic‑Spitzen auftauchen, lohnt sich ein sauberer Monitoring‑Unterbau. Weitere Themen finden sie in unserm Blog. Wenn Sie bei der Einordnung Ihrer Messergebnisse oder beim Aufbau eines reproduzierbaren Test-Setups Unterstützung brauchen, erreichen Sie uns auch direkt über ADMIN INTELLIGENCE.