Ist dies das berüchtigte Peering der Telekom?

Mir ist das ganze Problem erst so stark aufgefallen, seitdem meine Docker-Pulls ewig dauern, habe aber festgestellt, dass sich das ganze mit meinen Problemen mit Discord und SWTOR deckt; Über meine DSL-Leitung der DTAG Package Loss und Verbindungsabbrüche, mit VPN alles entspannt. Nachbar 1 mit DTAG ebenfalls Probleme bei manchen Webservices, Nachbar 2 mit 1&1 hat keine Probleme. Leider ist Routing außerhalb des LANs nie bei uns in der Berufsschule vermittelt worden, daher bin ich grad überfragt, was zu tun ist. So viele Telekom-Forumseinträge wie es gibt, brauch ich denk ich mal gar nicht versuchen ein Ticket aufzumachen... Dauerhaft über VPN arbeiten ist für mich grad aber auch keine Lösung. Hat da jemand Abhilfe-Ideen?
Edit: Traceroutes zu unterschiedlichen Zielen zeigen Package Loss entweder bei Cloudflare-IPs oder Frf1 Colt, wobei hier ja schon gesagt wurde, dass es eher wenig aussagekräftig ist.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: kieleich
nachbar2 nach dem wlan passwort fragen ;-)
 
Ich muss leider auch noch ca. ein Jahr aushalten. Ohne Proxy/VPN ist das Peering in den Abendstunden echt nicht auszuhalten.
 
Bleibt nur zu hoffen, dass mancher fanatische User und auch Moderator mal endlich registriert, dass diese Probleme, wenn auch mit ungleichmäßig starker Symptomatik, real sind.
 
  • Gefällt mir
Reaktionen: Brainorg und dropdead
Zumal der von den Magenta Fanboys vielgepriesene VPN Zugang direkt über die Fritzbox sowieso nicht richtig funktioniert. Nach einem Tag kommen dann diese Fehlermeldungen und nichts geht mehr richtig. Nur ein jeweiliger VPN Client auf den Geräten selbst ist möglich. Da braucht man wohl einen professionellen Router.

1770019648944.png
 
Also ich habe schon gehört, dass die wireguard-Implementierung auf den fritzboxen etwas eigensinnig ist und ich nutze sie auch nur zum "klassischen" Zweck (Heimnetzwerk von unterwegs erreichen), dabei allerdings ohne irgendwelche Probleme. Ob diese Probleme hier an der Implementierung liegen oder am VPN-Provider, ist schwer zu sagen. Grundsätzlich sollte DynDNS jetzt recht unabhängig davon funktionieren?

Insgesamt würde ich mir halt schon ziemlich blöd vorkommen, wenn ich zusätzlich zu meinem Internetzugangsvertrag mit meinem ISP dann noch einen weiteren Vertrag abschließen muss, um dieses Internet auch wirklich nutzen zu können. Also eine VPN-"Lösung" ist eher ein Notfall-workaround als sonst irgendetwas.

Damit eben nicht noch mehr Leute vor diesem Problem stehen und während der Mindestvertragslaufzeit bemerken, dass ihr ISP gar keinen marktüblichen Internetzugang bereitstellt, ist Aufklärung eben wichtig. Klar, wenn man noch nie etwas von diesem Problem gehört hat, denkt man vielleicht, man bekäme bei der DTAG einen besonders guten Zugang (deren "bestes Netz"-Marketing suggeriert das ja aktiv).

Und man muss natürlich hoffen, dass andere Mitbewerber nicht vom Marktführer lernen. Vodafone baut ja auch ihre Außenanbindung massiv um und verabschiedet sich vom Public Peering. Und noch bevor deren DE-CIX-Anbindung abgeschaltet ist, hatten einige Kunden massive Probleme mit fastly. Die läuft zwar ziemlich sicher nicht über den DE-CIX, das timing ist aber schon sehr ungünstig.

