Schlechtes Routing zu Cloudflare CDN-Subnetzen über Lumen-Transit (mik.net) - hohe Latenz und Paketverlust besonders abends

vor 3 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

ae10.edge5.ber1.sp.lumen.tech 53 ms

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

Letzte Aktivität

vor 7 Minuten

von

Gelöschter Nutzer

96

10

    • vor 3 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 2 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 2 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 2 Stunden

      dem17

      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): 

      ae5.edge6.dus1.sp.lumen.tech 33 ms ← Lumen DÜSSELDORF

      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): 

      ae10.edge5.ber1.sp.lumen.tech 86 ms ← Lumen BERLIN

      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. 

      dem17

      Dies bestätigt eindeutig, dass das Problem KEIN Infrastruktur-Problem zwischen Telekom und Cloudflare ist, sondern ein spezifisches Routing-Problem für meinen Anschluss.

      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 einer Stunde

      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 einer Stunde

      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 55 Minuten

      Und was macht der 3rd Level Support?

      0

      von

      vor 7 Minuten

      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 54 Minuten

      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

    Beliebte Tags letzte 7 Tage

    Loading...Loading...Loading...Loading...Loading...Loading...Loading...Loading...Loading...Loading...