Massiver und protokollunabhängiger Paketverlust im O2-Netzwerk

Edit: Screenshots angehängt

​@Tannus 

Alles, was folgt, ohne Gewähr!

Du schriebst, dass manchmal nur Dienste wie google gehen. Es gab schon einmal einen Fall (oder auch mehrere Fälle), wo das IPv4-Protokoll nicht ging.

Wenn also wieder einmal nichts zu gehen scheint, außer eben google, dann öffne bitte mal ein Terminal/Bash-Fenster und gib folgendes ein:

tracert -4 google.de

bzw. bei unixoiden Systemen

traceroute -4 google.de

!

Sollte der Name nicht aufgelöst werden können, geht das IPv4-Protokoll nicht (mehr). Nutzt Du WLAN? Es gab mal eine Zeit, wo das IPv4-Protokoll im WLAN-Modus irgendwann nicht mehr ging, im LAN-Modus aber schon.

Ansonsten probiere mal bitte folgende Seite:

https://packetlosstest.com/

Mit WINMTR habe ich auch ab der zweiten IP, die mit 10 beginnt, Packetloss, aber im o. g. Test nicht!

Probleme habe ich mit dem Server aus India, unter 10 % späte Pakete, fast oder 100% späte Pakete habe ich mit Servern aus Brazil, Singapore und Australia, aber kein Packetloss.

Hi ​@GTO63 und zunächst vielen Dank für deine Antwort.

traceroute kennt den von dir vorgeschlagenen Parameter (-4) nicht. Bin aktuell auf Ubuntu unterwegs.

Mein Output:

~ ❯ traceroute google.de   
traceroute to google.de (216.58.206.35), 64 hops max
  1   192.168.178.1  5,818ms  2,073ms  2,125ms 
  2   192.168.1.1  3,326ms  2,190ms  4,206ms 
  3   10.0.80.195  19,222ms  16,983ms  17,819ms 
  4   10.81.102.57  21,317ms  21,553ms  18,622ms 
  5   10.81.85.22  19,114ms  22,704ms  17,325ms 
  6   195.71.150.242  19,358ms  19,296ms  17,655ms 
  7   62.53.4.46  23,389ms  25,611ms  24,443ms 
  8   62.53.2.158  28,852ms  24,731ms  23,350ms 
  9   62.53.14.142  23,176ms  29,565ms  23,819ms 
 10   62.53.11.13  23,207ms  24,193ms  24,011ms 
 11   *  *  * 
 12   192.178.106.11  97,851ms  23,350ms  23,551ms 
 13   142.250.214.188  28,626ms  25,982ms  25,427ms 
 14   108.170.233.59  21,420ms  24,599ms  26,970ms 
 15   216.58.206.35  29,938ms  *  * 

Mit “mtr” sehe ich übrigens immer noch packet loss am selben Hop wie zuvor. Protokoll egal (ICMP, UDP, TCP).

Nutze IPv4 only. Aktuell wie gesagt im CGNAT, aber würde gerne (sobald es wieder läuft) auf public IPv4 wechseln. Bin seit ~5 Monaten auch genau so unterwegs gewesen.

Die Namensauflösung hatte ich schon ausgeschlossen, daher auch mein Traceroute auf die 1.1.1.1 zuvor.

Ich nutze WLAN mit meinem Endgerät. Was das WLAN damit zutun haben soll, ist mir nicht bewusst. Falls du Infos oder Links dazui hast, gerne posten.

Clients über LAN sind genauso betroffen. Ich nutze als Router einen Zyxel FWA510, sollte aber nichts zur Sache tun.

Meine Ergebnisse von https://packetlosstest.com/ mit default Parametern zeigen:

• Late Packets in Georgia (1,6%), UK (6,5%), India (100%), Brasil (100%), Singapore (100%), Australia (100%)
• Sonst keine Auffälligkeiten

Theoretisch könnte man jetzt noch schauen, welche Server genau da kontaktiert werden, aber ich schätze die sind teilweise einfach down. AFAIK Nutzt die Seite unter der Haube ebenfalls UDP, ließe sich also mit “mtr” z.B. auch nachstellen.

​@Tannus 

Okay, Danke für Deine Antwort.

Was mir Sorgen macht ist UK. Ich habe mit keinem nahe Europa liegenden Server, bzw. europäischen Servern Probleme! Also gibt es bei Dir kein Packetloss!

Ich habe bei Dir den Verdacht, dass Du wegen Problemen mit dem APN netpublic hier schreibst, kann das?

Aber egal, normalerweise sollte der genannte Befehl 

traceroute -4 google.de 

bei Dir funktionieren. Aber es erscheint bei Dir ein traceroute im IPv4-Protokoll. Normalerweise wird hier per Standard (ohne -4 als Option) das IPv6-Protokoll genutzt, ich mag da aber auch irren.

Aber wie auch immer! Ich bin hier raus.

Kann es sein, dass Du wegen eines schlechten Pings im netpublic-Modus hier EIGENTLICH schreibst?

Es ist bekannt, dass bei netpublic der Ping in die Höhe geht, was des Gamers Herz in die Höhe schlagen lässt, wenn auch nicht als Freude. Aber als ausgleichende Gerechtigkeit geht wenigstens die Downloadgeschwindigkeit in die Knie.

Ist bekannt.

Wie gesagt, hier bin ich raus!

​@GTO63  Du sagst, du wärst raus, also fühle dich nicht verpflichtet zu antworten. Danke dir für deine Mühe 😊 Meine Fragen richten sich ans Plenum.

Würde diese kleine Stichprobe von https://packetlosstest.com/ jetzt nicht auf die Goldwaage legen. IMO nicht repräsentativ. Aber ich habe mir das mal genauer angesehen:

• packetlosstest.com nutzt WebRTC, was wiederum auf UDP aufbaut
• Hostname für den “Germany” Server: hde.packetlosstest.com

Mit diesen Parametern kann man einen funktional identischen Test mit mtr erstellen, was Paketverluste angeht. Siehe da: Bei ausreichend großer Stichprobe (oder mit “gutem Timing”) lässt sich der Paketverlust nachweisen:

Ich möchte klarstellen: Es geht hier NICHT um den “netpublic” APN, Pings/Latenzen oder die Bandbreite. Ich nutze das Netz aktuell wie gedacht: ”internet” APN, interne IP von O2 durch CGNAT.

Es geht um signifikante Verluste an der Stelle von o2 ins public net, exakt beim Hop 10.81.85.22. Die Geschichte ist kein Einzelfall, bin bei meiner Recherche über zahlreiche Posts gestoßen, die sogar dieselbe IP nennen und eine Problematik, die zu meiner passt. Um genauer spezifizieren zu können, was hier passiert, müsste man internes Wissen mitbringen.

Die Symptomatik ist wie zu erwarten:

• Videocalls und Gaming (UDP Traffic) laufen, sofern eine Verbindung zustande kommt. Ein Teams Call ist noch nutzbar, Online Gaming nicht wirklich. Eben nur so viel, wie die jeweilige Anwendung tolerieren kann.
• Surfing und co. (TCP Traffic) funktioniert je nach Timing und Komplexität. Lädt eine Website z.B. viele Ressourcen im Hintergrund, und sind diese Ressourcen notwendig, ist sie idR nicht nutzbar. Einfachere Seiten schon eher, ist aber letztendlich Glückssache.
• Pings (ICMP Traffic) versinken einfach, Monitoring z.B. mit Uptime Kuma o.ä. effektiv nicht möglich.

Dafür kann es mWn folgende Ursachen geben:

• Strukturelle Überlastung (Congestion)
• Fehlerhaftes Routing oder Peering-Problem
• Defekte Hardware / Linecard
• Fehlkonfigurierte QoS- oder Policing-Regeln
  • Mal vorsichtig ausgedrückt: Könnte es sich hierbei um eine bewusste, aber falsch kalibrierte Drosselungsmaßnahme handeln, die fälschlicherweise auch regulären Kunden-Traffic verwirft, anstatt nur den Netzwerk-Missbrauch zu begrenzen?

In jedem Fall kann ich leider von meiner Seite aus nichts mehr tun. Das Problem liegt nachgewiesenermaßen bei O2.

Wo kann ich mich denn noch hin wenden, wenn meine Störungsmeldung im Sande verläuft? Oder bleibt da nur die Bundesnetzagentur?

Was den First Level Support angeht:

• Nein, den Router an- und auszuschalten, löst das Problem nicht. 🤡
• Nein, ich möchte meinen Tarif nicht upgraden…

Noch ein Beispiel: Youtube nicht nutzbar

Hier mal exemplarisch im Netz eines anderen ISP, was eigentlich zu erwarten sein sollte:

Bei den vermeintlichen “Verlusten” der intermediären Hops sollte man sich nicht verunsichern lassen. Letztendlich zählt, ob beim letzten Hop Pakete verloren gehen. Hier gibt es kein Problem, Loss = 0%.

Ich bin der Meinung, das sollte als Beweisführung für das konkrete Problem genügen.

Um jede weitere Hilfe wäre ich dankbar.

​@Tannus 

<Oberlehrer Zeigefinger!>

Huerens (Hoeren Sie), in den ersten Screenshots war noch der Gateway zu sehen, was wohl eine Fritte war (oder sein soll). In den letzten Screenshots ist jeweils der Gateway demaskiert. Man kann nicht Äpfel mit Birnen vergleichen!

;)

</Oberlehrer Zeigefinger!>

Wie auch immer, die BNetzA dürfte hier nicht weiterhelfen können. Davon abgesehen, dass Du hier mit Fachbegriffen Dein Problem beschrieben hast, wo mir schwindelig wird, da ich nicht mithalten kann.

Die BNetzA mischt sich nur bei Problemen ein, wie z. B. bei Geschwindigkeitsproblemen. Dafür muss man eine Messkampagne starten, mit der App/Software der BNetzA und dokumentieren! Und zwar über eine LAN-Verbindung. 

Das stellt sich aber gerade bei dem Medium, der als extrem problematisch gilt, als schwierig heraus, da von allen Internetzugängen, die man als shared Medium (ich bleibe bei der Meinung!) betreibt, Mobilfunk der problematischste Internetzugang ist.

Natürlich, wenn Du einen Dipl.-Ing. bei der BNetzA erwischst, der Dir folgen kann, wird auch er nicht viel tun können.

Anders sieht es aus, wenn Du täglich beim LiveCheck eine Meldung tätigst:

https://www.o2online.de/netz/netzstoerung/?partnerId=SocialMedia&medium=socialpost&campaignName=CM-Commerce

Wenn Du noch Andere mobilisieren kannst, die da eine Störung melden, mit denselben Deinen Problemen, dann schaut man sich das dort vielleicht genauer an. Aber selbst da wird es schwer.

Du kannst alternativ das D2-Netz nutzen. Du erhältst dort auf Anfrage kostenlos eine öffentliche IPv4, so noch welche frei sind, was zum Daddeln reicht, aber hast keinen Zugriff von außen auf Dein Heimnetz.

Beim D1-Netz kannst Du kostenlos eine volle gültige IPv4-Adresse erhalten, aber die Verbindung lahmt entweder oder der APN (wie seit Jahren geplant) wird bald eingestellt.

​@GTO63 

Nehme die Kritik gerne entgegen, da hast du natürlich Recht. Meine Public IP wollte ich dabei einfach zensieren.

Mir ging es auch lediglich um den Endpunkt, also den letzten Hop. Da geht nichts verloren beim anderen ISP. Dennoch: Auch ohne meinen Äpfel-Birnen-Vergleich ist das beschriebene Problem weiterhin gültig, daran ändert sich nichts.

Das mit der BNetzA habe ich eher scherzhaft verwendet. Ich möchte doch eigentlich nur, dass diese Meldung es in die richtige Abteilung schafft.

Wenn ich die zahlreichen anderen verwandten Themen anschaue, verliere ich leider die Hoffnung.

Wen es interessiert, das sind ein paar davon:

Ein kleiner Lichtblick: 

Nach Aktivierung von IPv6 zeigt sich ein klares Bild:

• Verbindung über IPv4 (getestet mit mtr -4):
  • Das bekannte Problem: Massiver, realer Paketverlust, der am O2-Knoten 10.81.85.22 beginnt und sich bis zum Ziel fortsetzt.
• Verbindung über IPv6 (getestet mit mtr -6):
  • Der Datenverkehr nimmt eine komplett andere, funktionierende Route.
  • Obwohl einige Hops im O2-Netz "kosmetischen" Verlust anzeigen, fällt dieser an den nachfolgenden Knoten (Hop 6-8) wieder auf 0.0%.
  • Ergebnis: Dies beweist, dass der Traffic sauber durch das O2-Netz geleitet wird. Die Verbindung über IPv6 ist stabil.

 Beweis:

Hier ist der mtr-Trace der IPv6-Verbindung mit 200 Paketen zur Analyse:

Ja, die IPv6-Adresse habe ich zensiert 😉

• Auffällig sind die Paketverluste auf den Hops 3-5. Dies ist jedoch kein Indikator für eine Störung, wie die nachfolgenden Hops beweisen.
• Auf den Knotenpunkten 6, 7 und 8 fällt der Verlust wieder auf 0.0%. Das zeigt, dass der eigentliche Datenverkehr die vorherigen Stationen vollständig und verlustfrei passiert hat.
• Dieses Verhalten ist typisches Rate-Limiting: Router verwerfen zum Selbstschutz einen Teil der Diagnose-Anfragen, leiten den Nutzdatenverkehr aber korrekt weiter.
• Alle folgenden Verluste haben nichts mit O2 zutun, sie entstehen im (Ziel-)Netz von Google. Erneut handelt es sich um Rate-Limiting.

Fazit: Der Trace dokumentiert eine stabile und funktionsfähige IPv6-Verbindung durch das O2-Netz.

 

In einfacher Sprache:

• Im mobilen O2-Netz tritt signifikanter Paketverlust auf.

• Die Ursache konnte eindeutig auf den O2-internen Netzknoten 10.81.85.22 eingegrenzt werden.

• Die Analyse zeigt, dass das Problem ausschließlich den IPv4-Traffic betrifft.

• Der gesamte IPv6-Verkehr wird über eine separate, fehlerfreie Route geleitet und ist davon nicht betroffen.

• Dadurch ist die Stabilität für IPv4-Anwendungen (z. B. Streaming, Gaming, Serverdienste) stark beeinträchtigt

Alles Weitere müsste sich nun eigentlich die zuständige Fachabteilung anschauen. Oder zumindest jemand, der dafür bezahlt wird. Als “Normalo” ist hier das Ende der Fahnenstange erreicht.

​@Tannus 

Ist schon wahr, mit der  10.81.85.22.

Hier mein Ergebnis:

Wenn ich statt google.com google.de eintrage, ist es nicht ganz so tragisch.

​@GTO63 Vielen Dank für deine Mühe.

Das legt doch nahe, dass es sich um ein grundsätzliches Problem handelt.

Um konkrete Schlüsse ziehen zu können, müsste mMn die Anzahl der Pakete erhöht (länger laufen lassen) und verschiedene Protokolle getestet werden. Ich nutze WinMTR nicht, aber laut ChatGPT müsstest du damit auch andere Protokolle außer dem Standard (= ICMP) testen können: Options → Packet Type → ICMP / UDP / TCP

Wenn das Problem auch mit anderen Protokollen auftritt, bestätigt das die Vermutung. TCP auf Port 443 sollte aber am aussagekräftigsten sein.

Dennoch ist ein Loss genau am selben Hop wirklich auffällig. Ob es sich um ICMP Rate Limiting handelt, lässt sich leider nicht eindeutig sagen.

Subjektiv habe ich den Eindruck, dass das Problem letztes Wochenende extrem war und inzwischen stark nachgelassen hat. Trotzdem gibt es Einschränkungen bei der Internet-Nutzung. Websites im Browser müssen häufig neu geladen werden, etc.

​@GTO63 Hast du Einschränkungen feststellen können? Bist du nur mit IPv4 oder IPv4/IPv6 Dual Stack unterwegs?