Packet Loss messen und analysieren – warum Pings oft lügen und Wireshark die Wahrheit sagt

Der Admin pingt den Server. Antwortzeit: 2 ms. Paketverlust: 0 %. Alles grün. Und trotzdem rufen die Kollegen aus dem Vertrieb an, weil ihre CRM-Anwendung wieder hängt und der RDP-Desktop ruckelt wie ein Diaprojektor aus den 90ern.

Dieses Szenario ist kein Einzelfall – es ist Alltag. Der Ping lügt nicht, aber er erzählt bei Weitem nicht die ganze Wahrheit. Er testet genau einen Protokolltyp auf einem Pfad, während produktiver Traffic einen anderen Weg nimmt, anders priorisiert wird und auf ganz andere Engpässe trifft.

Dieser Artikel erklärt, warum ICMP-Pings als Diagnosewerkzeug an ihre Grenzen stoßen, wie echter Paketverlust entsteht, welche Auswirkungen er auf Anwendungen hat und wie du ihn mit Wireshark zuverlässig nachweist und lokalisierst.

Warum der Ping als Diagnosewerkzeug trügt

Ping ist schnell, universell verfügbar und liefert sofort eine Zahl. Genau das macht ihn so verführerisch – und so gefährlich als einziges Diagnosewerkzeug.

ICMP wird von Netzwerkgeräten anders behandelt als TCP oder UDP. Firewalls priorisieren ICMP-Pakete häufig niedrig oder antworten selbst, ohne den eigentlichen Endhost zu erreichen. Quality-of-Service-Regeln (QoS) stecken ICMP in eine eigene Warteschlange, die mit dem produktiven Datenverkehr wenig zu tun hat. Eine UTM-Appliance kann auf Pings einwandfrei antworten, während sie beim Durchleiten von TLS-Verbindungen längst am Limit ist.

Ping misst außerdem nur ICMP-Erreichbarkeit – keine Verbindungsqualität. Er sagt dir, ob ein Host grundsätzlich erreichbar ist. Er sagt dir nicht:

• ob TCP-Verbindungen unter Last stabil bleiben
• ob der Durchsatz einbricht
• ob Pakete im produktiven Stream verloren gehen
  
  

Das klassische Fehlbild: Ping zeigt 0 % Verlust und 3 ms RTT. Die Anwendung baut trotzdem Verbindungsabbrüche. Der Admin erklärt: „Das Netz ist in Ordnung.” Die Nutzer erklären das Gegenteil. Beide haben aus ihrer Perspektive Recht – nur misst der Admin schlicht das Falsche.

Was Packet Loss wirklich bedeutet

Paketverlust bedeutet, dass IP-Pakete ihren Weg vom Sender zum Empfänger nicht vollständig zurücklegen. Sie werden verworfen – irgendwo auf dem Pfad, aus irgendeinem Grund.

Man unterscheidet zwei grundlegende Verlusttypen:

• Sporadischer Verlust: Tritt unregelmäßig auf – durch kurzzeitige Überlastung, WLAN-Interferenzen oder fehlerhafte Hardware, die sich nur unter bestimmten Bedingungen zeigt.
• Systematischer Verlust: Reproduzierbar und konsistent – oft durch eine fehlerhafte Konfiguration, einen Duplex-Mismatch oder eine dauerhaft überlastete Leitung.
  
  

Die Auswirkungen auf TCP sind gravierend. TCP erkennt Verlust durch ausbleibende Acknowledgements oder durch das Empfangen von Duplicate ACKs. Die Reaktion ist immer dieselbe:

• Das Congestion Window wird drastisch verkleinert – der Sender drosselt den Durchsatz.
• Der Retransmission-Timeout (RTO) greift: TCP wartet auf einen Timeout, bevor es ein verlorenes Paket neu sendet. Dieser Wert liegt je nach Netz bei mindestens 200 ms, oft deutlich höher.
• Eine Handvoll solcher Events pro Minute kann eine Verbindung praktisch lahmlegen.
  
  

