Danke für die TXT-Datei!
Muss ich erst mal analysieren, um Muster zu erkennen.
Eine Zeile sticht aber hervor: "Internetverbindung IPv6: AFTR konnte nicht bezogen werden: Grund 7 (got no aftr)"
Wie sieht denn die IPv6-Konfiguration in deiner FB aus?
Du solltest am DG-Anschluss _nicht_ "DS-Lite" konfiguriert haben!
Idealerweise sollte "Native IPv4-Anbindung verwenden" konfiguriert sein.
Ja, IPv6 funktioniert nach Zuweisung eines Präfix eine Weile, danach dann aber nicht mehr - bis wieder eine neues Präfix zugewiesen wird. Das Log zeigt auch Lease-Timeouts, es gibt also gelegentlich Probleme, eine Lease zu verlängern. Stattdessen weist DG einfach ein neues zu, dass dann wieder eine Weile funktioniert.
Kritisch wird es dann (schlechte "User experience" bei dir), wenn dein Router das letzte zugewiesene Präfix im LAN noch propagiert, dieses im DG-Backend (vermutlich) aber nicht mehr geroutet wird. Das sind die Phasen, wo der Dauerping in deinem Test vorhin keine Antworten geliefert hat.
Und das hier ist auch witzig:
"Internetverbindung wurde erfolgreich erneuert. IP-Adresse: 100.102.133.109, DNS-Server: 185.22.44.50 und 185.22.44.50, Gateway: 100.102.128.1"
Der DHCP-Server weist zweimal 185.22.44.50 als DNS-Server zu. Sollte eigentlich so aussehen: "DNS-Server: 185.22.44.50 und 185.22.45.50"
Auch deine IPv4-Adresse wechselt recht oft - sollte eigentlich auch über sehr lange Zeiträume konstant sein.
Vorschlag:
Deaktiviere vorerst IPv6 in der Fritzbox für ein paar Tage. Beobachte, ob wenigstens IPv4 konstant/stabil läuft - inklusive guter Performance beim Laden von Websites etc. Bei IPv4 zeigt die FB in der Ereignisanzeige auch die Leaseverlängerungen der IPv4-Adresse etwa 2x am Tag an. Wäre interessant, ob die IPv4-Adresse dabei konstant bleibt oder sich auch regelmäßig ändert - dies aber nur nebenbei.
Danach könnte man IPv6 wieder aktivieren, um einen geeigneten Paketmitschnitt am WAN-Port der FB durchzuführen, der das IPv6-Fehlverhalten mitschneidet. Wenn du willst kann ich dich dabei unterstützen (muss mir noch überlegen, wie man das "am dümmsten" macht), so dass du der DG in einem Ticket das Problem auch technisch fundiert nachweisen kannst. Dann wärst du in jedem Fall auf der sicheren Seite - auch wenn im DG-Support erst mal keiner Paketmitschnitte lesen kann und du vermutlich 10 Tickets aufmachen musst, bis dir evtl. geholfen wird.
Ich habe das Eventlog der FRITZ!Box (im folgenden "FB") (siehe #37) nun mal analysiert:
Es erstreckt sich über den Zeitraum 26.05.2025 20:49:23 - 01.07.25 17:21:37 und zerfällt in Abschnitte, die jeweils durch ein manuelles Neuverbinden in der FB (Internet | Online-Monitor | TAB "Verbindungsdetails" | Schaltfläche "Neu verbinden") ausgelöst wurden. Dies ist im Eventlog daran erkennbar, dass die beiden Ereignisse ...
... im Abstand von nur wenigen Sekunden auftreten - es werden also stets sowohl IPv4-WAN-Adresse als auch IPv6-Adressen (WAN-Adresse und PD-Präfix) neu bezogen.
Abgesehen von irrelevanten Abschnitten, in denen experimentiert wurde (DS-Lite/AFTR, 6to4, "Globale Adresse aus dem zugewiesenen Präfix ableiten"), gibt es bezogen auf IPv6 zwei spezifische Abschnittstypen mit unterschiedlichen Charakteristika:
Die Lease-Timeouts des Abschitt-Typs 1 tauchen regelmäßig jede Stunde auf, weil dann jeweils die Leasedauer abläuft. DHCPv6-Renews und -Rebinds scheiterten also in dieser Phase. Immerhin wurden aber im Rahmen eines sich anschließenden neuen DHCPv6-Exchanges dieselben IPv6-Adressen (WAN-Adresse und PD-Präfix) zugewiesen.
Das änderte sich nach Ende des ersten Abschnitts dann wie folgt:
Alle folgenden Abschnitte (ab 27.05.2025 12:57:50) sind jetzt nur noch vom Typ 2. Gelegentlich treten auch innerhalb eines solchen Abschnitts DHCPv6 Lease-Timeouts auf, die (im Unterschied zu Abschnitt 1) auch jeweils geänderte IPv6-Adressen (WAN-Adresse und PD-Präfix) nach sich ziehen (Abschnitte 27.05.2025 12:57:50 - 27.05.2025 14:28:05, 28.05.2025 07:15:38 - 31.05.2025 22:47:54, 08.06.2025 13:28:46 - 08.06.2025 17:29:04). Gelegentlich tritt auch der Fehler "IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4001 (server failure: requested IA_PD not provided)" auf, der aber nur eine kurze Verzögerung bis zum Bezug eines PD-Präfix bewirkt.
Man könnte jetzt vermuten, dass DG mit diesem neuen "Konzept" möglicherweise versucht, von quasi-statischen IPv6-Adressen für Privatanschlüsse wegzukommen, um echte statische Adressen den Business-Anschlüssen vorzubehalten.
Es ist aus meiner Sicht aber keine gute Idee, einen PD-Präfix "unter Tage" zu tauschen, indem man den altem Präfix entzieht und einen neuen zuweist - das ist der Tod für jede bestehende Netzverbindung (insbesondere TCP-Verbindungen), der Anwender wird das als Netzwerkunterbrechung wahrnehmen.
Ich gehe also davon aus, dass die hohe "IPv6-Dynamik" ein Indiz für eine Fehlkonfiguration bei DG darstellt.
Zudem scheint es so zu sein, dass ein gerade neu zugewiesenen PD-Präfix nur eine begrenzt lange Zeit (lt. Anwenderangabe etwa 20-30 Minuten) im DG-Backend tatsächlich auch geroutet wird. Das bedeutet, dass bis zur nächsten Zuweisung eines (geänderten) PD-Präfix das bestehende Präfix im Kundennetz zwar noch announced wird, aber längst schon nicht mehr funktioniert - das ist ziemlich tödlich für eine "IPv6 User Experience".
Eine Validierung dieser These erfordert allerdings einen Paket-Mitschnitt am WAN-Port der FB (während eines Dauerpings auf eine IPv6-Adresse im Internet). Der wäre auch sehr aufschlussreich für die Analyse, wie genau der PD-Präfixwechsel erfolgt und wie lange das neue Präfix bei DG auch geroutet wird.
Ergänzung:
Die nach Anwender-Beobachtung ausbleibende IPv6-Erreichbarkeit des Internets (keine IPv6-Ping-Antworten) kann evtl. auch dadurch begründet werden, dass zwar mit Neuzuweisung eines PD-Präfix für kurze Zeit auch gültige Router-Advertisements (RA) mit einer Router-Lifetime von 1800s gesendet werden, danach jedoch nicht mehr, so dass die IPv6-Defaultroute nach einem Timeout von 30 Minuten ungültig wird. Oder es werden nach einer Weile fehlkonfigurierte unsolicited RA mit einer Router-Lifetime=0 gesendet, die die IPv6-Defaultroute sofort ungültig werden lassen. Auch derlei würde man nur in einem Paketmitschnitt sehen können.
Die Verbindung wird nicht getrennt, sondern das DHCP-Lease für deine IPv4-Aresse erneuert.
Immer noch verblüffen mich die zugewiesenen DNS-Server. Dies sollten die folgenden sein:
DNS-Server: 185.22.44.50 und 185.22.45.50Meine Verbindung wird alle 12 Std getrennt.
Die Meldungen sind harmlos, sie bedeuten lediglich, dass deine DHCPv4-Leasedauer wieder auf den Maximalwert (3600s) verlängert wird. Das passiert alle 30 Minuten, die FB loggt das allerdings nur alle 12 Stunden - warum, weiß nur AVM.
Immer noch verblüffen mich die zugewiesenen DNS-Server. Dies sollten die folgenden sein:
Ein weiteres Indiz einer DG-seitig fehlerhaften Konfiguration des Kundenzugangs.
Nach Deaktivierung von Ipv6 habe ich jetzt keine Probleme mehr, dass Internet läuft einwandfrei
Genau das war erwartbar. IPv4 ist ok. IPv6 ist kaputt. Wird nicht einfach, das der DG zu verklickern.
Die DHCP-Konfig ist auch nicht in Ordnung (wegen der fehlerhaften Übermittlung der DNS-Server). An deinem Anschluss/Port/Account/Profil ist von Seite des Providers ganz schön herumgespielt worden...
Du musst/solltest ein Ticket wegen Fehlkonfiguration deines Anschlusses via Portal öffnen und sobald es vom Support geschlossen wurde (und die Problematik noch besteht) mit "Nachfrage zu Ticket #..." Im Portal wieder öffnen. Leider sehe ich keinen anderen Weg als diesen, damit irgendwann eine kündige Person sich deines Falles annimmt.
Wenn du möchtest, kannst du einen Paketmitschnitt machen, der die technischen Probleme ziemlich genau nachweisen könnte. Ich würde dir eine entsprechende Anleitung für eine geeignete Vorgehensweise schreiben, andernfalls erspare ich mir das.
hab DG jetzt eine Nachricht geschrieben, vermutlich wird ein Router reset verlangt wie die andern 10 male auch
Na, dann gehst Du halt darauf ein und teilst mit, dass Du diesen vorgenommen hast und das Problem damit nicht behoben wurde. Bestehe auf einer Lösung dieser Anschlussstörung durch Deutsche Glasfaser.
der die technischen Probleme ziemlich genau nachweisen könnte
Das ist bei DG leider nicht das Problem.
habe ich schon geschrieben, dann sollte ich einen Speedtest machen der natürlich in Ordnung war und somit war die sache bei denen durch
Du musst beharrlich bleiben!
"Nachfrage zu Ticket #..." hält die Störungsmeldung offen!
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
