Kein Traffic über IPv6 möglich (Deutsche Glasfaser)

  • Sorry ja, auch so was kann man googeln oder chatgp nutzen. Kollegen hatten ja längst Links zu Tests verlinkt, ich dachte aber immer dass es schädliche Links oder Werbung ist. Nun weiß ich Bescheid, danke an alle.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Installier doch mal trippy:

    trippy - Rust

    und teste mal:

    trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -6 one.one.one.one 
    und poste einen Screenshot nach >= 10 Messungen.

  • Guten Abend zusammen,


    ich habe das gleiche Problem. Sind ein neues Ausbaugebiet und habe seit ca 2 Monaten Internet via Deutsche Glasfaser. Hatte schon mehrere Tickets dort offen aber keine sinnvolle Antwort/Hilfe erhalten.


    Ich habe ein kundeneigenes Gerät Fritzbox 5530 Fiber. Diese hatte ich auch einige Zeit direkt an der Faser, bis mir das Problem mit IPv6 aufgefallen ist. Seitdem hänge ich via LAN1 am Modem von Deutscher Glasfaser (Nokia XS-010X-R).


    Nach einem Werkreset der FritzBox heute hatte ich eine funktionierende IPv6 Verbindung. Mittlerweile geht es nicht mehr, vermutlich nach dem Präfix refresh. Ein Neuverbinden vom Internet genügt nicht um es wieder zum Funktionieren zu bekommen.

    An den Interneteinstellungen habe ich nichts außerdem Provider "Deutsche Glasfaser" geändert.

    Fritzbox Log sagt momentan 1x pro Stunde:

    Code
    26.11.24 	17:03:06 	IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:73d8:5b00::/56 	
    26.11.24 	17:03:06 	Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a00:6020:7380::1848 	
    26.11.24 	17:03:06 	IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out) 	
    26.11.24 	17:03:06 	Internetverbindung wurde getrennt. 	
    26.11.24 	17:03:06 	Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
    26.11.24 	16:03:06 	IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:73d8:5600::/56 	
    26.11.24 	16:03:06 	Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a00:6020:7380::1843 	
    26.11.24 	16:03:06 	IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out) 	
    26.11.24 	16:03:06 	Internetverbindung wurde getrennt. 	
    26.11.24 	16:03:06 	Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.


    Ich habe laut FritzBox eine IpV6 Adresse + Präfix. Meine Systeme bekommen auch im richtigen Präfix Adressen zugewiesen.


    Meine bisherige Diagnose lässt mich vermuten, dass das Routing nach meiner FritzBox schief läuft.


    Ich hatte auch schonmal den PC direkt am Modem. Auch dort habe ich eine IpV6 Adresse bekommen. Eine IPv6 Verbindung war jedoch nicht möglich.


    Code
    traceroute google.de
    traceroute to google.de (142.251.39.99), 30 hops max, 60 byte packets
     1  fritz.box (192.168.178.1)  0.796 ms  0.987 ms  1.168 ms
     2  * * *
     3  185.22.46.64 (185.22.46.64)  12.107 ms  13.418 ms  13.398 ms
     4  185.22.44.29 (185.22.44.29)  18.145 ms  17.935 ms  18.334 ms
     5  74.125.242.187 (74.125.242.187)  16.331 ms  18.520 ms 74.125.243.133 (74.125.243.133)  20.694 ms
     6  142.251.225.137 (142.251.225.137)  20.485 ms  13.669 ms 142.251.225.135 (142.251.225.135)  15.286 ms
     7  ams15s48-in-f3.1e100.net (142.251.39.99)  17.325 ms  14.609 ms  15.130 ms
    Code
    traceroute6 google.de
    traceroute to google.de (2a00:1450:400e:803::2003), 30 hops max, 80 byte packets
     1  fritz.box (2a00:6020:****:6500:d624:ddff:****:****)  0.858 ms  1.013 ms  1.195 ms
     2  * * *
     3  * * *
    Code
    ping4 google.de
    PING google.de (142.251.39.99) 56(84) bytes of data.
    64 bytes from ams15s48-in-f3.1e100.net (142.251.39.99): icmp_seq=1 ttl=118 time=17.5 ms
    64 bytes from ams15s48-in-f3.1e100.net (142.251.39.99): icmp_seq=2 ttl=118 time=16.1 ms
    64 bytes from ams15s48-in-f3.1e100.net (142.251.39.99): icmp_seq=3 ttl=118 time=16.7 ms
    64 bytes from ams15s48-in-f3.1e100.net (142.251.39.99): icmp_seq=4 ttl=118 time=17.3 ms
    64 bytes from ams15s48-in-f3.1e100.net (142.251.39.99): icmp_seq=5 ttl=118 time=16.2 ms
    64 bytes from ams15s48-in-f3.1e100.net (142.251.39.99): icmp_seq=6 ttl=118 time=16.5 ms
    64 bytes from ams15s48-in-f3.1e100.net (142.251.39.99): icmp_seq=7 ttl=118 time=16.3 ms


    Der Rechner von dem die Tests ausgingen hängt via Ethernet Leitung an der FritzBox.


    Viele Grüße


    Stefan

  • Das Phänomen, dass das Lease ausläuft und nicht rechtzeitig erneuert wird, hatten wir schon mal. Ich weiß aber nicht mehr, was damals die Lösung war. Wenn ich mich recht erinnere, trat es auch nicht mit einer Fritzbox auf, sondern mit einem anderen Endgerät.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Wenn zwar per DHCPv6 IPv6-Adressen (WAN-Port + LAN-Präfix) zugewiesen werden (auch wenn es offenbar nicht klappt, eine bestehende Lease per DHCPv6-Renew bzw. ggf. auch DHCPv6-Rebind zu verlängern; nach dem Ablauf der Lease wird ja erfolgreich sofort eine neue Lease angefordert), man dann aber nicht auf das Internet via IPv6 zugreifen kann, könnte es daran liegen, dass die DG-Gegenstelle keine Router-Adversements (RA) sendet. Oder es werden zwar RA gesendet, im RA ist die Router-Lifetime jedoch auf "0" gesetzt.

    Ein Paket-Mitschnitt am WAN-Port der Fritzbox könnte hier weiterhelfen.

  • Ich habe mal einen Blick auf den Mitschnitt geworfen. Zu DHCPv6 (Ansichtsfilter "dhcpv6" setzen): Ja, man sieht mehrere Rebind-Requests, die von der DG-Gegenstelle jedoch ignoriert werden. Am Ende (also nach Ablauf der Leasedauer) leitet die Fritzbox (fe80::d624:ddff:febd:b46b) dann mit einer DHCPv6-Solicitatation eine neue Transaktion (neue XID) zum Bezug einer neuen Lease ein, die erfolgreich von der Gegenstelle mit einem Reply abgeschlossen wird (Rapid Commit aktiv). Das stimmt mit dem oben gezeigten Eventlog überein.

    Was aber bzgl. RA merkwürdig ist: Diese sollten normalerweise von der DG-Gegenstelle an die Multicast-Adresse ff02::1 gesendet werden. In deinem Trace sieht man (Filter icmpv6.type==134 setzen) jedoch ausschließlich unzählige RA-Unicasts an einzelne linklokale Ziele (fe80::...), bei denen die Adresse deiner Fritzbox (s.o.) auch zweimal dabei ist. RA-Unicasts werden normalerweise nur als Reaktion auf vorausgegangene Router-Solicits (RS) gesendet, solche (Filter icmpv6.type==133) sind in dem Mitschnitt aber nicht zu finden. Überhaupt sollten am LAN1-Port, der hier ja als Ersatz-WAN-Port fungiert, nur genau eine MAC-Adresse bzw. die dazu gehörige linklokale IPv6-Adresse sichtbar sein. Es sieht irgendwie so aus, als würdest du auf deiner WAN-Leitung lauter RA sehen, die für andere DG-Kundenanschlüsse gedacht sind.

    Die IPv6-Kommunikation beschränkt sich auf den Austausch von ND-Paketen (NS, NA, RA) mit der DG-Gegenstelle (fe80::22). Auch hier auffällig: Du erhältst unzählige Neighbor-Advertisments (NA) als Unicasts an linklokale IPv6-Adressen, die vermutlich nicht zu deinem Anschluss gehören, und die als "solicited reply" geflagt sind, obwohl von deinem Router zuvor keine dazu passenden Neighbor-Solicit (NS) gesendet wurden. Korrekt sind dabei nur die NS/NA-Transaktionen, die dein Router initiiert hat (Filter "(icmpv6.type==135 || icmpv6.type==136) && ipv6.addr==fe80::d624:ddff:febd:b46b" <-- alles zwischen "" kopieren).

    Sieht mir irgendwie nach einem Problem auf DG-Seite aus.

    Noch zwei Ergänzungen:

    Ein Grund für den DHCPv6 Lease-Timeout ist vermutlich, dass die bestehende Lease seitens DG nicht mehr zu verlängern war, weil dein Anschluss andere IPv6-Adressen bekommen sollte: Die neue WAN-Port-Adresse hat als letzte Ziffer anstelle einer 2 nun eine 7. Im LAN-Prefix hat sich eine Ziffer von 5 auf a geändert. In der Regel bekommt man an stabil funktionierenden Anschlüssen stets dieselben Adressen zugewiesen. Bei meinem Anschluss haben die sich bisher nur nach einer DG-Wartung einmal geändert.

    Wäre mal interessant zu beobachten, ob dein Router nach jedem Lease-Timeout mit anschließender Neuaushandlung einer Lease geänderte IPv6-Adressen bekommt.

    Man sieht ferner, dass dein Router ausgehenden IPv6-Traffic korrekt zur MAC-Adresse 20:00:00:00:10:82 der DG-Gegenstelle routet, nur kommt von da nie was zurück (Ansichtsfilter eth.addr==d4:24:dd:bd:b4:6b && ipv6). Externe IPv6-Zieladressen wurden dabei zuvor über IPv4 aufgelöst. Ausgehende TCP-Verbindungen kommen so über SYN nicht hinaus, DNS- und NTP-Queries bleiben unbeantwortet. Dies ist ein weiteres Indiz für ein Problem auf der DG-Seite.

    Und noch eine Ergänzung:

    Aus den Ziel-MAC-Adressen der am WAN-Anschluss erhaltenen NA- und RA-Unicast-Pakete lassen sich ja die OUI-Anteile (die ersten 24 Bits, z.B. d4:24:dd) und somit die Hersteller der Geräte, an die das jeweilige Paket gerichtet ist, ablesen (Wireshark zeigt das zweckmäßigerweise gleich mit an). Dabei sind alle RA-Zieladressen (die seltener auftauchen) eine Teilmenge der NA-Zieladressen. Wenn ich letztere auszähle kommen ich auf 55 AVM-Router und 37 Sagemcom-Router (die man von DG als Homerouter beziehen kann). Abzüglich dem eignen (AVM-Router) sieht man hier also fehlgeleitete Pakete von 91 fremden Kundenanschlüssen auf der WAN-Leitung, sofern meine Deutung richtig ist. Dass man die im Trace überhaupt sieht, liegt vermutlich daran, dass das WAN-Interface während des Mitschnitts in den "promiscuous mode" gesetzt wird.

    6 Mal editiert, zuletzt von ::1 (28. November 2024 um 13:44) aus folgendem Grund: Typo + mehrere Ergänzungen

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Wow, vielen dank für diese umfassende Analyse. Endlich hab ich eine sinnvolle Grundlage mit der ich nochmal auf Deutsche Glasfaser zugehen kann. Auch hast du mir bestätigt, dass die Ursache sehr wahrscheinlich bei Deutsche Glasfaser liegt und nicht bei mir.


    Gehe ich recht in der annahme, dass die Tatsache dass hier XGS-PON Ausgebaut wurde dafür verwantwortlich ist, dass ich die Nachrichten anderer Router sehe?


    Ich melde mich hier sobald ich Neuigkeiten habe.


    Viele Grüße Stefan

  • Es sieht irgendwie so aus, als würdest du auf deiner WAN-Leitung lauter RA sehen, die für andere DG-Kundenanschlüsse gedacht sind.

    Scheint exakt das gleiche zu sein wie bei mir... gab hier in dem Gebiet jetzt auch schon zwei Wartungen von der DG, hat sich aber nichts geändert.

    Über einen Zeitraum von ~30 Min habe ich jetzt 3 RAs gesehen, kommen alle von fe80::22 und MAC 20:00:00:00:10:83, nur mit unterschiedlichen Link-Local-Adressen als Ziel, einmal mein Router und die anderen zwei gingen an irgendwelche AVM MACs, müssen wohl andere Kunden sein?

    Sind mittlerweile auch deutlich mehr RAs und NAs geworden, die an fremde Router gehen. Denke mal, dass die meisten Anschlüsse hier im Gebiet mittlerweile aktiviert sind. Wundert mich ehrlich gesagt das hier noch nichts passiert ist, bei mir waren nämlich viele Webseiten / Apps extrem langsam oder unbenutzbar während IPv6 aktiviert war, da immer zuerst eine Verbindung über IPv6 versucht wurde... entweder haben die anderen keine solche Probleme oder der DG Support gibt es nicht an die, die das beheben könnten, weiter.

  • oder der DG Support gibt es nicht an die, die das beheben könnten, weiter.

    Meine Erfahrung ist, dass es den Support nicht interessiert, solange man überhaupt ein Verbindung hat. Und wenn man keinen Router gemietet hat, ist grundsätzlich der kundeneigene Router schuld.

    In der Nachbarschaft hat einer mit DG-Router das gleiche Problem, mal schauen ob der was erreichen kann.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Ich habe tatsächlich schnell Antwort vom Support erhalten:


    Im internet hab ich jedoch gelesen, dass der Werkreset des ONT nicht empfehlenswert ist und ggf. eine erneute Provisionierung durch einen Techniker vor Ort erfordert. Bin da aber nicht sicher ob das wirklich der Fall wäre. Letztendlich konnte ich meine FritzBox direkt an der Glasfaser auch selber provisionieren.


    Hat jemand von euch mehr erfahrung damit? Ich hätte als Fallback immer noch die Möglichkeit meine FritzBox direkt an die Glasfaser anzuschließen, die habe ich provisioniert momentan aber nicht direkt dran weil ich von DG will dass es mit ihrem Gerät geht.


    Vielen Dank und viele Grüße Stefan

  • Das wurde mir im ersten Ticket auch empfohlen, wobei "kleiner schwarzen Kasten" bei meinem weißen XGS-Modem nicht zutreffend ist (bei einem späteren Telefonat wollten sie mir auch nicht glauben, dass das Modem nicht schwarz ist...).

    Kann man machen, man kann danach warten oder auch nicht, sehr lang oder kurz, macht bei mir keinen Unterschied.

  • Das Problem ist hier doch partiell auf Layer 3 (IPv4, IPv6) des Netzwerk-Stacks zu verorten, und IPv4 funktioniert ja einwandfrei. Wofür nun eine Maßnahme auf Layer 1+2 (Optik <-> Elektronik + Ethernet), nämlich ein Reset des ONT, gut sein soll, weiß wohl nur der Support auf Layer 8. Oder anders: Läge dort das Problem, würde IPv4 auch nicht funktionieren. Aber ich lasse mich hier gerne eines Besseren belehren.

    ONT-Reset habe ich auch schon mal gemacht. Ging immer gut und war auch nie Ursache des Problems (hatte zeitweise auch schon IPv4 und/oder IPv6-Konnektivitätsausfälle - allerdings maximal nur für ein paar Stunden - inzwischen läuft mein Anschluss sehr stabil).

    Einmal editiert, zuletzt von ::1 (29. November 2024 um 22:02) aus folgendem Grund: Typos

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Technisch bin ich nicht so bewandert, von denn ganzem Analysen verstehe ich null.

    Aber habe schon 2 mal diesen Reset am Nokia ONT gemacht, nach Aufforderung durch DG Hotline. Beim 1. Mal wegen langsamem Internet, 2. Mal um meine Telefonnummern ans Laufen zu bringen.

    Telefon läuft seitdem und Internet ist auch ok, wie vorher bei DSL 300, schneller aber nicht. Downloads sind wie bei DSL zum Teil langsam, was ja meist an den Servern liegt.

  • Danke schon jetzt für eure Unterstützung. Anbei hab ich den WAN-Port mitschnitt. In diesen ist auch ein dhcpv6 rebind gefallen. Soweit ich das sehe ist die RA gut, die Router Lifetime sitzt auf 4500.


    Hier ist der FritzBox WAN Mitschnitt:

    Ein Grund für den DHCPv6 Lease-Timeout ist vermutlich, dass die bestehende Lease seitens DG nicht mehr zu verlängern war, weil dein Anschluss andere IPv6-Adressen bekommen sollte: Die neue WAN-Port-Adresse hat als letzte Ziffer anstelle einer 2 nun eine 7. Im LAN-Prefix hat sich eine Ziffer von 5 auf a geändert. In der Regel bekommt man an stabil funktionierenden Anschlüssen stets dieselben Adressen zugewiesen. Bei meinem Anschluss haben die sich bisher nur nach einer DG-Wartung einmal geändert.

    Wäre mal interessant zu beobachten, ob dein Router nach jedem Lease-Timeout mit anschließender Neuaushandlung einer Lease geänderte IPv6-Adressen bekommt.

    gordrin: Deinem Mitschnitt konnte ich eine Information entnehmen (keine Sorge: die vergesse ich auch wieder), die es mir ermöglicht, die aktuell deinem WAN-Port zugeordnete Adresse zu ermitteln und damit meine noch offene Frage selbst zu beantworten:

    Demnach weist DG deinem Anschluss eine DHCPv6-Lease (WAN-Adresse + /56-PD-Block für's LAN) mit der Leasedauer 1h zu, die aber per DHCPv6-Renew/Rebind nicht verlängert wird. Nach einer Stunde, also Ablauf der Leasedauer, bezieht die Fritzbox eine neue Lease und erhält dabei jedes Mal eine andere WAN-Port-Adresse (und ich gehe davon aus, auch einen anderen PD-Block). Das Ganze wiederholt sich jede Stunde (etwa um XX:09 Uhr) - müsste im Eventlog des Routers auch angezeigt werden.

    Meine Interpretation: DG schafft es nicht, für deinem Anschluss feste (oder sagen wir: "quasistatische", denn echt "fest" ist nicht garantiert) IPv6-Adressen (IA_NA, IA_PD) zu reservieren, geschweige denn, in der DG-Netzinfrastruktur für den jeweils zugewiesenen PD-Block bzw. die WAN-Port-Adresse eine (Rückwärts-)Route über deine WAN-Leitung zu deinem Router zu generieren.

    Ich nehme mal an, der vom DG-Support vorgeschlagene ONT-Reset hat nichts gebracht?

    Einmal editiert, zuletzt von ::1 (4. Dezember 2024 um 21:53)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Hallo danke für deine weitere Analyse. Ich hoffe und gehe davon aus, dass diese Information sowieso nichts bringen wird um mir Probleme zu bereiten, die Adresse ändert sich ja regelmäßig und offene Ports habe ich sowieso nicht.

    Wie du geschrieben hast, wird jede Stunde der Präfix erneuert.

    Ich habe aktuell den ONT Reset noch nicht gemacht, ich hatte noch keine Zeit gefunden. Ich melde mich sobald ich das gemacht habe und was das Egebnis war.

    FritzBox Log:

  • gordrin: In deiner aktuell vorliegenden Konstellation wird deinen LAN-Clients vorgegaukelt, sie könnten neben IPv4 auch vollwertig IPv6 nutzen. Dort, wo "Happy Eyeballs" nicht greift, wird sich ggf. eine schlechte User Experience einstellen, nämlich immer dann, wenn zunächst bevorzugt versucht wird, eine IPv6-Verbindung aufzubauen, um nach dem zwangsläufigen Scheitern dieses Versuchs es mit einer IPv4-Verbindung zu versuchen - Ergebnis: Eine als zu lang empfundene Aufrufdauer. Bezogen auf einen Webbrowser an einem Client kann man das Verhalten bzgl. "Happy Eyeballs" hier mal testen.

    Es wäre aktuell ggf. empfehlenswert, in der Fritzbox die IPv6-Unterstützung vorerst zu deaktivieren und sie von Zeit zu Zeit nur zu Testzwecken anzuschalten. um zu prüfen, ob das Problem auf DG-Seite denn nun gelöst wurde, bevor sie dann wieder dauerhaft aktiviert bleiben kann. Das aus meiner Sicht derzeit beste Testwerkzeug für IPv6 am Client: https://test-ipv6.com/

    Noch ein Nachtrag:

    Die eben erwähnte Testseite https://test-ipv6.com/ enthält oben rechts noch den schönen Link "Für den Helpdesk". Klickt man den, dann gelangt man auf eine Seite, auf der unten ein Link auf das Testergebnis angegeben ist. Den könntest du z.B. auch dem DG-Support zukommen lassen. Vielleicht hilft es ...

    Einmal editiert, zuletzt von ::1 (7. Dezember 2024 um 13:12) aus folgendem Grund: Nachtrag ergänzt