Schlechtes Routing zu Cloudflare CDN-Subnetzen über Lumen-Transit (mik.net) - hohe Latenz und Paketverlust besonders abends
vor 5 Stunden
Hallo zusammen,
ich habe seit Wochen abends massive Probleme beim Surfen: Webseiten laden langsam, Bilder kommen nur teilweise, Videos buffern. Tagsüber meistens unauffällig, abends regelmäßig sehr schlecht. Ein Speedtest läuft dabei normal durch, das eigentliche Surfen ist trotzdem zäh.
Nach umfangreicher Diagnose habe ich das Problem auf ein Routing-Problem zu Cloudflare- CDN -Subnetzen zurückführen können. Da praktisch jede moderne Webseite Cloudflare als CDN nutzt, betrifft mich das im Alltag massiv.
**Meine Anschluss-Daten:**
- Anschluss: Telekom MagentaZuhause Hybrid (DSL + LTE )
- Modem: Speedport Hybrid
- Router: Ubiquiti UDM Pro hinter dem Speedport
- Standort: Bielefeld, Nordrhein-Westfalen
**Symptome:**
- Pings zu 1.1.1.1 (Cloudflare): 37 ms, 0 % Paketverlust → einwandfrei
- Pings zu 8.8.8.8 (Google): 33 ms, 0 % Paketverlust → einwandfrei
- Pings zu 9.9.9.9 (Quad9): 35 ms, 0 % Paketverlust → einwandfrei
- Pings zu Cloudflare CDN -IPs (z. B. 104.16.132.229): 290 ms durchschnittlich, 12-13 % Paketverlust
- Pings zu weiteren Cloudflare-IPs:
- 104.16.0.1: 295 ms, 27 % Paketverlust
- 162.159.200.123: 293 ms, 17 % Paketverlust
- 198.41.128.1: 100 % Paketverlust (komplett unerreichbar)
**Traceroute zu 104.16.132.229:**
1 unifi.localdomain (192.168.178.1) 0.3 ms
2 192.168.2.1 (Speedport) 1.4 ms
3 * * *
4 217.237.147.13 38 ms
5 195.145.92.80 46 ms
6 b-eh3-i.B.DE.NET. DTAG .DE (62.153.188.78) 47 ms
7 ae10.edge5.ber1.sp.lumen.tech 53 ms
8 dialup-212.162.17.178.frankfurt1.mik.net 331 ms ← +280 ms in einem Hop!
9 104.16.132.229 (Cloudflare) 319 ms
**Zwischen Hop 7 (Lumen Berlin) und Hop 8 (mik.net "Frankfurt") springt die Latenz um +280 ms.** Diese Distanz entspricht physikalisch ca. 28.000 km Glasfaser - was natürlich nicht der reale Berlin-Frankfurt-Pfad sein kann. Vermutlich wird der Traffic über einen weit entfernten internationalen Backbone-Knoten geroutet, statt direkt zu Cloudflares Frankfurt-PoP über DE-CIX.
**Was bisher ausgeschlossen wurde:**
- Lokales Netzwerk-Problem: Pings zu 1.1.1.1 sind perfekt, also ist die Anbindung grundsätzlich gesund
- DNS-Problem: DNS-Auflösung funktioniert sauber, IPs sind korrekt
- Eigenes Setup: Pi-hole und Router-Konfiguration wurden geprüft und sind sauber
- Speedtest-Bandbreite: Volle Geschwindigkeit verfügbar
**Vermutung:**
Der Traffic zu Cloudflare-Subnetzen 104.16.0.0/12 und 162.159.0.0/16 wird über einen überlasteten Lumen-Transit (Hop "ae10.edge5.ber1.sp.lumen.tech") geroutet, statt über das direkte Cloudflare- Peering am DE-CIX in Frankfurt. Besonders zu den Abendstunden wird der Lumen-Pfad offenbar überlastet, was zu hohem Paketverlust und Latenz führt.
**Bitte um Prüfung:**
Könntet ihr das Routing zu den genannten Cloudflare-Subnetzen prüfen lassen und gegebenenfalls auf direktes Peering umlegen? Dass IPs aus demselben Cloudflare-Netzwerk so stark unterschiedlich erreichbar sind (1.1.1.1 perfekt, 104.16.x.x katastrophal), deutet auf ein Routing-Problem auf Telekom-Backbone-Seite hin.
Ich nutze aktuell als Workaround ein VPN über einen anderen Provider, was das Problem komplett umgeht - das bestätigt, dass es ein Telekom-spezifisches Routing-Problem ist.
Vielen Dank vorab für eine Rückmeldung!
Viele Grüße
120
10
Das könnte Ihnen auch weiterhelfen
7103
4
56
vor 3 Monaten
1797
4
32
1687
0
4
vor einem Jahr
2781
4
19
207
0
3
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.

Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.

