Paketverlust unter Windows prüfen
Paketverlust ist die Ursache hinter abbrechenden Videokonferenzen, stockenden Remote-Sitzungen und Anwendungen, die „manchmal hängen“. Messen lässt er sich mit Windows-Bordmitteln in wenigen Minuten – die Interpretation ist der schwierigere Teil, weil ausgerechnet die auffälligsten Zahlen häufig bedeutungslos sind.
Richtig messen: vier Pakete reichen nicht
Der Standardaufruf ping ziel sendet unter Windows vier Echo-Anfragen. Damit beträgt die kleinste nichtleere gemessene Verlustrate 25 %; ein tatsächlicher Verlust von 2 % bleibt bei nur vier Paketen meist unentdeckt. Für eine aussagekräftigere Momentaufnahme sendet man mehr Pakete:
ping -n 50 192.168.10.1 ping -n 50 8.8.8.8 ping -n 50 fileserver.firma.intern
Das erste Ziel steht hier für das Standardgateway, das zweite ist eine öffentliche IP-Adresse ohne Namensauflösung und das dritte ein Platzhalter für einen internen Namen. Ping prüft ICMP-Echo-Antworten. Filter oder Ratenbegrenzung können Antworten unterdrücken; ein fehlender Ping beweist daher weder einen Anwendungsfehler noch den Ausfall eines bestimmten Netzabschnitts.
Diese drei Aufrufe liefern Hinweise zur Eingrenzung: Verlust zum Gateway kann auf ein lokales Problem mit Kabel, Port oder WLAN hindeuten. Verlust erst zu einem externen Ziel kann auf Router, Leitung, Provider oder das Ziel selbst hinweisen. Scheitert bereits die Auflösung eines Namens, sollte die Namensauflösung getrennt geprüft werden. ICMP-Filterung und Ratenbegrenzung können die Messung beeinflussen; einzelne Ergebnisse sind Momentaufnahmen und sollten wiederholt werden.
Messen, während der Fehler auftritt
Paketverlust ist meist sporadisch und lastabhängig. Eine Messung am nächsten Morgen im leeren Büro belegt nichts. Wenn möglich, sollte während der gemeldeten Störung gemessen werden – oder wiederholt zu unterschiedlichen Zeiten, um ein Muster zu finden.
Die Ausgabe lesen
Die folgende Ausgabe ist fiktiv und dient nur als Rechenbeispiel; sie ist keine Messung eines realen Anschlusses.
Ping-Statistik für 8.8.8.8:
Pakete: Gesendet = 50, Empfangen = 47, Verloren = 3 (6% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 11ms, Maximum = 212ms, Mittelwert = 24ms
| Wert | Aussage |
|---|---|
| Verlust in % | Der zentrale Messwert. Paketverlust führt bei TCP zu Neuübertragungen und kann je nach Höhe, Dauer und Anwendung die Übertragungsrate deutlich reduzieren. |
| Mittelwert | Grundlatenz der Strecke. Allein aussagekräftig nur im Vergleich zu einem funktionierenden Referenzgerät. |
| Maximum | Die höchste beobachtete Laufzeit. Ein einzelner Spitzenwert kann auf eine Verzögerungsspitze hinweisen, belegt aber keine typische Schwankung (Jitter); dafür müssen die Messwerte über die Zeit betrachtet werden. |
| Minimum | Niedrigste in dieser Messung beobachtete Laufzeit. Liegt sie schon hoch, kann die Strecke selbst lang sein oder eine dauerhafte Auslastung aufweisen; sie ist keine exakte physikalische Untergrenze. |
| „Zielhost nicht erreichbar“ | Der lokale Rechner oder ein Router meldet, dass das Ziel nicht erreichbar ist. Das weist eher auf Routing, Filterung oder ein nicht verfügbares Ziel hin und ist nicht automatisch Paketverlust. |
| „Zeitüberschreitung der Anforderung“ | Keine Antwort innerhalb des Timeouts. Kann echter Verlust sein – oder eine Firewall, die ICMP verwirft. |
Die beiden letzten Zeilen führen häufig zu einem Auswertungsfehler: Eine „Zeitüberschreitung“ auf ein Ziel, das ICMP blockiert oder begrenzt, ist allein kein Nachweis für Paketverlust bei Anwendungsverkehr. Deshalb sollte wiederholt gegen ein Ziel gemessen werden, von dem bekannt ist, dass es auf ICMP antwortet.
Grobe Richtwerte, keine festen Grenzwerte
Die folgenden Bereiche sind nur Orientierung, keine allgemeingültigen Pass/Fail-Grenzen. Die Auswirkungen hängen von Anwendung, Protokoll, Dauer und Verteilung der fehlenden Antworten ab.
| Verlust | Auswirkung |
|---|---|
| 0 % | Unauffällig. Bei gemeldeten Störungen weitersuchen – Latenz, Jitter, DNS oder Anwendung. |
| unter 1 % | Als grobe Orientierung im Internet oft unauffällig. Innerhalb des eigenen LAN ist bereits geringer Verlust ein Hinweis zur weiteren Prüfung von Kabel, Port, Funk oder Adapter. |
| 1–3 % | Kann bei Sprache und Video auffallen; die Wirkung hängt unter anderem von Codec, Anwendung und Messstrecke ab. TCP-Downloads können langsamer werden. |
| über 3 % | Kann deutlich stören und Remote-Sitzungen beeinträchtigen. Die konkrete Wirkung hängt von Anwendung, Protokoll und Dauer des Verlusts ab. |
| über 10 % | Für viele interaktive Anwendungen sehr problematisch. Statt weiter zu optimieren, sollte die Ursache auf der betroffenen Strecke eingegrenzt werden. |
Im lokalen Netz gilt meist ein strengerer Maßstab als im Internet: Ein Ping auf das eigene Standardgateway sollte unter normalen Bedingungen keinen Verlust und eine niedrige Latenz zeigen. Abweichungen sind im LAN erklärungsbedürftig, müssen aber mit Wiederholungsmessungen und der konkreten Verbindung bewertet werden.
Traceroute und die ICMP-Falle
tracert ziel zeigt den Weg zum Ziel Station für Station. Dabei entsteht die verbreitetste Fehlinterpretation der Netzwerkdiagnose:
Sternchen an einer Zwischenstation sind meist kein Fehler
Router behandeln an sie selbst gerichtete ICMP-Antworten oft mit niedriger Priorität oder senden sie gar nicht. Erscheint ein Hop als * * *, während spätere Hops antworten, belegt das, dass zumindest einige Proben weiter gelangt sind; es beweist weder fehlerfreie Weiterleitung noch, dass alle Pakete diesen Hop passieren. Auch anhaltende Auffälligkeiten bis zum Ziel grenzen die Ursache nicht sicher auf den davorliegenden Abschnitt ein: ICMP-Filterung, Ratenbegrenzung und unterschiedliche Hin- und Rückwege können die Antworten beeinflussen.
Auch diese Traceroute ist vollständig fiktiv; die öffentlichen Adressen stammen aus für Dokumentation reservierten Netzen.
1 1 ms 1 ms 1 ms 192.168.10.1 2 8 ms 9 ms 8 ms 198.51.100.1 3 12 ms 11 ms 12 ms 198.51.100.14 4 * * * Zeitüberschreitung der Anforderung 5 17 ms 18 ms 17 ms 203.0.113.10
Hop 4 antwortet nicht, Hop 5 schon: Mindestens einige Proben sind weiter gelangt, doch über den normalen Verkehr oder die Zuverlässigkeit des Abschnitts sagt das allein nichts Sicheres aus. Traceroute sendet standardmäßig nur drei Proben pro Hop und eignet sich deshalb nicht zur belastbaren Verlustmessung; es hilft, den beobachteten Weg und Stellen ohne ICMP-Antwort zu erkennen.
pathping für Verlust pro Station
pathping kombiniert die Wegermittlung von tracert mit wiederholten ICMP-Proben. Die angezeigten Verlustraten beschreiben, wie häufig Router beziehungsweise Ziel auf diese Proben antworten; sie messen nicht unmittelbar, wie viele weitergeleitete Anwendungsdaten an einem Link verloren gehen.
pathping -q 100 8.8.8.8
Der Lauf kann je nach Anzahl der Hops einige Minuten dauern. Ein Verlustwert, der bei einem Router auffällt, bei späteren Hops und am Ziel aber nicht, deutet häufig auf eingeschränkte ICMP-Antworten dieses Routers hin und belegt keinen Transitverlust. Bleibt der Verlust auch am Ziel sichtbar, ist das ein Hinweis auf fehlende Antworten auf dem Weg zum Ziel, aber kein Beweis für einen bestimmten Abschnitt: zielseitige Filterung, Ratenbegrenzung und asymmetrische Rückwege sind ebenfalls möglich. Wiederhole den Lauf und vergleiche mit einem zweiten Ziel oder Gerät.
Ursache systematisch eingrenzen
- Verbindungsart klären.WLAN oder Kabel? Bei WLAN zuerst Signal, Band und Kanal prüfen – dort liegt die Ursache häufiger als auf der Leitung. Details unter WLAN Diagnose unter Windows.
- Gateway messen.
ping -n 50auf das Standardgateway. Verlust hier ist ein starker Hinweis auf ein lokales Problem; ICMP-Behandlung und Wiederholungsmessungen sollten dabei berücksichtigt werden. - Nach außen messen.Auf eine IP-Adresse ohne Namensauflösung. Verlust erst hier ist ein Hinweis auf fehlende ICMP-Antworten jenseits der lokalen Verbindung, lokalisiert aber keinen bestimmten Abschnitt; auch die ICMP-Behandlung am Ziel muss berücksichtigt werden.
- Namensauflösung trennen.Wenn IP-Adressen antworten, aber Namen nicht aufgelöst werden, spricht das für ein Problem der Namensauflösung. Eine erfolgreiche Auflösung mit anschließendem Ping-Fehler muss getrennt untersucht werden. Siehe ipconfig /all auswerten.
- Weg bestimmen.
tracertzur Wegbestimmung,pathpingzum Vergleichen von ICMP-Antworten an Stationen und Ziel. - Mit einem zweiten Gerät vergleichen.Der wirksamste Schritt: dieselbe Messung an einem unauffälligen Arbeitsplatz im gleichen Netz. Erst der Vergleich zeigt, ob das Gerät, der Port oder das Netz die Ursache ist.
Für Schritt 6 ist die manuelle Messung der Engpass, weil sie an mehreren Geräten wiederholt werden muss. admin-tools führt Ping mit konfigurierbaren Zielen, Traceroute, Routing-Tabelle und DNS-Prüfung in einem Durchgang aus und weist Paketverlust sowie minimale, mittlere und maximale Antwortzeit je Ziel als Kennzahl aus. Diese Messwerte bleiben Momentaufnahmen und ersetzen keine Prüfung von Filterregeln oder Anwendungsverkehr. Dieselbe Batch-Datei lässt sich an mehrere Anwender verteilen, sodass die Vergleichsmessung ohne zusätzliche Anleitung entsteht. Siehe auch die Windows-Diagnosefunktionen und die statische Windows-Beispielauswertung mit fiktiven Daten.