Bestimmte IPv6 Netze können nicht erreicht werden

  • Hallo,


    hatte schonmal jemand das Problem, dass nur bestimmte IPv6 Netze von einem Root-Server aus nicht erreichbar waren? Ich suche noch nach Ideen wie sich das Problem eingrenzen lässt.


    Der Support hat im Rettungssystem nur geprüft, dass IPv6 prinzipiell geht. Aber es wurde nicht das genannte Netz überprüft.


    Ich sehe zu Zielen in einem kompletten /29 IPv6 Netz dass Pakete den Root-Server verlassen, aber den Netcup Router nicht erreichen. Von der Gegenrichtung sieht man, dass die Pakete Netcup erreichen, aber dann ist Schluss.


    Das passiert nur auf diesem einen Server, meine anderen beiden Root-Server sind nicht betroffen.


    Hatte schonmal jemand ein ähnliches Problem?

  • Möchtest Du den traceroute6 vielleicht mal hier posten?

    Deinen Aussagen zufolge müssten die "Sterne" also bereits beim ersten Hop, dem gw02.netcup.net (2a03:4000:6:7000::3) auftauchen. Das spräche aber dann aber eher für ein Problem auf Deiner Maschine.


    Ich kann bestätigen, dass:

    • ich von meiner NetCup VM aus ein ping6 2001:4178:2:1113::42 erfolgreich durchführen kann
    • ein traceroute6 2001:4178:2:1113::42 aber nach einigen Hops offenbar auf eine Firewall trifft, die eine weitere Routenverfolgung verunmöglicht. Das ist allerdings schon im Zielbereich des Zielservers und nicht mehr im Verantwortungsbereich von NetCup. Und dieses Verhalten stellt außerdem grundsätzlich noch kein Problem dar.
  • So sieht das aus wenn das Ziel nicht erreicht werden kann:


    traceroute6 www.voja.de

    traceroute to www.voja.de(2001:4178:2:1113::42) from 2a03:4000:10:29c::1, port 33434, from port 34477, 30 hops max, 60 bytes packets

    1 * * *

    2 * * *

    ^C

    So sieht es bei Zielen aus die gehen (habe jetzt einen Netcup internen Host genommen um keine Konkurenten Name im traceroute zu haben):


    traceroute6 thor.voja.de

    traceroute to thor.voja.de (2a03:4000:1d:424::1) from 2a03:4000:10:29c::1, port 33434, from port 34243, 30 hops max, 60 bytes packets

    1 2a03:4000:10::3 (2a03:4000:10::3) 0.328 ms 0.220 ms 0.205 ms

    2 thor.voja.de (2a03:4000:1d:424::1) 0.218 ms 0.173 ms 0.309 ms


    Edit: besser formatiert kriege ich es im Moment (mobil) nicht hin.


    Edit 2: es gibt eine Firewall direkt vor dem Ziel, die UDP Pakete an unbekannte Ports dropped.

  • Danke schonmal fürs Anschauen. Ich sehe den Wald vor lauter Bäumen nicht mehr.


    route -6 -n

    Kernel IPv6 routing table

    Destination Next Hop Flag Met Ref Use If

    2a03:4000:10:29c::1/128 :: U 256 0 0 ens3

    2a03:4000:10:29c::/64 :: U 256 2 17013 br0

    fd8e:8f27:59d5:1ddc::/64 :: U 256 1 1 lxdbr0

    fe80::/64 :: U 256 2 17 ens3

    fe80::/64 :: U 256 0 0 br0

    fe80::/64 :: U 256 1 1 lxdbr0

    fe80::/64 :: U 256 0 0 veth4S6HJA

    fe80::/64 :: U 256 0 0 veth59NTP6

    fe80::/64 :: U 256 0 0 veth13K20P

    ::/0 fe80::1 UG 1024 2 24871 ens3

    ::/0 :: !n -1 1 41976 lo

    ::1/128 :: Un 0 3 86 lo

    2a03:4000:10:29c::/128 :: Un 0 1 0 lo

    2a03:4000:10:29c::1/128 :: Un 0 3 188 lo

    2a03:4000:10:29c::1/128 :: Un 0 3 43 lo

    fd8e:8f27:59d5:1ddc::/128 :: Un 0 1 0 lo

    fd8e:8f27:59d5:1ddc::1/128 :: Un 0 2 3 lo

    fe80::/128 :: Un 0 1 0 lo

    fe80::/128 :: Un 0 1 0 lo

    fe80::/128 :: Un 0 1 0 lo

    fe80::/128 :: Un 0 1 0 lo

    fe80::/128 :: Un 0 1 0 lo

    fe80::/128 :: Un 0 1 0 lo

    fe80::1471:e8ff:fe1f:6882/128 :: Un 0 3 25 lo

    fe80::74c5:d6ff:fe45:3817/128 :: Un 0 3 461 lo

    fe80::8c48:2cff:fe01:ef2c/128 :: Un 0 2 2 lo

    fe80::fc59:84ff:fef5:7a99/128 :: Un 0 1 0 lo

    fe80::fcb2:16ff:fed4:fbe0/128 :: Un 0 1 0 lo

    fe80::fce4:beff:fee0:60cf/128 :: Un 0 1 0 lo

    ff00::/8 :: U 256 2 7360 ens3

    ff00::/8 :: U 256 2 22 br0

    ff00::/8 :: U 256 2 24 lxdbr0

    ff00::/8 :: U 256 0 0 veth4S6HJA

    ff00::/8 :: U 256 0 0 veth59NTP6

    ff00::/8 :: U 256 0 0 veth13K20P

    ::/0 :: !n -1 1 41976 lo

  • Ad-Hoc sehe ich das Problem auch nicht.


    Die Default-Route ::/0 fe80::1 ist OK, und andere Routen die hier in die Quere kommen würden sehe ich ad-hoc auch nicht.

    Mal eine andere Frage: Funktioniert ein simples ping6 google.de sowie traceroute6 google.deüberhaupt?

  • Was sind br0, lxdbr0, veth4S6HJA, veth59NTP6 veth13K20P eigentlich für Interfaces?

    Hast Du dir da irgendwelche Bridges gebaut?

    Hast Du ein Layer2 VPN zwischen dem Zielsystem und dem Quellsystem laufen?


    Kannst Du diese ganzen Interfaces mal testweise abdrehen, sodass nur ens3 aktiv ist?

    Wenn sich dadurch das Problem löst, dann funkt von diesen anderen Interfaces irgendwas dazwischen.


    Als nächstes würde dann den ICMPv6 Verkehr mit TSHARK sniffen (tshark -i ens3 -p -Y icmpv6), dann sollte man Klarheit haben ob das Paket überhaupt auf die Leitung geht und welche Neighbor Solicitation da eventuell dazwischen funkt.

  • br0 ist eine Bridge über die Container mit public IPs versorgt werden.


    lxdbr0 ist die Default Bridge von LXD.


    Edit: bridge_ports ist jeweils none


    Die veth Interfaces gehören zu den lxc Containern. Zwei hängen an br0, einer an lxdbr0.


    Ob ich wirklich alle Bridges abgedreht kriege müsste ich mal gucken.


    tshark werde ich mir später mal anschauen.

  • Ein schneller Test mit tshark ergibt das selbe Fehlerbild. Zum Beispiel:


    Externer Server sieht den ping ausgehend.

    Netcup Server sieht den ping eingehend.

    Netcup Server sieht den ping ausgehend.


    Die Antwort kommt aber nicht an.

  • Der Support hat im Rettungssystem nur geprüft, dass IPv6 prinzipiell geht. Aber es wurde nicht das genannte Netz überprüft.

    Hast du schon mal selbst per Rettungssystem getestet?

    Meine (Netcup) Produkte: VPS 1000 G7 SE, S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Hast du schon mal selbst per Rettungssystem getestet?

    Ja, im Rettungssystem kann ich das Problem genau so feststellen.


    root@grml ~ # ip addr add 2a03:4000:10:29c::1/64 dev ens3

    root@grml ~ # /sbin/ip -6 route add default via fe80::1 dev ens3

    RTNETLINK answers: File exists


    D.h. ich musste die IP hinzufügen, aber die Default Route war schon gesetzt. Das Problem tritt auf genau wie vorher:


    root@grml ~ # traceroute6 2001:4178:2:1113::42

    traceroute to (2001:4178:2:1113::42) from 2a03:4000:10:29c::1, 30 hops max, 24 byte packets

    1 * * *

    2 * * *

    3 * * *

    ^C


    Gegenprobe Google, die auch vom Support angewendet wurde:


    root@grml ~ # traceroute6 google.de

    traceroute to (2a00:1450:4001:816::2003) from 2a03:4000:10:29c::1, 30 hops max, 24 byte packets

    1 2a03:4000:10::3 (2a03:4000:10::3) 0.715 ms 2.094 ms 1.121 ms

    2 2a00:11c0:47:3::1e (2a00:11c0:47:3::1e) 0.49 ms 0.495 ms 0.339 ms

    3 2a00:11c0:47:1:47::141 (2a00:11c0:47:1:47::141) 3.6 ms 3.779 ms 3.596 ms

    4 2001:4860:1:1::6bc (2001:4860:1:1::6bc) 3.786 ms 3.906 ms 3.785 ms

    5 2001:4860:0:11e0::1 (2001:4860:0:11e0::1) 4.019 ms 3.985 ms 3.9 ms

    6 2001:4860:0:1::6f9 (2001:4860:0:1::6f9) 4.075 ms 3.927 ms 3.924 ms

    7 fra16s07-in-x03.1e100.net (2a00:1450:4001:816::2003) 3.528 ms 3.483 ms 3.543 ms

    Der Support meinte auch schon die Netze werden jeweils korrekt announced und sollten erreichbar sein. Sind sie aber nicht.

  • Ich habe von außerhalb Netcupnetzes erfolgreich probiert 2001:4178:2:1113::42 zu erreichen. Da Du selbst google.de über die Default Route erreichen kannst, zugleich 2001:4178:2:1113::42 jedoch nicht und bereits der erste Hop Probleme macht, kann hier nur der Support von Netcup helfen.

  • Der Support konnte inzwischen auch das Problem nachvollziehen, aber noch nicht die genaue Ursache finden. Sie versuchen das zu klären, es könnte mit dem Zielprovider zusammen hängen.


    Edit: wobei ich nicht verstehe warum ich vom Root-Server aus den ersten Hop nicht sehe. Das passt für mich nicht ins Bild.

  • Interessant. Ich denke, dass ich jetzt genau dasselbe Problem habe und bin deshalb auf diesen Thread gestossen.

    Ich hoffe mal, dass ich nicht am zweiten Tag bei netcup schon den Support bemühen muss ;)

    Mit tshark und im Rettungssystem habe ich noch nicht getestet.


    Da ich schon mal ein ähnliches oder dasselbe Problem hatte, dass sich nach einem Wochenende von selbst gelöst hat, warte ich mal noch.

    Das heisst dann für mich Feierabend machen und zuerst mal Weihnachten geniessen :)