Netzwerkdiagnose und Report an Hetzner

Last change on 2024-12-11 • Created on 2024-12-03 • ID: CL-68C7A

Einführung

Falls Sie Netzwerkprobleme mit Ihrem Server haben, schicken Sie bitte eine Support-Anfrage über Cloud Console. Bitte wählen Sie "Technik" aus und geben Sie als Anliegen "Problem mit öffentlichem Netzwerk" oder "Problem mit privatem Netzwerk" an. Damit wir das Problem untersuchen können, ist es wichtig, dass Sie den betroffenen Server angeben.

Server ist nicht erreichbar

Falls Ihr Server nicht erreichbar ist, können Sie ihn selbst neu starten. Die Option finden Sie in der Cloud Console, wenn Sie den betroffenen Server auswählen und in der oberen Server-Menüleiste zu "Power" wechseln. Klicken Sie auf "Ausschalten". Nachdem der Server ausgeschalten wurde, können Sie auf "Einschalten" klicken, um den Server neu zu starten.

Wenn der Neustart nicht hilft, kann es sein, dass der Server von unserer Seite aus gesperrt wurde. In dem Fall werfen Sie bitte einen Blick auf den Leitfaden bei Serversperrung.

Falls Sie weiterhin Probleme haben, dann schicken Sie uns bitte eine Anfrage über Cloud Console. Bitte wählen Sie "Technik" aus und geben Sie als Anliegen "Problem mit öffentlichem Netzwerk" oder "Problem mit privatem Netzwerk" an. Wählen Sie den betroffenen Server aus und geben Sie in der Beschreibung "Server ist nicht erreichbar" an.

Paketverluste

Falls Paketverluste auftreten sollten, dann benötigen Sie einen Nachweis dafür. Einfache Angaben wie z.B. "mein Ping ist schlecht" oder "Pakete gehen verloren" sind leider nicht ausreichend, um das Problem einzugrenzen.

Wir benötigen in dem Fall ein MTR über mindestens 200 Pakete in beide Richtungen. Dafür können Sie Programme wie MTR oder WinMTR benutzen. Das Programm MTR kann mithilfe eines Paketmanagers unter Linux oder MacOS installiert werden. Für Windows können Sie das Programm von einer bestimmten Website herunterladen. Hier ist eine Übersicht, wie Sie das Programm unter bestimmten Betriebssystemen einrichten können.

OS-Typ Betriebssystem Installation
Linux Debian/Ubuntu apt install mtr-tiny
Linux CentOS/RHEL yum install mtr
Linux SuSE yast -i mtr
Linux Arch Linux pacman -S mtr
Linux Gentoo emerge -av mtr
Windows Windows 98 und neuer https://sourceforge.net/projects/winmtr/
MacOS * brew install mtr (HomeBrew vorrausgesetzt)

Folgendes ist bei der Erstellung des MTRs für unsere Techniker zu beachten:

  • mindestens 200 Pakete sollten verschickt werden
  • der MTR wird in beide Richtungen benötigt, d.h. vom Server zum Kunden (lokaler PC, Laptop etc.) und vom Kunden zum Server
  • Die IP-Adresse Ihres lokalen Endpunktes können Sie über ein Online-Tool ermitteln, wie zum Beispiel https://ip.hetzner.com/

Folgender Befehl eignet sich hervorragend für die Anfertigung eines MTRs unter Linux oder MacOS:

mtr -s 1000 -r -c 200 <ZIEL-IP_ODER_DOMAIN>

Bitte führen Sie dazu den genannten Befehl auf beiden Systemen aus und setzen Sie die IP-Adresse oder Domain der entsprechenden Gegenstelle anstelle der Platzhalter ein:

[user@SERVER]$ mtr -s 1000 -r -c 200 <CLIENT-IP_ODER_DOMAIN>
[user@CLIENT]$ mtr -s 1000 -r -c 200 <SERVER-IP_ODER_DOMAIN>

Der Test dauert in der Regel etwa 3-4 Minuten.

Wichtig:

  • Wenn Ihr MTR den letzten Hop als nicht erreichbar anzeigt, ist vermutlich das installierte System oder Ihr lokaler Router so eingestellt, dass ICMP-Anfragen aus Sicherheitsgründen ignoriert werden. Trotzdem kann der MTR zur Untersuchung der Verbindung verwendet werden.
  • Die Zeilen/Hops eines MTR zeigen den Verlauf der betreffenden Verbindung auf. Ihr MTR kann daher ganz anders aussehen unsere hier verwendeten Beispiele.

