Internetverbindung hängt ca. alle 30 Minuten

  • Hallo zusammen,


    ich habe ein Problem mit meinem vServer (Generation 6). Da ich den Fehler bisher nicht im Rettungssystem reproduzieren kann, kann der Support mir nicht weiterhelfen. Schade drum.


    Der Server ist ca. alle 30-45 Minuten (unregelmäßig) für einige Sekunden ab und an auch mal für ein paar Minuten aus dem Internet nicht erreichbar. Danach ist alles wie vorher.
    Intern ist er von anderen vServern aber problemfrei erreichbar. Der Server kann in diesem Zeitraum auch über die VNC-Konsole administriert werden, jedoch keine Verbindung nach außen aufbauen.


    Ich habe mir die Datei /var/log/messages schon angesehen. Hier ist nur eine regelmäßige FTP-Aktivität protokolliert, keinerlei Fehler. dmesg gibt ca. 5 Meldungen pro Tag über UDP-Paketen mit falscher Checksumme aus.


    Ich nutze eine Failover und die normale IP. Beide sind extern nicht erreichbar aber intern erreichbar.
    Meine Netzwerkconfig (funktioniert seit einem halben Jahr ohne Probleme):

    Code
    # This file describes the network interfaces available on your system# and how to activate them. For more information, see interfaces(5).source /etc/network/interfaces.d/*# The loopback network interfaceauto loiface lo inet loopback# The primary network interfaceauto eth0iface eth0 inet static	address 188.68.49.2XX	netmask 255.255.252.0	broadcast 188.68.51.255	gateway  188.68.48.1# 2nd network interfaceauto eth0:1iface eth0:1 inet static	address 46.38.230.XXX	netmask 255.255.255.255up ip route change default via 188.68.48.1 src 46.38.230.XXX


    Ich habe in den letzten Wochen updates eingespielt, ansonsten keinerlei Veränderungen vorgenommen. Probleme treten seit ca. 4-5 Tagen auf.
    Ca. 1 Woche vor Auftreten habe ich mich gar nicht eingeloggt, weil ich viel arbeiten war. Deswegen kommt mir das alles sehr komisch vor.


    Hat jemand von euch Ideen woran das liegen könnte?


    Vielen Dank schonmal!


  • "Internetverbindung hängt ca. alle 30 Minuten" ist in diesem Zusammenhang leider nur wenig hilfreich.


    Als erstes solltest du bei einem Ausfall ein mtr machen: MTR › Wiki › ubuntuusers.de
    Damit kannst du/wir dann sehen an welcher Stelle die Verbindung unterbrochen ist. Denn neben deinem Server und deinem PC kann auch jeder Server dazwischen die Störung verursachen.

  • "Internetverbindung hängt ca. alle 30 Minuten" ist in diesem Zusammenhang leider nur wenig hilfreich.

    Entschuldigung. Konstruktive Kritik wäre nett und einfach was besseres vorschlagen, dann passe ich das gerne an.

    Als erstes solltest du bei einem Ausfall ein mtr machen: MTR › Wiki › ubuntuusers.de


    Damit kannst du/wir dann sehen an welcher Stelle die Verbindung unterbrochen ist. Denn neben deinem Server und deinem PC kann auch jeder Server dazwischen die Störung verursachen.

    Danke für den Hinweis.
    Mtr laufen lassen auf Google. Als erstes kommt gw02.netcup.net (IP beginnt mit 188). Hier tritt auch der Paketloss auf, wenn es zum Ausfall kommt.
    Bei MTR von außen auf den Server ist der letzte Host vor dem Server gw01.netcup.net (IP beginnt mit 46). Hier kommt es ebenfalls zum Ausfall.
    Bei MTR von Netcup-Server mit anderer IP-Range ist der letzte Host vor dem Server gw01.netcup.net (IP beginnt mit 37). Hier kommt es auch zum Ausfall.
    Bei MTR von Netcup-Server mit gleicher IP-Range ist der letzte Host vor dem Server gw02.netcup.net (IP beignnt mit 188). Hier kommt es nie zu einem Paketloss.


    Wenn ich ein service networking restart durchführe ist der Server umgehend danach wieder verfügbar.
    Ich bekomme irgendwie das Gefühl es liegt an der FailOver...

  • wir haben die failover ip jetzt mal aus der config entfernt und nur die standard-ip am laufen. der server scheint jetzt durchgehend zu laufen. der fehler tritt also nur im zusammenhang mit der failover ip auf. ist diese vielleicht falsch eingerichtet?


    nur zur info, ich bin der kumpel von dessen servern wir die mtr/ping etc. laufen lassen.

  • Das dürfte zwar nichts ausmachen, aber ich würde es einmal so einrichten, dass es dem aktuellen Stand entspricht, wie es bei Debian (?) üblich ist. Aliase sind nämlich z.B. veraltet.



    Und optional halt auch noch Deine gewünschte Defaultroute:


    Code
    up ip route change default via 37.120.176.1 src 46.38.230.xxx
            down ip route change default via 37.120.176.1


    Diesen letzten Teil würde ich zum Test vorerst aber auch einmal weglassen.


    Denn neben deinem Server und deinem PC kann auch jeder Server dazwischen die Störung verursachen.


    Ja, nur heißen die Dinger dazwischen nicht Server… :D:)



    MfG Christian

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

  • Also!


    Entferne ich aus meiner obigen Config die letzte Zeile:

    Code
    up ip route change default via 188.68.48.1 src 46.38.230.XXX


    Treten keine Probleme mehr auf. Das Problem ist, dass ich nach außen zwingend die Failover-Ip haben muss (Teamspeak läuft sonst nicht,
    und die Mails landen auch bei allen im Spam-Ordner, weil die IP-Adressen nicht übereinstimmen).


    Code
    up ip route change default via 37.120.176.1 src 46.38.230.xxx        down ip route change default via 37.120.176.1


    Führt bei mir zum Totalausfall des Netzwerkes. Habe ich damals beim ersten Einrichten glaube ich auch schonmal versucht...
    Oder ist da einfach nur irgendwo ein kleiner Fehler?
    (Natürlich habe ich die IPs ersetzt ;-))


  • Interessant wäre noch, was dabei angezeigt wird, auch einmal währenddessen das Problem auftritt:


    Code
    ip -4 rule
    ip -4 route
    ip -4 neigh


    Ist der Gateway immer anpingbar?



    MfG Christian

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

  • Korrektur, nur die letzte Zeile deines Vorschlages killt alles:

    down ip route change default via 37.120.176.1

    Ich habe jetzt als versuch ein


    Code
    route add default gw 188.68.48.1


    vor dem Routing-Befehl eingefügt.


    Mal gucken was passiert...

  • Wenn Du die Gateway-IP aus meinem Beispiel nicht gegen die bei Dir notwendige austauschst ist klar, dass es alles killt… ;)



    MfG Christian

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

  • Hallo Knud,


    ich habe ein ähnliches Setup und ein paar Fragen wegen des Mailversandes der dann als Spam geflaggt wird.
    Ich habe dazu seinen neuen Beitrag aufgemacht: [URL=https://forum.netcup.de/administration-eines-server-vserver/vserver-server-kvm-server/8200-failover-ip-problem-beim-mailversand/)Failover-IP Problem beim Mailversand[/URL] weil ich den Thread hier nicht verwässern möchte.


    Ich schätze fast ich werde auch genauso eine Route brauchen wie du. Wenn dann aber meine Netzwerkverbindungen alle halbe Stunde wegkrachen wird das meine Firma nicht sonderlich glücklich machen...


    Thomas

  • also so langsam versteh ich das Problem von dem Server nicht mehr, als der Fehler akut war trat das Problem alle 30 min. ca auf (manchmal noch eher), dann war ca. 4-5 min Ausfall.


    nach dem hinzufügen der Zeile die Knud etwas weiter oben erwähnt hat lief der Server seit 19:50 ca. ohne Probleme, bis er vor ca. 20 Minuten angefangen hat sporadisch für ca. 1 Sekunde die Verbindung zu verlieren. Von außen ist der dann wieder nicht erreichbar, von netcup intern schon..

  • er hat sie ausgetauscht


    Ich habe mich nur gewundert, weil er es im gleichen Beitrag einmal so und anders schreibt. Von daher der Hinweis. Egal… :)


    Von außen ist der dann wieder nicht erreichbar, von netcup intern schon.


    Heißt netcup intern aus dem gleichen Subnetz? Oder liegen die beiden Server in unterschiedlichen Netzen? Die Ausgabe davon wäre übrigens weiterhin interessant: Beitrag #8


    So oder so würde ich das dem Support nochmals mit Verweis auf diesen Thread so schildern. Das klingt nicht danach, als ob es in Deinem Einflussbereich liegt. Wieso es dann nur auftritt, wenn Du alles über die Failover-IP leitest, weiß ich momentan auch nicht. Ich würde trotzdem einmal versuchen alles im Rettungssystem nachzustellen, sind ja nur zwei zusätzliche manuell auszuführende Befehle für die Failover-IP. (ip addr add … & ip route change …)



    MfG Christian

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

  • netcup intern bedeutet in der Tat aus gleichem Subnetz. Wir bauen das heute nochmal im Rettungssystem nach und werden uns die Sachen ausgeben lassen, die du vorgeschlagen hast. Dann schauen wir weiter.


    Danke für deine Hilfe!

  • Ich habe das gleiche nun auch nachgestellt (dieser Thread) bislang aber noch absolut keine Erreichbarkeitsprobleme feststellen können (Monitoring mit Icinga und Munin), bin aber ja nicht dirchgehend mit dem Server verbunden.


    Wenn ihr irgendwelche Tests mit meinem Server durchführen wollt -> PM


    Thomas

    Aus welchem Bereich stammt deine Failover? Auch 46.38.230.XXX ?
    Wäre weiterhin interessant ob du das gleiche Gateway nutzt.


    Wir nutzen zum Monitoring mtr. Test führen wir keine durch, da wir leider noch keine Idee haben wodurch sich das Problem provozieren lässt.

  • Hier mein 'ip route show' des Live-Systems welches die Failover-IP gerade hat.

    Code
    default via 188.68.56.1 dev ens3  src 46.38.230.xxx  
    188.68.56.0/22 dev ens3  proto kernel  scope link  src 188.68.59.xx

    Ist bei mir exakt gleich. Aber in der letzten halben Stunde gab es auch keine Ausfälle. Sehr unregelmäßig das ganze. Ich melde mich wenn es zum nächsten Ausfall gekommen ist, dann kannst du ja vielleicht mal überprüfen ob es diesen Ausfall bei dir auch gab.


  • Von der Theorie her könnte ich mir vorstellen, dass die Konfiguration bis auf die letzte Zeile (up ip route change default ...) richtig ist und auch dauerhaft ohne Probleme funktionieren sollte.


    Begründung:
    In der Letzten Anweisung (up ip route change default ...) wird dem System mitgeteilt, dass es die eigentlich schon vorhandene Gateway IP-Adresse 46.38.230.XXX, da es sich hier um eine Punkt- zu Punkt-Verbindung handelt, durch die Gateway IP-Adresse 188.68.48.1 ersetzt werden soll. Dies könnte von daher auch das eigentliche Problem sein.

    Einmal editiert, zuletzt von Exmember01 ()