Antworten auf Ihre häufigsten Fragen

Wie führe ich einen Erreichbarkeitstest durch?

(English version below)

Wenn Ihr Server bei uns nicht oder schlecht zu erreichen ist, ist es für die Fehlersuche oft nötig, das Problem mit einer Routenverfolgung einzugrenzen. Hier erfahren Sie mehr darüber.

Kurz und schmerzlos - Einen Traceroute per MTR erstellen ohne viel zu lesen:

Wenn Sie einfach nur einen Traceroute erzeugen möchten, ohne viel darüber wissen zu wollen, führen Sie folgende Schritte aus:

  1. Laden Sie auf dem Rechner das Programm (Win)MTR herunter (Links siehe unten).
  2. Starten Sie dieses und geben Sie dort die Adresse des problematischen Zielservers an.
  3. Starten Sie die Routenverfolgung und lassen Sie sie einige Zeit laufen (30 Sekunden sind ein guter Anfang).
  4. Kopieren Sie die Ausgabe (bei Windows "Export Text") in eine E-Mail und schicken Sie uns diese zu.

Downloadlinks:

Ausführlichere Infos:

Die vermaschte Struktur des Internets führt dazu, dass Daten um von einem Punkt zum anderen zu kommen oft mehrere Möglichkeiten ("Routen") haben. Wenn also ein Server Erreichbarkeitsprobleme aufweist, kann man eine Routenverfolgung dazu benutzen herauszufinden, wo Daten verloren gehen oder nur langsam transportiert werden.

Eine solcher Aufruf auf dem Quellrechner (hier ein Dedicated Server bei uns) erfolgt durch Angabe eines Zielrechners (in diesem Fall www.hosteurope.com, ein Server in England), am besten per MTR.

(Win)MTR stellt die Ergebnisse der Routenverfolgung sehr übersichtlich dar, dort werden auch Paketverluste und einige statistische Daten mehr angezeigt:

Wenn MTR auf Ihrem PC nicht zur Verfügung steht, können Sie alternativ den Befehl "traceroute" (Linux, MacOS), "tracert" (Windows) oder auch "pathping" nutzen. 
Für die besten Resultate nutzen Sie jedoch bitte MTR, wie oben angegeben.

Eine solcher Aufruf auf dem Quellrechner (hier ein Dedicated Server bei uns) erfolgt durch Angabe eines Zielrechners (in diesem Fall www.hosteurope.com, ein Server in England), z.B. so:

oder unter Windows:

Unter Windows:

Die Angaben sind so zu verstehen, dass die Position und Namen der Netzwerkknoten (Router) auf dem Weg dargestellt werden, dazu drei Messwerte für die Laufzeit eines Datenpaketes. Bei den ersten vier Punkten ("Hops") liegt die Zeit bei unter einer Millisekunde. Zum fünften Hop sind es dann plötzlich schon 20. Wie man aus dem Namen des Routers erschließen kann, befindet sich dieser schon in LONdon/England, so dass sich diese Laufzeit tatsächlich realistisch ist. Die Zeiten variieren beim gleichen Hop leicht durch verschiedene variable Eckdaten wie Auslastung der Leitung.
Beim 12 Hop, dem eigentlich Ziel erscheinen keine Daten mehr. Eine Firewall sorgt anscheinend dafür, dass hier keine Antworten auf unsere Datenpakete erzeugt werden (Traceroute benutzt unter Linux sog. UDP-Pakete, die gefiltert werden können, die Option "-I" schaltet auf ICMP um. Unter Windows wird normalerweise ICMP verwendet).

Typische Netzwerkprobleme äußern sich auf folgende Arten und Weisen:

  • Die Laufzeiten werden von einem Hop zum nächsten plötzlich und unerwartet massiv größer. "Unerwartet" ist dies dann, wenn keine Leitungseigenschaften dies erwarten lassen; eine gängige DSL-Leitung hat z.B. Laufzeiten zwischen 20 und 80 ms allein beim ersten Hop.
  • Die Route erreicht das Ziel nicht sondern endet unterwegs; die Daten erreichen also das Ziel nicht.

