Es bleibt nur zu hoffen, dass 6x Bahnhof zumindest für eine Eskalation reicht.
Bahnhof wird heutzutage im 1st Level gezielt ausgefiltert.
Niemals technisch werden, immer "Anwendung X funktioniert nicht, bei der Telekom geht alles" und dann immer schön dumm stellen.
Bisher keine weitere Antwort vom Support. Heute ist das Problem mal wieder aufgetreten. Habe erneut Screenshot vom Packet Capture an den Support geschickt.
Heute ist das Problem mal wieder aufgetreten.
Ich bin mir inzwischen nicht so sicher, ob der sporadische Wechsel von IPv6-Adressen an den neueren DG-Anschlüssen wirklich als ein immanentes "Feature" oder eher doch als ein Indikator für eine Fehlkonfiguration des BNG für den jeweiligen Kunden-Port zu bewerten ist.
Ich beobachte diesbezüglich schon eine Weile das Verhalten einiger DG-Anschlüsse mit RIPE-Atlas-Probe - da gibt es z.B. vier Anschlüsse, bei denen sich die IPv6-Adressen seit Mitte/Ende 08/26 nicht mehr geändert haben:
Nur ein Anschluss fällt negativ auf mit häufigem Wechsel der IPv6-Adressen: #1001325 (LAN-Prefix aus 2a00:6020:c700::/41).
Zu deinem LAN-Prefix aus 2a00:61e0:9d00::/41 gibt es bisher keine Anschlüsse mit Atlas-Probe.
Kriterien für die Identifikation neuerer DG-Anschlüsse:
Ich glaube, dass der Wechsel des Präfixes bei diesen Anschlüssen im RIPE-Atlas darauf zurückzuführen sind, dass die Fritz Box im unterschied zu odhcp6c bei dem REQUEST nach NoBinding nicht das ursprüngliche Präfix anfragt. Bei meinem Anschluss ist jetzt das /48 Präfix komplett stabil und ändert sich nicht. Lediglich IA_NA ändert, aber ausschließlich wenn ich zu viel selber rumprobiere und mal einen RELEASE sende. Bei dem normalen NoBinding -> REQUEST verhalten bleiben sowohl IA_NA und IA_PD stabil.
Update zum Support: Heute haben die mir geschrieben, dass sie ein Update auf meinem "Modem" (ich denke die meinen ONT) machen. Meinem Verständnis nach kann dies nichts bringen, da der ONT ein reines Layer 2 Gerät ist und Layer 2 hat ja keine Probleme (ipv4 läuft während den Störungen ohne Probleme weiter).
Aber ich warte mal ab, wer weiß was für Wechselwirkungen es da vielleicht gibt.
Ich bin mir inzwischen nicht so sicher, ob der sporadische Wechsel von IPv6-Adressen an den neueren DG-Anschlüssen wirklich als ein immanentes "Feature" oder eher doch als ein Indikator für eine Fehlkonfiguration des BNG für den jeweiligen Kunden-Port zu bewerten ist.
Ich beobachte diesbezüglich schon eine Weile das Verhalten einiger DG-Anschlüsse mit RIPE-Atlas-Probe - da gibt es z.B. vier Anschlüsse, bei denen sich die IPv6-Adressen seit Mitte/Ende 08/26 nicht mehr geändert haben:
- #29306: LAN-Prefix aus 2a00:6020:5380::/41
- #53014: LAN-Prefix aus 2a00:6020:7300::/41
- #60825: LAN-Prefix aus 2a00:6020:6700::/41 (LAN-Prefix hier aber nur ein /64 statt /56!)
- #1014833: LAN-Prefix aus 2a00:6020:9800::/41
Nur ein Anschluss fällt negativ auf mit häufigem Wechsel der IPv6-Adressen: #1001325 (LAN-Prefix aus 2a00:6020:c700::/41).
Sorry, den Teil hatte ich nicht korrekt gelesen zuerst. Bei den meisten dieser Anschlüsse ändert sich das Präfix also nicht mehr. Vielleicht gab es ein Fritz Box Update, welches das Verhalten nach NoBinding geändert hat, oder DG hat tatsächlich etwas geändert. Wie gesagt, mein Präfix ändert sich seit dem ich odhcp6c mit dem korrekten NoBinding Verhalten nutze auch nicht mehr. Trotzdem ist alle paar Tage für 0 bis 30 Minuten kein ipv6 Traffic möglich.
Zu deinem LAN-Prefix aus 2a00:61e0:9d00::/41 gibt es bisher keine Anschlüsse mit Atlas-Probe.
Kriterien für die Identifikation neuerer DG-Anschlüsse:
- Die ASN zu IPv4 ist stets 60294 (anstelle 8899)
Ja, AS60294 bei meiner IPv4.
- Die WAN-Interface-Adresse des Kunden-Routers (ermittelt aus Traceroutes von außen) liegt immer im ersten /112-Block des jeweiligen /41-PD-LAN-Block (jedenfalls nicht in 2a00:6020:1000::/48, wie bei älteren DG-Anschlüssen)
Ja, bei mir aktuell 2a00:61e0:9d00::164/128
- Das BNG taucht in Traceroutes (wenn überhaupt) stets mit der Adresse fc00::1 auf.
Bei mir ist er gar nicht im traceroute (sowohl raus als auch rein geprüft).
Vielleicht gab es ein Fritz Box Update, welches das Verhalten nach NoBinding geändert hat, oder DG hat tatsächlich etwas geändert.
Ja, die vier gelisteten DG-Anschlüsse mit aktuell schon länger stabilen IPv6-Adressen verwenden alle Fritzboxen als Home-Router (ermittelt aus verfügbaren IPv6-Outbound-Traceroutes).
Der auffällige Anschluss mit Probe #1001325 hat hingegen einen Router am Laufen, dessen OUI "00:10:18" auf "Broadcom" verweist - unklar, was das genau ist.
Heute wurde der ONT geupdated. Es gab einen sehr freundlichen Anruf von DG. Ich solle das jetzt die nächsten Tage beobachten und DG meldet sich Montag wieder.
In meinen Logs sehe ich, dass der Link vom WAN Port zum ONT um 12:56:07 CEST bis 12:56:32 CEST down war. Hinterher habe ich wieder das selbe IA_NA und IA_PD bekommen.
Heute wurde der ONT geupdated.
Was muss man sich darunter vorstellen? Firmware-Update? Physischer Tausch vor Ort? Oder nur ein Reset?
Was muss man sich darunter vorstellen? Firmware-Update? Physischer Tausch vor Ort? Oder nur ein Reset?
Laut DG: Firmware-Update. Haben die aus der Ferne veranlasst. Aus meiner Perspektive hatte ich halt zum ONT für ca. 25 Sekunden kein Link. Ob tatsächlich die Firmware jetzt anders ist oder ob es nur ein Reset war kann ich nicht feststellen.
Jetzt habe ich gerade mal reingeschaut und..... es gab wieder einen IPv6 Ausfall. Heute um 7:54. Hat also nichts gebracht. War ja eigentlich auch zu erwarten, denn der ONT ist ja in Layer 2.
Update vom Support: Gestern sollte ich nochmal die Packet Captures auf denen die Störung zu sehen ist an DG senden. Habe also nochmal die aktuellste Störung (nach dem ONT Update) hergenommen, und die pcap als PDF exportiert (.pcap ist leider im Kundenportal Upload nicht erlaubt) und ein bisschen erläutert und 3 verschiedene Filter gemacht. Ist im Anhang, falls das jemanden interessiert.
Das wurde jetzt an die Netzwerkabteilung weitergeleitet.
Wo ich jetzt nochmal hier darüberschaue fällt mir noch etwas interessantes auf. Ich überprüfe das mal und berichte gleich.
Wo ich jetzt nochmal hier darüberschaue fällt mir noch etwas interessantes auf. Ich überprüfe das mal und berichte gleich.
Was ich dachte gesehen zu haben stimmte nicht. Ich dachte erkannt zu haben, dass das letzte Paket vor dem Ausfall immer ein Neighbor Advertisement von meinem Router an fe80::22 als Antwort auf eine Neighbor Solicitation ist. Das wäre ein interessantes Muster, aber stimmt nicht. Das war nur Zufall bei den letzten beiden.
Gestern sollte ich nochmal die Packet Captures auf denen die Störung zu sehen ist an DG senden.
Das wurde jetzt an die Netzwerkabteilung weitergeleitet.
Wenn das nicht nur Nebelkerzen sind, wäre es tatsächlich eine enorme Verbesserung der Service-Qualität der DG - von aktiver Anforderung von Packet-Captures seitens DG konnte nach meinem Kenntnisstand hier im Forum noch niemand berichten.
.pcap ist leider im Kundenportal Upload nicht erlaubt
Wird denn eine .zip-Datei angenommen?
Wird denn eine .zip-Datei angenommen?
Hier Zitat aus dem Kundenportal:
Max. 5 MB insgesamt. Zulässige Dateitypen: TIFF, JPG, JPEG, GIF, WEBP, PNG, HEIC, TXT, RTF, PDF, DOC, PAGES, ODT, DOCX
Wenn das nicht nur Nebelkerzen sind, wäre es tatsächlich eine enorme Verbesserung der Service-Qualität der DG - von aktiver Anforderung von Packet-Captures seitens DG konnte nach meinem Kenntnisstand hier im Forum noch niemand berichten.
Ich bin mit dem Support bei diesem Ticket bisher sehr zufrieden und positiv überrascht. Ich habe dieses Ticket über den Messenger im Kundenportal eröffnet und dort direkt Screenshots von Packet Captures beigefügt (im Gegensatz zum ersten Ticket, bei dem es um das nicht funktionierende IPv6-Routing für das IA_PD ging und das ich telefonisch eröffnet hatte).
Die Mitarbeiterin im Kundenservice, die dieses Ticket betreut, wirkt sehr kompetent und daran interessiert, eine Lösung zu finden. Außerdem erhalte ich schnell Antworten auf meine Nachrichten (tagsüber schätzungsweise innerhalb von ca. 30 Minuten, abends dann eben am nächsten Tag). Darüber hinaus wurde ich von ihr direkt angerufen, um mich über das Update des ONT und die anschließenden weiteren Schritte zu informieren.
Vielleicht habe ich einfach die beste Mitarbeiterin im Serviceteam erwischt. Man darf ja auch mal Glück haben!
Bisher gab es noch kein Update, aber möglicherweise wurde das Problem behoben. Es ist jetzt 7 Tage her, dass es das letzte Mal passiert ist.
Hier die Zeitpunkte der letzten paar Störungen:
Das Problem wurde am 09.10 an die Netzerkabteilung weitergeleitet. Könnte also sein, dass sie es gelöst haben und noch ein bisschen abwarten, bevor sie es als gelöst markieren, aber vielleicht freue ich mich auch einfach zu früh, kann einfach Zufall sein.
Nochmal in meine Logs geschaut und das Letzte Mal, dass Neighbor Solicitations von meinem Router an fe80::22 gescheitert sind war am 14.10 um 11:37:16.
Falls du noch einen /48 PD-LAN-Prefix ziehen kann, halte ich die DG-seitige Konfiguration für fehlerhaft. Erst, wenn du nur noch einen regulären /56 bekommst, hat da jemand hin gelangt.
Es ist immer noch /48....
Aber ich vermute, dass das Verhalten des DHCPv6 Servers nur ein Symptom ist und nicht die Ursache. Deswegen kann es durchaus sein, dass sie das Problem lösen ohne etwas an der Konfiguration des DHCPv6 Servers zu ändern. Vielleicht ändern sie die DHCPv6 Konfiguration auch später.
Ist tatsächlich noch nicht gelöst. Gerade von 22:58:59 bis 23:13:23 war IPv6 wieder kaputt.
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
