Paketverluste bei IPv6

  • Hallo zusammen,

    ich bemerke bei meinem Server intermittierende, d.h. zufällig auftretende Paketverluste über IPv6.

    Das Problem liegt zwischen meinem Server (OpenBSD) und dem netcup-KVM-Host.
    Ich füge traceroute und ping output an. Bei IPv4 gibt es ein ähnliches Verhalten bzgl. der Latenzen, allerdings ohne Paketverlust.
    Leider kann ich mir keinen Reim darauf machen. Vielleicht hat jemand eine Idee dazu.

    Beste Grüße, Daniel.


    Traceroute6 (Ausschnitt):

    HOST: Laptop Loss% Snt Last Avg Best Wrst StDev
    5.|-- 2a00:11c0:47:1:47::140 0.0% 100 17.0 19.2 16.6 43.2 4.3
    6.|-- 2a00:11c0:47:3::21 13.0% 100 17.2 21.7 16.9 77.5 10.2
    7.|-- mein Server
    13.0% 100 17.6 19.3 16.8 31.0 2.9


    Ping6 vom Server zum netcup-gateway:

    Code
    1. PING fe80::1%vio0 (fe80::1%vio0): 56 data bytes
    2. --- fe80::1%vio0 ping statistics ---
    3. 100 packets transmitted, 100 packets received, 0.0% packet loss
    4. round-trip min/avg/max/std-dev = 0.500/3.571/64.690/9.673 ms
  • Naja, so ein paar mehr Informationen wären schon hilfreich. Welche Hardware-Einstellungen, welches BSD. Und das übliche: Nachvollziehbarkeit im Rettungssystem?

  • Darf man fragen wie die /etc/hostname.vio0 aussieht und ob noch weitere Schritte nötig sind? Nach einem Kaltstart ist bei mir IPv6 nämlich jetzt leider komplett tot.


    Ich habe seit 2014 OpenBSD bei netcup am laufen. Mit der einzigen Eigenart, das nach dem booten einmal fe80::1%vio0 angepingt werden muss, damit das Routing funktioniert, lief immer alles Problemlos. In letzter Zeit wurde die IPv6-Konnektivität allerdings immer schlechter.

    c82b6976b27c4dab591f12e4b7694be775767c2f.png


    Als ich hier vom Kaltstart laß, habe ich # halt -p ausgeführt. Im SCP erschien die Meldung, das mein Festplatten-Image eine Optimierung braucht. Was ich dann gleich durchführen ließ. Da die Meldung anschließend immer noch erschien, habe ich es gleich nochmal ausgeführt. Nach dem Booten musste ich dann feststellen, das IPv6 nicht mehr funktioniert. Das war gestern Nacht. Hab es seither nicht wieder zum laufen bekommen. Hab schon mehrfach alle drei Netzwerkkarten durch probiert.

    Das GW fe80::1 ist pingbar, ansonsten geht nichts.


    • virtio-Netzwerkkarte
    • OpenBSD 6.5

    Meine /etc/hostname.vio0:


    (Mit und ohne "inet6 eui64", "inet6 -soii" macht kein Unterschied. Auch wenn ich nur "-soii" anstelle von "inet6 -soii" schreibe macht kein unterschied.)


    In der Crontab ist dann noch

    Code
    1. @reboot sleep 10 && ping6 -c 10 fe80::1\%vio0 > /dev/null

    was bisher immer nötig war damit es funktioniert.



    Wenn ich das Rettungssystem boote und

    Code
    1. route -6 add default gw fe80::1 dev ens3
    2. ifconfig ens3 inet6 add 2a03:4000:6:f0::47/64

    eingebe funktioniert IPv6.

    (Pingen geht interessanterweise auch nicht

    Code
    1. ping6 -v heise.de
    2. ping: socket: Permission denied, attempting raw socket...

    aber TCP geht.)


    Ich verstehe es einfach nicht.

  • Hmm.


    Bevor du den Ping an fe80::1 rausschickst, kannst du bitte kontrollieren, ob das Interface up ist und wie die Ausgabe von ndp -a ist.

    Ggf. musst du beim ndp Command noch etwas ergänzen.


    Wie sieht das ndp Command nach dem Ping aus?

    Im Manual steht auch, dass die Interface Config die Zeile up am Ende erhalten sollte.

    Trifft das bei dir zu?


    https://man.openbsd.org/ndp.8

    https://man.openbsd.org/hostname.if.5

  • Danke für die Antwort!


    Ich hatte up seit Jahren nicht mehr verwendet, da in https://man.openbsd.org/ifconfig steht, das mit dem setzten der ersten Adresse das Interface "up" geschaltet wird und all meine anderen Systeme es auch nicht brauchen. Und jetzt gebe ich hier up ein und es geht ... :-)

    Es muss nach einem Neustart nicht mal zuerst fe80::1 angepingt werden.


    ... jetzt ist ne ~halbe Stunde vorbei, seit ich den oberen Absatz geschrieben habe und schon sieht es nicht mehr ganz so gut aus. Von meinen vier IPv6 Adressen funktioniert nur noch eine. Die anderen sind nach und noch ausgefallen. Auch ein Neustart ändert nichts. Das ist alles so bizarr. Wenn ich weitere Adressen hinzufüge sind die nicht erreichbar. Wenn ich die Anzahl der Adressen verringere ändert das auch nichts.


    Es funktioniert momentan nur diese zufällig ausgewürfelte Adresse 2a03:4000:6:f0:51ac:ff0a:4bd7:ee. Andere Adressen wie 2a03:4000:6:f0::47 oder 2a03:4000:6:f0:e:a:1:1, welche ich die letzten sechs Jahre in Verwendung hatte gehen nicht.

  • ndp technisch kann ich keine Auffälligkeiten erkennen:


    Code
    1. $ ndp -an
    2. Neighbor Linklayer Address Netif Expire S Flags
    3. 2a03:4000:6:f0::47 52:54:cf:85:a9:c9 vio0 permanent R l
    4. 2a03:4000:6:f0:b:0:d10:de 52:54:cf:85:a9:c9 vio0 permanent R l
    5. 2a03:4000:6:f0:e:a:1:1 52:54:cf:85:a9:c9 vio0 permanent R l
    6. 2a03:4000:6:f0:51ac:ff0a:4bd7:ee 52:54:cf:85:a9:c9 vio0 permanent R l
    7. fe80::1%vio0 00:00:5e:00:02:02 vio0 23h59m59s S R
    8. fe80::22d8:b00:66ee:ff4%vio0 2c:6b:f5:a0:77:c0 vio0 23h54m9s S R
    9. fe80::22d8:b00:66fa:424c%vio0 10:0e:7e:26:f1:c0 vio0 23h53m45s S R
    10. fe80::5054:cfff:fe85:a9c9%vio0 52:54:cf:85:a9:c9 vio0 permanent R l
  • jetzt ist ne ~halbe Stunde vorbei, seit ich den oberen Absatz geschrieben habe und schon sieht es nicht mehr ganz so gut aus.

    Das deutet eher darauf hin, dass dein BSD nicht auf NDP Packete antwortet.

    Ich habe dir mal ein paar Pings geschickt. Nach ca. 70 Packeten kommt erst eine Antwort.

  • Irgendsowas muss es sein. Hab auf alle Adressen dauer ping laufen. Es ist reiner Zufall, ob was und wie lange geht. Mal geht die eine Adresse für 10 Minuten, dann wieder ne andere. Dann gegen mehrere parallel. Dann wieder gar nix. :-/


    Ich werde dann mal versuchen demnächst auf 6.6 upzudaten, in der Hoffnung dass das was bringt.

  • Ich habe seit einigen Tagen ähnliche Probleme unter FreeBSD 12.1. IPv6 funktioniert nur noch sporadisch und auch nicht vorhersehbar. Es scheint außerdem tatsächlich ein Problem mit NDP vorzuliegen.


    Um der Sache mit den "bad neighbor solicitation messages" auf den Grund zu gehen, habe ich ICMP6 Neighbor-Discovery-Debugging eingeschaltet:


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

    Und bekomme nun Logeinträge der folgenden Form, aus denen ich nicht schlau werde, bzw. von denen ich denke, dass NDP-Solicitations zurecht verworfen werden:


  • Ich habe seit einigen Tagen ähnliche Probleme unter FreeBSD 12.1. IPv6 funktioniert nur noch sporadisch und auch nicht vorhersehbar. Es scheint außerdem tatsächlich ein Problem mit NDP vorzuliegen.

    Magst du deine Erkenntnisse bitte mit dem Support teilen?


    2a03:4000:6:d04e::9 - ist das deine Adresse? Wenn nicht hat Netcup im Multicast einige unerwünschte Nachrichten.

    Das dürfte aber nicht ins Gewicht fallen.

  • Magst du deine Erkenntnisse bitte mit dem Support teilen?


    2a03:4000:6:d04e::9 - ist das deine Adresse? Wenn nicht hat Netcup im Multicast einige unerwünschte Nachrichten.

    Das dürfte aber nicht ins Gewicht fallen.

    Nein, das sind nicht meine Adressen. Das ist entweder netcup Infrastruktur oder Adressen andere Kunden. Den Support werde ich anschreiben.

  • Magst du deine Erkenntnisse bitte mit dem Support teilen?


    2a03:4000:6:d04e::9 - ist das deine Adresse? Wenn nicht hat Netcup im Multicast einige unerwünschte Nachrichten.

    Das dürfte aber nicht ins Gewicht fallen.

    Nein, das sind nicht meine Prefixe. Das ist entweder netcup Infrastruktur oder Adressen anderer Kunden. Wahrscheinlich ist NDP die falsche Fährte und das Routing ist kaputt. Den Support habe ich angeschrieben.

  • Ich bekomme diese Meldungen:

    Code
    1. nd6_ns_input: NS packet from non-neighbor
    2. nd6_ns_input: src=2a03:4000:6::3
    3. nd6_ns_input: dst=2a03:4000:6:f0:e:a:1:1
    4. nd6_ns_input: tgt=2a03:4000:6:f0:e:a:1:1
    5. nd6_ns_input: NS packet from non-neighbor
    6. nd6_ns_input: src=2a03:4000:6::2
    7. nd6_ns_input: dst=2a03:4000:6:f0:51ac:ff0a:4bd7:ee
    8. nd6_ns_input: tgt=2a03:4000:6:f0:51ac:ff0a:4bd7:ee

    Hab noch nicht ganz verstanden was hier eine erlaubte src-Adresse wäre.



    Und es bleibt dabei, das es ab und an kurz mal funktioniert.

    c82b6976b27c4dab591f12e4b7694be775767c2f.png