Beiträge von olifre

    olifre, Herzlichen Glückwunsch!

    Danke!

    Spannend, dass es in deinem Fall eine Antwort gab, dass immerhin (angeblich) ein Ping von außen versucht wurde.

    Habe eben die Tickets zum Schließen markiert bei mir, und dabei gesehen, dass das Ticket für einen der Anschlüsse noch ein Bearbeitsungsdatum von gestern bekommen hat — vielleicht war da also doch noch wer aktiv, müsste dann aber eine Weile nach dem Routing-Fix gewesen sein.

    Ich kann mich nicht erinnern, wer die WEB-Seite "icanhazip.com" angeboten hat, die Seite hat damals leeres Blatt gezeigt, jetzt zeigt aber die IPv4 Adresse - siehe Anhang. Ich weiß es nicht ob diese eine Änderung bei DG zeigt oder ist das reine Zufall.

    Ich würde auch vorschlagen, diese direkten Adressen zu nehmen für Tests, wie von DLMttH vorgeschlagen:

    Zur Erklärung: Diese Seiten lassen sich nur über das jeweilige Protokoll auflösen. Üblicherweise sollte beim Besuch der "generischen" Adresse ein "Standard-Setup" IPv6 bevorzugen und damit die v6-Adresse auftauchen, so kann man aber das System zwingen, es per IPv6 zu versuchen und keinen Fallback zu machen, selbst falls es dann z.B. einen Timeout geben sollte.

    Von meiner Seite aus gute Nachrichten: Heute ca. 15:52 Uhr fing an beiden Anschlüssen IPv6 an zu funktionieren!

    Keine Reaktion heute an den Tickets (eins pro Anschluss), und auch kein Update des letzten Bearbeitungszeitpunktes, das war also wohl ein "unkorreliertes" Reparieren des Routings. An beiden Anschlüssen wurde Nichts verändert, und seit dem Zeitpunkt wechselt auch nicht bis zu alle 30 Minuten der IPv6-Präfix, sondern bleibt stabil.

    Das weniger problematische DNS-Server-Problem an einem Anschluss (zweimal der gleiche DNS-Server zugeteilt) besteht weterhin, aber das ist ein anderes Thema.

    Wenn IPv6 bis morgen stabil bleibt, werde ich dann morgen die Tickets an beiden Anschlüssen schließen.

    Ein Netzbereich mehr scheint nun also repariert worden zu sein, hoffentlich nachhaltig :-).

    Am Nachbaranschluss weiterhin zweimal derselbe DNS, auch nach Neustart und Reconnect (da auch am Glas, auch 5690 Pro, aber schon vor gut einem Monat aktiviert). Als ob beim Aktivieren ein Config-Profil kopiert werden würde, was zu dem Zeitpunkt kaputt war?

    Kurzes Update: Das ist weiterhin der Fall, auch nach Reconnect. Klingt also sehr danach, dass das Config-Profil beim Aktivieren des Modems (in dem Fall einer 5690 Pro) kopiert wurde und nun bei der DG für die Modem-ID (oder die MAC) so hinterlegt ist.

    Das Ticket für den Anschluss wurde mit dem üblichen Standardtext "Unsere technische Abteilung hat Ihren Anschluss geprüft und keine Unstimmigkeiten gefunden." geschlossen (war offen seit 21.8.), habe es wieder geöffnet mit Hinweis auf Traceroute und Paketmitschnitt.

    Noch eine spannende Beobachtung: Wenn ich die Fritz!Box reconnecte, loggt auch am Nachbaranschluss die Box, dass die Internetverbindung erneuert wurde (bekommt die gleiche IPv4, keine merkliche Verbindungsunterbrechung, bekommt aber eine andere IPv6-WAN und -Präfix, was aber vermutlich Teil des Konfigurationsproblems im Anschlussbereich ist). Meine Vermutung wäre, dass beide Anschlüsse am gleichen GPON-Strang hängen und die Modems beim Reconnect eines Anschlusses die Zeitfenster wieder aushandeln und dabei alle am gleichen GPON-Strang ein neues DHCP-Paket bekommen, was die FB dann loggt.

    Das war mir auch aufgefallen. Ich entdeckte jedoch in einem anderen Forum bei ähnlichem Problem genau diesen Ratschlag. Hatte soeben wieder den ersten Video-Stop und habe mal NUR IPv6 probiert. Da geht garnichts...

    Was sagt denn eine IPv6-Testseite, wenn IPv6 "normal" (also nicht als 6to4) aktiv ist?

    Vielleicht ist das ja der nächste Fall, wo IPv6 am Anschluss nicht geht (Adressen zugeteilt werden aber kein Routing stattfindet):

    Zaphod
    14. Januar 2025 um 08:56

    Kleines Update:

    • Nach Wartezeit hat letzte Woche Freitag jemand angerufen und nach noch einer Kontakt-Rufnummer gefragt, und heute war ein Techniker vor Ort von dem Team, was hier auch angeschlossen hat.
    • Er hat das Problem meines Erachtens verstanden. Dann mal von "mit ONT" auf "Router am Glas" umgesteckt und konfiguriert. IPv6 wird weiterhin zugeteilt, aber nicht geroutet.
    • Leider kann er da persönlich erwartungsgemäß nichts machen und hat auch keinen Kontakt in die Technik, kann das Ticket "für sich" also nur als gelöst markieren und das "intern weitergeben". Hat er gemacht, leider ging damit das ganz Ticket auch bei mir zu, und ich sehe Nichts zur internen Weitergabe, nur "Störung behoben".
    • Habe per Ticketrückfrage kommuniziert, dass der Techniker das Problem als "liegt in der Infrastruktur, Routing geht nicht" bestätigt hat.

    Mal schauen, was jetzt passiert. Vielleicht hilft ja die interne Weitergabe, die ich nicht sehe, oder das Ticket geht endlich in die Netzwerkabteilung, auch wenn ich langsam wenig Hoffnung habe.

    Spannend in jedem Fall: Nach Aktivierung der 5690 Pro per Glas bekommt diese nun zwei verschiedene DNS-Server per DHCPv4 verteilt! Per ONT war es noch zweimal derselbe, am gleichen Anschluss.

    Am Nachbaranschluss weiterhin zweimal derselbe DNS, auch nach Neustart und Reconnect (da auch am Glas, auch 5690 Pro, aber schon vor gut einem Monat aktiviert). Als ob beim Aktivieren ein Config-Profil kopiert werden würde, was zu dem Zeitpunkt kaputt war?

    Diese Problemmeldung werde ich dann aber erst nach der IPv6-Problematik angehen.

    Bis einschließlich 5590 Fiber sollte es mit dem Aktivierungscode funktionieren. Die 5690 Pro wurde von der DG noch nicht integriert und man muss eventuell über den Support die Modem-ID angeben.

    Anfang August hat an einem meiner beiden Anschlüsse das Aktivieren einer 5690 Pro per Aktivierungscode problemlos funktioniert (derzeit aktuelles Fritz!OS 8.03 vorher eingespielt). Als ONT war vorher ein Genexis FiberTwist verbaut, die passive Deckplatte hatten die Techniker dagelassen, sodass ich selbstständig "umbauen" konnte.
    Am anderen Anschluss nutze ich noch das ONT, in der Hoffnung, dass DG dann bereitwilliger die noch bestehenden Probleme löst (aber das ist ein anderer Thread).

    Noch eine kleine Ergänzung: Auch ich bekomme an beiden Anschlüssen, wie auch in anderen Threads hier im Forum berichtet, übermittelt:

    DNS-Server: 185.22.44.50 und 185.22.44.50

    und sehe daher nur einen IPv4-DNS-Server in der Fritz!Box. Für IPv6 werden zwei DNS-Server übermittelt.

    Diese Sorte Konfigurationsfehler bei der DG scheint also leider auch kein Einzelfall zu sein. Ich nehme mir das mal auf meine Liste mit Dingen für Folge-Tickets, aber wohl besser nach Behebung der IPv6-Problematik.

    ::1 Vielen vielen Dank! Das ist eine sehr hilfreiche Liste.

    Ergänzend: Ich habe bereits einmal einen Wireshark-Screenshot hingeschickt, das war von einem Capture bei ONT-Neustart und laufendem `ping -6 heise.de` von einem Linux-Rechner aus. Da war auch nicht viel "Fremdverkehr" drin, Linux kann man ja recht gut ruhig halten ;-).

    Der wurde (augenscheinlich unbesehen) auch mit der CGNAT-Standardantwort zugemacht. Das eine Ticket des Anschlusses mit ONT dazwischen, was aktuell noch offen ist, hat besagtes pcap gezippt im Anhang.

    Die DNS-Requests schlagen auf jeden Fall auch fehl — das sieht man auch recht schön in der Fritz!Box, falls man da mal testweise auf "IPv6-only" oder "IPv6 first" stellt und die dann das VOIP-Gateway nicht mehr auflösen kann und auch die NTP-Server der DG nicht mehr erreicht, bis IPv4 wieder an ist.

    Habe mir die hilfreiche Kommandosammlung und den Anzeigefilter mal in ein Skript gepackt (geht ja fast genauso auch auf Linux), wenn das nächste Ticket zugeht, mache ich mal am Wochenende einen solchen pcap und hänge ihn gezippt an. Auch wenn ich den Eindruck habe, dass da nie jemand reinschaut — Hoffnung bewahren.

    Kurzes Update von heute:

    Für den Anschluss mit der 5690 Pro "am Glas" mit dem offenen Netz 4.0 Ticket wurde dieses heute mit der Standardantwort "Störung behoben, bei Problemen Router neustarten" geschlossen. Interessanterweise nach knapp einer Woche, wie auch davor. Neustart habe ich natürlich gemacht, auch wenn das bei fehlendem Routing dahinter nicht wirklich einen Effekt haben sollte, und hat natürlich Nichts verändert, Problem besteht weiterhin.

    Ticket per Rückfrage wieder geöffnet, erwähnt, dass IPv6 zugeteilt wird, aber kein Routing vom Kundenanschluss raus plus rein stattfindet. Traceroute angehangen.

    2 Minuten später: Ticket mit der bekannten Standardantwort geschlossen, dass man eine CGNAT-IPv4 und eine IPv6-Adresse per DHCP erhält, und falls das nciht klappt, den Router entsprechend konfigurieren soll.

    Erneut per Rückfrage geöffnet und auf Traceroute hingewiesen und darauf, dass das Problem beim Routing in der DG-Infrastruktur liegt und nicht der Adresszuteilung.

    Leider sehr frustrierend, aber ich bleibe weiter hartnäckig und freundlich. Das Ticket beim anderen Anschluss ist noch offen, aber das aktuelle Ticket dort ist auch erst unter 1 Woche alt.

    Leider noch keine Nachricht aus dem Support, aber eine spannende Beobachtung: Beide Anschlüsse hatten heute für einige Stunden die exakt gleiche WAN-IP zugewiesen. Mit Lease-Time immer 3600 Sekunden, und beide konnten die Adresse auch scheinbar problemlos verlängern. Und das Präfix wechselt weiterhin meist im 30-Minuten-Takt.

    Habe mal einen Anschluss reconnected, der hat jetzt wieder eine andere WAN-IP... was natürlich am fehlenden Routing Nichts getan hat, ist weiterhin im gleichen Netzbereich natürlicherweise.

    Immerhin sind meine Tickets weiterhin offen.

    Nur mal interessehalber: Liegt dein LAN-Präfix in einem der von mir gelisteten IPv6-Ranges?

    Falls nein, würdest du mir den Range bis zur 11. Stelle (2a00:6020:XYZ) verraten? Ich muss für Z nur wissen, ob <8 bzw. >=8.

    Gerne, das ist ja nicht sehr identifizierend, sind ja immer noch etliche Adressen in dem Bereich.

    2a00:6020:9cc

    bekomme ich als erste 11 Stellen des LAN-Präfixes zugeteilt. Scheint also noch nicht in der Liste zu sein.

    Ja, alle alten Inexio-Anschlüsse scheinen in Bezug auf IPv4 zum AS8899 zu gehören, während sie in Bezug auf IPv6 im AS60294 liegen. Die CGNAT-Adressen dieser Anschlüsse scheinen nach meinen Beobachtungen stets im Range "DGW-FTTH-DYNAMIC-FRA1" = 94.31.96.0/20 zu liegen.

    Ich hatte damals nach freundlicher Nachfrage noch / wieder eine globale IPv4 bekommen (VPN-Zugang von außen), da zu Vertragsstart noch kein CGNAT gemacht wurde, war man da wohl kulant. Die kam aus 5.100.128.0/22.

    Update heute:

    • Erneut Mailantwort plus Ticket zu, diesmal wieder mit der Info, ich sollte das ONT resetten. Nun aber Anleitung für den FiberTwist.
      Habe freundlich drauf hingewiesen, dass ich das gestern schon gemacht habe (und auch am 7.8. nach Anruf bei der Hotline), obwohl man mir die andere Anleitung geschickt hatte.
    • Habe nun mal ein Ticket als "technische Anfrage" aufgemacht mit Hinweis auf "Problem in der BNG-Konfiguration => kein Routing des Subnetzes", Paketmitschnitt vom WAN-Port als ZIP angehangen, Screenshot vom Heise-Traceroute angehangen. Und Bitte um Weiterleitung in die Technik.

    Ich habe wenig Hoffnung, dass sich da was tut, aber immerhin fällt es vielleicht dem First Level schwer, dazu eine Standardantwort auszuwählen. Wenn überhaupt, dann vielleicht wieder die CGNAT-IPv4-IPv6-Standardantwort.

    Ok - dann ist das Problem hier anders gelagert: Die DG-Infrastruktur routet deine IPv6-Adressen nicht. Hatten wir hier im Forum auch schon.

    Ja, das passt. Mein Problem scheint sehr analog zu:

    ::1
    16. Dezember 2024 um 13:43

    zu sein, alle Traceroutes von außen stoppen bei:

    Code
    [...]
     8  as60294.dusseldorf.megaport.com (2001:7f8:8::eb86:0:1) [*]  6.556 ms * *
     9  2a00:6020:0:b::2 (2a00:6020:0:b::2) [AS8899/AS60294]  7.067 ms 2a00:6020:0:a::2 (2a00:6020:0:a::2) [AS8899/AS60294]  6.586 ms 2a00:6020:0:b::2 (2a00:6020:0:b::2) [AS8899/AS60294]  7.023 ms
    10  * * *

    Die kommen also nicht durch zum BNG. Von Innen sehe ich gar keine Hops nach der Fritz!Box.

    Als ich noch parallel den DSL-Anschluss bei meinem Vorgängerprovider Inexio hatte, der ja inzwischen auch zur DG gehört, endeten Traces von dort zu meinem DG-Anschluss auch bei fc00::1.

    Leider war in dem Thread die Lösung aller Threadteilnehmer ja effektiv "warten", aber ich werde hartnäckig dran bleiben, vielleicht hilft es was.

    Wäre es evtl. nicht erst mal naheliegender nachzuweisen, dass IPv6 outbound ebenfalls nicht funktioniert?

    Möglicherweise hat das ja in deinem Fall dieselben Ursachen, die ich in #381 beschrieben habe. Falls so, wäre es aus meiner Sicht viel effizienter, die eigentliche Ursache des Problems konkret zu benennen: Nämlich, dass die Hardware-Adressauflösung für IPv6 (per NS/NA) outbound nicht funktioniert, weil die DG-Gegenstelle die von deinem Router gesendeten NS nicht per NA beantwortet.

    Ja, das stimmt natürlich. Meine Annahme war, dass "ping von außen geht nicht" einfacher zu reproduzieren ist, damit das Problem als Solches akzeptiert und in die Technik weitergereicht wird.

    Freilich müsste man das für deinen Fall erst Mal durch einen Paketmitschnitt am WAN-Port verifizieren - möglicherweise liegen deinem Problem ja doch andere Ursachen zugrunde, als dem von Luki .

    Den habe ich schon gemacht, und an ein älteres Ticket bei DG als Wireshark-Screenshot angehangen (und daraufhin die Standardantwort bekommen, dass IPv4 mit CGNAT und echte IPv6 zugeteilt würde, also nicht passend zur Anfrage).

    Da ich das noch nicht im Forum geteilt hatte, bei mir sieht man im WAN-Port-Mitschnitt (synchron zu einem ONT-Neustart durchgeführt):

    • DHCPv6 Solicit und Reply
    • Daraufhin Multicast-Listener-Reports der Fritz!Box an die Gegenstelle
    • Ein Router-Advertisement der Gegenstelle
    • Outbound IPv6-Traffic der Box z.B. zu IPv6-NTP-Servern, von einem Ping auf `heise.de` den ich gemacht habe etc.

    Der Outbound IPv6-Traffic geht korrekt zur MAC der Gegenstelle, die sich als Router announced hat. Es kommt nur Nichts zurück, und dann sieht man Retransmits.

    Schließlich schickt die Box einigte NS an die Gegenstelle, und nach dem fünften NS bekommt sie dann auch einen NA von der Gegenstelle zurück.

    Bei mir ist das Problem also nicht NA/NS, sondern hier scheint es tatsächlich so zu sein, dass die Pakete hinter der Gegenstelle irgendwo verloren gehen.

    [...] Ob jemand den Text oder die PDF-Datei gelesen oder womöglich sogar verstanden hat, vermag ich nicht zu sagen.

    Bei meinen Telefonie-Tickets habe ich auch mal einen Screenshot des Kundenportals mitgeschickt und geschrieben, "im Kundenportal (siehe Anhang) sind keine Rufnummern sichtbar". Da eine Standardantwort zurückkam, wie man im Kundenportal an die Stelle kommt, wo ich den Screenshot gemacht habe, weiß ich, dass der Anhang nicht angeschaut wurde...


    Zurück zum Thema: Heute wurde mein schriftliches Ticket geschlossen, Anleitung zum ONT-Reset kam zurück (für die Nokia-Modelle, hier ist ein FiberTwist verbaut).

    Habe den Reset natürlich brav gemacht, drauf hingewiesen, dass man mir das schonmal empfohlen hat und ich das schonmal gemacht habe, und dass das Problem weiterhin besteht, also ping und traceroute auf die IPv6 von außen nicht gehen. Man hat auch nach der Modem-GPON-SN gefragt, habe ich geschickt.

    Sobald wieder etwas mit "Technik hat geprüft, alles ok" geschlossen wird, mache ich auch mal ein PDF, bin aber in der Tat auch skeptisch, dass es gelesen wird.

    müsste als komprimierte ZIP-Datei schon möglich sein.

    Oh! Ich hatte übersehen, dass auch ZIP im Kontaktformular geht...

    Das ist dann was als Follow-Up für das nächste Ticket, was zugemacht wird, danke für den Hinweis :-). Bin gespannt, ob das hilft, ein Wireshark-Screenshot wurde bei meinem letzten Versuch leider kommentarlos ignoriert.

    olifre, bist Du auch in NRW und auch noch in der Nähe von 47906 Kempen? Ich auch habe das Problem noch nicht gelöst bekommen, trotz die tägliche oder zweitägigen Telefonate mit Kundendienst.

    In RLP, aber ganz im Norden, ich kann recht schnell zu Fuß nach NRW laufen. Ist aber eine 53xxx PLZ. Recht neues Anschlussgebiet, es werden auch noch weitere Hausanschlüsse aktiviert, und ich merke, wie die letzte Stelle der IPv6-Adresse, die dem Router zugeteilt wird, bei Neuverbinden manchmal wächst.

    Update heute: Wieder wurde ein Ticket geschlossen, das "technische Anfrage"-Ticket, mit "Unsere technische Abteilung hat Ihren Anschluss geprüft und keine Unstimmigkeiten gefunden.". Ich habe diesmal mal per Mail mit einem Traceroute und der Info, dass Pings nicht durchgehen, geantwortet, das geht ja in Textform (Packet Captures kann man ja nicht anhängen).

    Das hatte ich schonmal versucht und da nur den Standardtext bekommen, dass es IPv4 per CGNAT und echte IPv6 gibt, also nicht so ganz mit meiner Frage korreliert.

    Kurzes Update meinerseits:

    Telefonie geht nun an unseren beiden Anschlüssen, an einem nach Ticket und ca. 5 Tagen warten, am anderen Anschluss erst nach Portierungstag vom Altanbieter (Ticket hing vorher ca. 1 Woche ab). Die Übergangsrufnummer ging nie. Einen Tag nach der Portierung tauchte die Nummer dann auch im Kundenportal auf.

    Zurück zum Hauptthema:

    • Beim Anschluss mit FB 5690 Pro hinter FiberTwist ist das IPv6-Problemticket noch offen (als "technische Anfrage" vom Telefonsupport aufgenommen). Das Ticket hatte ich durch Anruf eröffnen lassen, nachdem das letzte Ticket davor (Netz 4.0) vor einer Woche kommentarlos geschlossen wurde, und meine selbst eröffneten Tickets davor nur Standardantworten bekommen haben.
    • Beim Anschluss mit FB 5690 Pro direkt am Glas hieß das letzte IPv6 Problemticket auch Netz 4.0. Wurde heute Nachmittag kommentarlos (ohne Mail oder so) geschlossen. Grau im Kundenportal, also nicht einsehbar. Angerufen, scheinbar stand da nur dran, dass es wieder ginge. Neues Ticket eröffnet, heißt auch Netz 4.0.

    Immerhin ist der Telefonsupport bisher (bis auf eine Ausnahme, die sehr unfreundlich war) sehr freundlich, kann aber solche Probleme natürlich nur aufnehmen. Einen Rückruf von einem Techniker oder so habe ich leider noch nicht erhalten.

    Ich bleibe also auch hartnäckig, aber freundlich. Die Fritz!Box habe ich so konfiguriert, dass IPv6 weiterhin an ist, aber intern Router Advertisements und DHCPv6 aus. Damit ist die Box theoretisch von außen per IPv6 pingbar, sobald das Problem gelöst ist, und die Clients im Hausnetz haben keine Probleme, weil sie nichts vom IPv6-Präfix wissen.