Hetzner - DokuWiki

Pingplotter

Inhaltsverzeichnis

Netzwerkdiagnose mit Pingplotter und Co.

Pingplotter ist ein Windows-Programm, das ähnlich dem Traceroute-Befehl den Weg zwischen Client und Server im Netzwerk verfolgt, aber die Ergebnisse wesentlich übersichtlicher darstellt. Eine kostenlose Freewareversion kann unter

http://www.pingplotter.com

heruntergeladen werden.

Pingplotter perfect.png

Diese Abbildung zeigt einen fast perfekten Weg vom Client zum Server. In der zweiten Spalte würden Paketverluste, also verloren gegangene Testpakete dargestellt. Da hier aber keine Paketverluste auftraten, ist diese Spalte leer.

In den beiden Spalten IP und DNSName kann der Weg, den die Testpakete nehmen, nachvollzogen werden. Hier wurde beim Münchner Provider M-Net begonnen, die Pakete bei Hop 6 und 7 (im Peeringknoten INXS) an Noris übergeben und schliesslich bei Hop 9 (am Peeringknoten NIX) an das Hetzner-Netzwerk übergeben.

Die Spalten Avg und Cur stellen die Paketlaufzeit (in ms) bis zum jeweiligen Hop dar: Avg als Durchschnittswert, Cur zeigt den Wert der letzten Testpakete.

Zuletzt wird noch grafisch der Zeitablauf der Paketübertragung dargestellt. "Ausreisser" lassen sich so schnell am Verlauf der roten Linie erkennen. Man kann aber nur bedingt Rückschlüsse aus der Position der Linie ziehen: Die schwarzen Querlinien zeigen das Spektrum zwischen schnellster und langsamster Rückantwort dieses Hops. Anwortet nun ein Hop mal sehr spät, so verschiebt sich die rote Linie weiter nach links (weil rechts mehr Platz benötigt wird).

mtr

Falls Sie keinen Pingplotter besitzen, so können Sie die gleiche Funktionalität auch mit dem Programm mtr (bzw. WinMTR unter Windows) erreichen. Wie dies genau funktioniert ist hier beschrieben.

Typische Fehlerbilder

Es "laggt"!

Die Pings schnellen hoch, Terminalsitzungen ruckeln, Spiele werden unspielbar. Nicht immer ist der Server der Übeltäter, doch mit Pings als Diagnosewerkzeug kommt man nicht weit:

Pingplotter ping.png

Pingplotter bietet hier schon bessere Informationen:

Pingplotter lag.png

Man kann sofort erkennen, dass der Fehler (in dieser Simulation) im Netz von M-Netz zu sein scheint: Ab Hop 4 deutliche Verzögerungen, Pakete ab Hop 5 werden teilweise verworfen (was wiederum auf einen Fehler bei Hop 4 schliessen lässt), ab Hop 6 dann extreme Verzögerungen. Solche Fehlerbilder können von starken Engpässen, die beispielsweise durch DDoS-Angriffe entstehen, verursacht werden.

Paketverluste

Pingplotter loss.png

In diesem Beispiel ist die Sache anders: zwar werden viele Pakete ab Hop 10 verworfen, die Pingzeiten sind aber mit 37 ms im normalen Bereich. Hier könnte ein defekter Router oder ein Kabel Ursache sein.

Alles langsam

Gerade bei DSL-Anschlüssen findet man folgendes Fehlerbild häufig:

Pingplotter trace.png

Dieser wirre Traceroute zeigt nicht wirklich das Problem auf. Pingplotter ist da hilfreicher:

Pingplotter lag local.png

Hohe Last schon ab dem zweiten Hop deuten auf eine Überlastung der eigenen Internetanbindung hin, verursacht z.B. durch Versenden grosser Datenmengen per Mail, die den Upstream des ADSL-Anschlusses verstopfen. Oder auch durch Filesharing-Tools, die permanent im Hintergrund saugen, die man aber längst vergessen hat. Deutlich wird die Problemstelle auch durch einen Trace in die andere Richtung:

Pingplotter lag local rev.png

Alles im grünen Bereich, nur der Router des Client antwortet viel zu spät: Denkbar ist also nur eine Störung der Internetanbindung oder Überlastung des Client.

Paketverluste, die keine sind

Pingplotter Routerloss.png

