Schlechtes Routing zu Cloudflare CDN-Subnetzen über Lumen-Transit (mik.net) - hohe Latenz und Paketverlust besonders abends
vor 23 Tagen
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
464
28
Das könnte Ihnen auch weiterhelfen
7207
4
56
vor 3 Monaten
1821
5
32
vor einem Jahr
2829
4
19
215
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 23 Tagen
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.
2
von
vor 23 Tagen
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
von
vor 22 Tagen
ja, manche haben glück andere nicht. Und das kann sich im Laufe der Jahre auch ändern. VPN oder anbieter wechsel gilt generell als einziger workaround für die Telekom peering probleme.
0
Uneingeloggter Nutzer
von
vor 23 Tagen
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.
1
von
vor 23 Tagen
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 23 Tagen
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.
5
von
vor 23 Tagen
Und was macht der 3rd Level Support?
0
von
vor 23 Tagen
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
von
vor 22 Tagen
Wäre mal spannend, was deine Stichwörter waren, um etwas "umgestellt" zu bekommen. Wie hast du argumentiert und was wurde da dann umgestellt?
Das ist leider schon so lange her, ich weiß es nicht mehr.
Ich erinnere mich nur noch, dass ich über Monate Daten gesammelt und fast täglich angerufen hatte 😬
0
Uneingeloggter Nutzer
von
vor 23 Tagen
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
vor 23 Tagen
- 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
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
Unsinnig und nichtssagend.
Könntet ihr das Routing zu den genannten Cloudflare-Subnetzen prüfen lassen und gegebenenfalls auf direktes Peering umlegen?
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
Das Ziel bestimmt wie es erreicht werden will.
Also melde dich beim Ziel.
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! 🙄
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! 🙄
Was beweist das? Einfach - Cloudflare zockt den Anbieter dieser Website ab.
Die können ihre Traffic von Cloudflare optimieren lassen, dann isses Problem wie durch ein Wunder verschwunden.
7
von
vor 22 Tagen
Ich glaube, hier wird Ursache und Verantwortung etwas vermischt.
Dass beim TE @dem17 die erhöhten Latenzen AUSSERHALB des Telekom Netzes entstehen
Ich glaube, hier wird Ursache und Verantwortung etwas vermischt.
Dass die Latenz außerhalb des Telekom-Netzes entsteht, ist unstrittig. Entscheidend ist aber, dass die Wahl des Routingpfads - also über welchen Transit ein Zielnetz bzw. AS erreicht wird - beim Provider liegt und vom Endkunden nicht beeinflusst werden kann.
In unserem Fall ist klar, dass ein alternativer Pfad ( VPN ) die gleichen Zielnetze ohne Probleme erreicht. Zudem zeigen die Messungen, dass Latenz und Paketverlust erst ab einem bestimmten Übergabepunkt im Transit entstehen und danach unverändert weitergereicht werden.
Stimme ich dir zu.
Entscheidend ist aber, dass die Wahl des Routingpfads - also über welchen Transit ein Zielnetz bzw. AS erreicht wird - beim Provider liegt
Dass beim TE @dem17 die erhöhten Latenzen AUSSERHALB des Telekom Netzes entstehen
Ich glaube, hier wird Ursache und Verantwortung etwas vermischt.
Dass die Latenz außerhalb des Telekom-Netzes entsteht, ist unstrittig. Entscheidend ist aber, dass die Wahl des Routingpfads - also über welchen Transit ein Zielnetz bzw. AS erreicht wird - beim Provider liegt und vom Endkunden nicht beeinflusst werden kann.
In unserem Fall ist klar, dass ein alternativer Pfad ( VPN ) die gleichen Zielnetze ohne Probleme erreicht. Zudem zeigen die Messungen, dass Latenz und Paketverlust erst ab einem bestimmten Übergabepunkt im Transit entstehen und danach unverändert weitergereicht werden.
Ja eben beim Provider des CDNs und nicht beim ISP
von
vor 22 Tagen
Ja eben beim Provider des CDNs und nicht beim ISP
Ich glaube, hier wird Ursache und Verantwortung etwas vermischt.
Stimme ich dir zu.
Entscheidend ist aber, dass die Wahl des Routingpfads - also über welchen Transit ein Zielnetz bzw. AS erreicht wird - beim Provider liegt
Ja eben beim Provider des CDNs und nicht beim ISP
Das trifft auf den Weg der Pakete vom ISP zum CDN zu, aber nicht für den Rückweg.
Der ISP annonciert seine Netze und wählt damit den Rückweg - er kann also steuern, welchen Netzübergang z.B. der Download/Stream zum ihm nimmt.
von
vor 22 Tagen
Wir haben jetzt zwei Möglichkeiten: Entweder du weißt nicht, wie das technisch funktioniert oder du trollst bewusst. In beiden Fällen ist deine Antwort, so wie sie da steht, nicht sonderlich hilfreich.
0
Uneingeloggter Nutzer
von
vor 22 Tagen
@dem17
Ich bin hier nur Mitleser, kein Fachmann. Möchte aber einmal folgendes in den Raum stellen (falls die Erreichbarkeit doch nicht vom Ziel abhängt):
Angenommen , die Telekom verteilt ihren Netzwerkverkehr gleichmäßig auf die angeführten Lumen-Server (Lumen BERLIN, Lumen DÜSSELDORF, ...),
dann ist der Engpass doch dort, oder nicht? Und der eigentlich Engpass tritt ja sogar erst nach Lumen BERLIN auf, also definitiv außerhalb des Telekom-Netzes.
2
von
vor 22 Tagen
Guten Morgen, vom Prinzip ja, aber ihr (Telekom) bestimmt ja woher ihr mich schickt.
Wie erwähnt mein direkter Nachbar, gleicher Speedport Hybrid Router, gleicher Tarif hat diese Probleme eben nicht, da er anders geroutet wird.
Es finden ganze Paketverluste statt. Wie ein User hier geschrieben hat, merkt man das auf ganzer Linie.
Da Routing scheint ja auch nur über cloudflare zu laufen!?
0
von
vor 22 Tagen
Guten Morgen, vom Prinzip ja, aber ihr (Telekom) bestimmt ja woher ihr mich schickt.
Guten Morgen, vom Prinzip ja, aber ihr (Telekom) bestimmt ja woher ihr mich schickt.
Wie erwähnt mein direkter Nachbar, gleicher Speedport Hybrid Router, gleicher Tarif hat diese Probleme eben nicht, da er anders geroutet wird.
Es finden ganze Paketverluste statt. Wie ein User hier geschrieben hat, merkt man das auf ganzer Linie.
Da Routing scheint ja auch nur über cloudflare zu laufen!?
I.d.R:
Für den Hinweg zum Server bestimmt das der ISP des Serverbetreibers, durch annoncieren seiner Netze via Netzübergang "X".
Für den Rückweg bestimmt den Netzübergang die Telekom, sie annonciert ebenfalls ihre Netze und hat die Wahl. Es muss nicht ebenfalls via Netzübergang "X" sein, "Y" (oder jeder andere) ist ebenfalls möglich.
Uneingeloggter Nutzer
von
vor 22 Tagen
Was mir gerade aufgefallen ist, es macht einen Unterschied ob man IPv4 benutzt oder IPv6.
IPv6 alles ok
11 packets transmitted, 11 received, 0% packet loss, time 10019ms
rtt min/avg/max/mdev = 13.787/14.676/15.198/0.375 ms
IPv4 mit 36% Paketverlust und hoher Latenz
11 packets transmitted, 7 received, 36.3636% packet loss, time 10066ms
rtt min/avg/max/mdev = 292.896/317.866/351.745/23.238 ms
1
von
vor 22 Tagen
Was mir gerade aufgefallen ist, es macht einen Unterschied ob man IPv4 benutzt oder IPv6.
Was mir gerade aufgefallen ist, es macht einen Unterschied ob man IPv4 benutzt oder IPv6.
IPv6 alles ok
11 packets transmitted, 11 received, 0% packet loss, time 10019ms
rtt min/avg/max/mdev = 13.787/14.676/15.198/0.375 ms
IPv4 mit 36% Paketverlust und hoher Latenz
11 packets transmitted, 7 received, 36.3636% packet loss, time 10066ms
rtt min/avg/max/mdev = 292.896/317.866/351.745/23.238 ms
Ja, IPv6 geht gern mal ganz woanders lang, zumindest auf dem Hinweg. Im Januar hat das aber nur begrenzt geholfen, irgendwann zur Prime-Time war auch der IPv6-Weg von/zu Cloudflare verstopft.
0
Uneingeloggter Nutzer
von
vor 22 Tagen
Ich breche gerade zusammen hier.. 619MB Download soll 2 Tage dauern.
Impact.com hat über 2 Minuten gebraucht, um zu überprüfen ob ich ein Mensch bin.
So kann das nicht weitergehen :(
Update: Jetzt sind es 5 Tage 🤬
2TageDownload.png
5TageDownload.png
0
0
vor 22 Tagen
Update zum Nachweis der Tageszeit-Abhängigkeit:
Ich habe seit gestern einen kontinuierlichen Messaufbau mit SmokePing laufen,
der alle 5 Minuten 20 ICMP-Pings zu cloudflare.com (per DNS aufgelöst) sendet.
Das Ergebnis der letzten 24 Stunden zeigt eindeutig die tageszeitliche
Abhängigkeit des Problems:
Kennzahlen über 24 Stunden:
- Median-Latenz: 147 ms
- Maximum: 427 ms
- Minimum: 30,9 ms (nachts, wenn Lumen/mik.net-Transit wenig Last hat)
- Packet Loss Durchschnitt: 11,82 %
- Packet Loss Maximum: 100 %
- Aktuell (Dienstag, 21 Uhr): 409 ms Latenz, hoher Loss
Das Muster ist eindeutig:
- Montag 18-24 Uhr: 400+ ms, hoher Packet Loss
- Dienstag 00-16 Uhr: ~40 ms, stabil, kein Loss
- Dienstag ab 18 Uhr: Latenz steigt wieder auf 400+ ms an
Das bestätigt die Vermutung einer tageszeitabhängigen Überlastung des
Lumen-Transit-Pfads (Berlin → mik.net → Cloudflare), der für meinen Anschluss
genutzt wird, während andere Telekom-Kunden in unmittelbarer Nachbarschaft
(gleicher Anschlusstyp, gleiches Modem) über den funktionierenden
Düsseldorf-Lumen/COLT-Pfad geroutet werden.
Das Problem ist reproduzierbar und zeitlich klar eingrenzbar. Ich bitte
dringend um Prüfung des BGP-Routings.
0
vor 22 Tagen
Scheinbar hatte ich bisher Glück gehabt.
Dieser Zustand war mir nicht bekannt
https://netzbremse.de
Nehmt euch die Zeit!
🤨
0
Uneingeloggter Nutzer
von