Wann wird Paketverlust für Nutzer spürbar? Das hängt stark vom Anwendungstyp ab:

• VoIP und RDP: Bereits ab ca. 0,1–0,5 % Paketverlust nehmen Nutzer Aussetzer, Ruckler oder Verzögerungen wahr. Diese Protokolle tolerieren Verluste kaum – verlorene Pakete werden nicht erneut gesendet, sie sind schlicht weg.
• Dateitransfer über TCP: Deutlich toleranter durch den Retransmission-Mechanismus. Bei höheren Verlustraten bricht der Durchsatz jedoch erheblich ein – ein Transfer, der mit 100 Mbit/s laufen sollte, kann durch 2 % Verlust auf einen Bruchteil fallen.

Packet Loss mit Wireshark nachweisen

Den richtigen Capture-Punkt wählen

Der häufigste Fehler bei der Wireshark-Analyse ist ein falsch gewählter Capture-Punkt. Wer nur auf dem Client oder nur auf dem Server mitschneidet, sieht möglicherweise gar keinen Verlust – obwohl er mitten im Netzwerkpfad entsteht.

Die sauberste Methode ist ein Netzwerk-Tap oder ein gespiegelter Port (SPAN/Mirror Port) an dem Switch, der den verdächtigen Pfad durchleitet. Wer keinen Tap hat, kann mit parallelen Captures auf Client und Server arbeiten und die Sequenznummern manuell vergleichen.

Sequenznummern analysieren: Lücken im Stream erkennen

TCP nummeriert jeden gesendeten Byte-Block durch. Im Wireshark-Capture kannst du im TCP-Header die Sequence Number und die Acknowledgement Number verfolgen. Eine Lücke in den Sequenznummern – also ein Sprung von Seq 1000 auf Seq 1500, ohne dass Seq 1001–1499 erscheint – ist ein eindeutiger Hinweis auf verlorene Pakete.

Wireshark berechnet diese Lücken automatisch und markiert sie farblich. Du musst kein manuelles Rechnen betreiben.

Die wichtigsten Wireshark-Filter

Für die gezielte Suche nach Verlustsignalen gibt es drei Filter, die du im Alltag immer wieder brauchen wirst (einen Überblick über die wichtigsten Wireshark-Filter im Alltag findest du in einem separaten Artikel):

• tcp.analysis.lost_segment – Zeigt Pakete, bei denen eine Lücke in den Sequenznummern erkannt wurde. Das ist das direkteste Signal für Paketverlust.
• tcp.analysis.retransmission – Zeigt alle Retransmissions. Achtung: Eine Retransmission ist die Reaktion auf Verlust, nicht der Verlust selbst. Trotzdem ein wichtiger Indikator.
• tcp.analysis.out_of_order – Pakete, die außerhalb der erwarteten Reihenfolge ankommen. Kann auf Verlust, aber auch auf Routing-Asymmetrien oder Lastverteilung hinweisen.

Expert Information auswerten

Unter Analyze → Expert Information listet Wireshark alle erkannten Anomalien kategorisiert auf. Hier siehst du auf einen Blick, wie viele Lost Segments, Retransmissions und Out-of-Order-Pakete im Capture vorliegen. Ein Capture mit mehreren hundert Lost Segments ist ein klarer Befund – auch ohne tiefes Einlesen in einzelne Pakete.

IO-Graph: Verlustmuster zeitlich darstellen

Der IO-Graph (Statistics → IO Graph) ermöglicht es, Retransmissions oder Lost Segments als Zeitreihe darzustellen. So siehst du, ob der Verlust gleichmäßig verteilt ist oder in bestimmten Intervallen auftritt – was auf periodische Überlastung, Cronjobs oder Backup-Fenster hindeuten kann.

Paketverlust lokalisieren – wo im Netz steckt das Problem?

Packet Loss nachzuweisen ist der erste Schritt. Den genauen Entstehungsort zu finden, ist die eigentliche Diagnosearbeit.

