Ich habe mir mit PHP eine kleine Site gebastelt, auf der ich von unterwegs grundlegende Netztools zur Verfügung habe.
Unter ipv4.mobi gibts:

• ein “Was ist meine IP”-Tool (bei den mehrfach geNATteten Anbindungen im Mobilfunk essentiell)
• dazu Traceroute
• AS-Informationen
• und Reverse DNS Lookup.

Später werde ich wohl auch noch ein paar Funktionen wie BGP Routing einbauen (im Sinne eines “Looking Glass”), denn auch das kann man von unterwegs gut brauchen.

Dieser Artikel ist aus Sicht eines Gameserverhosters geschrieben, “wir” ist also die Filoo GmbH oder auch Gameserver-Hoster im Allgemeinen.

In unserer Gameserversparte Stormix Gameserver haben wir öfters mit Kunden zu tun, die sich über Probleme in der Anbindung (“Lag”, “Choke”, “loss”) beschweren. Diese Probleme werden häufig mit Ping- oder Traceroute-Ausgaben “belegt”. Es herrscht da aber bei den Kunden als auch bei einigen unserer Kollegen einige Verwirrung darüber, wie diese Ergebnisse zu interpretieren sind. Daher möchte ich hier mal grundsätzlich nach meinem besten Wissen aufklären, wie man einen “Trace” lesen sollte.

traceroute to absynth.dyndns.org (82.82.88.72), 30 hops max, 40 byte packets
1  ffm-93-190-64-1.gw.as47215.net (93.190.64.3)  3.165 ms  4.591 ms  4.575 ms
2  93-190-67-21.reverse.cust.as47215.net (93.190.67.21)  0.455 ms  0.550 ms  0.445 ms
3  194.25.210.57 (194.25.210.57)  4.372 ms  4.340 ms  4.306 ms
4  f-eb7-i.F.DE.NET.DTAG.DE (62.154.16.178)  0.727 ms  0.699 ms  0.664 ms
5  ffm-145-253-33-77.arcor-ip.net (145.253.33.77)  0.578 ms  0.599 ms  0.568 ms
6  ffm-145-254-16-241.arcor-ip.net (145.254.16.241)  2.227 ms  2.108 ms  2.072 ms
7  145.254.11.234 (145.254.11.234)  7.027 ms  6.800 ms  6.718 ms
8  dslc-082-082-088-072.pools.arcor-ip.net (82.82.88.72)  15.792 ms  16.716 ms  18.991 ms

Zuvor aber erst einmal eine kurze Einführung, wie Traceroute funktioniert und was es macht. Was es macht, ist einfach erklärt und ergibt sich schon aus dem Namen: Es verfolgt (= “trace”) den Weg (= “route”) eines Datenpakets durch ein IP-Netzwerk vom Sender zum Empfänger. Das macht es, indem es Pakete an den Empfänger schickt, die eine TTL (“Time To Live”) von anfangs 0, dann 1…etc. haben. Die TTL wird von jedem Router auf dem Weg um 1 gesenkt, und sobald sie 0 erreicht, wird eine Fehlermeldung an den Sender zurückgeschickt. Diese Fehlermeldung wird über das dafür gedachte Protokoll ICMP (Internet Control Message Protocol) versandt, das übrigens auch von traceroute oder ping genutzt wird, um die Pakete von Sender zu Empfänger zu schicken.

Über den Trick, die TTL schrittweise zu erhöhen, bis der Empfänger selber antwortet, kann in aller Regel jeder Router zwischen Quelle und Ziel ermittelt werden. Manchmal aber auch nicht und das ist

Problem 1: Wenn ein Router auf dem Weg ICMP-Nachrichten oder UDP-pakete (manche Versionen von traceroute nutzen keine ICMP- sondern UDP-Pakete) blockiert, etwa weil er firewalled ist, so wird dieser Hop des traceroute durch Timeouts (markiert durch Sternchen * * * ) markiert werden. Das heißt nicht, daß das Routing kaputt ist!

Problem 2: Wenn ein Traceroute (wie im Beispiel oben) reibungslos durchläuft, so kann man die aktuelle Route in eine Richtung von Quelle zu Ziel sehen. Diese kann sich aber deutlich von der Rückrichtung unterscheiden. Das nennt man “asynchrones asymmetrisches [danke an Kris] Routing” und das ist ein ganz normaler Vorgang im Traffic Engineering, z.B. wenn ein kleiner ISP wie wir sein Routing auf möglichst kurze Latenzen optimiert, aber große ISPs mit denen wir peeren, auf möglichst geringe Kosten. Dann schicken wir Pakete über die Telekom hin, sie kommen aber über unsere DE-CIX-Anbindung zurück. Das kann, muß aber nicht zu Problemen führen.

Schauen wir uns einen Traceroute mal an (komplettes Beispiel siehe oben):

2  93-190-67-21.reverse.cust.as47215.net (93.190.67.21)  0.455 ms  0.550 ms  0.445 ms