Ein Problem, welches im Ergebnis des Tests sichtbar wird, kann ein falsches Routing, eine zu hohe Latenzzeit auf einem der Netzwerk-Hops oder Paketverlust sein, der dann zu einer erneuten Übertragung der betreffenden Pakete führt. Bitte beachten Sie bei der Auswertung und Übermittlung folgende drei Arten von Paketverlust:

1. Paketverlust, welcher bis zum Ziel-Hop verschwindet

  • Wie Sie in diesem Beispiel sehen können, werden bei den Hops 4 und 5 Paketverluste angezeigt:

    1.|-- your_client.example.com    0.0%  1000    0.2   0.1   0.1  11.0   0.9
2.|-- 15172.your-cloud.host      0.0%  1000    0.2   0.2   0.1  11.0   0.8
3.|-- spine2.cloud1.hel1.hetzne  0.0%  1000   13.4  18.0   1.6 328.3  19.7
4.|-- spine15.cloud1.hel1.hetzn  4.2%  1000    0.8   1.3   0.7  50.0   3.1
5.|-- spine3.cloud1.hel1.hetzne 31.7%  1000    0.5   2.9   0.3  51.2   6.6
6.|-- 16659.your-cloud.host      0.0%  1000    0.6   1.4   0.4  56.6   4.2
7.|-- your_host.example.com      0.0%  1000    0.5   0.4   0.3  11.0   0.9

  • Da der Paketverlust auf 0% zurückkehrt, bevor die Verbindung den letzten Hop erreicht, zeigt der MTR in diesem Fall keine Probleme an, welche die Verbindung zu Ihrem Server beeinträchtigen könnten. Dieses Verhalten wird lediglich von Routern verursacht, die ICMP-Pakete ignorieren (z.B. um Bandbreite oder Rechen-Leistung zu sparen).

2. Paketverlust nur auf dem letzten Hop

  • In diesem Beispiel wird kein Paketverlust aufgezeigt, mit Ausnahme des letzten Hops

    1.|-- your_client.example.com    0.0%  1000    0.2   0.1   0.1  11.0   0.9
2.|-- 15172.your-cloud.host      0.0%  1000    0.2   0.2   0.1  11.0   0.8
3.|-- spine2.cloud1.hel1.hetzne  0.0%  1000   13.4  18.0   1.6 328.3  19.7
4.|-- spine15.cloud1.hel1.hetzne 0.0%  1000    0.8   1.3   0.7  50.0   3.1
5.|-- spine3.cloud1.hel1.hetzner 0.0%  1000    0.5   2.9   0.3  51.2   6.6
6.|-- 16659.your-cloud.host      0.0%  1000    0.6   1.4   0.4  56.6   4.2
7.|-- your_host.example.com     42.0%  1000    0.5   0.4   0.3  11.0   0.9

  • Dieses Problem wird in der Regel auf dem Server selbst verursacht, z.B. durch voll ausgenutzte Systemleistung, eine falsch konfigurierte Software-Firewall oder in seltenen Fällen durch die Netzwerkkarte bzw. das Uplink-Kabel. Bitte überprüfen Sie daher in einem solchen Fall zuerst Ihr installiertes System. Wenn Sie keines der genannten Probleme auf Ihrem System feststellen können, lassen Sie uns bitte die MTRs zur weiteren Untersuchung zukommen.

3. Paketverlust auf der Verbindung

  • Hier beginnt der Paketverlust beim Hop 5 und hält bis zum letzten Hop an

    1.|-- your_client.example.com    0.0%  1000    0.2   0.1   0.1  11.0   0.9
