Massiver und protokollunabhängiger Paketverlust im O2-Netzwerk

Hallo ​@o2_Matze, danke für deine Rückmeldung und fürs Weitergeben an die IT. 🙂

Ich kann die Verbesserung für meinen Anschluss bestätigen. Seit dem Nachmittag des 16.07. ist das frühere ziel- und verbindungsabhängige Fehlerbild im laufenden Router-Monitoring nicht mehr aufgetreten.

Zur Kontrolle habe ich den nativen o2-Pfad unter Umgehung meines Tunnels getestet. Die Routing-Ausnahme habe ich per Traceroute geprüft. Bei 30 aufeinanderfolgenden TCP-Verbindungen zu 1.0.0.1:443 gab es weder auffällige Verzögerungen noch Timeouts. Ein nativer Test mit 100 Pings zu 9.9.9.9 blieb ohne Verlust. Das frühere Fehlerbild ließ sich dabei nicht reproduzieren. Der Tunnel ist inzwischen deaktiviert. Auch mein regulärer Datenverkehr läuft wieder nativ über o2.

Außerdem zeigen meine Messungen zwei Veränderungen: Die nach außen sichtbare IPv4 stammt seit dem 16.07. aus einem anderen Adressbereich (46.114.x statt zuvor 176.7.x), und im Traceroute sind auf dem getesteten nativen Pfad keine o2-internen Hops mehr erkennbar. Welche interne Änderung dahintersteht, geht daraus nicht hervor.

5G SA habe ich entsprechend eurer Empfehlung am Modem deaktiviert. Derzeit ist das Modem über 5G NSA verbunden, mit LTE-Band 3 als Anker und n78 als 5G-Träger.

Vielen Dank auch an alle Beteiligten im Hintergrund für die Unterstützung. Das Monitoring lasse ich erstmal weiterlaufen und melde mich, falls das Fehlerbild erneut auftritt.

Viele Grüße

Hi ​@Walfischdreck 

Super, das sind doch großartige Nachrichten \o/ 

Vielen Dank auch an alle Beteiligten im Hintergrund für die Unterstützung.

Den Dank leite ich gerne weiter (ich glaube die Kollegen lesen hier aber eh heimlich mit 😄)

Das Monitoring lasse ich erstmal weiterlaufen und melde mich, falls das Fehlerbild erneut auftritt.

Das klingt nach einem guten Plan, sollte also noch was auffälliges in den Logs aufploppen ping uns hier einfach an. 

VG Matze 

Hallo ​@o2_Matze 

Es sieht so aus, als hätte ich wieder dasselbe Problem. 

Die Probleme liegen wohl wieder bei 10.81.85.22 und vermutlich spätestens seit gestern Nachmittag ;( 

Die folgende Screenshot ist eine Beispiel gegen 8 Uhr am 11.08.  Es wäre gut, wenn du die Technik-Team noch einmal informierst. Ich nutze gerade 5G NSA und bin in NRW.

​@ananas1111 

Wo exakt in NRW ?

​@The_Voice_70 Aachen

​@ananas1111 Vielen Dank für deine Meldung. Das ganze ist heute plötzlich aufgetreten?  Besteht der Fehler weiterhin, oder war das ganze nur ein temporärer Schluckauf heute Vormittag? 

VG Matze 

​@o2_Matze Hi, es ist gut möglich, dass es immer wieder zu Problemen kommt, aber seit gestern hat sich das Problem deutlich verschlimmert. Es kommt immer wieder zu Paketverlusten von deutlich über 80 %.

Momentan besteht das Problem weiterhin und es scheint, als würde es jetzt über MegaIX statt DE-CIX laufen. Der Paketverlust liegt aktuell bei etwa 50 %, siehe Screenshot:

​@ananas1111 Wir geben es gerne an die Fachabteilung zur Prüfung weiter. Kannst du noch kurz was zur verwendeten Hardware sagen, der Vollständigkeit halber will die Netztechnik auch immer was zu den Hintergründen wissen, also wo tritt der Fehler auf (an deiner Kontaktadresse?) und welche Hardware wird verwendet und bist du im 4G oder 5G Netz eingebucht und gibt es Unterschiede beim Fehler, je nachdem in welchem Netz du eingebucht bist?

VG Matze  

​@o2_Matze 

vielen Dank für deine Rückmeldung. Zur Hardware: Ich nutze eine Banana Pi R3 Mini mit einem Foxconn T99W175 WWAN-Modul (Qualcomm) sowie ein TCL-Tablet (MTK) mit 5G SA. Ich habe alle möglichen Modi (4G/5G NSA/SA) ausprobiert, aber das macht gar keinen Unterschied. Deswegen denke ich, dass das Problem sehr wahrscheinlich am O2-Backbone liegt.

Und ja, der aktuelle Betriebsort ist genau an meiner Kontaktadresse. Sag einfach Bescheid, was ich noch testen soll. 

Viele Grüße

​@ananas1111 Vielen Dank für die Infos. Wir nehmen ein Fehlerticket dazu auf und adressieren das an die Netztechnik, das ganze ist aber immer hoch komplex, daher vermag ich nicht zu sagen wie schnell hier die Fachabteilung aktiv werden kann, wir sind aber guter Dinge, das wir hier auch wie bei ​@Walfischdreck eine Lösung finden werden.

VG Matze 

​@ananas1111 Die Technik konnte im ersten Step den Fehler noch nicht lokalisieren, wir bleiben da aber am Ball und sind da hinter den Kulissen weiter für dich aktiv.

VG Matze 

​@o2_Matze Vielen Dank für deine Rückmeldung. 

Ich möchte noch einmal ein sehr spezifisches Detail im MTR-Muster hervorheben, das mir bei der Analyse aufgefallen ist und das hoffentlich bei der internen Fehlersuche hilft:

Der Paketverlust tritt nicht gleichmäßig (wie bei einer einfachen Überlastung) auf, sondern zeigt ein strikt phasenweises / blockweises Verhalten (Black-Hole-Flapping):

- Phase A: Für ca. 10–30 Sekunden gehen alle Pakete mit perfekter Latenz durch (...).
- Phase B: Schlagartig bricht die Verbindung ab und es folgen 10–30 Sekunden mit 100 % Paketverlust synchron auf allen Hops ab `10.81.85.22` bis zum Ziel (???).

Und danach wiederholt sich das Ganze kontinuierlich: Phase A→B→A→B... Dies lässt sich fast jederzeit mit `mtr` beobachten.

Das betrifft nicht nur ICMP (Ping), sondern protokollunabhängig auch z.B. TCP (mtr mit -T). Durch TCP-Retransmissions ist die gemessene Paketverlustrate bei TCP zwar scheinbar niedriger, aber das Störungsmuster bleibt exakt dasselbe.

Hingegen ist IPv6 immer einwandfrei, wie von praktisch jedem hier schon bestätigt wurde. Ich hoffe, das hilft euch, das Problem einzugrenzen und zu finden!

ICMP:

TCP: