IPv6-Netzwerk-Probleme

Von wo aus bzw. wie testest Du das? Nicht zufällig Uptime-Robot?

Lass mal am Server einen mtr zu einem externen Ziel (IPv4 & IPv6!) laufen, z.B. mit screen. Gibt es dann ebenfalls Auffälligkeiten?

Zitat von Jupp74

Hallo zusammen,

ich bin bei der Osteraktion bei den ARM-Servern fündig geworden und habe mir 2 VPS 1000 ARM G11 SE NUE OST24 geangelt.

Jetzt habe ich das Problem, dass bei beiden Servern mein Monitoring anspringt. In unregelmäßigen Abständen kriege ich die Fehlermeldung, dass 100% der Ping-PAkete über IPv6 verloren gehen. Meistens sind die Server nach ein oder zwei Minuten wieder erreichbar, aber manchmal dauern die Ausfällle auch länger...

Bei meinem VPS Karneval von 2020 habe ich diese Probleme nicht. Und auch mit den RS aus der Osteraktion 2022 hatte ich keine derartigen Probleme.

Hat jemand die gleichen Erfahrungen gemacht? Liegt es vielleicht an den ARM-Servern?

Grüße,

Steffen

Alles anzeigen

Ich habe die gleichen Erfahrungen gemacht. Allerdings ist mein Monitoring wohl nicht so engmaschig wie deins und merkt in der Regel die relatv kurzen Aussetzer nicht. Es betrifft ebenfalls (m)einen ARM-Server. Ich habe es bemerkt, weil mit putty immer die Verbindung verloren geht, meist nach ca 15 Minuten, kann aber auch mal etwas länger halten. Außerdem merke ich es auch gelegentlich bein ersten Aufruf einer auf dem Server liegenden Website nach längerer Zeit. Einmal konnte ich es sogar direkt von meinem PC beobachten, dass beim Ping mit IPv6 die Pakete verloren gingen, während es beim Ping mit IPv4 kein Problem gab. Da meine eigene Verbindung gelegentlich (selten) auch etwas wackelig ist, hatte ich auch immer einige Verbindungen per IPv6 mit putty zu anderen Servern offen (netcup, Strota), um dies als Ursache auszuschliessen. Die waren absolut stabil, den ganzen Tag über kein Verbindungsverlust.

Am Samstag Abend kam dann eine Mail von netcup wegen eines Ausfalls am node des vServers. Da hatte ich die Hoffnung, dass nach Behebung des Problems vielleicht auch das IPv6 Problem behoben wäre, bzw das Problem mit dem Node eben diese Verbindung war. Denn während die Mail eintraf, habe ich noch auf den Server zugegriffen ohne Probleme, der Node hatte also keinen Totalausfall. Als nach einer halben Stunde das von netcup gemeldete Problem behoben war, habe ich testhalber gleich eine Verbindung mit putty aufgebaut, die hielt dann mehrere Stunden, bevor sie dann doch wieder verloren ging. Jetzt bin ich auch wieder eher bei den 15 Minuten. Verbindungen per IPv4 zum ARM-Server und per IPv6 zu anderen Servern, auch bei netcup, weiterhin absolut stabil.

Ich hätte ja schon ein Ticket aufgemacht, habe aber (noch) keine nachprüfbaren/reproduzierbaren Messungen, die das Problem zeigen. Habe screen und mtr bisher nicht benutzt, ist aber vielleicht eine gute Gelegenheit dazu.

Bei deinen oben geposteten mtr's sehe ich kein Problem?

Das Ziel (letzte Zeile) ist bei allen 4 Messungen mit 0% loss.

Hast du mal auch die Gegenrichttung gemessen ? Oben ist nur

netcup arm --> extern

Was ist mit:

extern --> netcup arm ?

Da mtrs mit verbindungslosen Daten arbeiten, würde ein Problem auch in eingehender Richtung sofort auffallen. Die Traces oben sind sauber, da gibt es kein Problem. Allerdings sind 100 Pakete auch nicht viel.

Did anyone experience downtime in last 20 minute?

I am of impression of heavy- DDOS

Zitat von frank_m

Da mtrs mit verbindungslosen Daten arbeiten, würde ein Problem auch in eingehender Richtung sofort auffallen. Die Traces oben sind sauber, da gibt es kein Problem. Allerdings sind 100 Pakete auch nicht viel.

Ah, ok, danke!

Die Gegenrichtung nimmt aber ein anderes Routing, als netcup --> google.

Ggf. liegt das Problem ja woanders und nicht auf netcup Seite.
Ich hatte mal bei bestimmten Routings einen (defekten/falsch konfigurierten) Router auf dem Weg, der nur MTU Pakete< x Byte weiterleitete. Nach einer Woche war der Spuck dann vorbei...

Das ist die Standardantwort bei Netzwerkproblemen ...

Passt immer. Ich übersetze mir das so: Wir wollen einen Fehler in ihrer Systemkonfiguration ausschliessen, bevor wir Aufwand in die Suche stecken. Also tun wir das erst, wenn das Problem in einer genau definierten Konfiguration reproduzierbar ist.

Edit: Was ja auch durchaus Sinn macht.