Immerhin gibt es auf Telekom-Infrastruktur in der Regel genügend brauchbare Mitbewerber. Bei Vodafone ist das leider nicht der Fall.
 
Web-Schecki schrieb:
Also ich habe schon gehört, dass die wireguard-Implementierung auf den fritzboxen etwas eigensinnig ist und ich nutze sie auch nur zum "klassischen" Zweck (Heimnetzwerk von unterwegs erreichen), dabei allerdings ohne irgendwelche Probleme.
Ja, das funktioniert bei mir auch tadellos. Aber selbst diese musst du dann vorher löschen, wenn du eine VPN Netzwerkkopplung zu einem VPN Anbieter anlegen willst. Ansonsten meldet die Fritzbox einen Schlüsselkonflikt. Alles nur wegen der sch.. Telekom. Am Liebsten würde ich mich mit anderen betroffenen Kunden zusammenschließen, um eine Sammelklage zu erheben damit man vorzeitig aus dem Vertrag kommt. Aber ob das rechtlich wirklich durchsetzbar wäre? Alles sehr, sehr unangenehm.
 
Ein Geschäftskunde hat es mal geschafft: https://www.reddit.com/r/de_EDV/com...ndigt_wegen_schlechtem_peering_endlich/?tl=de

Im Endeffekt ist es für die Telekom eine Kosten-Nutzen-Rechnung. Wenn du den Service so oft nervst, ist es irgendwann wirtschaftlicher, dich ziehen zu lassen. Ich denke, spätestens wenn man noch einen Anwalt einschaltet, würde die Telekom den Kunden vermutlich aus dem Vertrag lassen, um einen Präzedenzfall vor Gericht zu vermeiden.

Was mich am meisten stört ist sind die Lügen, die in der ThC verbreitet werden. Es wird immer geschrieben, die Telekom kann das Problem nicht lösen, nur Cloudflare könnte. Oder dass die Telekom keinerlei Einfluss drauf hat, wie die Daten von Cloudflare ins Netz gelangen. Warum ist man nicht wenigstens ehrlich und kommuniziert dem Kunden gegenüber offen, dass die Telekom aus wirtschaftlichen Gesichtspunkten die Entscheidung gegen Übergaben an den IXen oder settlement-free peering getroffen hat, es aber bis dato zu keiner Einigung bezüglich paid peering mit Cloudflare gekommen ist.
 
eifelman85 schrieb:
Na ja, solchen Aussagen traue ich nicht unbedingt. Vielleicht wollte derjenige auch nur etwas angeben.
Letztendlich liest man wenig über Fälle, die den Rechtsweg beschritten haben. Problem ist auch, dass in diesem Fall kein nahtloser Providerwechsel stattfinden würde. Schlecht für jemanden, der komplett im Home Office arbeitet. Die unbegrenzte Mobilfunk Flat gibt es dann vermutlich nicht mehr (Magenta Eins Vorteil). Zudem könnte die Telekom bewusst einige Sachen boykottieren, wie zum Beispiel die schnelle Löschung der Modem-ID vom OLT von Ihrer Seite aus. In der Theorie einfach aber in der Praxis existieren dann doch gewisse Stolpersteine. Sonst wären vermutlich schon viele Tipps im Netz zu lesen.
 
Zuletzt bearbeitet:
Ich bin bei der Telekom und habe seit etwas über einer Woche Probleme.
Internetseiten zeitweise laden langsam bis garnicht (Verbindungsversuch wird nach >1min abgebrochen).
Ich habe auch ein Always-Online Spiel, welches bei jedem Servercheck 10+ Sekunden braucht oder ganz DC'ed, was die Woche davor ohne Probleme lief. Hier gibt es auch hunderte Meldungen von Spielern z.b. auf Reddit die auch diese Probleme mit der Telekom deutschlandweit haben.

Wenn ich allerdings einen VPN nutze, dann sind die Probleme weg.
 
  • Gefällt mir
