Root Server hat kein Netzwerkzugang

Hmm, vielleicht sind da doch noch so einige Kunden mit dem selben Problem vor dir in der Warteschlange. . Der Notfall-Support dürfte eher dünn besetzt sein, vielleicht sogar nur ein Mitarbeiter.

Notfallplan:

RS haben Zufriedenheitsgarantie. Die kann man, ohne Angabe von Gründen, bei voller Kostenerstattung, stornieren.

Sofort einen neuen ordern und, sobald der bereitgestellt ist und funktioniert, den jetzigen zurückgeben.

Nein. Für solche Fälle ist das ja durchaus auch gedacht.

Ich habe das auch schon ab und an genutzt.

Nur wenn man es zu häufig in Anspruch nimmt, kann man u.U. Probleme bekommen.

Zitat von aRaphael

Nur wenn man es zu häufig in Anspruch nimmt, kann man u.U. Probleme bekommen.

Wobei man in diesem speziellen Fall durchaus einen guten Grund darlegen kann: Mit einem vServer ohne Netzwerkanbindung kann man ja nicht zufrieden sein.

Insofern würde ich das bei einer eventuell Rückfrage in der Zukunft ziemlich locker sehen. Immerhin hat der TE alles probiert inkl. Notfallsupport. Mehr kann man wirklich nicht verlangen, da ist es durchaus nachvollziehbar, wenn man unzufrieden ist.

Dann ist die Frage nurnoch, ob der Rechnungsbug schon gefixt ist und er überhaupt nen neuen Server bestellen kann, bzw dieser bereitgestellt wird.

Ich würde mir womöglich mal das dmesg auf auffälligkeiten prüfen und im vcp testweise das netzwerkinterface umstellen.

Ich habe seit 11/2024 den ein oder anderen RS aus dem Netz 153.22.x.x gehabt (hier auch teils wieder abgekündigt/zurückgegeben).

Derzeit habe ich noch einen seit 01/2025.

Bei keinem (auch dem aktuellen) funktionierte DHCPv4 und ich musste grundsätzlich statisch konfigurieren.

Da dies damals auch der Zeitraum war, wo hier im Forum von vielen Netzwerkproblemen berichtet wurde, hatte ich das darauf geschoben.

Im Rescue-System (hat das überhaupt DHCPv4 beim Boot, erinnere mich gerade nicht) musste auch statisch konfiguriert werden.

Da ich aber grundsätzlich statisch konfiguriere, fiel das bei mir unter die Kategorie "egal".

Ich habe das so verstanden, dass du auch statisch getestet hast....wie sieht denn die Konfig aus (die habe ich hier im Thread nicht gesehen)?

Die Netzwerkkonfiguration in #6 und #8 sieht richtig aus. Wenn man neugierig ist, könnte man noch testen, ob irgendwelche anderen Adressen in der Broadcastdomain erreichbar sind. Die werden nicht geroutet und einige liegen sehr wahrscheinlich auf dem selben Host. Lösen wird man das Problem so aber nicht.

Zitat von tiekoetter

Für mich wirkt das so als ob in den Routern diese IPv4 Adresse beziehungsweise das IPv6 Subnet noch überhaupt nicht vergeben sind.

Klingt für mich einleuchtend, zumal die IPv4-Adresse davor mit 157 am Ende einwandfrei erreichbar ist, sowohl von meinem Server aus und auch von mir zuhause,

Hier mal jeweils ein mtr der beiden IPs von einem meiner Server (152.53.116.xxx) aus

~$ mtr -r -c 100 152.53.xxx.158
Start: 2025-04-13T13:15:15+0200
HOST: xxx.xxxx.de                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 152.53.116.2              98.0%   100  2003. 2003. 2003. 2004.   0.3
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

~$ mtr -r -c 100 152.53.xxx.157
Start: 2025-04-13T13:19:40+0200
HOST: xxx.xxxx.de                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 152.53.116.2               0.0%   100    0.9   2.7   0.4  46.2   6.5
  2.|-- v220250xxxxxxxxxxxxx.xxxx  0.0%   100    0.5   0.5   0.4   0.8   0.1

Die nächste IP (152.53.xxx.159) sieht genauso aus wie die 158, während die nachfolgenden wieder erreichbar sind (nur ping getestet). Da scheint man bei den zwei IPs irgendwas vergessen zu haben .

Edit: Oder die zwei Server sind einfach nur ausgeschaltet und es funktioniert mittlerweile.

Edit2: ping auf die IPv4 und IPv6 funktioniert mittlerweile wirklich. Da hat der Notfallsupport wohl das Problem mittlerweile gelöst.

Hmm. Sorry, da habe ich mich wohl selbst reingelegt. Ich sehe, ich bin über den Reverse-DNS Eintrag der IP gegangen und habe darauf gepingt. Der Reverse DNS löst aber auf ganz andere IPs auf. Die IPv4 direkt geht zumindest momentan bei mir auch nicht. Die 158 und 159 sind immer noch tot.

Zitat von tiekoetter

Angehangen habe ich mal den Auszug aus /etc/network/interfaces. Hab das nach dem testen wieder auskommentiert, nicht dass das noch schlimmere Fehler verursacht falls der Support was an der Netzwerk config probieren wollen würde.

Gibts da auch eine /etc/network/interfaces.d/50-cloud-init.cfg?

Ein Routingproblem aufs Subnetz können wir ausschließen, ich erreiche zahlreiche IPs aus dem Netz problemlos. Auch bei den fraglichen IPs komme ich bis zum letzten Hop davor.