Skip to main content
Warum O2
Warenkorb
Service

Massiver Paketverlust bei IPv4 Routing und temporaere 5G Abschaltung im Bereich von PLZ 15378


Pixel72
Besucher:in

Sehr geehrte Damen und Herren, liebe Community,

ich wende mich an den technischen Support und die Moderatoren hier im Forum, da in meinem Bereich seit circa 5 bis 7 Tagen massive Routing-Probleme und Netzstörungen im Mobilfunknetz vorliegen. Als erfahrener PC-Techniker habe ich den Fehler über mehrere Tage hinweg mittels detaillierter Netzwerkanalysen isoliert.

Der Fehler äußert sich im Alltag durch extreme Verzögerungen beim Verbindungsaufbau von bis zu 10 Sekunden beim Anklicken von Links, während die Bandbreite nach dem Aufbau voll da ist. Ein offizielles Ticket wurde bereits erstellt (Nr. S30345457).

Hier sind die exakten technischen Fakten zur Störung:

  1. Massiver Paketverlust im IPv4-Bereich beim CGNAT-Gateway: Langzeit-Messergebnisse zeigen, dass nativer IPv6-Traffic zu Google-Servern absolut fehlerfrei und mit Null Prozent Paketverlust läuft. Sobald jedoch Webseiten über das IPv4-Protokoll oder über den integrierten IPv4-Übersetzungstunnel angesprochen werden (wie zum Beispiel ard.de oder wetter.de), kommt es zu einem massiven Paketverlust von teils 40 bis über 70 Prozent. Das zuständige Carrier-Grade-NAT-Gateway beziehungsweise der AFTR-Server für meine Region verwirft die Routing-Pakete zyklisch, was zu den Timeouts beim Seitenaufbau führt.

  2. Synchrones Verhalten bei nächtlicher Abschaltung: Es ist seit circa einer Woche reproduzierbar zu beobachten, dass exakt zwischen 3 und 4 Uhr nachts alle Endgeräte im Haus – sowohl mein iPhone als auch der stationäre 5G-Router von ZTE – synchron von 5G auf LTE beziehungsweise 4G zurückgestuft werden. Punkt 4 Uhr morgens schaltet die Verbindung wieder fehlerfrei auf 5G um. Dies deutet unmissverständlich auf die nächtlichen Energiesparmodi oder laufende Wartungsarbeiten am lokalen Sendemasten hin.

  3. Protokoll-spezifisches Problem im Kernnetz unabhängig von der Netztechnologie: Obwohl der Router und das iPhone tagsüber wieder stabil im 5G-Netz eingebucht sind, bleiben die massiven Paketverluste im IPv4-Bereich durchgehend bestehen. Das bedeutet, dass die reine Funkverbindung über 5G zwar physisch aufgebaut wird, das dahintergelagerte Routing für den IPv4-Verkehr jedoch permanent gestört ist. Die beschriebenen Timeouts und Aussetzer treten somit plattformunabhängig und frequenzunabhängig auf und sind einzig auf eine Fehlkonfiguration oder Überlastung des regionalen CGNAT-Gateways zurückzuführen.

Fazit: Da der Fehler geräteunabhängig sowohl auf einem iPhone als auch auf dem ZTE-Router auftritt, ist ein Defekt meiner Hardware oder der lokalen WLAN-Struktur zu 100 Prozent ausgeschlossen (Router wurde natürlich mehrmals vom Strom genommen und neu gestartet und hat auch sehr guten Empfang). Das Problem liegt im Kernnetz des regionalen Funksektors beziehungsweise am dortigen IPv4-Routing-Gateway.

Ich hänge diesem Beitrag die Screenshots meiner PingPlotter-Messungen an. Ich bitte die Moderatoren höflich, diese detaillierten Daten an die zuständige Netzwerktechnik weiterzuleiten, damit das betroffene CGNAT-Gateway überprüft werden kann.

 

14 Antworten

Pixel72
Besucher:in
  • Autor
  • June 4, 2026

UPDATE / NEUE MESSERGEBNISSE:

Ich habe das Problem gerade noch einmal über die Windows-Eingabeaufforderung (CMD) mittels tracert eingegrenzt. Dabei hat sich das Fehlerbild konkretisiert:

Das Problem liegt überraschenderweise im nativen IPv6-Routing zu bestimmten Knotenpunkten (wie z. B. Google). Während die IPv4-Strecke absolut fehlerfrei und lückenlos durchläuft, bricht die IPv6-Route mitten im o2-Kernnetz bei Hop 6 (.ber.de.net.telefonica.de) reproduzierbar mit einer Zeitüberschreitung ab.

Da moderne Betriebssysteme standardmäßig IPv6 bevorzugen, führt dieser Paketverlust im Backbone zu den beschriebenen 10-Sekunden-Aussetzern (Timeouts), bevor der automatische Fallback auf das funktionierende IPv4 greift.

Ich hänge die beiden CMD-Screenshots (tracert -4 und tracert -6 zu dns.google) hier an diese Antwort an, damit die Netzwerktechnik den betroffenen Routing-Knoten direkt identifizieren kann.

 


Pixel72
Besucher:in
  • Autor
  • June 6, 2026

WICHTIGES UPDATE ZUR FEHLERISOLATION:

Ein Defekt oder eine Fehlkonfiguration meiner Heimnetz-Hardware kann nun zu 100 % ausgeschlossen werden. Ich habe den ZTE-Router komplett außer Betrieb genommen und testweise ein Samsung S10 als Mobilfunk-Hotspot an der Fritz!Box angemeldet.

Das Fehlerbild bleibt exakt identisch: Die Verbindung bricht alle paar Minuten ein, der Seitenaufbau dauert ewig, und nach einiger Zeit läuft es kurzzeitig wieder flüssig, bevor das Spiel von vorne beginnt. Auch das Deaktivieren von IPv6 bringt keine Besserung.

Da der Fehler somit plattform-, geräte- und SIM-kartenübergreifend (ZTE-Router vs. Samsung-Smartphone) auftritt, liegt hier definitiv eine gravierende Störung im regionalen o2-Mobilfunknetz (entweder am lokalen Sendemasten oder beim IP-Routing im Core-Netz) vor. Die SMS-Benachrichtigung, dass „keine technische Beeinträchtigung festgestellt wurde“, ist schlichtweg falsch. Ich bitte dringend um eine manuelle Überprüfung durch die Netztechnik!


Forum|alt.badge.img+3
  • Stammgast
  • June 6, 2026

Anrufen und gleichzeitig immer wieder ein Ticket aufmachen https://www.o2online.de/netz/netzstoerung/ leider ist nur Text erlaubt. Sonst auch https://www.o2online.de/service/kontaktformular/ dein TKG Entschädigung gelten machen. 

 


Pixel72
Besucher:in
  • Autor
  • June 6, 2026

UPDATE – Die Störung ist nun offiziell bestätigt!

Nachdem mein Ticket gestern noch mit einer Standard-SMS abgewiesen wurde, meldet der o2-Live-Check für meine Postleitzahl in Rüdersdorf bei Berlin nun endlich offiziell: „Eine Basisstation in der Nähe meldet Einschränkungen. Grund: Überlast oder eine andere Störung.“ (Siehe angehängter Screenshot).

Dies deckt sich zu 100 % mit meinen detaillierten Traceroute-Messungen und den geräteübergreifenden Aussetzern der letzten Tage. Die Luftschnittstelle mag aktiv sein, aber die Basisstation verliert unter Last reproduzierbar die Routen (insbesondere bei IPv6/Google/YouTube) und sorgt für die extremen Timeouts im Sekundenbereich.

Da der Fehler nun offiziell im o2-System detektiert wurde, erwarte ich eine zeitnahe Behebung der Überlastung/Störung durch die Netztechnik vor Ort. Mein internes Ticket darf gerne mit diesem Status aktualisiert werden.


Pixel72
Besucher:in
  • Autor
  • June 6, 2026

 


5G_Tester
Legende
  • Legende
  • June 6, 2026

Je nachdem in welchem Ortsteil du dich aufhältst ist der Netzausbau dort nicht optimal. 


Pixel72
Besucher:in
  • Autor
  • June 6, 2026

Danke für den Hinweis, aber ein „nicht optimaler Netzausbau“ verhält sich technisch völlig anders.

Wenn der Ausbau vor Ort einfach nur schwach wäre, hätte ich permanent schlechten Empfang, dauerhaft niedrige Datenraten oder konstante Paketverluste. Bei mir läuft es aber – wie beschrieben – stundenlang absolut perfekt und „ruck-zuck“ mit voller Geschwindigkeit, bis die Verbindung plötzlich wellenartig für einige Sekunden bis etliche Minuten  komplett einbricht und Webseiten wie YouTube blockiert.

Das ist kein Problem der Netzabdeckung oder der Signalstärke im Ortsteil, sondern ein klassisches Kapazitäts-, Routing- oder Softwareproblem direkt an der Basisstation. Und genau das bestätigt o2 ja seit heute auch offiziell im eigenen Live-Check für meine Postleitzahl: Da wird nun klipp und klar eine Überlastsituation oder andere Störung an einer Basisstation in der Nähe gemeldet.

Die Hardware liefert also das Signal, aber der Mast bricht unter der Last schlichtweg zyklisch zusammen. Das Problem liegt somit eindeutig in der Infrastruktur von o2 und nicht an meinem Wohnort.


5G_Tester
Legende
  • Legende
  • June 7, 2026

Richtig und ein besserer Netzausbau (und damit meine ich auch die Ausstattung einer Basisstation) würde einer Überlastsituation entgegenwirken durch mehrere Frequenzbänder, bessere Anbindung oder eventuell auch eine neue Basisstation, um einer bestehenden Basisstation Arbeit abzunehmen.


The_Voice_70
Legende
Forum|alt.badge.img+30

So, habe mal geschaut: 

4G
5G

Ist da definitiv recht dünn und eine Überlast kann da sehr schnell entstehen. 5G n28 (700 MHz) rein zur Flächenabdeckung. 


Pixel72
Besucher:in
  • Autor
  • June 7, 2026

Danke für die Recherche und die Screenshots von CellMapper! Das bringt uns in der technischen Analyse noch mal ein großes Stück weiter.

Wenn wir uns den 5G-Screenshot (image_592b88.jpg) ansehen, sieht man ganz deutlich, dass in der gesamten Region Rüdersdorf/Herzfelde mobiles 5G ausschließlich über Band 28 (700 MHz) läuft. Als Techniker weiß ich: Das ist das reichweitenstarke Low-Band, das primär für die Fläche da ist, aber keine massiven Kapazitäten bietet. Echtes Highspeed-5G (z.B. Band n78 im Gigahertz-Bereich) fehlt hier völlig.

Und genau hier treffen sich unsere beiden Argumente: Dass die Basisstationen hier (wie Mast 23809 Richtung Herzfelde) kapazitativ auf Kante genäht sind, steht außer Frage. Wenn dann – wie aktuell – eine akute technische Einschränkung oder eine extreme Überlastsituation vorliegt, die o2 ja nun auch selbst offiziell im Live-Check ausweist, bricht das sensible Kartenhaus bei Lastspitzen sofort zusammen.

Es handelt sich hier also um die Kombination aus einer ohnehin dünnen Kapazitäts-Ausstattung und einem aktuellen, akuten Problem an der Station oder deren Netzanbindung (Backbone). Genau deshalb rennen die Geräte zyklisch in die Timeouts. Ich hoffe sehr, dass die Netztechnik den betroffenen Masten bald wieder stabilisiert!


Pixel72
Besucher:in
  • Autor
  • June 7, 2026

Nachtrag zur 5G-Mogelpackung (technischer Beweis aus dem Router)

Ich habe das Ganze jetzt noch mal auf technischer Ebene in meinem Router überprüft, und das Ergebnis ist ein absoluter Offenbarungseid, der meine zyklischen Hänger (wie die 20-Sekunden-Aussetzer bei YouTube) perfekt erklärt.

Auf dem angehängten Screenshot meines Routers (image_4dc6c3.png) sieht man das Dilemma schwarz auf weiß:

Anzeige vs. Realität: Obwohl der Router im Display stolz ein „5G“-Signal vorgaukelt, ist die Tabelle „5G Zellen Info“ komplett leer (——). Es fließen also in Wahrheit absolut Null Daten über 5G. Es handelt sich um eine reine Schein-Verfügbarkeit.

Die LTE-Realität: Die gesamte Arbeit leistet das solide 4G-Netz auf Band 3 (1800 MHz) über den lokalen Masten 23809 (Richtung Herzfelde/Tasdorf). Die Signalwerte dort sind mit einem SINR von 24 dB und RSRP -90 dBm eigentlich hervorragend.

Die logische Schlussfolgerung für meine Probleme:
Da das Netz hier über das weit entfernte Low-Band n28 (700 MHz) permanent eine 5G-Verfügbarkeit signalisiert, versucht der Router im Kombi-Modus natürlich ständig, dieses 5G-Signal dynamisch dazuzuschalten. Da diese Zelle/Anbindung aber kapazitativ völlig auf Kante genäht ist oder aktuell massiv hakt (was der o2-Live-Check ja nun bestätigt), läuft der Router bei diesem Einbuchungsversuch im Hintergrund im Millisekundentakt ins Leere. Das Ergebnis: Die Datenpakete frieren für Sekunden ein.

Mein Workaround:
Ich habe den Router nun im Ausschlussverfahren fest auf „Nur 4G / LTE“ genagelt. Dadurch wird die leere Geister-Tabelle ignoriert, der Router schielt nicht mehr nach dem Pseudo-5G und bleibt stabil im starken LTE-Band 3.

Vielleicht hilft dieser technische Einblick ja auch anderen Nutzern, die sich über unerklärliche Timeouts trotz vollem „5G“-Logo wundern!


5G_Tester
Legende
  • Legende
  • June 7, 2026

Was für eine Geschwindigkeit erreichst du jetzt mit nur Band 3?


Pixel72
Besucher:in
  • Autor
  • June 7, 2026

Hier sind die nackten Zahlen frisch vom Sonntag-Nachmittag :

Download: ~152 Mbit/s

Upload: ~33 Mbit/s

Ping: 36 ms

Da mir vorher über 5G ohnehin nur Luftblasen ohne echte Datenpakete vorgegaukelt wurden, hat das LTE Band 3 (Mast 23809) wohl auch vorher schon die Hauptlast getragen. Zu absoluten Spitzenzeiten (z. B. nachts oder frühmorgens) zieht die Leitung hier im Schnitt sogar bis zu 250 Mbit/s im Down / 50 Mbit/s im Up durch. Je nach Auslastung der Zelle über den Tag verteilt sinkt es zu Stoßzeiten mal auf rund 80 Mbit/s. Mit den 152 Mbit/s an einem gut besuchten Sonntag-Nachmittag kann man von der reinen Bandbreite her also absolut nicht meckern.

Aber jetzt das große ABER zum Thema Stabilität:
Die kurzen, wellenartigen Hänger (die 20-sekündigen Totalaussetzer 

beim Seitenaufbau) sind auch im reinen 4G-Modus immer noch da.

Das bedeutet im Ausschlussverfahren: Der ständige Versuch des Routers, sich in eine fehlerhafte 5G-Zelle einzubuchen, war nicht der alleinige Auslöser. Das Problem liegt tiefer. Es betrifft direkt die o2-Infrastruktur vor Ort – sei es ein Paketverlust-Problem im LTE-Sektor von Mast 23809 selbst, ein Routing-Fehler oder eine Überlastung der Netzanbindung (Backbone) der Station. Genau das deckt sich ja auch mit der aktuellen o2-Störungsmeldung für meine Postleitzahl.

Wir haben die Fehlerquelle durch die Fixierung auf LTE jetzt also erfolgreich weiter eingekreist: Die Funkstrecke zum Masten steht wie eine Eins (SINR 24 dB), aber dahinter im o2-Netz hakt es gewaltig.


