3.15 Paketverlust, Latenz, Jitter und Bandbreite analysieren

Bandbreiten- und Lasttests dürfen nur gegen ausdrücklich freigegebene Systeme durchgeführt werden. Sie können Leitungen, Firewalls, Server und andere Benutzer erheblich belasten.

1 Byte = 8 Bit

Dateigrößen können binär oder dezimal angegeben werden. Zusätzlich reduzieren Protokoll-Overhead, Verschlüsselung, Wiederholungen und Dateisystemverarbeitung den nutzbaren Durchsatz.

Beispiel:

1-Gbit/s-Ethernet
≠
125 MB/s garantierte Nutzdatenrate

Vor der Messung ist der genaue Pfad zu dokumentieren:

Client
  ↓
WLAN oder Ethernet
  ↓
Access Point oder Switch
  ↓
Router beziehungsweise Firewall
  ↓
VPN, WAN oder Internet
  ↓
Zielnetz
  ↓
Server
  ↓
Anwendung und Datenträger

Benötigte Angaben:

Quelle:
Quell-IP:
Quellschnittstelle:
Ziel:
Ziel-IP:
Transportprotokoll:
Zielport:
IPv4 oder IPv6:
VPN beteiligt:
Proxy beteiligt:
NAT beteiligt:
Testzeitpunkt:
Gegenrichtung:
Erwartete Leistung:
Beobachtete Leistung:

Ohne definierten Messpfad ist die Aussage „Das Netzwerk ist langsam“ nicht technisch verwertbar.

Grundregel:

Mit der nächstgelegenen sinnvollen Messstelle beginnen und den Pfad schrittweise erweitern.

Eine einzelne Messung kann zufällig in einem guten oder schlechten Moment stattfinden.

Für eine belastbare Diagnose dokumentieren:

• Anzahl der Messwerte,
• Messdauer,
• Messintervall,
• Minimum,
• Maximum,
• Durchschnitt,
• Median,
• relevante Perzentile,
• Paketverlust,
• Zeitpunkt auffälliger Spitzen,
• gleichzeitige Netzlast,
• Benutzerzahl,
• Testmethode.

Durchschnittswerte können kurze Ausfälle verdecken:

99 Messungen: 10 ms
1 Messung:    2.000 ms

Durchschnitt:
29,9 ms

Der Durchschnitt wirkt noch relativ niedrig, obwohl eine einzelne Verzögerung von zwei Sekunden für Echtzeitanwendungen deutlich spürbar sein kann.

Ping misst die Round-Trip Time von ICMP Echo Request und Echo Reply.

Windows:

[TEST] ping -n 20 ZIEL_IP

Windows PowerShell:

[TEST] Test-Connection ZIEL_IP -Count 20

Linux:

[TEST] ping -c 20 ZIEL_IP

macOS:

[TEST] ping -c 20 ZIEL_IP

Zu dokumentieren sind:

• gesendete Pakete,
• empfangene Pakete,
• Verlust in Prozent,
• minimale RTT,
• durchschnittliche RTT,
• maximale RTT,
• starke Schwankungen.

Wichtig: Ein Ziel kann ICMP blockieren oder niedriger priorisieren, während Anwendungsverkehr weiterhin funktioniert.

Ein Ping beweist nicht die Leistungsfähigkeit von TCP, UDP oder der Anwendung.

Standardgateway ermitteln:

Windows:

[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
    Sort-Object RouteMetric |
    Format-Table InterfaceAlias, NextHop, RouteMetric

Linux:

[RO] ip route show default

macOS:

[RO] route -n get default

Gateway über längeren Zeitraum testen:

Windows:

[TEST] ping -n 100 GATEWAY_IP

Linux und macOS:

[TEST] ping -c 100 GATEWAY_IP

Wenn bereits zum lokalen Gateway Paketverlust oder starke Latenzschwankungen auftreten, sollten zuerst folgende Komponenten geprüft werden:

• WLAN-Funkverbindung,
• Ethernetkabel,
• Switchport,
• Netzwerkadapter,
• Treiber,
• Duplex und Linkgeschwindigkeit,
• lokaler Router,
• Clientauslastung.

Für die Eingrenzung werden mehrere Ziele betrachtet:

Ziel 1: lokales Gateway
Ziel 2: interner Server
Ziel 3: WAN-Gegenstelle
Ziel 4: Anwendungsserver

Interpretationsbeispiel:

Parallele Messungen müssen mit sinnvollen Intervallen erfolgen, damit die Diagnose nicht selbst unnötige Last erzeugt.

Wenn ICMP blockiert wird, kann ein Test zum tatsächlichen TCP-Port sinnvoller sein.

Windows:

[TEST] Test-NetConnection server.example.internal `
    -Port 443 `
    -InformationLevel Detailed

Linux und macOS:

[TEST] nc -vz -w 5 server.example.internal 443

Diese Befehle zeigen hauptsächlich, ob ein TCP-Verbindungsaufbau möglich ist. Sie liefern noch keine vollständige Leistungsmessung.

Windows mit PsPing, sofern autorisiert installiert:

[TEST] psping -n 20 server.example.internal:443

PsPing kann TCP-Verbindungszeiten messen und ist besonders nützlich, wenn ICMP nicht beantwortet wird.

Zeitanteile einer HTTP- beziehungsweise HTTPS-Anfrage:

[TEST][SENS] curl -sS -o /dev/null \
    -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \
    https://service.example.net/

Typische Eingrenzung:

Windows ohne Namensauflösung:

[TEST] tracert -d ZIEL_IP

Linux:

[TEST] traceroute -n ZIEL_IP

Falls traceroute nicht installiert ist:

[TEST] tracepath -n ZIEL_IP

macOS:

[TEST] traceroute -n ZIEL_IP

Zu kontrollieren sind:

• Anzahl der Hops,
• Änderung des Pfads,
• sprunghafter Latenzanstieg,
• Zeitüberschreitungen,
• unterschiedliche IPv4- und IPv6-Pfade,
• asymmetrische oder lastverteilte Pfade.

Ein Sternchen bei einem Zwischenrouter beweist keinen Paketverlust des weitergeleiteten Nutzverkehrs. Der Router kann Antworten auf Diagnosepakete begrenzen oder vollständig unterdrücken.

Ein Hostname kann sowohl IPv4- als auch IPv6-Adressen besitzen. Die Pfade und Leistungswerte können deutlich voneinander abweichen.

Windows:

[TEST] ping -4 -n 20 HOSTNAME
[TEST] ping -6 -n 20 HOSTNAME

[TEST] tracert -4 -d HOSTNAME
[TEST] tracert -6 -d HOSTNAME

Linux:

[TEST] ping -4 -c 20 HOSTNAME
[TEST] ping -6 -c 20 HOSTNAME

macOS:

[TEST] ping -c 20 IPV4_ADRESSE
[TEST] ping6 -c 20 IPV6_ADRESSE

HTTP getrennt testen:

[TEST] curl -4 -I https://service.example.net/
[TEST] curl -6 -I https://service.example.net/

Ein gutes IPv4-Ergebnis beweist nicht, dass der IPv6-Pfad ebenfalls funktioniert.

pathping kombiniert Pfadermittlung mit wiederholten Messungen zu Zwischenstationen.

Ohne Namensauflösung:

[TEST] pathping /n ZIEL_IP

IPv4:

[TEST] pathping /n /4 ZIEL_IP

IPv6:

[TEST] pathping /n /6 ZIEL_IP

Die Messung kann mehrere Minuten dauern.

Wichtige Interpretation:

Wenn ein Zwischenhop hohen Verlust zeigt, spätere Hops und das Ziel aber keinen entsprechenden Verlust zeigen, priorisiert oder begrenzt der Zwischenrouter wahrscheinlich nur seine eigenen ICMP-Antworten.

Ein echter Weiterleitungsverlust wird typischerweise ab einer Stelle auch an nachfolgenden Hops beziehungsweise am Ziel sichtbar.

mtr kombiniert fortlaufende Pfad- und Latenzmessungen. Es ist nicht auf jedem System standardmäßig installiert.

Prüfen, ob MTR vorhanden ist:

[RO] command -v mtr

Interaktive Messung ohne Namensauflösung:

[TEST] mtr -n ZIEL_IP

Berichtsmodus mit 100 Messzyklen:

[TEST] mtr -n -r -c 100 ZIEL_IP

TCP-basierter Test zu Port 443, sofern von der installierten Version unterstützt:

[TEST][PRIV] sudo mtr -n -r -c 100 -T -P 443 ZIEL_IP

Vor Verwendung erweiterter Optionen lokale Hilfe prüfen:

[RO] mtr --help

Auch bei MTR gilt: Verlust an einem Zwischenhop allein ist kein Beweis für weitergeleiteten Paketverlust.

Paketverlust in Prozent =
(verlorene Pakete ÷ gesendete Pakete) × 100

Beispiel:

Gesendet: 1.000
Empfangen: 990
Verloren: 10

Paketverlust = 1 %

Die Auswirkungen hängen von Anwendung und Verteilung des Verlusts ab.

Burst Loss ist für Echtzeitanwendungen häufig problematischer als derselbe prozentuale Verlust gleichmäßig verteilt.

Jitter beschreibt die Schwankung von Paketlaufzeiten. Es gibt unterschiedliche Berechnungsmethoden; Werte verschiedener Werkzeuge sind daher nicht immer direkt vergleichbar.

Typische Symptome hohen Jitters:

• abgehackte Sprache,
• schwankende Videoqualität,
• Ruckeln bei Remote-Desktop,
• ungleichmäßige Echtzeitdaten,
• vergrößerte Wiedergabepuffer,
• kurze Aussetzer trotz geringem Durchschnittsping.

ping zeigt Schwankungen der RTT, ist aber kein vollständiger Ersatz für eine anwendungsnahe Jittermessung.

Für UDP kann iperf3 Jitter und Datagrammverlust ausgeben:

[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30

Mit niedriger, kontrollierter Zielrate beginnen. Eine zu hohe Testbandbreite erzeugt selbst Verlust und Jitter.

Für eine kontrollierte Messung werden benötigt:

iperf3-Client
iperf3-Server
freigegebener Testpfad
bekannte Schnittstellen
ausreichende Serverleistung
definierte Testdauer

Server starten:

[TEST] iperf3 -s

Standardmäßig verwendet iperf3 Port 5201. Der Port kann verändert werden.

Clienttest:

[TEST] iperf3 -c SERVER_IP

Anderer Port:

Server:

[TEST] iperf3 -s -p 5202

Client:

[TEST] iperf3 -c SERVER_IP -p 5202

Firewallregeln müssen zum gewählten Transport und Port passen.

Bei UDP-Tests verwendet iperf3 zusätzlich eine TCP-Steuerverbindung. Die genaue Port- und Firewallkonfiguration ist deshalb vorab zu prüfen.

Standardtest vom Client zum Server:

[TEST] iperf3 -c SERVER_IP

30 Sekunden testen:

[TEST] iperf3 -c SERVER_IP -t 30

Gegenrichtung – Server sendet zum Client:

[TEST] iperf3 -c SERVER_IP -R -t 30

Beide Richtungen gleichzeitig, sofern unterstützt:

[TEST] iperf3 -c SERVER_IP --bidir -t 30

Mehrere parallele TCP-Datenströme:

[TEST] iperf3 -c SERVER_IP -P 4 -t 30

Parallele Datenströme können einen Pfad stärker auslasten und höhere Messwerte erzielen. Sie können aber Probleme eines einzelnen Datenstroms verdecken und erhebliche Last erzeugen.

Empfohlene Reihenfolge:

1. Ein TCP-Datenstrom zum Server.
2. Ein TCP-Datenstrom in Gegenrichtung.
3. Bei Bedarf mehrere Datenströme.
4. Erst danach gleichzeitiger bidirektionaler Test.

UDP-Test mit 10 Mbit/s Zielrate:

[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30

Gegenrichtung:

[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 -R

Relevante Ergebnisse:

• gesendete Bitrate,
• empfangene Bitrate,
• Jitter,
• verlorene Datagramme,
• Verlustquote,
• Out-of-Order-Pakete, falls ausgegeben.

Teststrategie:

niedrige Rate
→ Ergebnis prüfen
→ Rate schrittweise erhöhen
→ Beginn von Verlust und Jitter dokumentieren

Nicht sofort mit der maximal erwarteten Linkgeschwindigkeit beginnen. Ein UDP-Test besitzt keine TCP-Staukontrolle und kann andere Verbindungen stark beeinträchtigen.

JSON-Ausgabe anzeigen:

[TEST][SENS] iperf3 -c SERVER_IP -J

In Datei speichern:

[TEST][FILE][SENS] iperf3 -c SERVER_IP -t 30 -J > iperf3-test.json

UDP-Ergebnis speichern:

[TEST][FILE][SENS] iperf3 -c SERVER_IP \
    -u -b 10M -t 30 -J > iperf3-udp-test.json

Vor einer Weitergabe prüfen, ob die Datei interne IP-Adressen, Hostnamen oder andere sensible Angaben enthält.

Ein iperf3-Test misst Arbeitsspeicher-zu-Arbeitsspeicher-Netzwerkleistung und nicht automatisch Datei-, Datenbank- oder Anwendungsleistung.

Windows-TCP-Statistik:

[RO] netstat -s -p tcp

Windows-Verbindungen:

[RO] Get-NetTCPConnection |
    Format-Table LocalAddress, LocalPort, RemoteAddress,
                 RemotePort, State

Linux-TCP-Statistik:

[RO] nstat

Falls nstat nicht vorhanden ist:

[RO] netstat -s

Linux-Socketdiagnose:

[RO][SENS] ss -ti

macOS-TCP-Statistik:

[RO] netstat -s -p tcp

Zähler sind kumulativ und müssen über einen definierten Messzeitraum verglichen werden. Ein hoher Gesamtwert allein beweist kein aktuelles Problem.

Windows:

[RO] Get-NetAdapterStatistics |
    Format-Table Name, ReceivedBytes, SentBytes,
                 ReceivedDiscardedPackets, OutboundDiscardedPackets,
                 ReceivedPacketErrors, OutboundPacketErrors

Linux:

[RO] ip -s link

Linux – erweiterte Treiberstatistiken:

[RO][PRIV][SENS] sudo ethtool -S INTERFACE

macOS:

[RO] netstat -ib

[RO] ifconfig

Zu prüfen sind:

• RX- und TX-Fehler,
• Drops,
• verworfene Pakete,
• CRC- beziehungsweise Framefehler,
• Overruns,
• Carrierfehler,
• Link-Flaps,
• steigende Fehlerzähler unter Last.

Entscheidend ist, ob Zähler während des reproduzierten Fehlers ansteigen.

Windows:

[RO] Get-NetAdapter |
    Format-Table Name, Status, LinkSpeed, MediaConnectionState

Linux:

[RO] ip link show INTERFACE

[RO][PRIV] sudo ethtool INTERFACE

macOS:

[RO] ifconfig INTERFACE

Abhängig vom Adapter können zusätzliche Informationen über networksetup oder system_profiler verfügbar sein.

Zu prüfen sind:

• erwartete Linkgeschwindigkeit,
• Full Duplex oder Half Duplex,
• Autonegotiation,
• Linkstatus,
• unerwartete Begrenzung auf 100 Mbit/s,
• wiederholte Neuverhandlung,
• Kabel- oder Portfehler.

Ein Link mit 1 Gbit/s Anzeige beweist nicht, dass er fehlerfrei oder vollständig auslastbar ist.

Bufferbloat liegt vor, wenn Warteschlangen unter Last stark anwachsen und dadurch die Latenz deutlich steigt.

Typisches Verhalten:

Ping ohne Last:  10 ms
Ping unter Last: 300 ms
Paketverlust:    möglicherweise gering
Durchsatz:       hoch

Trotz hohen Durchsatzes reagieren Sprache, Spiele, Remote-Desktop und interaktive Anwendungen schlecht.

Testablauf:

1. Kontinuierlichen Ping zum geeigneten Ziel starten.
2. Basislatenz ohne Last dokumentieren.
3. Kontrollierten iperf3-Test starten.
4. Latenz während Downloadrichtung beobachten.
5. Latenz während Uploadrichtung beobachten.
6. Test stoppen.
7. Erholung der Latenz dokumentieren.

Beispiel:

Terminal 1:

[TEST] ping ZIEL_IP

Terminal 2:

[TEST] iperf3 -c SERVER_IP -t 30

Anschließend:

[TEST] iperf3 -c SERVER_IP -R -t 30

Eine Optimierung kann Queue Management oder Traffic Shaping erfordern. Solche Änderungen müssen am tatsächlichen Engpass und nicht willkürlich am Client erfolgen.

Typische Symptome einer Richtlinie:

• exakt begrenzter Durchsatz,
• nur bestimmte Anwendungen betroffen,
• UDP und TCP verhalten sich unterschiedlich,
• nur eine Richtung ist begrenzt,
• Unterschied zwischen internen und externen Zielen,
• Verhalten ändert sich zu bestimmten Uhrzeiten,
• DSCP-Markierungen werden verändert oder entfernt.

QoS ist kein Ersatz für ausreichende Kapazität. Eine Priorisierung kann wichtige Anwendungen schützen, erzeugt aber keine zusätzliche Bandbreite.

Während des Netzwerktests sind auf beiden Endsystemen zu prüfen:

• CPU-Auslastung,
• Arbeitsspeicher,
• Interruptlast,
• Netzwerktreiber,
• Energiesparzustand,
• Verschlüsselungsleistung,
• virtuelle CPU,
• Hypervisor-Auslastung,
• Containerlimits,
• Datenträger, falls Anwendungstest,
• Sicherheitssoftware.

Windows:

[RO] Get-Counter '\Processor(_Total)\% Processor Time'

[RO] Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10

Linux:

[RO] uptime

[RO] top

macOS:

[RO] top -l 1

Ein Durchsatztest kann durch die Rechenleistung eines virtuellen oder kleinen Systems begrenzt werden, obwohl das Netzwerk höhere Kapazität besitzt.

Eine Dateiübertragung misst gleichzeitig:

Quelldatenträger
+ Dateisystem
+ Serverdienst
+ Protokoll
+ Netzwerk
+ Sicherheitsprüfung
+ Zieldatenträger

Mögliche nicht netzwerkbezogene Engpässe:

• langsame HDD,
• ausgelastetes RAID,
• Virenscanner,
• Dateiverschlüsselung,
• Deduplizierung,
• Kompression,
• SMB-Signierung oder Verschlüsselung,
• kleine Dateien und Metadatenoperationen,
• Datenbankzugriffe,
• CPU-Auslastung,
• Cachezustand.

Empfohlene Trennung:

iperf3 gut
Dateikopie langsam
→ Speicher, Dateidienst oder Anwendung weiter prüfen

Windows mit Don't-Fragment-Bit:

[TEST] ping -4 -f -l 1400 ZIEL_IP

Linux:

[TEST] ping -4 -M do -s 1400 ZIEL_IP

macOS:

[TEST] ping -D -s 1400 ZIEL_IP

MTU anzeigen:

Die Ping-Nutzdatenlänge ist nicht mit der gesamten IP-Paketgröße identisch. Header müssen zusätzlich berücksichtigt werden.

Typische MTU-Symptome:

• kleine Anfragen funktionieren,
• große Übertragungen hängen,
• VPN-Verbindungen betroffen,
• TLS-Handshake unvollständig,
• bestimmte Websites laden nur teilweise,
• IPv6 meldet Packet Too Big.

Linux:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    'host ZIEL_IP' \
    -w performance-test.pcap

macOS:

[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \
    'host ZIEL_IP' \
    -w performance-test.pcap

Windows mit Dumpcap – Schnittstellen ermitteln:

[RO] dumpcap -D

Mitschnitt:

[TEST][PRIV][FILE][SENS] dumpcap -i 1 `
    -f "host ZIEL_IP" `
    -w performance-test.pcapng

Paketmitschnitte können vertrauliche Nutzdaten und Metadaten enthalten. Aufzeichnungsdauer und Filter sollten auf den benötigten Umfang begrenzt werden.

Wireshark-Analyseflags sind Schlussfolgerungen aus dem vorhandenen Mitschnitt. Fehlende Pakete am Messpunkt können falsche oder irreführende Markierungen erzeugen.

Einseitiger Mitschnitt:

zeigt nur Pakete am lokalen Messpunkt

Doppelseitiger Mitschnitt:

Clientmitschnitt
+
Servermitschnitt
+
synchronisierte Zeit

Dadurch lässt sich erkennen:

• ob ein Paket den Client verlässt,
• wann es den Server erreicht,
• ob der Server antwortet,
• wann die Antwort den Client erreicht,
• in welcher Richtung Verlust auftritt,
• wo zusätzliche Verzögerung entsteht,
• ob ein Netzwerkgerät Pakete verändert.

Für exakte Laufzeitvergleiche müssen die Uhren der Messsysteme ausreichend synchronisiert sein.

Beispiel:

Hop 1:  0 % Verlust
Hop 2: 60 % Verlust
Hop 3:  0 % Verlust
Ziel:   0 % Verlust

Hop 2 leitet den Verkehr offensichtlich weiter, antwortet aber nur eingeschränkt auf Diagnosepakete.

Wahrscheinlicher tatsächlicher Weiterleitungsverlust:

Hop 1:  0 % Verlust
Hop 2: 20 % Verlust
Hop 3: 20 % Verlust
Hop 4: 20 % Verlust
Ziel:  20 % Verlust

Auch dieses Muster muss mit weiteren Messungen bestätigt werden, da Pfadwechsel, Load Balancing und asymmetrische Routen Ergebnisse beeinflussen können.

Fall A – Latenz bereits zum Gateway hoch

Prüfen:

• WLAN-Signal und Kanal,
• Kabel,
• Switchport,
• Duplex,
• Adaptertreiber,
• lokalen Router,
• Clientlast.

Fall B – Gateway gut, Internet schlecht

Prüfen:

• WAN-Auslastung,
• Provider,
• Routerqueue,
• VPN,
• Proxy,
• externen Pfad,
• IPv4 gegenüber IPv6.

Fall C – Durchsatz gut, Echtzeitanwendung schlecht

Prüfen:

• Jitter,
• Burst Loss,
• Bufferbloat,
• QoS,
• UDP-Pfad,
• Anwendungsserver.

Fall D – Download gut, Upload schlecht

Prüfen:

• Upstreamkapazität,
• Shaping,
• Policing,
• WLAN-Senderichtung,
• asymmetrischen Pfad,
• fehlerhafte TX-Zähler.

Fall E – Kleine Übertragungen funktionieren, große nicht

Prüfen:

• MTU,
• Path-MTU-Discovery,
• ICMP-Blockierung,
• Fragmentierung,
• VPN-Overhead.

Fall F – iperf3 gut, Dateikopie langsam

Prüfen:

• Datenträger,
• Dateisystem,
• SMB oder NFS,
• Virenscanner,
• Verschlüsselung,
• Serverlast.

Fall G – Nur zu Stoßzeiten schlecht

Prüfen:

• Linkauslastung,
• Airtime,
• Backup,
• Synchronisation,
• WAN-Kapazität,
• Queue Drops,
• Serverlast.

Fall H – Nur ein TCP-Datenstrom langsam

Prüfen:

• RTT,
• Paketverlust,
• TCP-Fenster,
• Empfangspuffer,
• Congestion Control,
• CPU eines einzelnen Prozesses.

Nicht vorschnell:

• maximale UDP-Rate senden,
• viele parallele Datenströme starten,
• Tests während kritischer Geschäftsprozesse durchführen,
• produktive Server ohne Freigabe als iperf3-Ziel verwenden,
• QoS oder Shaping deaktivieren,
• Interfacezähler zurücksetzen,
• MTU beliebig ändern,
• Firewalls für Tests abschalten,
• öffentliche Speedtest-Dienste mit sensiblen Systemen automatisiert belasten,
• Messergebnisse verschiedener Pfade direkt vergleichen.

Sicherer Testablauf:

1. Testumfang genehmigen lassen.
2. Quelle, Ziel und Pfad dokumentieren.
3. Niedrige Last verwenden.
4. Messdauer begrenzen.
5. Überwachung parallel aktivieren.
6. Last schrittweise erhöhen.
7. Test bei negativen Auswirkungen sofort beenden.
8. Hin- und Rückrichtung getrennt messen.
9. Ergebnis samt Uhrzeit dokumentieren.
10. Testdienste anschließend kontrolliert beenden.

ZIEL_IP, HOST, PORT, SERVER_IP, INTERFACE und URL müssen durch die Werte des konkreten Störungsfalls ersetzt werden.

Störung:
Zeitpunkt:
Zeitzone:
Standort:
Benutzer:
Client:
Betriebssystem:

Quellschnittstelle:
Quell-IP:
Linkgeschwindigkeit:
Duplex:
WLAN-SSID:
WLAN-BSSID:
WLAN-Signal:
VPN beteiligt:
Proxy beteiligt:

Zielhostname:
Ziel-IP:
Zielport:
Transportprotokoll:
IPv4 oder IPv6:
Erwarteter Datenpfad:
Gemessener Datenpfad:

Gateway-RRT Minimum:
Gateway-RRT Durchschnitt:
Gateway-RRT Maximum:
Gateway-Paketverlust:

Ziel-RTT Minimum:
Ziel-RTT Durchschnitt:
Ziel-RTT Maximum:
Ziel-Paketverlust:
Jitter:
Burst Loss:

iperf3 TCP Client zu Server:
iperf3 TCP Server zu Client:
iperf3 parallele Streams:
iperf3 UDP Zielrate:
iperf3 UDP empfangene Rate:
iperf3 UDP Jitter:
iperf3 UDP Verlust:

Latenz ohne Last:
Latenz unter Uploadlast:
Latenz unter Downloadlast:

RX-Fehler vorher:
RX-Fehler nachher:
TX-Fehler vorher:
TX-Fehler nachher:
Drops vorher:
Drops nachher:
TCP-Retransmissions:

Client-CPU:
Server-CPU:
Server-Datenträger:
Testdauer:
Anzahl der Messungen:
Vergleichssystem:
Vergleichszeitpunkt:

MTU:
Größte erfolgreiche DF-Nutzlast:
Paketmitschnitt:
Festgestellte Ursache:
Genehmigte Änderung:
Rückfallplan:
Ergebnis der Nachprüfung:

• Wurde das Problem als Latenz-, Jitter-, Verlust- oder Durchsatzproblem konkretisiert?
• Sind Quelle, Ziel, Richtung und Datenpfad dokumentiert?
• Wurde zuerst das lokale Gateway gemessen?
• Wurden internes und externes Ziel getrennt geprüft?
• Wurden IPv4 und IPv6 getrennt verglichen?
• Wurde Hin- und Rückrichtung gemessen?
• Wurden Einzelspitzen und nicht nur Durchschnittswerte betrachtet?
• Wurde ein längerer Messzeitraum verwendet?
• Wurde Zwischenhop-Verlust korrekt interpretiert?
• Wurde TCP mit einem und mehreren Datenströmen verglichen?
• Wurde UDP mit einer kontrollierten Zielrate getestet?
• Wurden Jitter und Burst Loss erfasst?
• Wurde die Latenz unter Last geprüft?
• Steigen Schnittstellenfehler während des Tests?
• Stimmen Linkgeschwindigkeit und Duplex?
• Wurden Client- und Serverauslastung kontrolliert?
• Wurde iperf3 von Datei- oder Anwendungsleistung getrennt?
• Wurde die MTU geprüft?
• Wurden Paketmitschnitte an beiden Enden erwogen?
• War der Testumfang genehmigt und kontrolliert?
• Wurde nach der Änderung mit derselben Methode erneut gemessen?

• Microsoft Learn – ping:
  https://learn.microsoft.com/windows-server/administration/windows-commands/ping

• Microsoft Learn – tracert:
  https://learn.microsoft.com/windows-server/administration/windows-commands/tracert

• Microsoft Learn – pathping:
  https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/pathping

• Microsoft Sysinternals – PsPing:
  https://learn.microsoft.com/de-de/sysinternals/downloads/psping

• ESnet – iperf3-Dokumentation:
  https://software.es.net/iperf/

• ESnet – iperf3-Aufruf und Optionen:
  https://software.es.net/iperf/invoking.html

• Linux-Handbuch – ping:
  https://man7.org/linux/man-pages/man8/ping.8.html

• Linux-Handbuch – tracepath:
  https://man7.org/linux/man-pages/man8/tracepath.8.html

• MTR – Offizielle Dokumentation:
  https://mtr.readthedocs.io/

• Wireshark – TCP Display Filter Reference:
  https://www.wireshark.org/docs/dfref/t/tcp.html

• Wireshark – Benutzerhandbuch:
  https://www.wireshark.org/docs/wsug_html_chunked/

• RFC 3393 – IP Packet Delay Variation Metric:
  https://www.rfc-editor.org/rfc/rfc3393.html

• RFC 2680 – One-way Packet Loss Metric:
  https://www.rfc-editor.org/rfc/rfc2680.html

• RFC 6349 – Framework for TCP Throughput Testing:
  https://www.rfc-editor.org/rfc/rfc6349.html

• RFC 8201 – Path MTU Discovery for IPv6:
  https://www.rfc-editor.org/rfc/rfc8201.html