vor 4 Stunden
Du wirst hier leider keine Lösung finden. Offizielle Stellung der Telekom hier im Forum ist, das es kein Problem auf Seiten der Telekom gibt. Einfach das Board nach dem Schlagwort Peering durchsuchen und du wirst fündig.
0
1
von
vor 4 Stunden
Hi,
ja verstehe was du meinst. Aber das Problem ist ja weg wenn ich per VPN surfe.
Mein Nachbar hat den identischen Tarif und Hardware. Der hatte gerade Zeit und hat andere Daten, da er auch anders geroutet wird.
0
Uneingeloggter Nutzer
von
vor 4 Stunden
WICHTIGES UPDATE - DEFINITIVER BEWEIS FÜR FEHLERHAFTES BGP-ROUTING:
Ich habe den gleichen Test bei meinem direkten Nachbarn (Reihenhaus nebenan)
durchgeführt. Die Rahmenbedingungen sind IDENTISCH:
- Gleicher Anschluss-Typ: MagentaZuhause Hybrid
- Gleiches Modem: Speedport Hybrid
- Gleiche DSLAM / gleiche Vermittlungsstelle
- Gleiche LTE -Zelle
Trotzdem zeigt sein Traceroute zur identischen Cloudflare-IP einen
KOMPLETT ANDEREN PFAD mit einwandfreier Performance:
Nachbar (funktioniert):
5 195.145.92.86 35 ms
6 d-ed5-i.d.de.net.dtag.de 33 ms
7 ae5.edge6.dus1.sp.lumen.tech 33 ms ← Lumen DÜSSELDORF
8 ae2.3216.ear4.frf1.neo.colt.net 45 ms ← COLT Frankfurt
9 212.162.9.130 39 ms
10 162.158.84.251 38 ms ← Cloudflare Edge
11 104.16.132.229 36 ms ← Ziel (sauber!)
Mein Anschluss (defekt):
6 b-eh3-i.B.DE.NET. DTAG .DE 45 ms
7 ae10.edge5.ber1.sp.lumen.tech 86 ms ← Lumen BERLIN
8 dialup-212.162.17.178.frankfurt1.mik.net 413 ms ← mik.net (kaputt!)
9 104.16.132.229 361 ms
Zwei Nachbarn im Reihenhaus mit identischem Setup werden auf unterschiedliche
Telekom-Backbone-Routen geleitet:
- Nachbar: Telekom → Düsseldorf-Lumen → COLT → Cloudflare (sauber, 36ms)
- Ich: Telekom → Berlin-Lumen → mik.net → Cloudflare (defekt, 290-413ms)
Das ist ein eindeutiges BGP-Routing-Problem auf meinem Anschluss. Bitte
prüfen Sie dringend, warum mein Traffic zu den Cloudflare- CDN -Subnetzen
(104.16.0.0/12, 162.159.0.0/16) über den problematischen Berlin-Lumen-Pfad
mit defektem mik.net-Weiterleiter geleitet wird, während mein Nachbar mit
identischem Anschluss den korrekten Düsseldorf-Weg über COLT erhält.
0
1
von
vor 3 Stunden
Dies bestätigt eindeutig, dass das Problem KEIN Infrastruktur-Problem zwischen Telekom und Cloudflare ist, sondern ein spezifisches Routing-Problem für meinen Anschluss.
Da ich den Beitrag nicht bearbeiten kann hier ein WICHTIGES UPDATE:
Ich habe den gleichen Test bei einem Nachbarn durchgeführt, der ebenfalls Telekom-Kunde ist.
Sein Traceroute zur gleichen Cloudflare-IP (104.16.132.229) zeigt einen KOMPLETT ANDEREN PFAD:
Nachbar (gleicher Anschlusstyp):
7 ae5.edge6.dus1.sp.lumen.tech 33 ms ← Lumen DÜSSELDORF
8 ae2.3216.ear4.frf1.neo.colt.net 45 ms ← COLT Frankfurt
9 212.162.9.130 39 ms
10 162.158.84.251 38 ms ← Cloudflare Edge
11 104.16.132.229 36 ms ← Ziel erreicht
Meine Route (problematisch):
7 ae10.edge5.ber1.sp.lumen.tech 86 ms ← Lumen BERLIN
8 dialup-212.162.17.178.frankfurt1.mik.net 413 ms ← Mik.net (defekt!)
9 104.16.132.229 361 ms
Zwei Telekom-Kunden in unmittelbarer Nähe (6-8 meter), selbe Ziel-IP, aber KOMPLETT unterschiedliche Routing-Pfade.
Der Nachbar hat eine saubere Route über Düsseldorf-Lumen und COLT nach Frankfurt (36ms).
Mein Traffic wird über Berlin-Lumen und mik.net geschickt mit 300-400ms Latenz.
Dies bestätigt eindeutig, dass das Problem KEIN Infrastruktur-Problem zwischen Telekom und Cloudflare ist, sondern ein spezifisches Routing-Problem für meinen Anschluss. Vermutlich ist im BGP-Routing meines Anschlusspunkts ein fehlerhafter oder veralteter Pfad hinterlegt.
Bitte prüft dringend, warum mein Traffic zu Cloudflare- CDN -Subnetzen (104.16.0.0/12, 162.159.0.0/16) über den problematischen Berlin-Lumen-Pfad geroutet wird, während andere Telekom-Kunden in der Region den korrekten Düsseldorf-Pfad erhalten.
Die Teil-Tracerts, die du hier postest zeigen doch eindeutig, dass die Pakete das Netz der Telekom schon verlassen haben. Die Telekom kann dagegen nichts tun, das Ziel entscheided, wie es erreicht werden will.
Uneingeloggter Nutzer
von
vor 3 Stunden
Hey!
Ich habe exakt das selbe Problem mit exakt dem selben Hops. Bei mir geht das aber teilweise schon mittags los.
Ab ae10.edge5.ber1.sp.lumen.tech geht die Latenz deutlich hoch und ab dialup-212.162.17.178.frankfurt1.mik.net kommt Paketloss um die 30% dazu.
Vom 1st-Level bin ich natürlich sofort abgewimmelt worden.
Ich hatte ein ähnliches Problem vor einigen Jahren und da bin ich nach monatelangen Beschwerden umgestellt worden und das Problem war gelöst.
0
4
von
vor 3 Stunden
Ja.. Man muss es zum 3rd Level schaffen, da wird einem geholfen. Das Problem ist, da mal verbunden zu werden. Meistens wird man im 1st Level abgewimmelt. Auch wenn man ganz offensichtlich weiß, wovon man spricht.
0
von
vor 2 Stunden
Und was macht der 3rd Level Support?
0
von
vor 2 Stunden
Wäre mal spannend, was deine Stichwörter waren, um etwas "umgestellt" zu bekommen. Wie hast du argumentiert und was wurde da dann umgestellt?
0
Uneingeloggter Nutzer
von
vor 2 Stunden
Bemüh dich nicht, du wirst immer wieder sowas sehen:
Disclaimer: Die Telekom ist natürlich nicht schuld, schließlich haben die das beste Netz, stand sogar auf meinem Smartphone, kann also gar nicht sein! 🙄
0
0
Uneingeloggter Nutzer
von