Pixel72
Besucher:in
  • Autor
  • June 7, 2026

Hintergrundwissen: Die große 5G-Mogelpackung (n28 vs. n78)

Da hier so fleißig recherchiert wurde, möchte ich mal kurz für alle technisch aufklären, warum wir beim Thema 5G von den Netzbetreibern (nicht nur o2) im Grunde massiv an der Nase herumgeführt werden. Wer sich die CellMapper-Karten genauer anschaut, entdeckt nämlich zwei völlig verschiedene Welten, die alle unter dem gleichen Namen „5G“ vermarktet werden:

1. Das „Pseudo-5G“: Band n28 (700 MHz)

Das ist genau das, was bei uns in der Region die Karte großflächig grün einfärbt.

  • Wie es funktioniert: Die Anbieter nehmen bestehende 4G/LTE-Masten und schalten per Software-Update das Band n28 auf 700 MHz frei (oft über sogenanntes DSS / Dynamic Spectrum Sharing, bei dem sich 4G und 5G die gleiche Leitung teilen).

  • Der Marketing-Trick: Niedrige Frequenzen wie 700 MHz haben eine gigantische physikalische Reichweite und dringen perfekt durch dicke Wände. o2 kann so mit einem einzigen Masten einen riesigen Landkreis abdecken. Die Bundesnetzagentur sieht auf dem Papier „Ah, Fläche mit 5G versorgt“, die Ausbauauflagen sind billig erfüllt und auf unseren Handys leuchtet stolz das 5G-Logo.

  • Die bittere Realität: Die Kapazität und Geschwindigkeit auf diesem Band sind ein Witz – sie liegen auf dem Niveau von ganz normalem, mäßigem LTE. Schlimmer noch: Ist der Mast überlastet, sorgt das ständige, dynamische Hin- und Her-Jonglieren der Frequenzen zwischen 4G und 5G für massiven Verwaltungs-Overhead, der zu fiesen Timeouts und Hängern führt. Reine Kosmetik für die Statistik!

2. Das „echte Highspeed-5G“: Band n78 (3600 MHz)

Das ist die eigentliche Datenrakete, die wir eigentlich meinen, wenn wir von der „5G-Revolution“ sprechen.

  • Die Technik: Hier wird im Gigabit-Bereich auf 3,5 bis 3,7 GHz gefunkt. Hier gibt es massive Kapazitäten, extrem niedrige Pings und echte Highspeed-Downloadraten.

  • Das Problem: Diese hohen Frequenzen haben eine physikalisch extrem kurze Reichweite. Nach ein paar hundert Metern bis maximal 1–2 Kilometern ist Feierabend. Jeder Baum und jede Hauswand schluckt das Signal.

  • Der Vergleich auf der Karte: Schaut man sich auf CellMapper die Masten an, sieht man das Dilemma perfekt: Während ein n78-Mast im flachen, dicht besiedelten Berliner Speckgürtel (z. B. zwischen Schöneiche und Neuenhagen) noch ein ordentliches Feld abdecken kann, erzeugt er in bewaldeten oder ländlicheren Regionen oft nur noch mikroskopisch kleine „Zwergen-Sektoren“ von wenigen hundert Metern (wie im Strausberger Forst am Garzauer Weg). Wer da 50 Meter daneben steht, fällt sofort komplett aus dem echten 5G-Netz heraus.

Fazit für uns Kunden: Lasst euch vom 5G-Logo im Display nicht täuschen! In den allermeisten Fällen außerhalb der absoluten Innenstädte hängen wir im kapazitätsarmen n28-Pseudo-Netz. Wenn dann, wie bei mir aktuell, die LTE-Infrastruktur des Mastes ins Stocken gerät, zieht dieses künstlich aufgepropfte Schein-5G die Stabilität nur noch weiter in den Keller.

Genau deshalb bringt das harte Umschalten auf „Nur 4G/LTE“ im Router oft die stabilere Leitung, weil man dem Gerät den Stress erspart, einer 5G-Fata-Morgana hinterherzujagen!