Reaktionen: kieleich
Bei mir hat es sich offenbar wieder weitesgehend normalisiert. In Unifi sehe ich keinen Packet Loss mehr und auch smokeping zeigt nichts mehr.

SCR-20260203-jtnv.png
SCR-20260203-jtgu.png
 
Zuletzt bearbeitet:
Bei mir hat sich nichts geändert.

Da ich mittlerweile auch Packet Loss zu dem Cloudflare WARP Endpoint hatte, habe ich mir nun den Tunnel über mein Cloudflare VPS eingerichtet.

Ohne VPN geht der Traffic mit Packet Loss über London:


Code:
Atlas (192.168.100.168) -> www.flugzeugbilder.de (104.21.44.234) 2026-02-04T15:31:29+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                 Packets               Pings
 Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. OPNSense.home.arpa                          0.0%    92    0.2   0.6   0.2  19.9   2.4
 2. 62.156.244.46                               0.0%    91   12.8   8.2   4.7  62.2   7.7
 3. 80.146.232.24                               0.0%    91    6.4   6.6   5.7  12.2   1.0
 4. lon-sb2-i.LON.GB.NET.DTAG.DE                0.0%    91   59.7  28.7  27.2  59.7   3.5
 5. ldn-b2-link.ip.twelve99.net                 0.0%    91   28.2  28.1  27.7  31.0   0.4
 6. cloudflare-ic-339870.ip.twelve99-cust.net  27.8%    91   28.5  31.4  27.8  63.4   6.7
 7. 141.101.71.121                              3.3%    91   28.7  35.9  27.8 103.7  16.9
 8. 104.21.44.234                               9.9%    91   27.2  27.3  26.8  27.8   0.2

Via Netcup geht er ohne Packet Loss über Nürnberg:


Code:
jellyfin (192.168.100.166) -> www.flugzeugbilder.de (172.67.204.22026-02-04T15:32:08+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                 Packets               Pings
 Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. OPNSense.home.arpa                          0.0%   140    0.3   0.4   0.1   5.9   0.7
 2. 10.207.155.1                                0.0%   140   24.4  24.6  24.0  30.0   0.6
 3. 5.xxx.xxx.xxx                               0.0%   140   24.7  26.2  24.5  42.6   2.8
 4. 94.16.25.158                                0.0%   140   25.2  26.1  24.1  54.2   4.8
 5. ae2-1386.rt.nbg.nue.de.retn.net             0.0%   140   24.8  26.1  24.4  46.0   2.9
 6. ae3-4.rt.eqx.fkt.de.retn.net               38.1%   139   28.0  28.2  27.5  38.3   1.3
 7. 162.158.84.12                               0.0%   139   28.8  33.3  27.6  90.4  10.9
 8. 162.158.84.79                               0.0%   139   28.2  28.0  27.5  28.5   0.2
 9. 162.158.84.39                               0.0%   139   28.7  31.6  27.7  54.6   4.8
10. 172.67.204.251                              0.0%   139   28.4  28.2  27.5  28.9   0.2
 
Die Diskrepanz könnte daran liegen, dass flugzeugbilder.de ziemlich sicher Cloudflare-Free ist, oder zumindest das dafür typische Routing über Arelion mit Übergabe in London zeigt.

Bei x.com oder hub.docker.com könnte das gut und gerne anders sein. Für "Premium"-Cloudflare-Dienste haben wir hier aus dem DTAG-AS immer andere Routen über andere Carrier gesehen, die in der Regel innerhalb Deutschlands geblieben sind und die waren auch erst seit kurzem offensichtlich problematisch.

Hier kann man sich anzeigen lassen, welcher Cloudflare-Standort jeweils für die verschiedenen Cloudflare-Tiers beantwortet. Bei den meisten Nutzern in Deutschland dürfte da überall entweder Frankfurt oder Düsseldorf stehen. Nur im "besten Netz" halt nicht :)
 
  • Gefällt mir
Reaktionen: froeschi62 und conf_t
Zurück
Oben