Die Methode funktioniert wie ein binäres Suchverfahren:

1. Capture vor einem verdächtigen Gerät aufnehmen.
2. Capture nach dem Gerät aufnehmen.
3. Verlust nur auf einer Seite sichtbar? → Gerät gefunden.
4. Verlust auf beiden Seiten? → Weitersuchen in Richtung Server.

Wie sich Verbindungsabbrüche systematisch auf eine Ursache eingrenzen lassen, beschreibe ich ausführlich in einem eigenen Artikel: Verbindungsabbrüche analysieren mit Wireshark und TCP.

Buffer Bloat: der oft übersehene Verlustverursacher

Ein häufig unterschätztes Phänomen ist Buffer Bloat. Pakete gehen hier nicht verloren, weil die Leitung zu schmal ist – sondern weil Puffer in Switches, Routern oder Firewalls überlaufen und Pakete aktiv verworfen werden.

Das Tückische daran: Bei normaler Last ist alles unauffällig. Erst wenn ein großer Burst entsteht – ein Backup, ein Softwareupdate, ein Videostream – füllt sich der Puffer, und nachfolgende Pakete werden verworfen. Im Wireshark-Trace siehst du Verluste, die zeitlich mit bestimmten Traffic-Spitzen zusammenfallen. Der IO-Graph ist hier besonders hilfreich.

Häufige Ursachen für Packet Loss im Unternehmensnetz

Aus der Praxis sind folgende Ursachen besonders häufig:

• Überlastete Uplinks oder WAN-Leitungen: Wenn mehr Traffic anliegt als die Leitung transportieren kann, werden Pakete verworfen. Im Capture erkennbar als kontinuierliche, gleichmäßige Verluste – korreliert oft mit hoher Auslastung zu Geschäftszeiten.
• Defekte Hardware: Fehlerhafte Netzwerkkarten, beschädigte Kabel oder schlechte SFP-Module erzeugen oft sporadischen, schwer reproduzierbaren Verlust. CRC-Fehler auf Switch-Interfaces sind ein wichtiger Hinweis – diese findest du in der Interface-Statistik des Switches, nicht im Wireshark-Capture selbst.
• Duplex-Mismatch: Wenn eine Seite auf Full Duplex und die andere auf Half Duplex konfiguriert ist, entstehen charakteristische Verlustmuster: viele kurze Retransmissions bei gleichzeitig niedrigem Throughput. Ein klassischer Befund aus realen Projekten – Ursache ist häufig eine fehlende oder fehlerhafte Auto-Negotiation.
• Überlastete Firewalls oder UTM-Appliances: Deep Packet Inspection, SSL-Inspection und IDS/IPS-Funktionen kosten CPU. Wenn das Gerät unter Last gerät, kann es Verbindungen verlangsamen oder Pakete verwerfen – ein Ping durch dieselbe Firewall zeigt davon nichts.
• WLAN: Funksignale werden durch Hindernisse, Interferenzen und Kanalauslastung beeinträchtigt. TCP interpretiert WLAN-bedingte Verluste als Netzwerküberlastung und reduziert das Congestion Window – obwohl die kabelgebundene Infrastruktur vollkommen einwandfrei ist. Wer WLAN-Verluste ausschließen möchte, sollte den betroffenen Client testweise per Kabel anschließen.

Packet Loss vs. Retransmissions – was ist der Unterschied?

Diese Begriffe werden oft verwechselt. Zur klaren Abgrenzung:

• Packet Loss ist das eigentliche Verschwinden eines Pakets im Netzwerkpfad. Das Paket wird von einem Gerät verworfen und erreicht sein Ziel nicht.
• Retransmission ist die Reaktion des TCP-Stacks auf erkannten Verlust. TCP bemerkt, dass ein ACK ausbleibt oder Duplicate ACKs ankommen, und sendet das fehlende Paket erneut. Retransmissions sind also ein Symptom, kein Auslöser.
  
  