2.|-- 15172.your-cloud.host      0.0%  1000    0.2   0.2   0.1  11.0   0.8
3.|-- spine2.cloud1.hel1.hetzne  0.0%  1000   13.4  18.0   1.6 328.3  19.7
4.|-- spine15.cloud1.hel1.hetzn  0.0%  1000    0.8   1.3   0.7  50.0   3.1
5.|-- spine3.cloud1.hel1.hetzne 55.1%   551    0.5   2.9   0.3  51.2   6.6
6.|-- 16659.your-cloud.host     54.9%   549    0.6   1.4   0.4  56.6   4.2
7.|-- your_host.example.com     59.2%   592    0.5   0.4   0.3  11.0   0.9

  • Bitte senden Sie uns in diesem Fall die beiden MTRs direkt zu, damit wir das Problem untersuchen können. Falls der Paketverlust bereits außerhalb unseres Netzwerks beginnt (bzw. an einem Netzknoten, auf den wir keinen Zugriff oder Einfluss haben), wenden Sie sich bitte sowohl an den betreffenden Netzbetreiber, als auch an uns.

Falls Sie weiterhin Probleme haben, dann schicken Sie uns bitte eine Anfrage über Cloud Console. Bitte wählen Sie "Technik" aus und geben Sie als Anliegen "Problem mit öffentlichem Netzwerk" oder "Problem mit privatem Netzwerk" an. Wählen Sie den betroffenen Server aus und geben Sie in der Beschreibung "Packet Loss" an. Bitte senden Sie die Ausgabe der MTRs als Anhang Ihrer Anfrage.

Formatierung eines MTR

Bitte hängen Sie bei Support-Anfragen MTRs immer als Datei (z.B. TXT oder HTML) an die jeweilige Anfrage bzw. Antwort an, um die Lesbarkeit zu erhalten.

Wollen Sie die MTR Ausgabe in Foren (z.B. im Hetzner-Forum) posten, dann denken Sie bitte daran, den Text dort so zu gestalten, dass man die Ausgabe der Diagnoseapplikation auch verstehen kann, indem Sie die Ausgabe z.B. in [CODE]-Blöcke einschließen. So werden die Informationen in den jeweiligen Spalten viel besser lesbar sein.

Eine ungünstige Formatierung wäre:

1.|-- your_client.example.com 0.0% 1000 0.2 0.1 0.1 11.0 0.9
2.|-- 15172.your-cloud.host 0.0% 1000 0.2 0.2 0.1 11.0 0.8
3.|-- spine2.cloud1.hel1.hetzne 0.0% 1000 13.4 18.0 1.6 328.3 19.7
4.|-- spine15.cloud1.hel1.hetzn 0.0% 1000 0.8 1.3 0.7 50.0 3.1
5.|-- spine3.cloud1.hel1.hetzn 55.1% 1000 0.5 2.9 0.3 51.2 6.6
6.|-- 16659.your-cloud.host 54.9% 1000 0.6 1.4 0.4 56.6 4.2
7.|-- your_host.example.com 59.2% 1000 0.5 0.4 0.3 11.0 0.9

Hingegen, korrekt formatiert:

1.|-- your_client.example.com    0.0%  1000    0.2   0.1   0.1  11.0   0.9
2.|-- 15172.your-cloud.host      0.0%  1000    0.2   0.2   0.1  11.0   0.8
3.|-- spine2.cloud1.hel1.hetzne  0.0%  1000   13.4  18.0   1.6 328.3  19.7
4.|-- spine15.cloud1.hel1.hetzn  0.0%  1000    0.8   1.3   0.7  50.0   3.1
5.|-- spine3.cloud1.hel1.hetzne 55.1%  1000    0.5   2.9   0.3  51.2   6.6
6.|-- 16659.your-cloud.host     54.9%  1000    0.6   1.4   0.4  56.6   4.2
7.|-- your_host.example.com     59.2%  1000    0.5   0.4   0.3  11.0   0.9

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).

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:

Vom Client zum 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    *         core32.hel1.hetzner.com              (213.239.224.26)
10    393 ms    *         392 ms    spine16.cloud1.hel1.hetzner.com      (213.239.228.14)
11    393 ms    392 ms    *         (...)

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

Vom Server zum Client:

1     213.239.xx.xx                         (213.239.xx.xx)     0.233 ms     0.205 ms     0.281 ms
2     core31.hel1.hetzner.com               (213.239.228.1)     0.653 ms     0.660 ms     0.650 ms
3     juniper4.dc1.hel1.hetzner.com         (213.239.224.25)    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.

Sonstiges

Wir bitten Sie, keine Flood-Pings zur Fehlerdiagnose zu verwenden. Dies wird in vielen Netzwerken (nicht nur bei Hetzner) als Angriff gewertet und der verursachende Server kann recht schnell vom Netz genommen werden!

Table of Contents