Sowas ist eigentlich kein Fehler, denn dass Router mal nicht auf Testpakete antworten, ist normal. Je nach Konfiguration routen Router erstmal, und nur wenn dann noch Rechenleistung frei ist, antworten sie auf Testpakete. Solange die Hops dahinter nicht ebenfalls Pakete verlieren, besteht kein Grund zur Sorge.

Asymmetrisches Routing

Eine Fehlerdiagnose fällt relativ leicht, wenn der Hin- und Rückweg zwischen Client und Server über den selben Pfad führt. Aber oft nehmen Pakete einen anderen Rückweg (dies wird durch unterschiedliche Vorgaben der Provider des Client- und des Serverstandorts verursacht).

Die nachfolgende Animation (Flash-PlugIn erforderlich) soll das Problem verdeutlichen:

Fehlerbeispiel

In folgendem Beispiel schien das Netzwerk von Hetzner die Ursache der Verzögerungen zu sein, ab dem ersten Hetzner-Router stiegen die Pingzeiten erheblich an, Pakete wurden verworfen:

Client ---> Server

1 67 ms 65 ms 66 ms 62.26.xx.xx
2 63 ms 63 ms 65 ms 62.26.251.97
3 80 ms 74 ms 76 ms so-6-0-0.core3.f.tiscali.de (62.27.95.2)
4 74 ms 75 ms 73 ms so-3-0-0.fra30.ip.tiscali.net (213.200.64.25)
5 73 ms 74 ms 75 ms ffm-s2-rou-1071.DE.eurorings.net (80.81.192.22)
6 75 ms 74 ms 75 ms ffm-s1-rou-1001.DE.eurorings.net (134.222.227.65)
7 78 ms 79 ms 78 ms nbg-s1-rou-1071.DE.eurorings.net (134.222.227.30)
8 84 ms 78 ms 79 ms gi-0-1-286-nbg5.noris.net (134.222.107.26)
9 392 ms 393 ms * ne.gi-2-1.RS8000.RZ2.hetzner.de (213.133.96.65)
10 393 ms * 392 ms et-2-16.RS3000.RZ2.hetzner.de (213.133.96.38)
11 393 ms 392 ms * (...)


Erst bei Traceroute in umgekehrter Richtung erkannte man die eigentliche Fehlerquelle:

Server ---> Client

1 213.133.xx.xx (213.133.xx.xx) 0.233 ms 0.205 ms 0.281 ms
2 et-1-11.RS8000.RZ2.hetzner.de (213.133.96.37) 0.653 ms 0.660 ms 0.650 ms
3 nefkom-gw.hetzner.de (213.133.96.66) 1.119 ms 0.423 ms 0.415 ms
4 GW-SF-BBR-06-S2-3.nefkom.de (212.114.147.23) 0.635 ms 0.807 ms 0.457 ms
5 hsa2.mun1.pos6-0.eu.level3.net (212.162.44.25) 6.811 ms 6.347 ms 6.143 ms
6 ae0-19.mp1.Munich1.Level3.net (195.122.176.193) 315.587 ms 314.949 ms 315.164 ms
7 so-0-0-0.mp1.Frankfurt1.Level3.net (212.187.128.90) 301.324 ms 300.789 ms 300.742 ms
8 gige1-2.core1.Frankfurt1.Level3.net (195.122.136.101) 301.673 ms 300.853 ms 301.087 ms
9 de-cix.fra30.ip.tiscali.net (80.81.192.30) - 317.844 ms 317.634 ms
10 so-4-0-0.core3f.tiscali.de (213.200.64.26) 318.453 ms - 318.021 ms
11 so-1-0-0.core1.hh.tiscali.de (62.27.95.38) 307.780 ms 307.230 ms 307.252 ms
12 ge-2-0-0.7.core0.hh.tiscali.de (62.27.93.83) 307.431 ms 307.298 ms 307.084 ms
13 62.26.251.101 (62.26.251.101) - 307.753 ms 308.933 ms
14 (...) 390.856 ms 399.355 ms -


Hier war wohl eine Stelle zwischen zwei Level3-Routern in München Fehlerursache. Zunächst schien der Fehler von Hetzner auszugehen, da die Pakete bis zum Hop 8 (noris) wieder über die funktionierende Strecke zurückgeroutet wurden. Testpakete ins Hetzner-Netz und wieder zurück nahmen aber einen anderen Rückweg, der in München die Verzögerung auslöste.



© 2018. Hetzner Online GmbH. Alle Rechte vorbehalten.