Interleaving (Echtzeitanwendungen)

[Zuckersüß]

Der Router steht im Flur. Da sollte es keine Störer geben und es ist wie gesagt exakt wie mit dem Docsis-Anschluss. Am Sonntag (Nacht) ist der Spuk dann wahrscheinlich wieder vorbei.

Die impulsstörfestigkeit habe ich auf alles mögliche eingestellt, es ändert sich aber nichts zum besseren/schlechteren.

Ich vermute, dass die Telekom hier ein System (Hard- oder Software) fährt, was dieses Problem verursacht und vlt. hat Vodafone das selbe System am laufen. Etwas was mit dem Paketen etwas macht.

Ich kenne 2-3 Personen, die ähnliche Probleme haben und die wohnen wie ich in einer Großstadt.

Ich hätte erwartet, dass es bei einem FTTC-Anschluss nicht zu solchen Problemen kommen sollte.

Die UDP-Pakete werden irgendwie - warum auch immer - verzögert. Vielleicht kann das jemand erklären?



Auffällig: Bei 13 Hops ist das Problem immer da. Sind es 8 bis 11 Hops, läuft es besser.

 

[KunterBunter]

Auffällig: Bei 13 Hops ist das Problem immer da. Sind es 8 bis 11 Hops, läuft es besser.

Jetzt hast du endlich die entscheidende Ursache gefunden: das Routing bei Telefonica.

 

[Zuckersüß]

Das habe ich nicht gesagt, aber es scheint einen Unterschied zu machen, ob es z.B. 11 (5x O2) oder 13 (7x O2) Hops sind.

Jetzt gerade laufen Echtzeitanwendungen wieder viel besser. Später wird es wieder eine Katastrophe.

Ich würde das Problem gerne messen bzw. sichtbar machen.

 

[tango501]

Es ist leider schwierig, die internen BGP Algorithmen und Routen Selektionskriterien des Providers zu beeinflussen. Es gibt von Lancom dazu etwas zum Thema "Beeinflussung des Routing-Algorithmus durch Attribute" was ggf. weiterhelfen könnte.
"https://www.lancom-systems.de/docs/...bgpv4_manipulation-of-routing-algorithms.html"
Alternativ bleibt nur den Provider zu kontaktieren und die Probleme zu melden, idealerweise dann immer durch Traceroute Analysen belegt.

 

[Zuckersüß]

Seit Abends sind Echtzeitanwendungen - wie angekündigt - wieder komplett unbrauchbar. Davor lief es sehr gut.

Es muss so etwas wie Traffic-Forming (Traffic-Shaping) sein. Gut möglich das Outbound-Pakete auch gelöscht werden bzw. vom Server nicht mehr akzeptiert werden, weil sie zu lange gepuffert werden. Eventuell will man auch Filesharing eindämmen und meine Echtzeitanwendung-Pakete leiden darunter. Ich weiss es auch nicht.

- Wenn der Ping in die Höhe schiessen würde, wäre das ganze nachvollziehbar
- Wenn der Jitter plötzlich stark steigen würde, wäre das ganze nachvollziehbar
- Wenn die Bandbreite (Download/Upload) plötzlich sehr niedrig wäre, wäre das ganze nachvollziehbar

Aber das alles passiert nicht.

Das einzige was ich feststellen kann sind die 4000-5000 FEC-Error pro Minute. Die FritzBox (7530 AX und 5690 Pro) zeigte zwar weniger DTU-Fehler an (~50-150) aber im Protokoll waren es ebenfalls Millionen.

Ich habe vor Verweiflung IPV6 auf meinem Asus-Router eingerichtet. Damit sind es nur 9 Hops (2 weniger), aber es ändert sich sonst nichts. Auch ein Router-Neustart hilft nicht. Es hilft alles nichts, weil das Problem am Straßenrand hockt und der Telekom gehört.

 

[Zuckersüß]

Heute gegen 11.00 Uhr lief wieder alles normal. Ich würde zu gern wissen, wieso das passiert.

• Zuviele Geräte im Heimnetzwerk (kann nicht sein weil jetzt gerade die meisten Geräte verbunden sind)
• Der AWS-Server ist das Problem (dann müssten alle Betroffen sein, was aber nicht der Fall ist)
• FEC-Fehler (Ja, diese sind hoch, aber das ist auch jetzt gerade der Fall und trotzdem lief es eben gut)
• Routing (das Routing von O2 ist schon gut, aber wenn das Problem da ist, hilft auch kein VPN oder z.B. ExitLag)
• Allgemeine Verkabelung (unwahrscheinlich da es ja zu bestimmten Uhrzeiten gut funktioniert)

Wie gesagt ist es 1:1 wie mit dem DOCSIS-Anschluss.

Ich bräuchte so etwas wie einen PingPlotter, der aber 60 Pakete pro Sekunde rausschickt und empfängt. Das ganze müsste dann mal 2-3 Tage laufen.

 

[KunterBunter]

Routing (das Routing von O2 ist schon gut, aber wenn das Problem da ist, hilft auch kein VPN oder z.B. ExitLag)

Ja, was denn nun? Oben hast du geschrieben: "Bei 13 Hops ist das Problem immer da. Sind es 8 bis 11 Hops, läuft es besser."

 

[Zuckersüß]

Ja, das beobachte ich hier auch.

Ich meine, dass das O2-Routing kein Packetloss (scheinbar) usw. verursacht und es gibt keine Peering-Probleme.

Meine Vermutung ist der DSLAM.

 

[KunterBunter]

Also meinst du, dass das Routing eine falsche Fährte ist? Ich meine nicht.

 

[Zuckersüß]

Bis auf die Anzahl an Hops, ändert sich beim Tracert-Test nichts. Es sind immer 7-9ms. Mit IPV6 sind es 8-9 Hops, alle Geräte unterwegs antworten auch.



Auch VPN (Kostenpflichtig) bringt keine Verbesserung und auch ExitLag, was für Gamer gemacht wurde, zeigt keinerlei Verbesserung sobald das Problem da ist.

Kurz: Sobald das Problem aktiv ist, hilft einfach nichts mehr. Ich muss es dann aussitzen. Ein Freund aus der Nachbarschaft (100er Telekom Leitung) hat exakt das gleiche Problem. Wir hängen aber nicht am selben DSLAM (mehrere Straßen weiter). Ich kann mir schon vorstellen, dass die Telekom hier ein System fährt, was das Problem verursacht.

EDIT:

14.30 Uhr: Es geht wieder los. Ich bin so Müde davon.

 

[Zuckersüß]

Echtzeitanwendungen funktionieren wieder nicht wie sie sollten.

Es fühlt sich an wie als würde man meine Pakete zusammenfassen (Packet-Coalescing) oder verwerfen. Die Anwendung zeigt aber keinerlei Probleme an, was aber nicht unbedingt was heissen muss, da UDP-Pakete ja "Fire and Forget" sind. Wenn unterwegs was kaputt geht, merkt es die Anwendung vielleicht nicht einmal.

FEC-Error liegen bei 4800 pro Minute im Download.



Das hängt im Treppenhaus:



Ich kann mir aber nicht vorstellen, dass hier echtes Glasfaser (FTTH, FTTB oder G.Fast) gemeint ist. Wahrscheinlich wollen die das Docsis-Netz erneuern oder so.

 

[tango501]

Der erste Screenshot gibt dazu einen Hinweis, liegt der Standort zufällig im Raum Düsseldorf?
"Basierend auf aktuellen Informationen (Stand 2025/Anfang 2026) treten im Backbone-Netz von Telefónica Deutschland (o2), insbesondere im Bereich Düsseldorf (dus.de.net.telefonica.de), sporadisch Routing- und Latenzprobleme auf. Diese äußern sich oft durch erhöhte Ping-Zeiten oder kurzzeitige Verbindungsprobleme."

 

[Zuckersüß]

Ja wohne in Düsseldorf. Ist diese Meldung aktuell? Link?

 

[tango501]

Das war das Ergebnis einer KI Suche mit Google. Ja, manchmal nutze ich eben auch Google als Quelle.

"Übersicht mit KI

Basierend auf aktuellen Informationen (Stand 2025/Anfang 2026) treten im Backbone-Netz von Telefónica Deutschland (o2), insbesondere im Bereich Düsseldorf (dus.de.net.telefonica.de), sporadisch Routing- und Latenzprobleme auf. Diese äußern sich oft durch erhöhte Ping-Zeiten oder kurzzeitige Verbindungsprobleme.
Hier sind die wichtigsten Erkenntnisse zu Routing-Problemen:

• Netzinterne Routing-Unterschiede: Es gibt Berichte, dass verschiedene PPPoE-Gateways bei Telefonica (o2) unterschiedliche Routen nutzen. Verbindungen über bestimmte Gateways (z. B. 62.52.193.57) können über andere Internetknoten (wie Mega-IX Frankfurt) geleitet werden als andere, was zu Routing-Abweichungen führen kann.
• Latenzspitzen (Ping-Spikes): Nutzer berichten von tageweisen Hängern, besonders bei Online-Spielen, während die generelle Bandbreite (Download/Upload) normal erscheint.
• Wartungsarbeiten: Gelegentliche Wartungsarbeiten im Backbone, etwa zwischen Amsterdam und Düsseldorf, können zu temporär höheren Latenzen führen.
• Peering-Probleme: Es kann zu suboptimalem Routing kommen, wenn Verbindungen vom Telefonica-Netz zu anderen Netzen (z. B. Telekom oder spezifischen CDNs) aufgebaut werden.

Empfohlene Maßnahmen bei Problemen:

1. Router-Neustart: Ein Neustart des DSL-Endgeräts (für 10 Minuten vom Strom trennen) kann helfen, eine neue IP-Adresse und ein anderes Gateway zu erhalten.
2. Traceroute prüfen: Nutzen Sie tracert oder mtr, um festzustellen, ob Pakete im Telefonica-Backbone (Knotenpunkte mit dus.de.net.telefonica.de) verloren gehen oder verzögert werden.
3. o2-Livecheck: Überprüfen Sie den o2-Netzstatus (Livecheck), ob eine regionale Störung vorliegt.
4. IPv4/IPv6: Bei Telefonie-Problemen (z. B. mit dus.net) kann es helfen, die IPv4-Verbindung zu forcieren.

Hinweis: Wenn die Probleme trotz Neustart bestehen, ist eine Meldung bei der o2-Störungshotline ratsam, da Routing-Probleme oft netzseitig behoben werden müssen."

 

[Zuckersüß]

Ich überlege, ob ich zu net.D (quasi NetCologne Tochter) wechseln soll. Meine Sorge ist nur, dass es dann nicht nur Telekom-Infrastruktur (garantiert) ist, sondern auch alles restliche der Telekom. Wenn man hier 1&1 bucht, ist das genau so. Es ist quasi Telekom mit 1&1 Logo. Bei O2 hat man wenigstens deren Backbone-Netz.

Ich frage mich, was diese Firma hier genau machen soll (1 Jahr lang).

 

[tango501]

Ein Providerwechsel wird da vermutlich auch nicht weiterhelfen. Als ich im Screenshot die Einträge mit "dus.de.net" gesehen habe, da hat bei mir etwas geklingelt und ich habe Google bei der Suche bemüht. Das damalige Problem liegt schon Jahre zurück, war an einem Anschluss der DTAG im Raum Ddorf und fehlerursächlich waren letztendlich Routingprobleme mit "dus.de.net". Da hilft jetzt leider nur bei O2 Druck zu machen, da Routing-Probleme netzseitig behoben werden müssen.

 

[Zuckersüß]

Ich weiss mittlerweile:

1.) VDSL via Telekom
2.) VDSL via 1&1
3.) VDSL via Vodafone
4.) VDSL via O2

(Immer Telekom-Infrastruktur)

Läuft hier einfach nicht gut, wenn man Echtzeitanwendungen nutzt.

Entweder es ist ein Telekom-Problem (z.B. am DSLAM) oder ein Netz-Problem. Wenn ein Providerwechsel nichts bringt, dann kann es ja nur ein Telekom-Problem sein. Ich schreibe Problem, aber damit meine ich, dass es für mich ein Problem ist und in den Augen der Telekom kein Problem sein muss, sondern etwas gewolltes.

Heute ging das hin und her. Einige Minuten lief es gut, dann wieder schlecht, dann wieder gut. Es ist 1:1 wie mit einer gestörten DOCSIS-Leitung.

Laut der Glasfaser-Firma bekommen wir FTTH.

 

[tango501]

oder ein Netz-Problem

Das Problem tritt ja nicht permanent, sonder wohl immer zu "Stoßzeiten" auf. Am DSLAM liegt es nicht. Einige der möglichen Hintergründe sind hier mal exemplarisch zusammengetragen worden.

Der Rückzug vom offenen Peering – Wie das Internet seine Neutralität verliert

Deutsche Telekom und Vodafone verlassen öffentliche Internetknoten. Was als Effizienzgewinn verkauft wird, verändert die Grundstruktur des Internets.

insights.casoon.de

Auch heise.de hat sich mit der Thematik schon mehrfach befasst.

Peering: Verbraucherschützer machen gegen "Netzbremse" der Telekom mobil

"Die Telekom drosselt das Netz", beklagen die Macher einer neuen Kampagne. Das verstoße gegen die Netzneutralität. Eine offizielle Beschwerde soll bald folgen.

www.heise.de

"Netzbremse": Beschwerde gegen Peering-Praxis der Telekom

Ein Bündnis aus mehreren Organisationen hat bei der Bundesnetzagentur eine Beschwerde wegen angeblicher Verletzungen von Netzneutralitätspflichten eingereicht.

www.heise.de

 

[Zuckersüß]

Das Routing und Peering von O2 soll doch eines der besten in Deutschland sein?

Wenn das Problem mal wieder aktiv ist, hilft auch kein VPN usw. Daher lande ich in meinen Gedanken immer wieder beim DSLAM.

Mir wurde ein Link (USA) geschickt, wo ein Gerät für DOCSIS-Internet gezeigt wird, welches genau das macht, was ich hier geschrieben habe. Es packt Pakete zusammen, um das Netz zu entlasten. Quasi 1x LKW statt 10x PKW auf der Autobahn, was aber in Echtzeitanwendungen zu Problemen führen könnte.

 

[tango501]

Ein hilfreiches Tool zur weiteren Analyse und um die Probleme ggü. dem Provider besser dokumentieren zu können.

Graphical Network Monitoring and Troubleshooting | PingPlotter

Monitor latency, packet loss, and jitter. Plot results on an infinite timeline. Find the source of problems. Share the evidence.

www.pingplotter.com