Deutsche Glasfaser plötzlich kein Internet mehr

  • Es war halt schwierig mit dir zu arbeiten.

    Phasenweise war IPv4 auf jeden Fall in Ordnung und ich vermute weiterhin, dass die IPv6-Kommunikation zur Störung führte.

    Sorry, ich bin kein IT-Experte.
    Wenn das so wäre würde ich hier nicht um Hilfe bitten.
    Trotz IPv4 und mit deaktivierten IPv6 ließen sich keine Webseiten aufrufen.

  • Ja, weil das Endgerät dies immer noch fälschlich annahm.

    Du hast doch den curl Aufruf gesehen. Das war erfolgreich.

    Aber der Fehler lag natürlich am Provider, da gibt es für mich keine Diskussion.

    Das waren aber erstmal Basics, um das Problem etwas greifbarer zu machen.

  • Für mich stellt sich es so da, dass zwar eine IPv4/IPv6 bezogen wurde, aber Serverseitig die Gegenseite nicht antwortete.

    Wie gesagt, in den Tests, die du hier gezeigt hast, hat die Gegenseite geantwortet. Wir können uns hier halt nur auf das beziehen, dass sich aus den Ergebnissen der Tests belastbar ablesen lässt. Und da ist deutlich zu sehen, dass die Namensauflösung funktioniert hat, die Traces haben das Ziel erreicht und die HTTP Verbindungen wurden erfolgreich aufgebaut. Damit ist alles vorhanden, was man auch fürs Surfen braucht.

    Was darüber hinaus auffiel, dass IPv6 vom Endgerät nicht mal die Box erreicht hat. Wenn es ein IPv6 Problem beim Provider gibt, dann funktioniert zumindest der erste Hop zum Router, meistens auch noch ein oder zwei Hops danach. Irgendwo in den Routern des Providers ist dann Schluss. Du hattest ein gültiges Prefix vom Provider, das zeigten deine Screenshots, die du inzwischen gelöscht hast. Da du ein Prefix hattest, hatte dein Endgerät auch eine gültige Adresse, zumindest, wenn Box und Endgerät korrekt eingestellt waren. Der Trace hätte mindestens die Box erreichen müssen.

    Was IPv6 natürlich gründlich stören kann, ist VPN Software. Die hast du ja definitiv im Einsatz, und wenn die die IPv6 Routen abräumt, dann erreicht ein IPv6 Paket auch den Router nicht mehr. Das machen die üblicherweise, um zu verhindern, dass die Pakete per IPv6 am VPN vorbeifließen.

    Das VPN hat aber grundsätzlich funktioniert, wie man an deinem ersten Trace sehen konnte. Da sind die Daten über den VPN Anbieter geflossen. Bis zum Ziel, also hat auch da alles funktioniert.

    Dazu kommen die Screenshots aus deiner Fritzbox. Du hattest gültige IPv4 und IPv6 Adressen vom Provider. In der Zeit, wo dein Internet angeblich nicht funktioniert hat, sind gigabyteweise Daten übertragen worden. Das lässt sich auch nicht mit Surfen oder den Traces erklären, das waren Streams oder Datenübertragungen, von deiner Kamera, wie du schreibst, was bei der Verteilung von Sende- und Empfangsdatenmenge plausibel klingt. Aber wie ist die ins Internet gekommen? Wie? Gibt es dafür eine einigermaßen sinnvolle Erklärung? Eins ist sicher: die Kamera hat kein VPN genutzt.

    Sorry, aber nach allem, was du hier im Thread präsentiert hast, spricht nichts, aber auch wirklich gar nichts für eine Störung des Providers. Dafür taucht plötzlich diese Mail auf, und du fängst an, Beiträge zu löschen. Und da kann pufferueberlauf noch so oft schreiben, dass für ihn die Situation klar ist. Warum das so ist, hat er nicht geschrieben,und das dürfte selbst für ihn schwierig werden, das auf Basis der bekannten Daten technisch zu begründen.

    Einmal editiert, zuletzt von frank_m (23. Mai 2026 um 00:00)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Warum das so ist, hat er nicht geschrieben,und das dürfte selbst für ihn schwierig werden, das auf Basis der bekannten Daten technisch zu begründen.

    Easy, weil ich von Fall zu Fall schaue was die Indizien hergeben, und nicht schon vorher weiss, auf welcher Seite es im Argen liegt. Und hier tauchten die Probleme halt ohne Endkundenintervention auf und verschwanden auch wieder auf diese Art und Weise und der ISP hat die Verantwortung uebernommen. Der Drops ist fuer mich gelutscht. Aber hey, glaub ruhig weiter an eine Verschwoeung, ich bin dann mal raus hier, der OP ist wieder im Netz (unklar was wir dazu beigetragen haben) und damit dieser Thread auch eigentlich an einem natuerlichen Ende.

    Einmal editiert, zuletzt von pufferueberlauf (23. Mai 2026 um 06:03)

  • Klar, mit der Einstellung macht man es sich einfach. Im Sinne der Community ist es nicht. Andere Nutzer mit vergleichbaren Problemen sollen über die Suche ja auch Hinweise bekommen, was Lösungen sein können und wo sie suchen können. Der Anspruch wird durch eine solche Einstellung natürlich hintertrieben. Außerdem entsteht ein falscher Eindruck, wer letztlich für die Probleme verantwortlich ist.

    Aber anderen Leuten Unhöflichkeit vorwerfen. Hmm.

    Jedenfalls werde ich der Sache auch zukünftig auf den Grund gehen, wenn ich solche Widersprüche sehe.

    Einmal editiert, zuletzt von frank_m (23. Mai 2026 um 10:39)

  • Klar, mit der Einstellung macht man es sich einfach

    In der Tat, wenn man datenbasiert vorgeht ist es einfacher als wenn man versucht vorgefasste Ueberzeugungen umzusetzen.

    Im Sinne der Community ist es nicht.

    Unklar, ich sehe nicht, dass wir diesen Aspekt als Gemeinschaft das diskutiert haben, geschweige denn, dass wir eine gemeinsame Position gefunden haben.

    Andere Nutzer mit vergleichbaren Problemen sollen über die Suche ja auch Hinweise bekommen, was Lösungen sein können und wo sie suchen können.

    Unklar... nichts gegen theoretische Threads um Debugging-Methoden zu demonstrieren und zu erklaeren, aber praktische Threads sind mMn. in dieser Hinsicht nuetzlicher, wenn die Methode auch zu Erfolgen oder zumindest einer besseren Diagnose fuehrt.

    Der Anspruch wird durch eine solche Einstellung natürlich hintertrieben.

    Wie gesagt es gibt mMn. gar keinen allgemeinen Anspruch den wir uns als Gemeinschaft gegeben haben...

    Außerdem entsteht ein falscher Eindruck, wer letztlich für die Probleme verantwortlich ist.

    D.h. Du bist immer noch der Meinung, der ISP waere hier nicht verantwortlich? Eindrucksvoll, wie hier Vorurteil ueber beobachtbare Realitaet zu gewinnen scheint.

    Was Hoeflichkeit angeht, ja Deine selbstgerechten Unfreundlichkeiten mit denen Du freizuegig um Dich wirfst gehen mir auf den Senkel: so vetreibt man Neulinge mMn. recht effektiv.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • In der Tat, wenn man datenbasiert vorgeht ist es einfacher als wenn man versucht vorgefasste Ueberzeugungen umzusetzen.

    Wo bist du denn datenbasiert vorgegangen? Das, was von der Löschaktion übrig geblieben ist, reicht ja, um es dir anzusehen. Beantworte mir folgende Fragen:

    • Warum waren die Traces erfolgreich?
    • Warum funktionierte die Namensauflösung?
    • Warum funktionierte der VPN Tunnel?
    • Warum funktionierten die curl Aufrufe?
    • Warum konnten andere Geräte im Netz etliche Gigabyte an Daten übertragen?

    Und das alles, während eine Providerstörung vorlag?

    Du reklamierst für dich, den Fragestellungen rein datenbasiert, sachlich nüchtern und unvoreingenommen gegenüberzustehen. Und da ist das Zitat einer Mail, die - basierend auf den Posts dieses Forums - nachweislich häufig versendet wurde, ohne das ein Anschluss von einer Störung betroffen war, relevanter, als die Ergebnisse all dieser Messungen und Versuche?

  • All die genannten Punkte lassen sich mit einer gestörten IPv6-Verbindung beantworten, sodass zum Beispiel die Aufrufe in Safari vor die Wand gefahren sind. Aber auch da empfinde ich es nicht plausibel, dass der Browser keine Fehlermeldung rausgibt.

    Bei curl hat OP es verpasst, den Aufruf zu verifizieren, denn auf mich wirkt es so, dass "-o /dev/null" nicht gegriffen hat. Entweder Tippfehler oder "/dev/null" ist unter Mac anders, glaube ich aber nicht. Daher könnte es zum Beispiel sein, dass die Verbindung zwar initiiert wurde, effektiv aber keine Daten flossen. CityCobra könnte höchstens aus der Terminal-History den Befehl neu aufrufen und schauen, ob es immer noch zum Schreibfehler kommt. Dann wüssten wir mehr.

    Dem gegenüber steht die Selbstdiagnose der FB, die sowohl bei IPv4 als auch bei IPv6 keinen gültigen Uplink gefunden hat.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • frank_m ich habe in diesem Thread gar nicht diagnostizierend eingegriffen, und weder Hypothesen aufgestellt noch Experimente verlangt, daher frage ich mich warum ich mir von Dir Hausaufgaben geben lassen sollte?

    Daher antworte ich nur mit einer Gegenfrage, welche Aktion des OP nach Anleitung hier aus dem Forum hat Deiner Meinung nach den Knoten geloest?

    Dass die DG momentan ihre IPv6-Provisionierung aendert ist kein Geheimnis und auch nicht, dass das nicht so geschmeidig und unauffaellig ablaeuft wie man sich das wuenschen wuerde. Daher ist es fuer mich nicht unwahrscheinlich, dass der OP von so einer Aktion betroffen war.

  • Dass die DG momentan ihre IPv6-Provisionierung aendert ist kein Geheimnis und auch nicht, dass das nicht so geschmeidig und unauffaellig ablaeuft wie man sich das wuenschen wuerde.

    Nach meinen Beobachtungen aufgrund der vielen Fälle, die wir hier im Forum schon hatten, stellt man bisher offenbar keine Bestands-Anschlüsse um, die nach alter IPv6-Provisionierung funktionieren (erkennbar an den WAN-Port-Adressen aus 2a00:6020:1000::/48 bzw. genauer 2a00:6020:1000:XX::/112, wobei XX eine spezifische 2-stellige Kennung des BNG-Clusters ist).

    Die neue Provisionierung erfolgt bisher offenbar nur für IPv6-Ranges, die bisher nicht für Bestandsanschlüsse mit Alt-Provisionierung verwendet wurden - hier eine (sicherlich unvollständige) Liste aus meiner Statistik (wie bei der Alt-Provisionierung sind es jeweils /41-Ranges pro BNG-Cluster), Stand 05.06.2026:

    PD-Block (/56) aus:WAN-Port-Adresse aus:
    2a00:6020:5380::/412a00:6020:53c0::/112
    2a00:6020:5c80::/412a00:6020:5c80::/112
    2a00:6020:7300::/412a00:6020:7300::/112
    2a00:6020:7380::/412a00:6020:7380::/112
    2a00:6020:7680::/412a00:6020:7680::/112
    2a00:6020:7700::/412a00:6020:7700::/112
    2a00:6020:7800::/412a00:6020:7800::/112
    2a00:6020:7880::/412a00:6020:7880::/112
    2a00:6020:8f00::/412a00:6020:8f00::/112
    2a00:6020:9100::/412a00:6020:9100::/112
    2a00:6020:9400::/412a00:6020:9400::/112
    2a00:6020:9480::/412a00:6020:9480::/112
    2a00:6020:9800::/412a00:6020:9800::/112
    2a00:6020:9a80::/412a00:6020:9a80::/112
    2a00:6020:9c80::/412a00:6020:9c80::/112
    2a00:6020:bb00::/412a00:6020:bb00::/112
    2a00:6020:c700::/412a00:6020:c700::/112

    Diese Ranges kommen vorrangig in BW, teilweise auch in RP und SL zum Einsatz, also grob im Südwesten der Republik.

    Ob IPv6 beim Anschluss des OP nach neuer IPv6-Provisionierung erfolgt, wissen wir leider nicht, solange der zugeordnete IPv6-Präfix bzw. die WAN-Port-Adresse nicht bekannt sind.

    3 Mal editiert, zuletzt von ::1 (5. Juni 2026 um 15:19)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Ob IPv6 beim Anschluss des OP nach neuer IPv6-Provisionierung erfolgt, wissen wir leider nicht, solange der zugeordnete IPv6-Präfix bzw. die WAN-Port-Adresse nicht bekannt sind.

    Wo finde ich diese Infos in meiner Fritz!Box und wie kann ich feststellen ob mein Anschluss nach neuer IPv6 Provisionierung versorgt wird?

  • Wo finde ich diese Infos in meiner Fritz!Box

    Das Präfix für dein 56er Netz findest Du bei Internet > Online-Monitor - Reiter Verbindungsdetails: Internet-Verbindung - Internet, IPv6

    Die WAN-Adresse der Box findest Du an der gleichen Stelle.

    Nachtrag:

    Ich habe einen Altanschluss (Hessen, Main-Taunus-Kreis). Bei mir sieht es wie folgt aus:

    IPv6-Adresse: 2a00:6020:1000:...

    IPv6-Präfix: 2a00:6020:b398:.../56

    Einmal editiert, zuletzt von HubeBube (23. Mai 2026 um 16:21)

  • frank_m ich habe in diesem Thread gar nicht diagnostizierend eingegriffen, und weder Hypothesen aufgestellt noch Experimente verlangt, daher frage ich mich warum ich mir von Dir Hausaufgaben geben lassen sollte?

    Du hast sehr wohl eine Hypothese aufgestellt, nämlich welche Probleme ursächlich sind und wer in diesem Thread richtig oder falsch liegt. Mich würde jetzt halt interessieren, wie du ob aller gezeigten Daten - die für dich nach eigener Aussage ja maßgeblich sind - und ohne Diagnose - die du nach eigener Aussage ja nicht durchgeführt hast - zu diesem Urteil gekommen bist, und habe dafür die Fragen formuliert, die für mich mit diesem Urteil im offenen Widerspruch stehen.

    Daher antworte ich nur mit einer Gegenfrage, welche Aktion des OP nach Anleitung hier aus dem Forum hat Deiner Meinung nach den Knoten geloest?

    Ob es eine konkrete Anleitung war, sei dahingestellt. Hinweise, wo man suchen kann, gab es ja viele. Vielleicht war es die VPN Software oder deren Konfiguration? Vielleicht eine Proxy-Einstellung im Browser? Jedenfalls genug Erklärungen, die mit einem Klick angewendet worden sein können. Es war ja sehr auffällig, dass die Kommandos auf der Konsole funktionierten, während Zugriffe auf Webseiten aus dem Browser heraus nicht funktionierten. Darüber hinaus, dass Geräte im Heimnetz, auf denen keine VPN Software lief, das Internet problemlos nutzen konnten und dabei auch signifikante Datenmengen erzeugten.

    Dass die DG momentan ihre IPv6-Provisionierung aendert ist kein Geheimnis und auch nicht, dass das nicht so geschmeidig und unauffaellig ablaeuft wie man sich das wuenschen wuerde. Daher ist es fuer mich nicht unwahrscheinlich, dass der OP von so einer Aktion betroffen war.

    Dem stimme ich sogar zu, das kann durchaus sein. NUR: Die Mail spricht von einer Störung, nicht von Wartungsarbeiten. Und selbst wenn: wie passt das zu den beschriebenen Symptomen und den gezeigten Daten? Die Symptome, die dazu in den anderen Threads beschrieben werden, hätten hier andere Ergebnisse erzeugen müssen. Die Fritzbox hatte eine gültige IPv6 Adresse und ein Prefix, das zeigten inzwischen gelöschte Screenshots. Die in anderen Threads beschriebenen fehlenden Adressen waren es also nicht. Die Latenzerhöhungen können es vielleicht sein, hätten hier aber nicht zum kompletten Ausfall der Verbindung geführt. Andere Routing-Probleme, wie wir sie bei der DG öfter sehen (die aber im Zuge dieser Umstellung noch nicht berichtet wurden), können durchaus aufgetreten sein, hätten dann aber dazu geführt, dass zumindest die ersten paar Hops des IPv6 Traces funktioniert hätten.

    Für die Widersprüche hab ich bislang einfach keine befriedigende Erklärung gefunden. Deshalb tue ich mich schwer, einfach mal so ein Provider-Problem verantwortlich zu machen. Und außer anzüglichen Bemerkungen oder Ausflüchten hab ich von euch bislang auch nichts gelesen, außer dass einige Nutzer meinen, Öl ins Feuer gießen zu müssen, die sonst gar nichts beizutragen haben. Wenn es so offensichtlich ein Provider Problem ist, dann schreibt doch einfach "Deshalb ist es so", anstatt in zig Beiträgen um den heißen Brei herumzueiern und mir zu erklären, warum ihr auf meine Fragen nicht antworten wollt oder warum in diesem Thread ausgerechnet ich derjenige bin, der einer vorgefertigten Meinung folgt.

    Einmal editiert, zuletzt von frank_m (23. Mai 2026 um 16:24)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Das Präfix für dein 56er Netz findest Du bei Internet > Online-Monitor - Reiter Verbindungsdetails: Internet-Verbindung - Internet, IPv6

    Die WAN-Adresse der Box findest Du an der gleichen Stelle.

    Dort steht bei mir:

    WAN verbunden Download 400 Mbit/s, Upload 200 Mbit/s

    Internet, IPv6 verbunden, Deutsche Glasfaser
    IPv6-Adresse: 2a00:6020:1000:xxx
    IPv6-Präfix: 2a00:6020:b40f:da00::/56

  • IPv6-Adresse: 2a00:6020:1000:xxx
    IPv6-Präfix: 2a00:6020:b40f:da00::/56

    Der Anschluss müsste somit am "BNG-Cluster 4" Düsseldorf hängen ("alte" IPv6-Provisionierung, u.a. auch zuständig für den Block 2a00:6020:b400::/41) - dieser taucht in Inbound-Traceroutes mit der Adresse 2a00:6020:ffff:ffff::3 auf.

    Die WAN-Adresse müsste genauer in 2a00:6020:1000:1a::/112 liegen (die letzten 4 Ziffern sind individuell für deinen Anschluss, genauso wie die Ziffern "0f:da" deines Anschlusses im /56-Präfix)

    Nachtrag:

    Dieser Traceroute bestätigt es:

    Dein WAN-Interface lässt sich auch anpingen - Standard bei Fritzboxen.

    Einmal editiert, zuletzt von ::1 (23. Mai 2026 um 18:05)

  • Heute war es ziemlich unstabil von der Leitung.
    Wenn ich z.B. ein YouTube Video starten wollte, dauerte es teilweise Sekunden bis des Video startete.
    Auch meine Frau die im Home Office spürte das die Leitung nicht flüssig und schnell lief.
    Die Diagnose in meiner Fritz!Box zeigte nichts Auffälliges und bei der DG lag angeblich keine Störung vor.
    Was verursacht denn solche Verzögerungen?
    Eigentlich sollte sich doch eine aufgerufene Seite blitzschnell öffnen, oder nicht?

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.