Falls du Netzwerkprobleme mit deinem Server hast, dann schick bitte eine authentifizierte Anfrage aus dem Robot an unsere Techniker. Bitte wähle dabei den betroffenen Server aus. Du kannst zwischen zwei verschiedenen Anfragetypen auswählen, je nachdem, welches Problem du hast.
Server ist nicht erreichbar
Falls dein Server nicht erreichbar ist, kannst du ihn selbst neu starten. Die Option findest du im Robot unter dem Reiter "Reset", nachdem du den betreffenden Server angeklickt hast. Es kann sein, dass der Server von unserer Seite aus gesperrt wurde, dann hilft der Reset nicht. In dem Fall wirf bitte einen Blick auf den Leitfaden bei Serversperrung.
Falls du weiterhin Probleme hast, dann schick uns bitte eine Anfrage aus dem Robot. Geh zum "Support" oben rechts. Wähle "Server" als Produkttyp, dann den richtigen Server und anschließend "Netzwerk" als Thema des Supportproblems. Wähle dann "Server ist nicht erreichbar".
Paketverluste
Falls Paketverluste auftreten sollten, benötigst du 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 kannst du Programme wie MTR oder WinMTR benutzen.
Das Programm MTR kann mithilfe eines Paketmanagers unter Linux oder MacOS installiert werden. Für Windows kannst du das Programm von einer bestimmten Website herunterladen.
Hier ist eine Übersicht, wie du das Programm unter bestimmten Betriebssystemen einrichten kannst.
| 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 deines lokalen Endpunktes kannst du ü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ühre dazu den genannten Befehl auf beiden Systemen aus und setze 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 dein MTR den letzten Hop als nicht erreichbar anzeigt, ist vermutlich das installierte System oder dein 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. Dein 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 beachte bei der Auswertung und Übermittlung folgende drei Arten von Paketverlust:
1. Paketverlust, welcher bis zum Ziel-Hop verschwindet
-
Wie du in diesem Beispiel sehen kannst, 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.|-- dmbkt.your-cloud.host 0.0% 1000 0.2 0.2 0.1 11.0 0.8 3.|-- leaf1.cloud2.fsn1.hetzner 0.0% 1000 13.4 18.0 1.6 328.3 19.7 4.|-- spine1.cloud2.fsn1.hetzne 4.2% 1000 0.8 1.3 0.7 50.0 3.1 5.|-- core21.fsn1.hetzner.com 31.7% 1000 0.5 2.9 0.3 51.2 6.6 6.|-- core21.fsn1.hetzner.com 0.0% 1000 0.6 1.4 0.4 56.6 4.2 7.|-- ex9k2.dc1.fsn1.hetzner.co 0.0% 1000 0.6 1.8 0.4 214.1 12.0 8.|-- 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 deinem 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.|-- dmbkt.your-cloud.host 0.0% 1000 0.2 0.2 0.1 11.0 0.8 3.|-- leaf1.cloud2.fsn1.hetzner 0.0% 1000 13.4 18.0 1.6 328.3 19.7 4.|-- spine1.cloud2.fsn1.hetzne 0.0% 1000 0.8 1.3 0.7 50.0 3.1 5.|-- core21.fsn1.hetzner.com 0.0% 1000 0.5 2.9 0.3 51.2 6.6 6.|-- core21.fsn1.hetzner.com 0.0% 1000 0.6 1.4 0.4 56.6 4.2 7.|-- ex9k2.dc1.fsn1.hetzner.co 0.0% 1000 0.6 1.8 0.4 214.1 12.0 8.|-- 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üfe daher in einem solchen Fall zuerst dein installiertes System. Wenn du keines der genannten Probleme auf deinem System feststellen kannst, lass 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.|-- dmbkt.your-cloud.host 0.0% 1000 0.2 0.2 0.1 11.0 0.8 3.|-- leaf1.cloud2.fsn1.hetzner 0.0% 1000 13.4 18.0 1.6 328.3 19.7 4.|-- spine1.cloud2.fsn1.hetzne 0.0% 1000 0.8 1.3 0.7 50.0 3.1 5.|-- core21.fsn1.hetzner.com 55.1% 551 0.5 2.9 0.3 51.2 6.6 6.|-- core21.fsn1.hetzner.com 54.9% 549 0.6 1.4 0.4 56.6 4.2 7.|-- ex9k2.dc1.fsn1.hetzner.co 59.2% 592 0.6 1.8 0.4 214.1 12.0 8.|-- your_host.example.com 59.2% 592 0.5 0.4 0.3 11.0 0.9 -
Bitte sende 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), wendest du dich bitte sowohl an den betreffenden Netzbetreiber, als auch an uns.
Falls du mit dem MTR Programm Paketverluste feststellst, schick uns bitte eine Anfrage aus dem Robot. Klicke dazu links auf "Server", wähle den betreffenden Server, aktiviere den Reiter "Support" und wähle "Packet Loss". Bitte sende die Ausgabe der MTRs als Anhang deiner Anfrage.
Formatierung eines MTR
Bitte häng bei Support-Anfragen MTRs immer als Datei (z.B. TXT oder HTML) an die jeweilige Anfrage bzw. Antwort an, um die Lesbarkeit zu erhalten.
Wolltest du die MTR Ausgabe in Foren (z.B. im Hetzner-Forum) posten, dann denk bitte daran, den Text dort so zu gestalten, dass man die Ausgabe der Diagnoseapplikation auch verstehen kann, indem du die Ausgabe z.B. in [CODE]-Blöcke einschließt. 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.|-- dmbkt.your-cloud.host 0.0% 1000 0.2 0.2 0.1 11.0 0.8
3.|-- leaf1.cloud2.fsn1.hetzner 0.0% 1000 13.4 18.0 1.6 328.3 19.7
4.|-- spine1.cloud2.fsn1.hetzne 0.0% 1000 0.8 1.3 0.7 50.0 3.1
5.|-- core21.fsn1.hetzner.com 55.1% 1000 0.5 2.9 0.3 51.2 6.6
6.|-- core21.fsn1.hetzner.com 54.9% 1000 0.6 1.4 0.4 56.6 4.2
7.|-- ex9k2.dc1.fsn1.hetzner.co 59.2% 1000 0.6 1.8 0.4 214.1 12.0
8.|-- your_host.example.com 59.2% 1000 0.5 0.4 0.3 11.0 0.9Hingegen, korrekt formatiert:
1.|-- your_client.example.com 0.0% 1000 0.2 0.1 0.1 11.0 0.9
2.|-- dmbkt.your-cloud.host 0.0% 1000 0.2 0.2 0.1 11.0 0.8
3.|-- leaf1.cloud2.fsn1.hetzner 0.0% 1000 13.4 18.0 1.6 328.3 19.7
4.|-- spine1.cloud2.fsn1.hetzne 0.0% 1000 0.8 1.3 0.7 50.0 3.1
5.|-- core21.fsn1.hetzner.com 55.1% 1000 0.5 2.9 0.3 51.2 6.6
6.|-- core21.fsn1.hetzner.com 54.9% 1000 0.6 1.4 0.4 56.6 4.2
7.|-- ex9k2.dc1.fsn1.hetzner.co 59.2% 1000 0.6 1.8 0.4 214.1 12.0
8.|-- your_host.example.com 59.2% 1000 0.5 0.4 0.3 11.0 0.9Asymmetrisches 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 * 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:
Vom Server zum 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.
Sonstiges
Wir bitten dich, 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!