IPv6 network is down/unreachable

  • Der ping ist aber keine dauerhafte Lösung. IPV6 ist nur sporadisch verfügbar.

    Dem Support habe ich das vor einer Woche gemeldet.

    Gegebenenfalls äußert sich das Problem an verschiedenen Nodes unterschiedlich - oder wir haben unterschiedliche Probleme. Bei mir funktioniert IPv6 seit 6 Tagen nach dem letzten Reboot durchgehend.

  • This was working fine for years, I never had any issue, service was "perfect", the support team as confirm they found the issue and are working on it but unfortunately seems that is taking more than expected to fix the problem.

  • Also experiencing the same issue. Sysctl values are set like written in wiki. Noticed this when i was trying to login to an pure ssh shell and not ansible anymore where it used the IPv4. OS is in all 6 Cases Debian Buster. Static IPv4 and IPv6 NIC Configuration like written in the wiki.

  • Also experiencing the same issue. Sysctl values are set like written in wiki. Noticed this when i was trying to login to an pure ssh shell and not ansible anymore where it used the IPv4. OS is in all 6 Cases Debian Buster. Static IPv4 and IPv6 NIC Configuration like written in the wiki.

    Did you made a reboot to the server, after you had configured it?

    Have you told this to the support?


    [netcup] Felix P. Because it seems that this is an bigger issue - may we can have a statement of netcup? Are there any other known reasons for this problems?

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Ja ganz witztig. Habe gestern mal versucht VM ein und auszuschalten (komplett). Hat nicht geklappt, nach dem Ping zu Netcup.de hats funktioniert.

    Sehr komisch.

    Auch bei mir war es Debian Buster (aber ein Umzug via Image Export).

  • Did you made a reboot to the server, after you had configured it?

    Have you told this to the support?


    [netcup] Felix P. Because it seems that this is an bigger issue - may we can have a statement of netcup? Are there any other known reasons for this problems?

    Yes, the Server were all completely shut down, also with the SCP Button "Power off" after being configured.

    Funny things is that it seems random if it works currently or not. Like right now 1 of the 6 servers i can reach with IPv6, even though it takes a few seconds before the first ping comes back. And all of them can do ping6 netcup.de, but this does not mean i can also ping them from my home.


    I did not reach out to Support yet for this as i happily don't need to rely on IPv6 only.

  • Sorry but goodbye.


    I had to move out due to the current situation, support ticket still open, I know you guys are doing your best, but the problem persists and is affecting all my services.


    It is a very unfortunate situation since the service was working perfectly, I really never ever had an issue until now.


    I hope this problem gets fixed soon and please after fixing it, post a detailed postmortem, It would be very helpful to understand what happened and learn from it, this will be something that could give me the confidence to know that services are up again and why not consider coming back again as a happy customer.

  • for my part, the outgoing issues seem to be resolved.

    For incoming connections, it helps FreeBSD to accept router advertisements.

    In /etc/sysctl.conf:

    Code
    net.inet6.ip6.accept_rtadv=1


    To enable immediately:

    Code
    ndp -i vtnet0 accept_rtadv
  • I still have problems with dropped packets. This, the long denial of the problem and the unprofessional support behavior have led me to host my servers elsewhere in the future.

    Too bad, it worked fine for a long time.

  • Ich hatte genau das gleiche Problem (sporadischer Packet Loss), und habe festgestellt dass es (bis jetzt) vollständig behoben ist durch das Erlauben von ipv6-icmp Paketen durch die Firewall.


    Bisher hatte ich diese Konfiguration (mit Packet Loss):

    Code
    ip6tables -A INPUT -s fe80::/10 -p ipv6-icmp -j ACCEPT


    Ersetzt durch diese Zeile funktioniert alles problemlos:

    Code
    ip6tables -A INPUT -p ipv6-icmp -j ACCEPT


    (Sorry, for English folks: I also had a high sporadic packet loss over IPv6, and fixed it by allowing ICMP packets through the firewall)

  • Clemens Alter Fuchs - Vielen Dank. Ich hatte ICMP grundsätzlich vor einer Weile deaktiviert, und kürzlich nicht funktionierende IPv6 Routen bemerkt. Damit hätte ich das ohne deinen Kommentar, in diesem doch schon älteren Thread, nie in Zusammenhang gebracht! Kann jemand erklären warum IPv6 zwangsläufig funktionierendes ICMP benötigt, während IPv4 problemlos ohne auskommt? Ist dies Besonderheit der Netcup Infrastruktur, oder auch bei anderen Hostern so?


    P.S.: Falls jemand, wie ich, firewalld im Einsatz hat, so lauten die Kommandos wie folgt:

    Code
    #This only adds a temporary rule - add it, then test if everything is working as excpected
    firewall-cmd --direct --add-rule ipv6 filter INPUT 0 -p ipv6-icmp -j ACCEPT
    
    #If everything runs fine, make the temporary rule a permanent one
    firewall-cmd --runtime-to-permanent

    Getestet auf drei Netcup Root Servern mit openSUSE 15.2.

  • Kann jemand erklären warum IPv6 zwangsläufig funktionierendes ICMP benötigt, während IPv4 problemlos ohne auskommt? Ist dies Besonderheit der Netcup Infrastruktur, oder auch bei anderen Hostern so?

    Genauer gesagt: Es werden bestimmte "Unterklassen" benötigt, und das ist generell so. Ich empfehle einen Blick auf die Quellen, die ich in dem Beispielscript hier referenziert habe: suppress-ping.sh

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing