FreeBSD 12.1 Probleme IPv6

  • Hallo,


    ich habe auf meinem RS FreeBSD 12.1 installiert. Es sieht so aus, als ob es Probleme mit dem Neighbor Discovery Protocol gibt. Out of the box funktioniert IPv6 nicht. Ich muss über


    Code
    1. sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1


    einschalten, dass sich die NDP-Requests auf einen Link bezieht. Das wurde in FreeBSD deaktiviert Grund: https://www.freebsd.org/securi…/FreeBSD-SA-08:10.nd6.asc.


    Prinzipiell funktioniert damit IPv6, jedoch stellt sich noch ein Problem:


    Code
    1. ping6 google.com
    2. PING6(56=40+8+8 bytes) 2a03:4000:42:1db::1 --> 2a00:1450:4001:806::200e
    3. 16 bytes from 2a00:1450:4001:806::200e, icmp_seq=83 hlim=120 time=93.311 ms
    4. 16 bytes from 2a00:1450:4001:806::200e, icmp_seq=84 hlim=120 time=3.902 ms
    5. ...

    Es vergeht eine Ewigkeit bis der erste Ping durchkommt und hat deutlich längere Laufzeiten als die nachfolgenden Pings. Solange der NDP Eintrag gültig ist funktioniert alles wie gewünscht. Danach dauert der erste Ping wieder sehr lange.


    Woran kann das liegen? Ich würde mich sehr über eine Lösung für das Problem freuen.

  • Ich habe das Problem auch auf meinem FreeBSD 12.1. Bei mir ist allerdings gar kein IPv6 möglich. Das hat mal früher gut funktioniert.


    Die Einstellungen scheinen auch korrekt zu sein, denn ich komme mit traceroute6 bis zum Router 2a00:11c0:47:3::32, wenn ich versuche Google zu erreichen dann ist Feierabend.

  • Ich habe noch einmal in den Logs nachgeschaut. Das letzte mal als ich eine IPv6 Verbindung zu Web-Servern gehabt habe war am 22. August 2020 um 02:43. Und die erste fehlgeschlagene SMTP-Verbindung ist um 15:35 am gleichen Tag.


    Übrigens, ich bin neu hier liest hier überhaupt jemand vom Suppport oder ist das nur für Kundenplauderei? Sonst wäre es besser hierzu eine Störung zu melden.

  • Ich habe noch einmal in den Logs nachgeschaut. Das letzte mal als ich eine IPv6 Verbindung zu Web-Servern gehabt habe war am 22. August 2020 um 02:43. Und die erste fehlgeschlagene SMTP-Verbindung ist um 15:35 am gleichen Tag.


    Übrigens, ich bin neu hier liest hier überhaupt jemand vom Suppport oder ist das nur für Kundenplauderei? Sonst wäre es besser hierzu eine Störung zu melden.

    Das hier ist primär ein Kundenforum - Kunden helfen Kunden. Der Support oder auch die Geschäftsführung liest hier gelegentlich mit, aber verlassen sollte man sich darauf nicht. Besser den Support direkt kontaktieren, per Telefon, E-Mail (von der bei netcup registrierten Adresse) oder Formular im CCP.

  • Die Mitarbeiter von Netcup gucken hier nur zufällig und sporadisch rein. Wenn es relevant oder dringend ist, dann würde ich support@ empfehlen.

  • Es vergeht eine Ewigkeit bis der erste Ping durchkommt und hat deutlich längere Laufzeiten als die nachfolgenden Pings. Solange der NDP Eintrag gültig ist funktioniert alles wie gewünscht. Danach dauert der erste Ping wieder sehr lange.

    Mit OpenBSD 6.7 beobachte ich genau das gleiche Problem.

  • Bekanntes Problem. Liegt nicht an FreeBSD. Habe es schlussendlich durch ein zus. IPv6 Netz gelöst welches vernünftig (seitens Netcup) geroutet wird.

    Was soll sich eigentlich bei einem zusätzlichen IPv6-Subnetz ändern? OK, das wird auf eine Adresse Deines primären Subnetzes geroutet, braucht also kein NDP für jede einzelne Adresse. Für das Ziel dieser Routingaktion ändert sich aber nichts. Dort hat man genau gar nichts gewonnen. Oder übersehe ich da irgendeine Kleinigkeit?


    (Ich verwende kein *BSD und ich weiß somit auch nicht, woran es im Detail scheitert.)

  • Was soll sich eigentlich bei einem zusätzlichen IPv6-Subnetz ändern? OK, das wird auf eine Adresse Deines primären Subnetzes geroutet, braucht also kein NDP für jede einzelne Adresse. Für das Ziel dieser Routingaktion ändert sich aber nichts. Dort hat man genau gar nichts gewonnen. Oder übersehe ich da irgendeine Kleinigkeit?


    (Ich verwende kein *BSD und ich weiß somit auch nicht, woran es im Detail scheitert.)

    Von dem was ich hier so gelesen habe ist das inkludierte v6 Netz geswitcht, jedes zus. erworbenes geroutet. Was das im Detail bedeutet weiß ich nicht, ich bin kein Netzwerkspezialist.


    Jedenfalls wollte ich einen Teil des Netzes für LXC Container verwenden, war aber unterm Strich nicht praktikabel, da die Route von seitens Netcup immer wieder fallen gelassen wurde. Tools wie ndppd haben nichts gebracht.

    Das zus. v6 Netz dagegen funktionierte auf Anhieb und fehlerfrei.


    Schöne Grüße

  • Hallo,


    sorry für die späte Antowort. Ich melde mich nochmal zu diesem Thread zurück. Die initiale Verzögerung des Ping6 liegt an der Infrastruktur von Netcup. Der Support dazu:

    Quote

    Bis die NDPv6 Adjacency erstmalig auf den Routern zustande kommt, erklärt diese Verzögerung.


    Das kann ich soweit akzeptieren. Das jedoch dieses Problem in Intervallen von ca. 5 - 30 Minuten regelmäßig auftritt ist aus meiner Perspektive nicht in Ordnung. Ich habe dann alles möglich selber probiert mit u.a. ein Cronjob der regelmäßig google oder den Gateway pingt. Irgendwann habe ich mir von einem befreundeten FreeBSD Sysadmin gebeten sich es anzuschauen. Hier eine Kurzzusammenfassung der Erkenntnisse (Anmerkung: Das beruht alles auf Vermutungen aufgrund der gesammelten Informationen):


    Der Gateway für das IPv6 Subnet in dem mein RS hängt scheint 2a03:4000:42::2/48 zu sei; die Default Route liegt aber auf fe80::1%vtnet0. Im tcpdump konnte nun folgendes beobachtet werden: Der ping6 geht über die Default Route raus an google, dass ist soweit alles in Ordnung. Der Netcup Router schickt die Antwort aber über 2a03:4000:42::2 in dessem /48 Subnetz mein /64 Netz liegt und nicht über die Default Route fe80::1%vtnet0. Damit ist Ausgangsrichtung (an fe80::1%vtnet0) ungleich der Eingangsrichtung (zu meiner IP). FreeBSD und vermutlich auch die anderen *BSDs haben damit ein Problem. FreeBSD (*BSD) muss sich regelmäßig mit den beiden Routern sortieren. Sobald alles sortiert ist funktioniert IPv6 normal für eine gewisse Zeit. Wieso Linuxe damit keine Probleme haben kann ich nicht sagen.


    Das Problem wäre lösbar, wenn Netcup alles entweder über 2a03:4000:42::2 oder fe80::1%vtnet0.
    @killerbees19: Wenn das zusätzlich gebuchte IPv6 Subnetz wie von angeritten und vmk erwähnt ordentlich geroutet ist, dann tritt das oben geschilderte Problem nicht auf, da Ausgangs- und Eingangsrichtung gleich sind. Es ist sogar möglich, dass sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1 dann nicht mehr nötig ist, weil die NDP Mitteilungen dann von Hosts kommen, die via Link Local erreichbar sind. Und man damit keine 12 Jahre alte Sicherheitslücke wieder öffnen muss.


    Leider muss ich aber sagen, dass der viel gerühmte Netcup Support nicht mit Qualität geglänzt hat. Dieser geht auf meine Frage ob die oben geschilderten Annahmen korrekt sind gar nicht ein und möchten mich mit Verweis auf die oben zitierte Nachticht abspeisen. Daher bleiben es bisher weiterhin nur Vermutungen.


    Daher abschließend meine Frage an angeritten : Musstest du nur das zusätzliche IPv6 Netz dazubuchen, oder musstest du den Support auch noch motivieren irgendwelche Einstellungen vorzunehmen.


    Es wäre schön, wenn man ohne diesen Aufpreis ein ordentliches IPv6 Subnetz unter FreeBSD/*BSDs bekommen könnte.


    Schöne Grüße

  • Hallo zusammen,
    ich denke ich habe jetzt das Problem im Griff. Ich würde meine Erkenntnisse teilen, daher hier nochmal abschließend eine Zusammenfassung:

    Setup:

    OS: FreeBSD 12.1

    Netzwerktreiber: virtio

    Produkt: Root-Server (Mega-Ei OST20)

    IPv4: DHCP

    IPv6: Statisch

    DNS: Netcup

    Problem:

    Die statisch konfigurierte (nach Netcup Anleitung) IPv6 Verbindung ist nicht stabil. Der initiale Ping6 ist extrem verzögert und es kommt zu Paketverlusten. Dieses Phänomen tritt in unregelmäßigen Intervallen ca alle 5-30 Minuten auf. Noch "schlimmer" verhält es sich, wenn versucht wird von außen den Server via IPv6 zu pingen. Es kommt zu Paketverlusten, bis eine Verbindung zustande kommt. Es kam auch vor, dass gar keine Verbindung etabliert wurde.


    Nach der Rückmeldung anderer *BSD Nutzer hier im Forum tritt das dort ebenfalls auf (soweit ich das gelesen habe).


    Um eine Fehlkonfiguration von meiner Seite ausschließen zu können habe ich auch das FreeBSD 12.1 Image von Netcup verwendet und konnte das Problem reproduzieren.

    Analyse:

    Disclaimer: Die Analyse beruht auf reinen Vermutungen. Ich habe leider von Netcup keine Informationen bekommen, ob diese Annahmen korrekt sind oder nicht.

    Anfänglich hatte ich wie oben beschrieben die Vermutung, dass der Fehler im NDP liegt und die Einträge einfach nach sehr kurzer Zeit ungültig sind und dann wieder eine aus unerfindlichen Gründen lange Neighbor Discovery nötig ist. Diese Annahme war nicht korrekt. Nach weiterer Analyse konnte ich (mit Hilfe von Freunden) folgendes feststellen:

    ... Der Gateway für das IPv6 Subnet in dem mein RS hängt scheint 2a03:4000:42::2/48 zu sei; die Default Route liegt aber auf fe80::1%vtnet0. Im tcpdump konnte nun folgendes beobachtet werden: Der ping6 geht über die Default Route raus an google, dass ist soweit alles in Ordnung. Der Netcup Router schickt die Antwort aber über 2a03:4000:42::2 in dessem /48 Subnetz mein /64 Netz liegt und nicht über die Default Route fe80::1%vtnet0. Damit ist Ausgangsrichtung (an fe80::1%vtnet0) ungleich der Eingangsrichtung (zu meiner IP). FreeBSD und vermutlich auch die anderen *BSDs haben damit ein Problem. FreeBSD (*BSD) muss sich regelmäßig mit den beiden Routern sortieren. Sobald alles sortiert ist funktioniert IPv6 normal für eine gewisse Zeit. ...

    Mehr kann man leider vom Server aus nicht wirklich feststellen.


    Anmerkung: Dieses Phänomen tritt unter Linuxen nicht auftritt; im Rescue System (GRML Linux) ist nur der initiale Ping verzögert, danach funktioniert IPv6 wie es soll. Der IPv6 Stack der *BSDs entspricht der freien Referenzimplementierung des Kame-Projektes. Ob die Linux Distributionen sich ebenfalls nach dieser Implementierung richten ist mir unbekannt. Fakt ist, das Problem ist unter FreeBSD zu beobachten und unter GRML Linux nicht.


    Zusätzlich gab es noch weitere Infos:

    ... Von dem was ich hier so gelesen habe ist das inkludierte v6 Netz geswitcht, jedes zus. erworbenes geroutet. Was das im Detail bedeutet weiß ich nicht, ich bin kein Netzwerkspezialist. ...

    Lösung:


    Wie von vmk und angeritten bereits erwähnt ist ein zusätzliches IPv6 Subnetz die Lösung. Wie KB19 es schon richtig geschrieben hat, bedeutet es:

    ... OK, das wird auf eine Adresse Deines primären Subnetzes geroutet, braucht also kein NDP für jede einzelne Adresse. ...


    Zusatzinfo für alle die kein zusätzliches IPv6 Subnetz bekommen haben: Nachdem man das IPv6 Subnetz dem Server zugewiesen hat sind im SCP -> Netzwerk IPv6 zwei Subnetze gelistet. Zuerst das inkludierte Subnetz, mit der Info Gateway fe80::1. Für das zweite zusätzliche Subnetz bekommt man kein Gateway gelistet, sondern eine Routing to IPv6 Adresse. Diese Routing to IPv6 Adresse ist aus dem Adressbereich des inkludierten Netzes.


    Wenn ich nun die Routing to Adresse als statische IPv6 Adresse auf dem Host eintrage bekomme ich eine stabile IPv6 Verbindung ohne initialem Lag, ohne irgendwelche Probleme. (Da das nirgends dokumentiert zu sein scheint hat es doch eine gewisse Zeit gebraucht um das herauszufinden). Auch sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1 ist dann nicht mehr nötig. Meine Vermutung ist, dass diese Routing to IPv6 mit dem zusätzlichen Subnetz im Routing von Netcup extra konfiguriert wird und das es dann einer Konfiguration entspricht mit dem FreeBSD (und hoffentlich auch die anderen) IPv6 Stack funktioniert.


    Hinweis: Nach meinen Tests ist die Routing to Adresse die einzige, die problemfrei läuft. Alle anderen Adressen des Subnetzes haben weiterhin das oben beschriebene Problem. Wenn man aber mehr als eine IPv6 Adresse benötigt, z.B. für Jails, kann man problemlos die IPv6 Adressen des zusätzlichen Subnetzes verwenden. Knackpunkt hier: Das Netzwerkinterface (vtnet0 in meinem Fall) muss die Routing to Adresse haben und alle weiteren IPv6 Adressen (aus dem zusätzlichen Subnetz) können dann als alias zugefügt werden. Das ist wichtig, weil sonst logischerweise keine Route vom zusätzlichen Subnetz (über die Adresse des inkludierten Subnetzes) zum Default Gateway fe80::1 möglich ist.


    Das Verhalten kann im Resuce System nachvollzogen werden:

    1. Rescue System booten 2. ip -6 addr add [Subnetz ::2] dev ens3 3. ping6 heise.de

    Der erste Ping ist verzögert und funktioniert danach (zumindest beim meinem RS). Memo die IP sollte nicht die Routing to Adresse sein.

    1. Rescue System booten 2. ip -6 addr add [routing to] dev ens3 3. ping6 heise.de

    Der erste Ping ist nicht verzögert. Alles funktioniert von anfang an.


    Disclaimer: Wieso es funktioniert ist wieder eine Vermutung und ist keine von Netcup gesicherte Aussage.

    Epilog

    Ist bei allen Kunden im inkludierten IPv6 Subnetz der erste IPv6 Ping verzögert? Außerdem, wenn andere Kunden mit einem zusätzlichen IPv6 Subnetz das Verhalten im Rescue System nachvollziehen könnten und hier Feedback geben fände ich das sehr interessant.


    Momentan ist dieser Lösungsweg nur ein 'works on my machine'. Falls diese Lösung anderen hilft wäre hier Feedback schön um den Lösungsweg zu legitimieren.


    Beste Grüße


    PS: Sorry für die wall of text

  • Sorry, dass ich das nochmal ausgrabe, aber ich habe zufällig eine Lösung gefunden. Auch wenn die etwas stumpf klingt. Wie es scheint müssen die Default-Routen-Einträge einfach vertauscht werden. D.h. zuerst in /etc/rc.conf die IPv6 Route festlegen und dann erst die IPv4 Route.


    Ich habe das mal eben gerade gemacht und sieht soweit super aus.


    Dieser Thread hat mich auf die Lösung gebracht.

  • Nach längeren Analysen muss ich hier zurück rudern. Das Problem wird durch das Vertauschen der Konfigurationseinstellungen nicht behoben.


    Ich versuche das Problem einzugrenzen, jedoch sind das wahrscheinlich mehrere kombinierte Probleme. Den verzögerten ersten Verbindungsaufbau verstehe ich überhaupt nicht.


    Ich sehe aber, dass einer von den drei Routern im Netz gar nicht auf Neighbor Discovery Antworten von meinem Host reagiert und dann gibt es eine ca. 6-minütige Pause bis ein anderer Router aus der Lastverteilung übernimmt.