vServer hat immer wieder Konnektivitätsprobleme und Erfahrungen mit Support

    Hallo in die Runde,


    ich bin mit mehreren Servern Kunde bei Netcup und auch ein Verein den ich betreue hat einen Teil seiner Server bei Netcup und genau bei einem Server habe ich nun seit mehreren Wochen das Problem dass der Server immer wieder nicht erreichbar ist. Das äußert sich dann darin das die Anwender keine E-Mails versenden können (Thunderbird meldet dass es den SMTP Server nicht erreichen kann) sowie der Nextcloud Client offline ist. Am Anfang habe ich natürlich gedacht "okay temporäre Routingprobleme an meinem DSL Anschluss". Aber nach und nach habe ich immer wieder Meldungen von Anwendern bekommen dass sie ebenfalls keinen Zugriff haben. Also habe ich ich mich an den Support gewendet und mein Problem geschildert. Ich wurde gebeten das ganze im Recovery-System mithilfe von Pings nachzuweisen. Daraufhin habe ich den Server (ich nennen ihn ab jetzt A) ins Recovery gebootet und ihn von extern (Server B, ebenfalls bei Netcup gehört dem selben Kundenaccount) angepingt und das Logfile davon gesichert. Auch habe ich von A aus verschiedene andere Ziele angepingt z.b. 8.8.8.8 und 1.1.1.1. Dabei ist mir aufgefallen dass der der Server A teilweise 1.1.1.1 nicht anpingen kann aber in der Zeit ohne Probleme 8.8.8.8 erreicht. Die Infos und entsprechenden Logs habe ich dem Support zur Verfügung gestellt.


    Einen Tag später habe ich dann die Antwort vom Support bekommen dass sie den Server selber ins Recovery booten müssen um den Fehler nachvollziehen zu können. Dem habe ich zugestimmt mit der Ansage dass der Server bitte nicht tagsüber ins Recovery gehen soll sondern Abends. Nun gut "Abends" wurde vom Support als 17:00 Uhr gedeutet und die Kiste war mal 5-10 Minuten im Recovery.

    Ich habe daraufhin die Antwort bekommen "Problem tritt im Recovery nicht auf, liegt also am Kundensystem". Das ich vorher Logfiles angefertig habe die das genaue Gegenteil beweisen war egal. Daraufhin habe ich dem Support nochmals geschrieben und erklärt dass der Fehler ja auch nicht "ständig" auftritt. Es kann auch mal 1-3 Stunden dauern bis der Server dann für ein zwei Minuten seinen Schluckauf hat.


    Ich wurde gebeten das ganze nochmals gebeten das ganze per Pings im Rescue-System zu dokumentieren --> habe ich getan und zwar über eine ganze Nacht. Server A hat B angepingt sowie diverse andere Server. Und hat in der Nacht zu mehreren Servern wiederholt Verbindungsprobleme. Server B hat ebenfalls die selben Server wie A angepingt und konnte die anderen Server die ganze Zeit ohne Probleme erreichen nur A war immer wieder nicht erreichbar.


    Dieses Log habe ich dann wieder an den Support geschickt mit der bitte um weitere Prüfung. Daraufhin habe ich nur die Antwort zurück bekommen dass sie mit den Pings ja nichts anfangen können ich müsse schon "mtr" nutzen. Da frage ich mich: Wieso wird nicht direkt genau mitgeteilt welche Art von Log gebraucht wird.


    Aber gut ich habe meinen Ärger über die schlechte Kommunikation runter geschluckt und habe den Server wieder eine Nacht im Recovery verbringen lassen mit den jeweiligen gegenseitigen Pings mit mtr.

    Auch das Log habe ich zur Verfügung gestellt nur um dann die Meldung zu bekommen dass sie das System ins Recovery schalten müssen um den Fehler zu untersuchen, (zu dem Zeitpunkt ist ja nun eindeutig klar dass es nicht an meiner Installation liegt, da der Fehler nun mehrfach im Recovery auf Logfile protokolliert wurde.)

    Deswegen habe ich mir auch erlaubt in der Antwort an den Support zu fragen ob es nicht auch im normalen System geht und meine Handynummer hinterlassen um das ganze kurz telefonisch klären zu können, leider rief niemand an. Stattdessen habe ich die Antwort bekommen wenn sie das System nicht ins Recovery booten können dann können sie mir nicht helfen. Zähneknirschend habe ich also zugestimmt dass der Server zu normaler Tageszeit ins Recovery gebootet werden darf. Daraufhin ist mehrere Tage nichts passiert und nach meinem heutigen Anruf meldete sich der Techniker per Mail dass sie keine Störungen feststellen können (und der Server wurde nicht ins Recovery gebootet). Ich sehe aber weiterhin die Aussetzer (mittlerweile läuft auf B ein dauerhaftes mtr in Richtung A und ich bekomme auch immer wieder Nachts eine E-Mail das das Backup nicht erstellt werden konnte weil Server C nicht erreicht werden kann. ("remote: ssh: Could not resolve hostname Server_C.tld: Temporary failure in name resolution").

    Auf den Backupserver backupen jede Nacht noch mehrere weitere Server ohne Probleme.



    Ich habe hier nun mehrere Fragen an euch:
    - Gibt es jemanden der die selben Verbindungsprobleme hatte und der weiß wie es gelöst wurde?

    - Gibt es eine Möglichkeit mit dem Support auf direkteren Weg zu kommunizieren? Ich schließe nicht aus dass hier einfach nur ein Kommunikationsfehler vorliegt den man durch ein kurzes Telefonat ausräumen kann.


    Ich bin auf eure Meinungen und Erfahrungen gespannt.


    netcup versteht mich nicht falsch, ich bin seit vielen Jahren treuer Kunde von euch und habe auch mehreren Leuten empfohlen bei euch Produkte zu holen, gefühlt hat aber der Support über die Jahre sich massiv verschlechtert.


    Grüße White

    Quote from White

    "Could not resolve hostname Server_C.tld: Temporary failure in name resolution"

    Ich hatte auch schon Server, auf denen das öfter der Fall war.

    Netcups Name-Resolver haben wohl leider öfter mal einen Schluckauf.

    Nachdem ich dann (etwas unsauber, als Workaround) in der resolv.conf einfach den nameserver von 127.0.0.x auf 8.8.8.8 umgestellt hatte, lief dann alles problemlos.

    Später habe ich dann den sauberen Weg genommen und systemd-resolve durch unbound ersetzt. Läuft seitdem dauerhaft rund.

    Quote from aRaphael

    Ich hatte auch schon Server, auf denen das öfter der Fall war.

    Netcups Name-Resolver haben wohl leider öfter mal einen Schluckauf.

    Nachdem ich dann (etwas unsauber, als Workaround) in der resolv.conf einfach den nameserver von 127.0.0.x auf 8.8.8.8 umgestellt hatte, lief dann alles problemlos.

    Später habe ich dann den sauberen Weg genommen und systemd-resolve durch unbound ersetzt. Läuft seitdem dauerhaft rund.

    Kann ich nur bestätigen. Sowohl, dass nicht alle Server gleichermaßen betroffen sind und auch nicht immer, als auch, dass die Änderung der Resolver meine Probleme dauerhaft behoben hat. Lässt sich also wie es aussieht problemlos beheben - nur eben nicht mit den netcup-Resolvern. Mittlerweile habe ich auch alle Server bis auf einen auf Unbound umgestellt. Der letzte verbleibende Server nutzt aber auch keine netcup-Resolver mehr. Kann man also bei Bedarf auch weiterhin mit systemd-resolved betreiben und auf saubere Weise auf andere Resolver umstellen.

    Quote from tab

    dass die Änderung der Resolver meine Probleme dauerhaft behoben hat.

    Das löst aber doch nicht sein Problem der von-außen-nicht-Erreichbarkeit seines A-Servers.


    Ich würde den Server auf einen anderen Host migrieren lassen.

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Nach der Beschreibung bin ich auch skeptisch, dass es DNS Probleme sind. Warum treten die auf bei einem Ping auf eine IP Adresse?


    Wo treten die mtr Verluste auf? Das ist die entscheidende Frage. Wenn es innerhalb des Netcup Netzes ist, dann müssen sie tätig werden. Das kann man aber nur am Trace sehen. Wenn du von uns Hilfe willst, soll du die Traces posten.

    Hier die mtr logs.

    Dabei war Server A im Rescue System.

    Server B zu A (A im REscue System): https://pastebin.com/P0RVsa33


    und hier Server A zu Server B (A läuft im Rescue System): https://pastebin.com/J8fNKhXk


    Das die eingetragenen Nameserver Probleme machen könnte ja doch maximal bei den Pings von A zu B sein (ich pinge ja hostnames, keine Ip-Adressen) aber wenn B zu A pingt sollte es ja egal sein ob A eine funktionierende Namensauflösung hat oder?

    https://pastebin.com/P0RVsa33

    Ja, bei einem ping auf eine IP sollte das meines Erachtens nicht die Ursache sein, bei einem traceroute dagegen eventuell schon (reverse DNS Abfragen). Auch bei Mail dürfte der Server den PTR der Gegenseite abfragen. Wie sich hierbei eine Störung der Resolver letztlich auswirken würde weiss ich aber nicht. Aber das Problem beim Backup wurde wohl in jedem Fall dadurch verursacht. Schon allein deshalb würde ich die Resolver ändern, auch wenn das hier wahrscheinlich nicht alle Probleme lösen wird.

    Quote from White

    Das die eingetragenen Nameserver Probleme machen könnte ja doch maximal bei den Pings von A zu B sein (ich pinge ja hostnames, keine Ip-Adressen) aber wenn B zu A pingt sollte es ja egal sein ob A eine funktionierende Namensauflösung hat oder?

    https://pastebin.com/P0RVsa33

    Doch, damit sind DNS Probleme plötzlich wieder ganz oben auf der Liste. Wer kann auch ahnen, dass du solche Tests mit Hostnamen machst? Es ist zwar egal, ob A eine funktionierende DNS Konfiguration hat, aber die Auflösung von B kann auch scheitern.

    Es sind Netzwerkprobleme, das mit dem DNS war Quatsch, sorry. Die Pakete von B->A gehen erst auf dem letzten Hop verloren.


    Damit ist es ein Netzwerkproblem, und zwar in unmittelbarer Nähe von Server A, möglicherweise sogar auf dem Host von A.

    Ich habe jetzt mal die Nameserver geändert, mal sehen was es bringt. Das der Server aber 1.1.1.1 nicht erreichen kann (per ping -O 1.1.1.1 geprüft) spricht ja dagegen dass es allein daran liegt. Stabile Namensauflösung ist ja trotzdem nicht verkehrt ;)


    Ja sry dass ich auf die Hostnames pinge hätte ich erwähnen sollen. Dem Support ist es aber bekannt, die haben zuerst Konsolenausgaben geschickt bekommen inklusive Befehl und später auch das Script was per Ping prüft ob der Host da ist und das ganze in eine Datei loggt.

    Einerseits würde ich ausschließlich mit MTR testen, aber das wurde eh schon erwähnt. Und dann eventuell mit anderen Zielen, nicht dass Du bei den genannten DNS-Servern mit Deinen Pings in einem Rate Limit landest. ;)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Ich meinte natürlich mtr, ich habe keine Scripte mehr laufen die pings machen.


    Ich stelle mal den zweiten Server bei Netcup ebenfalls mal weg von den nameservern von Netcup und dann schaue ich mal was die Nacht bringt. Glaube aber nicht dran. Da ich die selben Aussetzer auch von einer Debian Kiste bei mir zu hause sowie von nem Arch Linux Laptop sehe.

    Quote from White

    und hier Server A zu Server B (A läuft im Rescue System): https://pastebin.com/J8fNKhXk

    Meiner Meinung nach ist das MTR bereits aussagekräftig genug, die Pakete gehen unregelmäßig bereits am ersten Netcup Gateway (gw02) flöten (>66% über 500 Pakete ist schon krass ...).

    Hier muss netcup dann eigentlich so langsam mal tätig werden.

    Vielleicht noch mal etwas deutlicher im Ticket hervorheben, dass auch aus dem Rescue heraus getestet schon am ersten Gateway Pakete in unregelmäßigen Abständen verloren gehen und dieses MTR dann entsprechend anhängen. Vielleicht auch eine Ticket-Eskalation nach weiter oben versuchen ...