Das ist wichtig: Ein Capture mit vielen Retransmissions bedeutet nicht zwingend, dass viele Pakete verloren gehen. Es kann auch bedeuten, dass die Verbindungslatenz hoch ist und ACKs verzögert ankommen. Deshalb immer beides betrachten: Lost Segments und Retransmissions zusammen.

Wie TCP auf Paketverlust reagiert und welche Auswirkungen das auf die Performance hat, ist ein Thema für sich – ausführlich beschrieben im Artikel TCP Retransmissions: Performance-Killer im Wireshark-Trace.

Fazit und Handlungsempfehlung

Ping ist kein Netzwerkdiagnose-Tool. Er ist ein Erreichbarkeitstest – nicht mehr. Wer Netzwerkprobleme damit diagnostiziert, wird systematisch falsche Schlüsse ziehen.

Echter Paketverlust analysieren erfordert:

• einen Capture am richtigen Punkt im Netzwerkpfad
• die Analyse von Sequenznummern und TCP-Flags
• die Auswertung der Expert Information in Wireshark
  
  

Die Kombination aus tcp.analysis.lost_segment, tcp.analysis.retransmission und dem IO-Graph liefert ein belastbares Bild. Wichtig bei der Lokalisierung: nicht am nächstgelegenen Interface anfangen, sondern methodisch von einem Punkt zum nächsten vorarbeiten. Der häufigste Fehler ist nicht ein zu kleines Werkzeug – es ist der falsche Capture-Punkt.

Wenn du unsicher bist, ob ein bestehendes Netzwerkproblem auf Paketverlust zurückzuführen ist, oder wenn du eine belastbare Analyse für eine Eskalation oder Entscheidung benötigst: Ein professioneller Netzwerkmitschnitt und eine strukturierte Auswertung bringen mehr als wochenlange Trial-and-Error-Suche.

Welche Rolle TCP Window Size und Congestion Window dabei spielen, erkläre ich ausführlich in einem weiteren Artikel: TCP Window Size und Scaling erklärt.

FAQ: Packet Loss messen und analysieren

Wie kann ich Packet Loss ohne Wireshark messen?
Tools wie pathping (Windows) oder mtr (Linux/macOS) können Paketverlust auf Hop-Ebene anzeigen und sind deutlich aussagekräftiger als ein einfacher Ping. Sie messen jedoch nur ICMP-Traffic und können den Zustand produktiver TCP-Verbindungen nicht abbilden. Für eine belastbare Analyse bleibt Wireshark das Mittel der Wahl.

Ab welchem Wert ist Packet Loss ein Problem?
Das hängt vom Anwendungstyp ab. Bei VoIP und RDP sind bereits Verlustraten ab ca. 0,1–0,5 % wahrnehmbar. Bei Dateitransfers über TCP wirkt der Retransmission-Mechanismus als Puffer, jedoch bricht der Durchsatz bei steigendem Verlust stark ein. Als grober Richtwert gilt: In einer stabilen Unternehmensumgebung sollte der Paketverlust im LAN bei 0 % liegen.

Kann Packet Loss durch Software verursacht werden?
Ja. Überlastete Endgeräte können Pakete verwerfen, bevor sie die Anwendung erreichen – etwa wenn der Netzwerk-Stack unter Last gerät. Auch Treiberfehler, veraltete Firmware auf Netzwerkkarten oder fehlerhafte Netzwerk-Teaming-Konfigurationen können Verluste erzeugen, die wie Netzwerkverlust aussehen, aber im Gerät selbst entstehen.

Warum zeigt Wireshark Retransmissions, obwohl Ping keinen Verlust zeigt?
Ping testet ICMP-Erreichbarkeit, keine TCP-Verbindungsqualität. TCP-Retransmissions entstehen, wenn ACKs ausbleiben oder Duplicate ACKs empfangen werden – das kann durch sporadischen Paketverlust im TCP-Stream passieren, der im ICMP-Traffic nicht sichtbar ist. Genau dieser Unterschied ist der Kern des Problems: Wireshark sieht den produktiven Traffic, Ping nicht.