IPv4-Verbindungen brechen regelmäßig ab, IPv6 bleibt stabil

Es geht um einen o2 Home Tarif?

Hallo ​@dbad,

herzlich willkommen in unserer o2 Community 😀

Ich bedaure, wenn es Probleme mit dem mobilen Internet an deinem Standort gibt. 

Hier über die Community ist eine Störungsmeldung zwar möglich, aber wir haben hier durchaus eine längere Bearbeitungsdauer.

Es empfiehlt sich daher, eine Mobilfunkstörung direkt telefonisch oder ggf. über unseren Live Check zu melden. 

Handelt es sich denn um den Mobilfunkvertrag, mit dem du auch hier in der Community angemeldet bist? Hierzu kannst du dich auch direkt bei unserer Geschäftskundenbetreuung unter der 0800-10 90 20 0 melden.

Viele Grüße

Giulia

Hallo ​@blablup, hallo ​@o2_Giulia,

danke für eure Rückmeldungen! Sorry für meine späte Antwort, ich war länger im Urlaub.

​@blablup : Nein, kein o2 Home Tarif – es ist ein o2 Free L Boost (Online-Tarif, normaler Mobilfunkvertrag), genutzt u. a. im Huawei H122. Das Problem tritt aber wie beschrieben auch mit einer zweiten o2-SIM im Handy-Hotspot auf, ist also weder tarif- noch gerätespezifisch.

​@o2_Giulia : Telefonische Meldung mache ich, Ticketnummer reiche ich hier nach. Da die Hotline bei so einem Fehlerbild erfahrungsgemäß beim Endgerät ansetzt, habe ich das Problem inzwischen technisch vollständig eingegrenzt – vielleicht hilft das bei der Weitergabe an die Netztechnik:

Neue Messung während eines laufenden Ausfalls am 09.09.2026, ca. 13:35–13:57 Uhr (Cell-ID 26285098):

• IPv6 durchgehend stabil: 0 % Paketverlust, 11 ms zu Google
• IPv4 zum Internet: 100 % Paketverlust (ICMP und TCP, mehrere unabhängige Ziele: 8.8.8.8, 1.1.1.1)
• Aber: Die IPv4-Verbindung selbst steht – der Router hat eine WAN-IPv4 (10.188.56.216, CGNAT) zugewiesen, 9 h Uptime ohne Reconnect
• APN internet ist per Router-API verifiziert dual-stack IPv4v6
• Netzinterne IPv4-Ziele bleiben erreichbar: der o2-DNS 62.109.121.17 antwortet während des Ausfalls normal
• Traceroute kommt bis ins Telefónica-Core und stirbt dann:

 1  192.168.9.1    2,8 ms   (Router)
 2  10.0.81.130   13,9 ms   (Telefónica Core)
 3  10.81.102.88  15,2 ms   (Telefónica Core)
 4  *  *  *                 (ab hier 100 % Verlust)

Besonders auffällig: Die Verbindung flappte (13:50 down → 13:53 up → 13:54 down → 13:57 up), und beim zweiten Ausfall lief der Pfad über einen anderen Core-Hop (10.81.102.92 statt .88) – starb aber ebenfalls direkt dahinter.

Fazit: Funkstrecke (RSRP -76 dBm, SINR 28 dB), Router, SIM, APN und DNS sind ausgeschlossen. Die Pakete gehen erst hinter 10.81.102.x am CGNAT-/Border-Gateway verloren, während IPv6 denselben Funkweg problemlos nimmt. Das erklärt auch exakt das ursprüngliche Symptom: IPv6-fähige Seiten laden, IPv4-only-Seiten hängen.

Seit heute läuft bei mir ein automatisches Monitoring (minütlicher IPv4-/IPv6-Check mit Traceroute bei jedem Ausfallbeginn) – eine mehrtägige Ausfalltabelle mit exakten Zeitstempeln zum Korrelieren mit euren Gateway-Logs kann ich nachreichen. Standortdaten und Rohdaten gern per PN.

Könnt ihr das bitte mit diesen Infos an die Netztechnik geben, mit Bitte um Prüfung der CGN-/Border-Gateways für den Bereich Cell-ID 26285098/26285118 (WAN-Pool 10.188.x)?

Vielen Dank!

Nachtrag (14:10 Uhr): Störung hat sich von selbst aufgelöst – Verursacher-Hop identifiziert

Um 14:01 Uhr kam IPv4 spontan zurück – ohne Reboot, ohne Reconnect, ohne jede Aktion unsererseits (Router-Uptime lief durch, gleiche WAN-IP). Das Monitoring hat den kompletten Verlauf im Minutenraster erfasst:

Der Traceroute nach der Erholung zeigt jetzt den vollständigen Pfad – identisch bis Hop 3, aber der vorher stumme Hop 4 forwarded wieder:

 1  192.168.9.1     (Router)
 2  10.0.81.130     (Telefónica Core)
 3  10.81.102.92    (Telefónica Core – gleicher Hop wie während des Ausfalls)
 4  10.81.85.22     ← dieser Hop hat während der Ausfälle alles verworfen
 5  62.53.206.66    (öffentliches Telefónica-Netz)
 …
10  8.8.8.8         16 ms

Damit ist das verursachende Element eingegrenzt: 10.81.85.22 (CGN-/Border-Gateway). Während eines der Ausfälle antwortete Hop 5 sogar noch, während Hop 4 bereits Pakete verwarf – das Gateway hat also selektiv verworfen statt hart auszufallen, was zu einer Überlast (z. B. volle Session-Table) passt und das wiederkehrende Muster „mehrmals täglich, minuten- bis viertelstundenweise“ erklärt.

Das Monitoring läuft weiter; die nächsten Ausfallfenster liefere ich mit exakten Zeitstempeln nach.

Hey ​@dbad,

Danke für die ausführliche Antwort :) Ein Ticket bei den Kollegen wäre sicherlich der sinnvollste Weg hier!

Viele Grüße,
Flo