Packet Loss

Welche Auswirkungen ein „instabiles Netzwerk“ hat, habe ich bei einem Kunden mal wieder am eigenen Leib erfahren. Diese Seite beschreibt die Fehlersuche und Lehren, die ich daraus gezogen habe.

Wichtig: Paketverlust und erneute Übertragungen kommen auch im regelbetrieb vor und sind ein wichtiges Kriterium, anhand dem Sender und Empfänger die Netzwerkübertragungsleistung ermitteln und anpassen können, damit alle Verbindungen aller Teilnahmer fair die Bandbreite aufteilen.

Ausgangssituation

Ich habe mich an einem Desktop angemeldet und Outlook gestartet. Da ich wechselnde Arbeitsplätze habe, nutze ich Outlook ohne OST-Datei direkt Online gehen Exchange. Damit fallen mir natürlich kleinste Unterbrechungen in der Verbindung auf. Das ist sehr gut, wenn gerade Exchange mit Loadbalancer eingeführt wird. Der Cache-Mode kaschiert doch einige Mängel im Netzwerk.

Aber ich habe parallel auch im Internet gesurft und per RDP mich mit Servern verbunden. Irgendwie war das aber alles nicht wirklich „schnell“ und wenn Outlook immer wieder die Verbindung verliert, dann stört das mächtig den Arbeitsablauf. Zuerst habe ich Angst um die Loadbalancer und Exchange Server gehabt. Vielleicht gibt es hier ein grundlegendes Problem. Aber andere Kollegen haben keine Effekte verzeichnet. Also bin ich zu den Wurzeln zurück und haben mit PING den gewünschten Server angesprochen. Die meisten Anfragen kamen auch zurück aber nicht alle.

PathPing, das bessere Ping

Ich habe dann mit PathPing viele Pakete senden lassen und hier recht schnell gesehen, dass 6-10% „packetloss“ bei einfachen ICMP-ECHO-Paketen anliegen. 

C:\Users\fc>pathping cas01.msxfaq.de
Routenverfolgung zu cas01.msxfaq.de [10.1.2.10]
über maximal 30 Abschnitte:
  0  pc1.msxfaq.de [10.1.30.173]
  1  10.1.30.3
  2     *     10.1.20.254
  3  cas01.msxfaq.de [10.1.2.10]
 
Berechnung der Statistiken dauert ca. 75 Sekunden...
            Quelle zum Abs.  Knoten/Verbindung
Abs. Zeit   Verl./Ges.=   %  Verl./Ges.=   %  Adresse
  0                                           PC1.msxfaq.de [10.1.30.173]
                                7/ 100 =  7%   |
  1    0ms    11/ 100 = 11%     4/ 100 =  4%  10.1.30.3
                                0/ 100 =  0%   |
  2    2ms     7/ 100 =  7%     0/ 100 =  0%  10.1.20.254
                                2/ 100 =  2%   |
  3    0ms     9/ 100 =  9%     0/ 100 =  0%  cas01.msxfaq.de [10.1.2.10]

Schon dieser test mit vielen Paketen zeigt, dass auf der ersten Stelle schon ca. 7% verloren gehen und angeblich auf dem dritten Teilstück auch noch mal 2%. Wobei das ja ein Nebeneffekt der Verluste auf der ersten Strecke sein könnten.

Teilstrecken messen

Ich habe mich dann erst mal auf die erste Teilstrecke zwischen dem Client und dem Default Gateway konzentriert. Das ist ja „LAN“ und daher schnell, in der Regel nicht überlastet und durch Switches idealerweise kollisionsfrei. Ein einfacher „Ping“ ist selbst mit der Option „-t“ als Dauerping nicht ausreichend. PathPing ist hier viel effektiver, da per Parameter die Anzahl der Pakete pro Abschnitt und die Pausenzeit zwischen den Paketen bestimmt werden kann

REM: 100 Pakete pro Abschnitt mit 1ms Abstand 
pathping 10.181.30.1 -p 0 -q 100

Auf dem Netzwerk ist dann folgendes zu sehen: (Hier allerdings in meinem Haus-LAN, da ich auf dem Problem-PC kein lokaler Admin war und daher keine Netzwerkmitschnitte aufzeichnen konnte:

Es ist aber gut zu sehen, dass hier in schneller Folge ICMP-Pings und die Antworten ankommen. Das ist zwar keine „hohe Last“ aber doch sehr viele Pakete in einer Sekunde und damit lassen sich viel schnelle Paketverluste ermitteln. Es reicht aber natürlich nicht für eine Durchsatzmessung. Zudem hilft diese Messing nicht, wenn die Paketverluste nicht allgemeiner Natur sind, sondern nur größere Pakete oder bestimmte Ports erwischen. Wenn eine „Firewall“ Pakete blockiert oder ein Router zu große Pakete nicht korrekt segmentiert, ist das auch eine Art „Paketverlust“. Das ist aber eine andere Story.

Hinweis:
Wenn Sie einen HTTP-Proxy einsetzen, dann kann der Ping oft nicht bis zum Zielsystem laufen. Hier messen Sie dann nur Teilstrecken.

Lösung

Da hier das Problem schon auf dem Weg vom Client zum Gateway aufgetreten ist, startet die Suche im lokalen LAN. Um es kurz zu machen: In diesem Fall war es das Netzwerkanschlusskabel, welches den PC vom Tisch zur Wand-Dose verbunden hat. Es hat wohl schon einige Jahre seinen Dienst zwischen den Schreibtischbeinen hinter sich und wurde sicher schon ein paar mal unsanft behandelt und wurde so einfach immer schlechter. Interessanterweise hat ein umstecken des Kabels in eine andere Patchdose auch schon geholfen. Es können also auch Kontaktkorrosion o.ä. eine Rolle gespielt haben. Nachdem die Netzwerktruppe den Patch selbst geprüft hat, wurde daher das Kabel getauscht und alle folgenden PathPing haben 0% Loss gehabt.

Interessant war hier die „schleichende“ Verschlechterung. Leider hatte ich nicht Change auf dem Switch die Statistiken einzusehen, ob es andere „Vorwarnsignale“ gegeben hat. Eine schlechte Leitung kann durchaus Fehler verursachen, auf die man nicht so einfach kommt. Ich hatte ursprünglich auch erst einmal auf den neu installierten Loadbalancer oder die Server getippt, weil der Client ja schon jahrelang problemlos gearbeitet hatte. Es zeigt sich aber wieder mal, dass man immer an den Grundlagen anfangen sollte, die z.B. per PathPing in wenigen Sekunden geprüft werden konnten.

Ich habe dann natürlich noch mal den Test gegen die Exchange Server wiederholt und natürlich war dann auch auf den dritten Teilstück kein Paketverlust mehr zu sehen:

C:\Users\fc>pathping cas01.msxfaq.de -p 1 -q 150

Routenverfolgung zu cas01.msxfaq.de [10.181.200.10]
über maximal 30 Abschnitte:
  0  PC1.msxfaq.de [10.1.30.173]
  1  10.1.30.3
  2  10.1.201.254
  3  cas01.msxfaq.de [10.1.2.10]
 
Berechnung der Statistiken dauert ca. 0 Sekunden...
            Quelle zum Abs.  Knoten/Verbindung
Abs. Zeit   Verl./Ges.=   %  Verl./Ges.=   %  Adresse
  0                                           PC1.msxfaq.de [10.1.30.173]
                                0/ 150 =  0%   |
  1    0ms     0/ 150 =  0%     0/ 150 =  0%  10.1.30.3
                                0/ 150 =  0%   |
  2    1ms     0/ 150 =  0%     0/ 150 =  0%  10.1.201.254
                                0/ 150 =  0%   |
  3    0ms     0/ 150 =  0%     0/ 150 =  0%  cas01.msxfaq.de [10.1.2.10]

Die Anzeige des PathPing weiter oben war also in dem Fall irreführend.

Packetloss mit VoIP

Dies war nun ein Beispiel mit 5-10% Packetloss bei der Nutzung von TCP-Verbindungen. TCP ist ja „verbindungsgesichert“ und erkennt fehlende Pakete und fordert diese noch mal an. Diese „Heilung“ von Paketverlusten funktioniert aber nur, wenn die Verlustrate nicht zu hoch wird. Der Empfänger wartet nämlich schon etwas, bis er von einem Verlust ausgeht und wenn dann die Nachforderung zufällig auch verloren geht, dann kann sich die Wartezeit deutlich verlängern. In meinem Fall kamen z.B. RDP-Verbindungen gar nicht erst zustande.

Wird über so eine Verbindung dann noch Sprache und Video per RTP übertragen, dann sind 5-10% Paketverluste deutlich zu viel.

Bei nächster Gelegenheit habe ich vor, eine Audio/Video-Wiedergabe aufzuzeichnen und gezielt die Pakete zu droppen. Dann können Sie am besten selbst hören, wie sich bestimmte Packetloss-raten auswirken.

Überwachung ist erforderlich

Ich habe auf verschiedenen anderen Seiten der MSXFAQ schon über die Besonderheiten von Netzwerken und VoIP im Speziellen etwas geschrieben. Diese "Erfahrung", die mich hier nur an einem Client betroffen hat, zeigt wieder einmal wie wichtig die "richtige" Überwachung ist. Als versierter Nutzer konnte ich auch ohne lokale Administratorenrechte oder Zugriff auf den Switch allein mit Bordmitteln mir behelfen und das Problem einkreisen. Mit den Vorabinformationen konnte der Helpdesk dann gleich die richtigen Fachleute mit Kabeltester und Ersatzkabel an den Platz senden und das Problem beheben.

Was macht aber ein Arbeitgeber mit einem weniger versierter Anwender, der nur unspezifisch über einen "langsamen PC" und allgemeine Probleme berichtet? Wie viel Zeit geht hier verloren, weil wir als Windows-gläubige Administratoren eher aus der Ferne und Perfmon und Eventlog anschauen oder per Fernsteuerung mit Process Explorer, ProcMon, Wireshark und anderen schönen Tools nach dem verantwortlichen Prozess suchen.

Was machen wir aber mit Servern, auf denen in der Regel niemand interaktiv arbeitet und man sich daher nicht direkt über "Probleme" beschweren wird sondern auch nur indirekt durch Anwender beim Zugriff auf den Server ein Feedback bekommen? Wie oft sind Server "langsam" und man sucht bei Exchange, dem Storage, Virenscannern o.ä. nach Fehlern und letztlich ist es vielleicht nur die Netzwerkkarte oder der Netzwerklink?.

Wenn sich alle Komponenten ordentlich benehmen und die Verbindung über TCP abgewickelt, wird, dann ist Perfmon wirklich ein Werkzeug um solche Probleme zu ermitteln. Es gibt einen Counter unter TCPv4 bzw. TCPv6, der die Anzahl der erneut übertragenen Segmente/Sek meldet. Bei UDP und IP gibt es den Counter Prinzip-bedingt nicht. Leider ist das kein Summencounter, sondern nur "pro Sekunde". Man muss also schon häufiger abfragen oder den Durchschnitt/Max-Wert auswerten.

Dann ist aber dieser Counter schon ein erstes Alarmzeichen, dass vielleicht im Netzwerkstack ein Problem vorhanden sein könnte. Ich drücke das absichtlich vorsichtig aus, denn erneut übertragene Segmente durchaus normal sein können. Stellen Sie sich vor ein Client ist in einer entfernten Lokation, die per WAN angebunden ist, Hier kann es schon mal passieren, dass die bereits gesendeten Pakete noch mal gesendet werden müssen, weil diese auf dem WAN verworfen wurden. Wobei man hier natürlich auch der Buffer des Routers eine Rolle spielt.

Wenn aber ein Server primär lokal angesprochen wird, sollten diese Counter 0 oder niedrig sein. Sehr interessant ist in dem Zuge auch der Vergleich des Counters verschiedener Server. Ein Server, der hier nach oben aus der Rolle fällt, sollte vielleicht untersucht werden.

Beachten Sie dazu die Seite TCP Retransmit Monitoring und TCP Retransmit und SACK

Physik in Ordnung?

Auf der physikalischen Schicht lohnt sich durchaus mal der Blick auf die Management-Software der Netzwerkkarte. Einige Hersteller packen hier Tools ein, mit denen sogar ein Kabeltest möglich ist. Dies ist mittlerweile sogar bei diversen Switches mit an Bord. Hier am Beispiel eine 100€ 24port TPLink TL-SG1024DE:

Selbst dieses einfache Gerät kann zumindest die Länge der Kabel müssen. Aber für eine qualifizierte Aussage der Verbindung ist das natürlich nicht ausreichend.

Überwachung durch aktive Tests

Letztlich läuft es wieder darauf hinaus, dass man aktiv Verbindungen zum Server aufmacht und die Qualität der Leitung überwacht. Das kann man z.B. mit PRTG und dem dort enthaltenen QoS Sensor machen. Oder man baut sich eigene Skripte und Tools, die Daten zu einem Dienst senden und dabei überwachen, wie viele "Retransmits" es gibt um so eine Teilstrecke zu profilieren.

Genau genommen ist dies das Gleiche, was ich mit meinen "End2End"-Tests für verschiedene Dienste schon länger propagiere. In dem Fall ist es der End2End-PING-Test, mit dem man die lückenlose Erreichbarkeit einer Gegenstelle prüfen kann und quasi über viele Monate hinweg die Veränderungen der Betriebswerte erkennen könnte. Leider fehlen mir hierzu aber noch Langzeitwerte oder ein Kabel, welches man absichtlich "verschlechtern" kann. Und dann steht ja immer noch die Frage im Raum, ob diese Verluste sich noch nach der Länge der Pakete unterscheiden.

Weitere Links