Failover-IP funktioniert nach Reboot nicht

Hallo zusammen,

ich komme leider nicht weiter und brauche mal euren Rat.

Vor zwei Wochen habe ich einen Ubuntu-Server migriert (RS 2000 G11 SE NUE OST25 zu RS 2000 G12 Pro NUE BW25). Die Migration habe ich über einen Snapshot-Export durchgeführt. Dank Failover-IPs (IPv4 und IPv6) dachte ich, dass die Migration problemlos über die Bühne gehen müsste. Ich habe also die IP-Adressen angepasst und das Routing umgestellt. Lieder lief dann erstmal nur IPv6. Bei IPv4 ging weder etwas rein noch raus. Auch nicht auf der originalen IP vom neuen Server.

Nachdem ich dann mehrfach curl --interface 159.195.XXX.XXX icanhazip.com (159.195.XXX.XXX ist die originale IP vom neuen Server) ausgeführt habe, lief IPv4. Sowohl die originale als auch die Failover-IP funktionierten wie erwartet.

Sobald ich den Server aber neustarte oder netplan apply ausführe, ist die Verbindung wieder weg. Mehrfaches Ausführen des o.g. curl-Befehls behebt das Problem dann wieder.

Ich habe bereits versucht die Failover-IP kurz auf einen anderen Server zu schwenken und dann wieder zurück. Hat leider nicht geholfen. Es scheint so, als sei nur diese eine Server betroffen. Bei diesem Server fehlt auch die passende Subdomain unter yourvserver.net. Mein Gefühl sagt mir, dass dieser Server nicht ganz korrekt eingerichtet wurde und deswegen das Routing der Failover-IP irgendwie hakt.

In meiner Verzweiflung habe ich die KI nach Rat gefragt. Zurück kam nur "ARP/Neighbor-Cache" und wilde netplan-Konfigurationen.

Was ist eure Einschätzung? Was kann ich noch überprüfen? Liegt der Fehler eher auf meiner Seite oder auf der von netcup?

Hier noch meine netplan-Config:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - "159.195.XXX.XXX/22" # Originale IP vom Server
        - "152.53.XXX.XXX/32"  # Failover-IP
        - "2a0a:XXXX:XX:db81:d4f8:feff:fede:3d9d/64" # Originale IP vom Server
        - "2a03:XXXX:XX:2cc::1/64"                   # Failover-IP
      routes:
        - to: "default"
          from: "152.53.XXX.XXX" # Failover-IP
          via: "159.195.XXX.1"
        - to: "default"
          from: "2a03:XXXX:XX:2cc::1" # Failover-IP
          via: "fe80::1"
          on-link: true
    eth1:
      addresses:
        - "192.168.255.4/24"
      routes:
        - to: "192.168.254.0/24"
          via: "192.168.255.1"
        - to: "192.168.0.0/24"
          via: "192.168.255.1"

Wenn ich die Failover-IP gar nicht konfiguriere, funktioniert der Traffic über die originale IP des Servers problemlos. Sobald ich aber die Failover-IP hinzufüge (auch ohne from: "152.53.XXX.XXX" bei den Routes, geht gar nichts mehr. Wie konfiguriere ich denn die Failover IP, ohne danach netplan apply ausführen zu müssen? Denn damit ist die Verbindung dann sofort wieder futsch.

Zitat von Mordor

educated guess

Für die IPv4-Route fehlt das "on-link: true"

---

Sonst schau dir mal die Routen an, die das Netplan generiert.

(ip route)

Habe es mal mit on-link: true probiert. Macht leider keinen Unterschied zum aktuellen Verhalten.

ip route gibt folgendes aus:

default via 159.195.XXX.1 dev eth0 proto static src 152.53.XXX.XXX 
159.195.XXX.0/22 dev eth0 proto kernel scope link src 159.195.XXX.XXX 
192.168.0.0/24 via 192.168.255.1 dev eth1 proto static 
192.168.254.0/24 via 192.168.255.1 dev eth1 proto static 
192.168.255.0/24 dev eth1 proto kernel scope link src 192.168.255.4 

Zitat von aRaphael

Meine funktionierende netplan sieht so aus (angepasst an deine ips):

Vielen Dank! Leider macht es auch hier keinen Unterschied zum aktuellen Verhalten. Ich muss auch hier wieder mehrfach curl --interface 159.195.XXX.XXX icanhazip.com ausführen, damit es funktioniert. Einziger Unterschied im Verhalten dieser Konfiguration ist, dass ausgehende Anfragen von der originalen IP gemacht werden und nicht von der Failover-IP (curl -4 icanhazip.com).

ip route sieht dann natürlich auch entsprechend anders aus:

default via 159.195.XXX.1 dev eth0 proto static 
152.53.XXX.XXX via 159.195.XXX.XXX dev eth0 proto static 
159.195.XXX.0/22 dev eth0 proto kernel scope link src 159.195.XXX.XXX 
192.168.0.0/24 via 192.168.255.1 dev eth1 proto static 
192.168.254.0/24 via 192.168.255.1 dev eth1 proto static 
192.168.255.0/24 dev eth1 proto kernel scope link src 192.168.255.4 

Zitat von andreas.

Hast du nach dem Einspielen des Images vom alten Server auf den neuen Server auch die MAC-Adresse auf dem System des neuen Servers aktualisiert? Denn das Fehlerbild deutet auf eine falsche MAC-Adresse auf dem neuen Server hin.

Nein, habe ich nicht. Aber wo sollte die MAC-Adresse denn statisch konfiguriert sein? ip link show eth0 zeigt mir die korrekte MAC-Adresse vom neuen Server an.

Zitat von Hille

Das Problem tritt nur nach einem reboot auf, richtig ? Hattest du meinen Hinweis mal getestet ?

Und nach dem Aufruf von netplan apply. Ich bin in der Nachricht darauf eingegangen. Hab leider vergessen dich zu zitieren:

Zitat von Virinum

Wie konfiguriere ich denn die Failover IP, ohne danach netplan apply ausführen zu müssen? Denn damit ist die Verbindung dann sofort wieder futsch.

Um hier mal ein Update zu geben: Ich habe am Mittwoch den Support kontaktiert. In unter einer Stunde kam eine Antwort mit der Bitte, die Tests nochmal im Rettungssystem durchzuführen. Bin erst heute dazu gekommen. Hier meine Erkenntnisse:

• Wenn einem Server zusätzliche/Failover-IP-Adressen zugeordnet sind, sind sie auch direkt im Rettungssystem konfiguriert (dachte immer, dass sich das Rettungssystem seine IP über DHCP zieht)
• Im Rettungssystem waren direkt bei IPv4-Adressen erreichbar
• Nachdem ich wieder das normale System gestartet habe, waren auch hier direkt beide IPv4-Adressen erreichbar
• Selbst nach einem erneuten Reboot und netplan apply sind sie direkt erreichbar
• Problem hat sich anscheinend von alleine gelöst oder netcup hat doch etwas im Hintergrund gemacht