Packetloss bei der Deutschen Glasfaser seit November 2025

    Liebe Glasfasermitstreiter/innen,

    ich bin nun seit 03/2021 Kunde bei der DG (PLZ Bereich 635xx) und habe von Anfang an eine OPNSense am ONT hängen. ONT typ ist Nokia G-010G-P. Das lief 4 1/2 Jahre lang einwandfrei - bis auf einige DHCPv6 Themen, die aber mittlerweile gelöst sind - aber seit November 2025 (genauer Tag weiß ich nicht) habe ich immer mal wieder Packetloss auf der Leitung. Aufgefallen ist das beim Zocken (ja, ich zocke selbst und habe drei Jungs hier im Haus, die das auch tun) aber auch bei Teams-Meetings bleibt hin und wieder das Bild mal für eine Sekunde stehen.

    Ich lasse auf meinem kleinen Heimserver einen SmokePing Container laufen, um Pings zu einigen Endpunkten (IPv4 und IPv6) über den Tag zu beobachten. Was ich sehen kann, ist, dass meine OPNsense nie Verluste zeigt, während der erste Hop dahinter schon diese Losses hat. Alle anderen Webseiten / DNS / Gamingserver zeigen auch dieses Verhalten.

    Nun habe ich auch den Artikel Deutsche Glasfaser als erstes Netzwerk mit 800GE Port am DE-CIX gelesen und hab schon die Befürchtung, dass da etwas mit zu tun hat. Bandbreite ist halt nicht Alles, was ein guter Internetanschluss braucht.

    DG Support Ticket ist eröffnet, geht bei denen wohl /dev/null. Seit über einem Monat keine Antwort.

    Ich habe schon darüber nachgedacht, die OPNsense direkt ans Glas zu hängen, um das ONT als Ursache ausschließen zu können. Ich war schon auf dem Webinterface vom ONT aber außer die Dämpfung bekommt man da keine Infos, die auf Fehler auf der Glasstrecke hindeuten. Ich denke aber aktuell nicht, dass es das ONT ist. (Telnet geht bei meinem nicht)

    Die Interfacestatisktik auf dem WAN Port der Opnsense zeigt keinerlei Errors, crcs oder losses.

    Ich wollte nur fragen, ob es hier Personen gibt, die Ähnliches beobachtet haben, damit ich den Aufwand hier sparen kann, eine ONT zu klonen oder ein SFP passend zu Programmieren. Fritzbox ist für mich keine Option.

    (Ich habe die Forumssuche benutzt, finde aber immer nur Themen, die etwas Abweichendes berichten wie hohe Latenz oder niedrige Downloadbandbreite oder kein IPv6, was bei mir nicht der Fall ist)

    MS-Teams und Google.com Graph ist IPv6, alles andere IPv4. DG-CGN ist (denke ich) der NAT Router von der DG, also der erste Hop, den ich im MTR sehen kann

    (Spessart ist der Container)

    Danke & Viele Grüße

    Wie sieht die Statistik aus, wenn ihr kein ICMP, sondern UDP Pakete verwendet? ICMP ist immer heikel, und bei 0.5% braucht man da schon sehr viele Pakete, um auf belastbare Aussagen zu kommen (jedenfalls mehr als 400). Versuche mal mtr mit UDP oder auch mal mit TCP.

    ICMPs dürfen deine Firewall ungehindert passieren, ohne burst Regel und so? Bei so Tracing Programmen kann genau sowas problematisch sein, wie ich schon mal schmerzhaft spüren musste.

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

    Ok, es war halt verdächtig, weil es ungefähr das gleiche Verhalten zeigte.

    Leider mögen Gameserver kein TCPPing

    Ich habe nun für Google und Teams mal nen TCP Ping auf Port 443 konfiguriert. Muss erstmal etwas laufen. Den DG-Router werde ich wohl mit TCPPing nicht bekommen

    (UDP Mtr kommt bei mir nirgendwo richtig durch (durch die FW schon) aber sonst nicht wirlich) ICMP Limit gibt es keines, afaik

    Danke für den Hinweis.. Wer misst....

    Zitat von lp24db

    DG-CGN ist (denke ich) der NAT Router von der DG, also der erste Hop, den ich im MTR sehen kann

    Ich habe mich ein wenig mit der Adress-Systematik der DG u.a. auf Basis von RIPE-Atlas-Probes an DG-Anschlüssen befasst und kann daher mit einiger Sicherheit sagen:

    1. Hop 2 (100.124.1.11) ist lediglich die der Kundenseite zugewandte IPv4-Adresse des "BNG-Cluster-1" der DG in Frankfurt (dieser BNG-Cluster hat auf der dem Internet zugewandten Seite die IPv6-Adresse 2a00:6020:ffff:ffff::e). Der BNG-Cluster ist aber nicht zugleich die CGNAT-Instanz.
    2. Folglich ist die CGNAT-Instanz der Hop 3 oder der Hop 4, wobei ich auf Hop 3 tippe. Hop 4 wäre dann der letzte DG-BGP-Router am DE-CIX Frankfurt.

    Wenn meine Analyse richtig und dein Anschluss keine der berühmten Ausnahmen von der Regel ist, müsstest du einen IPv6-LAN-Range (/56) aus dem IPv6-Block 2a00:6020:5080::/41 (also einen der /56-Blöcke aus 2a00:6020:5080::/56 bis 2a00:6020:50ff:ff00::/56) und eine WAN-Adresse der Form 2a00:6020:1000:41::WXYZ haben.

    Die folgenden beiden public Atlas-Probes hängen ebenfalls am BNG-Cluster deines DG-Anschlusses: #10214 und #53040. Die IPv4-Traceroute-Messungen dieser Probes stimmen für die Hops 2-4 mit deiner Messung überein (Klicke auf einen Messdatenpunkt und dann auf "SHOW TRACEROUTES" in 10214-Built-ins-v4 bzw. 53014-Built-ins-v4, um die Traceroutes anzuzeigen).

    Woher weiß ich, dass die BNG-Cluster kein CGNAT-machen?

    Antwort:

    Es gibt Atlas-Probes an DG-Kundenanschlüssen, die an verschiedenen BNG-Clustern hängen, aber dieselbe public IPv4-Adresse besitzen. Da diese public IPv4-Adresse nicht gleichzeitig durch zwei verschiedene BNG-Cluster verwendet werden kann, muss der NAT-Schritt folglich an einer nachgelagerten Instanz erfolgen.

    Beispiel:

    • Probe #28672: public IPv4=94.31.112.13, BNG-Cluster: 100.124.1.27 / 2a00:6020:ffff:ffff::24 - BNG-Cluster-2 Nürnberg
    • Probe #31836: public IPv4=94.31.112.13, BNG-Cluster: 100.124.1.24 / 2a00:6020:ffff:ffff::21 - BNG-Cluster-1 Nürnberg

    Die TCPPing auf 443 Ports der möglichen Server läuft noch. Ich poste morgen. Spoiler: klar ist jetzt schon, auch hier sporadischer Loss.
    Korrekt, IPv6 Range ist 2a00:6020:usw.... mit /56, also genau in deiner beschrieben Range

    Ich hab nochmal geschaut, ich pinge das Gateway, was ich vom DHCP der DG bekomme - 100.84.0.1 (was bei OPNsense als Gateway angezeigt wird) Dachte, das wäre der CG-NAT auf der mir zugewandten Seite.

    Danke für die Ripe Links. Wusste gar nicht, dass es so etwas gibt. BNG-Cluster... never heard of before. Gibt auch ein nettes PDF auf der Seite der Bundesnetzagentur dazu

    Übel was gelernt... Und das am Freitag Abend :) Danke

    Einmal editiert, zuletzt von lp24db (17. Januar 2026 um 00:26) aus folgendem Grund: typo

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

    Hier mal der Stand der letzten ca. 20 Stunden. Auch bei TCP Verbindungen (hier 443 und teilweise 80/ bzw. 8080 getestet. IPv6 (facebook, google) und IPv4 ( der maskierte Graph - ist ein Citrix Netscaler und der "FA Silent" ) zeigen Gleiches.
    Immer wieder sproadische losses. Das fängt alles schon beim v4 Gateway 100.84.0.1 an - wenn man ICMP als Referenz nimmt. (ich traue mich kein nmap auf die 100.84.0.1 zu machen, nicht dass die mich noch vom Anschluss werfen :D )

    Das ONT zeigt mir "Optical power (dBm)" mit dem Wert -19,4 an. Ist das gut / schlecht? Ich meine gut. Mehr bekommst du aus dem Nokia Ding nicht raus.

    ::1 hast du eine Idee, was das sein könnte? Oder wo man ansetzen könnte? Bandbreiten-Tests sind 100%. Ich bekomme genau das, was vertraglich zugesichert ist.

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

    Bandbreiten-Tests sind 100%. Ich bekomme genau das, was vertraglich zugesichert ist.

    Das ist aber ein Zeichen dafür, dass es auf TCP Ebene keine Paketverluste gibt. Auf sowas reagieren Speedtests recht empfindlich.

    Zitat von ::1

    Die folgenden beiden public Atlas-Probes hängen ebenfalls am BNG-Cluster deines DG-Anschlusses: #10214 und #53040. Die IPv4-Traceroute-Messungen dieser Probes stimmen für die Hops 2-4 mit deiner Messung überein (Klicke auf einen Messdatenpunkt und dann auf "SHOW TRACEROUTES" in 10214-Built-ins-v4 bzw. 53014-Built-ins-v4, um die Traceroutes anzuzeigen).

    Deren Packet Losses sind unauffällig, jedenfalls deutlich besser, als die hier im Thread.

    Zitat von frank_m

    Das ist aber ein Zeichen dafür, dass es auf TCP Ebene keine Paketverluste gibt. Auf sowas reagieren Speedtests recht empfindlich.

    Die Losses sind ja nicht ständig. Könnte auch gut sein, dass ich beim Speedtest keine erwischt habe. Machnmal passiert ja auch eine Stunde lang gar nichts. Ich denke auch nicht, dass das "Backbone" hier ein Problem ist, sonst wäre der Aufschrei ja wesentlich größer. Ich kann ja nochmal ein Speedtests anfertigen. Das geht leider nur nachts, weil gerade jetzt am Wochenende hier Hochbetrieb ist.

    Wir haben in der Schule unseres Sohnes einen DG-Business Anschluss (bin dort Ehrenamtlich tätig). Da ist überhaupt kein Loss - ist aber auch kein GPON also nicht direkt vergleichbar. (und man bekommt sogar echten Support, wenn man dort anruft)

    Dann versuche ich mal mein "Glück" nächste Woche mal telefonisch. - Parallel schaue ich mal, ob ich so mein ONT geclont bekomme.

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

    Das ist aber ein Zeichen dafür, dass es auf TCP Ebene keine Paketverluste gibt. Auf sowas reagieren Speedtests recht empfindlich.

    Jein, ganz so einfach ist das nicht... was stimmt ist, dass bei klassischem TCP-Reno der maximale Durchsatz eines Flows von der RTT (Entfernung zu den Servern) und der Verlustrate abhaengt (seminales Paper von Matt Mathis zur Berechnung des maximalen TCP Durchsatzes in Abhaengigkeit von RTT und Packetloss). Aber z.B. BBR misst die Kapazitaet und Latentz unabhaengig und ist bereit und in der Lage auch relativ hohe Verlkustraten (um 1%) durch Fast-Retransmitts zu tolerieren ohne das klassischen Durchsatzverhalten von TCP Reno zu zeigen.

    Tl:dr: "keine Paketverluste" ist etwas strikt, aber ich sehe es auch so, dass das gegen massiven Verlust spricht, zumindest ueber den Pfad zu den breitbandmessung.de-Servern.

    Mach doch mal ein paar laengere Trippy tests, z.B. ueber Nacht mit >= 1000 samples?

    Und wenn Du mir Deine aktuelle IP (v4 oder v6) per PN mitteilen willst, kann ich einen aehnlichen Trippy-Test von hier aus gegen Deinen Router laufen lassen (wenn der denn auf ICMP echo requests von aussen antwortet).

    Zitat von lp24db

    ::1 hast du eine Idee, was das sein könnte? Oder wo man ansetzen könnte? Bandbreiten-Tests sind 100%. Ich bekomme genau das, was vertraglich zugesichert ist.

    Naja, Ideen kann man viele haben. Mir fällt hierzu dieser Thread ein. Dort lagen die Dinge zwar etwas anders (Netz mit ~100 Clients an einem Privat-Anschluss), aber die Ursache könnte doch in beiden Fällen am IPv4-CGNAT des DG zu suchen sein - die Hintergründe habe ich in jenem Thread in meinen Beiträgen #10 und #14 erläutert.

    Insofern wäre es mal interessant, deine Messungen im Vergleich einmal via IPv4 und einmal via IPv6 für ein Internet-Ziel durchzuführen, das dual-stack, also über beide Protokolle erreichbar ist. Treten bei zwei Vergleichsmessungen zu demselben Internet-Ziel Verluste signifikant nur via IPv4, nicht jedoch via IPv6 auf, wäre das zumindest ein Hinweis, dass es am CGNAT liegen könnte.

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

    Langzeitmessungen werden auch nichts anderes zeigen. Ob icmp oder tcp es ist alles betroffen. Hab mal die trip Screenshots angehängt, die aber auch keine neue oder andere Erkenntnis bringen. Loss, immer mal wieder sporadisch und grundsätzlich nach dem Gateway der DG.

    Ich werde mal meine IPv6 von meinem Webserver mit trip beboachten, danke für den Tip. Aber würde das wirklich Erkenntnisse bringen?

    Mal zusammengefasst:

    - Das mit dem Portlimit habe ich bereits gelesen. Halte ich aber für unwahrscheinlich, da das Fehlerbild anders ist.
    - CGNat kann man eigentlich auch schon ausschließen, da auch IPv6 Adressen betroffen sind.
    - Ich habe schon vier unterschiedliche Router / Hardware verwendet, auch mit älteren Softwareständen, das Fehlerbild ist immer gleich.
    - ONT Neugestartet usw. kein Unterschied
    - Dämpfung scheint ok zu sein, falls das nicht so wäre würde ich auch mit einer höheren Fehlerquote rechnen (kenne ich von Servern im Fibrechannel oder bei Ethernet >=10Gbit zumindest so)
    - vor Mitte November war alles 100%ig ok.


    Am Wahrscheinlichsten:
    - ONT ne Macke?
    - SFP auf deren Seite?
    - Leitung überbucht?


    Spekulation:
    - Kann es die Faser selbst sein? Es gab im September 2025 einen Schaden wegen eines Wasserrohrbruchs, das wurde aber repariert und lief 2 Montate ohne Probleme (hab ich schon wieder verdrängt) Wenn aber die Dämpfung ok ist?
    - ich habe noch den alten 400/200 für 49€ Vertrag. Heute bekommt man hier für 49€ nur noch 300/150 Wollen die mich da runtermobben ? ;)


    Es wäre halt so einfach, wenn die DG einfach beliebige Endgeräte wie bei einem DSL Anschluss z.B. erlauben würden. Aber nein. 1h Mac Sperre, keine "Zugangsdaten" also PLOAM oder sonstige Infos im Kundeportal, NULL Response bei Fehlertickets, Informationhiding an allen Ecken. Ich frag mich manchmal, warum sowas überhaupt sein darf. Ok die Fritzbox mit GPON kann man jetzt automatisch provisionieren lassen aber auch das hat vier Jahre gedauert.
    Von einem Kollegen aus der Nähe von Mainz habe ich gehört, dass das auch ganz anders gehen kann.

    Am liebsten würde ich ja auf den Gigabit wechseln, dann könnte ich zumindest das GPON Thmea sparen. Aber ich befürchte das könnte genauso in die Hose gehen. Vier Jahre bestes Internet und jetzt nervt es nur noch.

    Habe mal eine IPv6-Vergleichsmessung zu one.one.one.one (2606:4700:4700::1001) gemacht analog deiner Messung im Screenshot 174352:

    Also ein paar Paketverluste habe ich auch, wenn auch deutlich geringer als bei dir.

    Habe auch einen DG-Classic-Tarif 400/200, hänge aber am BNG-Cluster 100.124.1.26/2a00:6020:ffff:ffff::23 (BNG-Cluster 2 Nürnberg).

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

    Musst Du die DG fragen... macht vermutlich aus deren Sicht Sinn aber unklar ob technisch, oder nur kaufmaennisch...
    Ich hatte frueher mal einen ISP der mit DHCP gearbeitet hat, der hat die MAC Adressen dauerhaft gebunden (hat allerdings 4 MACs pro Kunde erlaubt)... da gab es allerdings eine Webseite auf der man das selber Resetten konnte.