Solche Störungen liegen im Einflussbereich des jeweiligen Providers, der hier ggf. durch Routingänderungen oder Kapazitätenvergrößerung reagieren kann.

Scheinbare Störungen/Paketverlust unterwegs, aber nicht zum Ziel:

Wenn Sie eine Leitungsstörung aufgrund eines Traces annehmen, der wie folgt aussieht, obwohl Sie möglicherweise noch nicht mal Probleme bemerken, finden Sie hier eine Erklärung.

Diese Anzeige ist zu entnehmen, dass der Router 4. nicht auf alle Pakete eine Antwort sendet, der angesprochene Zielserver aber schon. In diesem Fall kann man nicht auf ein Erreichbarkeitsproblem des Servers schließen.

Ursache für ein solches Verhalten liegt in der Arbeitsweise des Routers selbst begründet. Solange keine Verluste beim Zielserver (hier 8.) auftreten, liegt kein hier erkennbares Problem vor.
 

How do I perform a reachability test?

If your server with us is not reachable or has poor connectivity, it is often necessary for troubleshooting to narrow down the problem using a route trace. Here you can find out more about this.

Quick and Easy - Creating a Traceroute with MTR without Reading Too Much

If you simply want to generate a traceroute without needing to know much about it, follow these steps:

  1. Download the (Win)MTR program to your computer (see links below).
  2. Start the program and enter the address of the problematic destination server.
  3. Start the route tracing and let it run for a while (30 seconds is a good starting point).
  4. Copy the output (on Windows, use "Export Text") into an email and send it to us.

Download links:

More Detailed Info

The meshed structure of the internet means that there are often several possible ways ("routes") for data to travel from one point to another. If a server is having connectivity issues, a route trace can help determine where data is being lost or delayed.

Such a trace is run on the source computer (here, a dedicated server with us) by specifying a destination computer (in this case, www.hosteurope.com, a server in England), preferably using MTR.

(Win)MTR displays the results of the route trace in a very clear way, showing packet loss and some additional statistical data:

If MTR is not available on your PC, you can alternatively use the "traceroute" command (Linux, macOS), "tracert" (Windows), or even "pathping".
For best results, however, please use MTR as described above.

A trace on the source computer (here, a dedicated server with us) is done by specifying a destination computer (in this case, www.hosteurope.com, a server in England), for example as follows:

or on Windows:

On Windows:

The output should be interpreted as follows: the positions and names of the network nodes (routers) along the way are displayed, as well as three measurements for the transit time of a data packet. For the first four points ("hops"), the time is under one millisecond. By the fifth hop, it's suddenly 20ms. As you can see from the router's name, this one is already in LONdon/England, so this transit time is actually realistic. The times for the same hop may vary slightly due to various factors such as line utilization.

At the 12th hop, the actual target, no more data appears. Apparently, a firewall is ensuring that no responses to our data packets are generated here (Traceroute uses so-called UDP packets under Linux, which can be filtered; the "-I" option switches to ICMP. On Windows, ICMP is usually used).

Typical network problems manifest themselves as follows:

  • The transit times suddenly and unexpectedly increase significantly from one hop to the next. This is "unexpected" when no line characteristics suggest it; for example, a typical DSL line has transit times between 20 and 80 ms just on the first hop.
  • The route does not reach the target but ends somewhere along the way; in other words, the data does not reach the destination.


Such disruptions are within the provider's area of responsibility, and the provider can respond by changing routing or increasing capacity.

Apparent disruptions / packet loss on the way, but not to the target

If you suspect a line issue due to a trace that looks like this, even though you may not even notice any problems, here is an explanation:

This output shows that router 4 does not respond to all packets, but the addressed target server does. In this case, you cannot conclude that there is a reachability problem with the server.

The reason for such behavior lies in the way the router itself works. As long as there are no losses at the target server (here, hop 8), there is no identifiable problem.

otto.friedrich@hosteurope.de xanthippe.ypsilante@hosteurope.de hercules.ikarus@hosteurope.de