Einführung
Falls Sie Netzwerkprobleme mit Ihrem Server haben, dann schicken Sie bitte eine authentifizierte Anfrage aus dem Robot an unsere Techniker. Bitte wählen Sie dabei den betroffenen Server aus. Sie können zwischen zwei verschiedenen Anfragetypen auswählen, je nachdem, welches Problem Sie haben.
Server ist nicht erreichbar
Falls Ihr Server nicht erreichbar ist, können Sie ihn selbst neu starten. Die Option finden Sie im Robot unter dem Reiter "Reset", nachdem Sie den betreffenden Server angeklickt haben. Es kann sein, dass der Server von unserer Seite aus gesperrt wurde, dann hilft der Reset nicht. 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 aus dem Robot. Gehen Sie zum "Support" oben rechts. Wählen Sie "Server" als Produkttyp, dann den richtigen Server und anschließend "Netzwerk" als Thema des Supportproblems. Wählen Sie dann "Server ist nicht erreichbar".
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.|-- 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 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.|-- 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ü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.|-- 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 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 mit dem MTR Programm Paketverluste feststellen, schicken Sie uns bitte eine Anfrage aus dem Robot. Klicken Sie dazu links auf "Server", wählen Sie den betreffenden Server, aktivieren Sie den Reiter "Support" und wählen Sie "Packet Loss". 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.|-- 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 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!