Ratgeber

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 Pakete. Damit ist die kleinste messbare Verlustrate 25 % – und ein realer Verlust von 2 % bleibt in den meisten Läufen komplett unsichtbar. Für eine belastbare Aussage braucht es mehr Pakete:

ping -n 50 192.168.10.1        :: Standardgateway, 50 Pakete
ping -n 50 8.8.8.8             :: öffentliche IP-Adresse, ohne Namensauflösung
ping -n 50 fileserver.firma.intern   :: interner Name, prüft auch den DNS

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

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	Der wichtigste Wert neben dem Verlust. Ein Maximum, das ein Vielfaches des Mittelwerts beträgt, zeigt Jitter – für Sprache und Video oft schlimmer als konstant hohe Latenz.
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“	Eine Station auf dem Weg 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 grundsätzlich blockiert oder begrenzt, ist allein kein Befund. Deshalb sollte immer gegen ein Ziel gemessen werden, von dem bekannt ist, dass es antwortet.

Grenzwerte zur Einordnung

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-Pakete mit niedriger Priorität oder antworten grundsätzlich nicht. Ein Hop, der mit * * * erscheint, während alle folgenden Hops normal antworten, leitet den Verkehr wahrscheinlich weiter – er beantwortet nur die Messung nicht. Bleibt der Verlust ab einem Hop bis zum Ziel erhöht, ist das ein starker Hinweis auf ein Problem in diesem Abschnitt; die Messmethode und ICMP-Ratenbegrenzung müssen mitbewertet werden.

  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 antwortet – das spricht dafür, dass Hop 4 den Verkehr weiterleitet, aber die ICMP-Messung nicht beantwortet. Eine fehlerfreie Strecke ist damit nicht bewiesen; dafür sind weitere Messungen bis zum Ziel und gegebenenfalls Wiederholungen erforderlich. Zweiter wichtiger Punkt: Traceroute sendet je Hop nur drei Pakete. Als Verlustmessung ist das Verfahren daher ungeeignet; es dient ausschließlich der Wegbestimmung.

pathping für Verlust pro Station

Wer wirklich wissen will, ab welcher Station Pakete verloren gehen, nutzt pathping. Der Befehl bestimmt zuerst den Weg wie tracert und sendet danach über einen längeren Zeitraum Pakete an jede Station, um pro Hop eine Verlustrate zu berechnen.

pathping -q 100 8.8.8.8

Der Lauf dauert je nach Anzahl der Hops einige Minuten. Zu lesen ist die Spalte mit dem Verlust zu jeder Station: Steigt der Wert an einem Hop an und bleibt bis zum Ziel erhöht, ist das ein starker Hinweis auf ein Problem in diesem Abschnitt. Steigt er nur an einem Hop und ist danach wieder null, spricht das eher für ICMP-Priorisierung als für echten Transitverlust.

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 50 auf 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 ein Problem außerhalb der lokalen Verbindung; auch die ICMP-Behandlung am Ziel und Zwischenstationen 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.tracert zur Wegbestimmung, pathping für den Verlust pro Station.
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. Dieselbe Batch-Datei lässt sich an mehrere Anwender verteilen, sodass die Vergleichsmessung ohne zusätzliche Anleitung entsteht.

Windows Netzwerkdiagnose ausprobieren → Einsatz im Helpdesk ansehen