Hier steht, daß der zweite (2) Hop, der Host 93-190-67-21.reverse.cust.as47215.net mit der IP 93.190.67.21, innerhalb von 0.455, 0.550 und 0.445 ms auf jeweils ein ICMP-Paket geantwortet (also eines zurückgesendet) hat. Sieht erstmal OK aus. Woran sehen wir nun, wenn etwas nicht OK ist?

Typischerweise kann man tatsächliche Routingprobleme in einem einzelnen Traceroute an zwei Dingen sehen:

1. Ungewöhnlich lange Route (mehr als ca. 12 Hops von einem Dialin-Provider zu einem unserer Gameserver)
2. Dauerhaft ungewöhnlich hohe Latenzen auf einem oder mehreren Hops in der Route

Ich möchte beide Punkte hier erläutern und häufige Mißverständnisse ausräumen.

Zu 1)

Es passiert ab und an, daß irgendwo Leitungen wegbrechen (der berüchtigte Bagger) oder vom ISP auf Kosten optimiert wird (dann werden schlechtere Anbindungen, die halt billiger sind, bevorzugt). Dann verlängert sich die Route mal mehr, mal weniger.
Insbesondere wenn ein großer ISP Probleme mit einzelnen Knoten in seinem europaweiten Glasfaserring hat, kann es passieren, daß Pakete von z.B. Hamburg nach Frankfurt über seltsame Wege wie Paris oder Amsterdam geleitet werden. Diese Probleme sind in aller Regel temporär, aber stets meldenswert. Sie deuten auf Probleme an einem der großen Internetaustauschknoten (DECIX, VIX, AMSIX, LINX) hin, die nicht immer von einem Menschen bemerkt werden.

(Wieso das? Weil das Routingprotokoll BGP4, das in allen aktuellen IP-Netzen verwendet wird, Leitungsprobleme automatisch erkennt und behebt. So kann es passieren, daß ein Umrouting komplett automagisch vonstatten geht und das NOC, wenn angepißte Gameserverkunden anrufen, nicht einmal weiß, daß es Probleme gab.)

Ein weiteres, sehr viel selteneres Problem neben ungünstigem Routing sind tatsächliche Fehler im Routing, also z.B. Loops, bei denen derselbe Host/IP an mehreren Stellen nacheinander oder in Wechsel mit einem anderen mehrfach auftaucht. Das deutet auf echte Probleme hin und sollte unbedingt gemeldet werden.

Zu 2)

Wer einen normalen einzelnen tracert macht, der sollte sich darüber im Klaren sein, daß pro Hop genau 3 Pakete gesendet und gemessen werden, und daß die resultierende Aussage (Problem 3) genau nichts wert ist. Das Internet ist ein hochkomplexes Netz und es kann durchaus mal sein, daß ein paar Pakete zwischendurch höhere Laufzeiten hatten – z.B. auch weil der Clientrechner einfach gerade beschäftigt ist. Daher sollte man stets ein Tool wie z.B. mtr (Matt’s TraceRoute) oder WinMTR verwenden, die mehrere Pakete senden und daher auch einigermaßen aussagekräftige Resultate liefern. Es ist außerdem wichtig, unter Vista / Win7 das Tool als Admin zu starten, damit der IP-Stack nicht vollkommen verhunzt ist (das liefert nämlich auch unbrauchbare Resultate).

Mal so als Anhaltspunkt: Bevor ich einem meiner Upstreamprovider auf die Nase haue, weil seine Leitungen voll sind, lasse ich eine Stunde lang einen mtr-Traceroute laufen. Das sind über 3000 Pakete. Mindestens 100 Pakete sollte jeder vorweisen können, der uns eine Beschwerde zukommen läßt, alles andere ist aufgrund von Meßschwankungen zu ungenau um es sich überhaupt anzuschauen.

Sieht man an einem oder mehreren Hops deutlich erhöhte Reaktionszeiten, so ist das ein Indiz, daß etwas nicht in Ordnung ist. Besorgniserregend ist in der Regel eine Erhöhung um mindestens 20ms innerhalb eines Backbones und 100ms bei DSL-Zugangsnetzen. Daß ein traceroute derlei Probleme zeigt, heißt aber noch lange nicht, daß der Gameserveranbieter bzw. Hoster dran schuld ist. Um das festzustellen, muß man erst einmal ermitteln, wo der Hund begraben liegt.

Wie wir gerade schon erwähnt haben, ist ein Traceroute eine Verfolgung des Wegs von der Quelle zum Ziel einer Kommunikation. Die Quelle bei einem traceroute vom Kunden ist natürlich der Rechner des Kunden. Dann kommt sein eigener DSL-Router, der Übergang ins IP-Netz des Providers (T-Online, Vodafone, you name it) und dann beliebig viele Backbonerouter. Irgendwo gibt es dann einen oder mehrere Übergänge in andere Netze, die mehr oder minder schwer zu sehen sind. Schauen wir uns nochmal einen anderen Traceroute an.

Routenverfolgung zu dnscache1.de-punkt.de [93.190.64.60] über maximal 30 Abschni
tte:

1     3 ms     1 ms     1 ms  m638-mp2.cvx1-b.man.dial.ntli.net [62.252.202.126]
2    15 ms     9 ms     8 ms  popl-lam-4-tenge24-3716.network.virginmedia.net [82.14.169.62]
3     9 ms     7 ms     8 ms  popl-core-1a-ge-400-0.network.virginmedia.net [62.255.81.117]
4     7 ms     7 ms     7 ms  pop-bb-a-as2-0.network.virginmedia.net [213.105.174.234]
5    15 ms    15 ms    15 ms  amst-ic-1-as0-0.network.virginmedia.net [213.105.175.6]
6    24 ms    25 ms    32 ms  ramsix-astd-n101.nms.mediaways.net [195.69.144.91]
7    24 ms    25 ms    25 ms  195.71.254.129
8    27 ms    27 ms    27 ms  xmwc-frnk-de01-vlan-11.nw.mediaways.net [62.53.238.14]
9    28 ms    37 ms    29 ms  xfio-frnk-de01-vlan-35.nw.mediaways.net [217.188.245.170]
10    27 ms    26 ms    26 ms  tde-ffm-br01.as47215.net [195.71.237.218]
11    25 ms    32 ms    26 ms  bb01.av.backbone.filoo.de [93.190.67.18]
12    28 ms    34 ms    26 ms  dnscache1.de-punkt.de [93.190.64.60]

Ablaufverfolgung beendet.

Dieser traceroute ist ein bißchen länger, dafür kann man aber auch ein bißchen mehr sehen.

Los geht es bei einem merkwürdigen Hostnamen, der “dial” enthält. Das wird wohl irgendein Dialup-Knoten sein. Dann gehts bis zu Hop 5 weiter im Netzwerk “virginmedia.net”, das ist ein Dialup/DSL-Netzwerk in Großbritannien.

Auf Hop 5 sieht man eine Erhöhung der Laufzeit von 7 auf 15 ms. Das liegt daran, daß hier der Ärmelkanal überquert wurde (siehe der Hostname, “amst” steht für Amsterdam).

Hop 6 ist noch interessanter: Da steht “ramsix-irgendwas.mediaways.net”. Hier ist offenbar ein Übergang in ein anderes Netz passiert, nämlich in das von MediaWays (also known as Telefonica/O²). “ramsix” deutet darauf hin, daß dieser Hop physikalisch in Amsterdam am AMSIX (AMSterdam Internet eXchange) beheimatet ist.

Nun kommt ein bißchen Gedöns in Frankfurt (*-frnk-*.mediaways.net) und dann ist in Hop 10 wieder ein Übergang zu sehen: tde-ffm-br01.as47215.net ist unser Backbone-Router (“as47215″ steht für die internationale ID unseres IP-Netzwerks). Nun befindet sich das Paket also im Netz der Filoo GmbH und wird über einen Backboneswitch (bb01.av.backbone.filoo.de, Hop 11) zum Zielrechner (dnscache1.de-punkt.de, Hop 12) geleitet.

Beschwert sich der Kunde nun über eine hohe Latenz in Hop 5, ist er bei uns an der falschen Adresse. Wir sind erst ab Hop 10 überhaupt in der Lage, irgendetwas an einem möglichen Fehler zu ändern, davor können wir von der Filoo GmbH nur an den jeweiligen ISP zurückverweisen.

Mal noch ein paar Beispiele (danke an Crowfire!):

Hier ist der Fall auch klar (fett markiert): Bei Hop 2, also im Netzwerk des DSL-Zugangsanbieters, gibt es 14% Paketverlust. Da ist wahrscheinlich ein DSL-Knotenpunkt von T-Online überlastet. Das ist nicht Schuld des Gameserveranbieters!

Hier ist es etwas schwieriger, festzustellen woran es liegt. Sieht so aus als sei bei Hop 4/5, also bei der Netzverbindung zwischen dem Leipziger Knoten und dem Frankfurter Knoten von T-Online ein Problem. Vermutlich auch nix, was den Gameserverprovider (in diesem Fall nicht wir) anginge.

Auch ein schönes Beispiel (Kommentar des Kunden: “HIGHPING!!!!! an der Leitung kanns nicht liegen!”). Der fett markierte Hop ist der Übergang (“das Peering”) von Kabel Deutschland zu Telefonica. Dort ist offenbar die Leitung voll. Das kann Telefonicas Schuld sein oder die von Kabel Deutschland. Unsere ist es nicht.

Um das Ganze etwas zusammenzufassen: Wenn Ihr als Kunde eines Hosters oder Gameserverproviders eine mögliche Leistungsverschlechterung melden wollt, dann prüft bitte vorher, ob er auch Euer richtiger Ansprechpartner ist. In über 90% der Fälle in denen sich bei uns Kunden über hohe Pings, Paketverluste oder Schwankungen beklagen, ist der Zugangsprovider der Schuldige. Und an den solltet Ihr euch dann auch wenden, anstatt uns mit Kündigung, Klage, Leibstrafen oder sonstigem Ungemach zu drohen. Wir sind fast immer nicht schuld.

Seit heute ist unsere neue Seite online. Wir werden Sie an dieser Stelle in Zukunft mit aktuellen Nachrichten aus dem Bereich Webhosting versorgen. Also schauen Sie mal wieder rein!