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.
Also doch "mein" Problem? Dann ist ja gut dass der Notfallsupport nicht erreichbar war. Ist jetzt nur die Frage was ich falsch gemacht habe 🤔
Gibts da auch eine /etc/network/interfaces.d/50-cloud-init.cfg?
Mein Fehler dass ich da nicht reingeschaut habe.
Ja gibt es. Darin enthalten ist die korrekte statistische IPv4 und v6 konfiguration für eth0 (was in diesem Fall identisch zu ens3 ist) mit besagten IP Adressen. Bis auf das hier die netmask im cidr format angegeben wird ist es identisch zu dem was ich zum testen verwendet habe.
Alles anzeigenIch 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)?
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.
Also hier funktioniert immer noch überhaupt nichts. Es hat sich auch niemand vom Support gemeldet oder ähnliches.
Neuer Server auch nicht erreichbar!! IP auch wieder 152.53.x.x und 2a0a. Dieses mal habe ich überhaupt nichts angefasst.
So... nach 75 Minuten Warteschlange keinen ans Telefon bekommen.
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.
Gute Idee! Falls ich beim Notfall-Support niemanden mehr erreiche werde ich das wohl so machen. Ich nehme mal an das Konto wird dadurch aber nicht irgendwie eingeschränkt wenn man das in Anspruch nimmt, oder?
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.
Ja solange ich den bis zum 17.04. zum laufen bekomme ist alles noch ok. Hab halt für meine services ein 72 Stunden Fenster ab da freigehalten wo ich den Server umziehen wollte. Hätte aber gerne schon angefangen ein paar der Daten zu transferieren.
Erste halbe Stunde in der Warteschlange 😴
Wenn sich herausstellt, dass das Problem auf deiner Seite liegt: Ja, werden sie.
Da bin ich aber gespannt um was für einen Fehler es sich handeln soll, der ohne meinen Input, nach Neuinstallation und im Rescue Mode vorhanden ist (und scheinbar auch bei einem weiteren Kunden dessen Server im selben IP "Netz" ist). Also klar das Problem ist "auf" dem Server, also je nach Auslegung würde ich dann ja immer bezahlen.
Ich probiere es jetzt auch mal mit dem Notfall-Support. Da keine weiter Antwort vom regulären Support gekommen ist. Mal gucken ob die mir dann am Ende Geld abbuchen wollen falls ich durch komme 😅
Oh, hab gerade eine Antwort vom Support erhalten. Glaube den ist überhaupt nichts bekannt. Sollte ich da mal einfach den Beitrag hier verlinken?
Jup
Dann wäre jetzt spannend zu wissen ob alle Neubestellungen betroffen sind oder nur die die Adressen aus diesen Bereichen zugeteilt bekommen.
Komisch das sich noch keiner von Netcup zurückgemeldet hat.
Bin jetzt im Rescue System. Hab die Netzwerkeinstellungen mit dem Webpanel verglichen und die stimmen auch, inklusive der Default-Route. Erreiche über den Ping auch nicht den Default Gateway, mtr bleibt beim 1. HOP hängen. (Auf der richtigen Installation war das Verhalten gleich)
Die ersten beiden Oktetten sind identisch wie bei mir. Scheint als ob Netcup ein problem mit den 152.53.x.x Adressen hat. Wie ist denn dein IPv6 Prefix? Stimmt der ebenfalls überein?
Dann könnte das Problem doch dein Rechner sein. Wenn er bis zum zweiten Hop käme, dann wärst du raus, aber so nicht.
Ist aus der Perspektive des Servers, also über die VNC Konsole. Wenn ich dort Heise, Google oder die Netcup DNS Server oder sogar das eigene Gateway versuche zu erreichen meldet sich nur der eigene Host zurück. Ich kann Zuhause problemlos alles erreichen. Auch von meinen anderen Servern bei Netcup.
Wenn du den Server brauchst, ist der Fehler ein triftiger Grund, den Notfallsupport in Anspruch zu nehmen.
Also es ist kein Notfall. Ich brauche den nur weil ich meinen Hauptserver von einem anderen Anbieter umziehen muss, da der demnächst den Betrieb einstellt. Ich finde den Fehler hier sehr komisch, da ich schon zwei andere Server hierher problemlos umgezogen habe. Für mich wirkt das so als ob in den Routern diese IPv4 Adresse beziehungsweise das IPv6 Subnet noch überhaupt nicht vergeben sind.
Wie weit kommt den ein traceroute auf Google oder Heise?
Bleibt beim 1. hop stecken
Denke mal Support anschreiben
Habe ich schon. Keine Ahnung wann / ob da eine Antwort kommt.
Das kann auch ein Problem der Defaultroute sein.
Sieht meinem empfinden nach jetzt nicht unbedingt falsch aus. Hab ein Screenshot angehangen.
Hi,
was sagt denn die Netzwerkconfig?
Mal mit manueller IP-Konfiguration getestet?
Und sind im Rettungssystem auch Probleme vorhanden?
Gruß
Ich habe mal zwei Screenshots angehangen. Weder mit manueller config noch im rescue mode geht es.
Standard-Image von Netcup oder von DVD frisch installiert?
Bei letzterem sollte IPv4 via DHCP gehen (aber statisch ist sicherer) - IPv6 geht nur manuell...
Von Netcup. Hab den um 16:57 heute bestellt. Hat weder mit dem Ausliefrungsimage noch mit dem von mir neu installierten funktioniert.
