IPv6 Failover Probleme mit dem Routing

  • Hallo zusammen,


    folgendes Problem besteht seit mindestens einer Woche mit meinem Server Cluster + IPv6 Failover (davor hab ich das ganze ignoriert und nicht im Monitoring gehabt). Bevor ich jetzt ein Support Ticket aufmache frage ich hier einmal nach, ob bei anderen Kunden das gleiche Phänomen auftritt. Ich konnte hier bereits Beiträge lesen, wo aber meistens der Fall anders aussieht.


    Ziel ist es mein Cluster auf lange Sicht IPv4 und IPv6 ready zu machen.


    Zu dem System:


    3x RS2000 G8, alle auf Debian Buster neuste Updates werden regelmäßig eingespielt. Kernel läuft ein 4.19 er. Macht soweit auch keine Probleme.


    Firewall und IP Config ist bis auf das Gateway und die einzelnen IP's bei allen Systemen identisch (via Ansible) eingerichtet und funktioniert auch soweit.


    Was aktuell keine Probleme macht (via DNS oder direkter IP kein Unterschied):


    • Ping 4 von netcup Server <-> netcup Server (via Failover v4 bzw. die servereigene IPv4 geht beides)
    • Ping 6 von netcup Server <-> netcup Server (via Failover v6 bzw. die servereigene IPv6 geht beides)
    • Ping 4 von externem Server <-> netcup Server (via IPv4 und Failover v4 in beide Richtungen kein Problem)
    • Ping 6 von netcup Server zum externem Server (1x von der Failover v6 und einmal von der servereigenen v6 IP)
    • Ping 6 von externem Server zum netcup Server (auf die servereigene IPv6, Failover v6 geht nicht siehe unten)


    Was aktuell Probleme macht, wo ich mir noch nicht zu 100% sicher bin, ob es wirklich in meinem Verantwortungsbereich liegt.


    • Ping 6 von externen Server zum netcup Server (bekomme hier zur Failover v6 ein: "Destination unreachable: Address unreachable")

    Auf den Servern sehe ich bei dem Interface mit der Failover v6 ein "scope global deprecated" anstelle von "scope global" bei der servereigenen IPv6.


    Das komische an dem ganzen ist, dass es so aussieht, als würde die IPv6 auf keinen Server zeigen (Zuordnung im SCP habe ich auch schon gewechselt) bzw, der Router nicht wissen, was damit passieren soll.


    Anbei mal ein paar MTRs von und zum Server. (Man vergleiche die Hops bei v6), da diese leider keine Hostnames haben, gehe ich davon aus, dass das Problem am Routing direkt vor meinem Server hängt.


  • Sorry für den doppelt Post aber das hier ist mir auch noch aufgefallen, war aber für das Erstellen zu lange:



    Was ich komisch finde, sind die letzen beiden MTRs von extern nach Failover v6 vs. direkte IPv6 man sieht, dass vor meinem Server noch die "2a00:11c0:47:3::21" kommt. Diese IP ist bei der Failover nicht erreichbar?


    Bin gerade etwas ratlos, ob ich hier etwas nicht verstehe, oder ob die FailoverIPv6 einfach nicht sauber auf meinen Server zeigt. Ich weiß auf jeden Fall, dass die Failover IPv6 damals als ich sie initial via Ansible eingerichtet hatte ohne Probleme erreichbar war.



    So nachdem dieses Buch geschrieben ist, hoffe ich auf konstruktives Feedback. Echt nervig, wenn etwas nicht so tut, wie man es gerne hätte....

  • Zu den sysctl Einträgen: Habe ich auch bereits getestet, dass war gestern (ja apply und reboot brachten dort auch nichts). Die Einträge sind laut Commands aktiv und werden soweit korrekt genutzt.


    Das mit dem erst Pakete von meinem Server los senden: Müsste das nicht durch die Pings bereits erledigt sein (sofern ich als Absender die Failover IPv6 nutze?), oder muss ich da etwas weiteres beachten?

    Habe gerade via mtr nochmal geschaut, jetzt bekomme ich von der Failover v6 gar keinen Host in Richtung extern mehr angezeigt?!? (Wenn ich eine falsche Absender IPv6 angebe bekomme ich korrekterweise "mtr: Address not available")


    Failover v6 nach netcup.de:

    Code
    Start: 2021-02-27T20:52:57+0100
    HOST: rcluster2 Loss%   Snt   Last   Avg  Best  Wrst StDev

    Servereigene IPv6 nach netcup.de:

    Code
    Start: 2021-02-27T20:56:45+0100
    HOST: rcluster2            Loss%   Snt   Last   Avg  Best  Wrst StDev
      1.|-- 2a03:4000:2b:1000::2  0.0%     1    0.6   0.6   0.6   0.6   0.0
      2.|-- 2a03:4000::e01e       0.0%     1    0.4   0.4   0.4   0.4   0.0


    Wie schon beschrieben die servereigene IPv6 funktioniert genau so wie ich es auch von der Failover IPv6 erwarten würde. Habe auch nochmal via "ip a" und "ip -6 r" geprüft, dort ist nichts auffälliges von meiner Seite aus.

  • Sorry für den Doppelpost.

    Das Problem ist behoben. An für sich war der Fehler auf meiner Seite, jedoch auch ein "komisches" verhalten von Debian.


    Lösung:


    Es müssen auf dem Server:

    - Die eigentliche IPv6 (Server eigene) als network Interface angelegt werden

    - Die Failover IPv6 (die man sich aussucht z.B. für DNS) angelegt werden

    - UND die IPv6, welche die Failover IPv6 im SCP anzeigt, angelegt werden. (also IPv6 Failover + Link Local vom jeweiligen Server)


    Der letzte Punkt war mein Problem und ich konnte ihn auch nachstellen. Ich habe damals 2019 mit Ansible die Netzwerk Konfiguration erstellt. Dann ging einmal alles und ich habe geschaut, was denn "überflüssiger" Ballast darin ist. Dabei konnte ich (geht immer noch) die oben letzte genannte IPv6 entfernen und das networking restarten, ohne dass es irgendeinen Impact zu Schein hatte. Großer Fehler, denn irgendwo scheint Debian für 1800 Sekunden alle Routen nochmals zu "cachen". Danach funktioniert das ganze via Failover IPv6 einfach nicht mehr.