Hallo zusammen,
seit einigen Tagen habe ich massive Verbindungsprobleme zu allen Diensten die Cloudflare nutzen (Discord, diverse Webseiten). Verbindungen zu anderen Anbietern funktionieren einwandfrei.
Meine Tests (direkt vom Router, 500 Pings über 8 Minuten):
- Google (8.8.8.8): 0% Packet Loss ✓
- Cloudflare (1.1.1.1): 22,4% Packet Loss
- Discord/Cloudflare (162.159.136.232): 16,2% Packet Loss
Ausgeschlossen:
- Lokales Netzwerk getestet: 0% Loss
- Keine Fehler auf Router-Interfaces
- Speedtest zum Telekom-Server: 182/40 Mbit – normal
Symptome:
- Discord Voice: Verzögerte Join-Sounds, lange Verbindungszeiten, Immer wieder Abbrüche / rejoins
- Webseiten mit Cloudflare- CDN laden langsam oder gar nicht
Das sieht für mich nach einem Peering -Problem zwischen Telekom (AS3320) und Cloudflare (AS13335) aus.
Hat noch jemand das Problem?
vor 19 Stunden
Hat noch jemand das Problem?
Hallo zusammen,
seit einigen Tagen habe ich massive Verbindungsprobleme zu allen Diensten die Cloudflare nutzen (Discord, diverse Webseiten). Verbindungen zu anderen Anbietern funktionieren einwandfrei.
Meine Tests (direkt vom Router, 500 Pings über 8 Minuten):
Ausgeschlossen:
Symptome:
Das sieht für mich nach einem Peering -Problem zwischen Telekom (AS3320) und Cloudflare (AS13335) aus.
Hat noch jemand das Problem?
Schau dir doch die Beiträge an, Deiner ist gefühlt der 270. Beitrag…….
20
von
vor 10 Stunden
Würde ich von der Telekom zu einem anderen Provider wechseln, hätte ich dann das gleiche Problem auch?
Okay.
Joar .. aber was soll man machen, wenn Cloudflare das so will?
Kann mich bitte mal jemand aufklären?
Würde ich von der Telekom zu einem anderen Provider wechseln, hätte ich dann das gleiche Problem auch?
Okay.
Falls ich mit einem anderen Provider das Problem nicht hätte, wie soll man dann die Antwort oben bewerten:
... aber was soll man machen, wenn Cloudflare das so will?
Es kommt darauf an, zu wem du wechselst.
Ich betreue ein recht bekanntes Sport-Event. Dort verlassen sich zwei Streaming-Anbieter und eine öffentlich-rechtliche Rundfunkanstalt auf unsere Glasfaseranschlüsse.
2024 kam es das erste Mal zu massiven Beschwerden.
2025 hatte ich dann einen Anschluss von Telekom 1000 Mbit/s zu [Mitbewerber, dessen Name ich nicht nenne] 600 Mbit/s wechseln lassen. Da stand dann auf einmal der Techniker vom Streamingdienst vor meiner Tür und bedankte sich für die "massiv verbesserte Leitung".
2024 hatte er noch gefrustet eine Starlinkantenne aufgebaut.
von
vor 10 Stunden
Wenn man Easybell und Maingau buchen kann, hat man immer L2- BSA und wäre bezüglich 1&1 immer im Versatel Peering .
Yep, bei easybell auch.
Wenn man Easybell und Maingau buchen kann, hat man immer L2- BSA und wäre bezüglich 1&1 immer im Versatel Peering .
Ein Kunde, der seinen Anschluss bei Easybell FTTH hat (und bei dem auch Maingau FTTH anbieten würde), befindet sich im Ecotel Netz (AS-12312).
Dasselbe gilt für mich, hier aber als DSL-Anschluss.
0
von
vor 9 Stunden
Ein Kunde, der seinen Anschluss bei Easybell FTTH hat (und bei dem auch Maingau FTTH anbieten würde), befindet sich im Ecotel Netz (AS-12312).
Dasselbe gilt für mich, hier aber als DSL-Anschluss.
Wenn man Easybell und Maingau buchen kann, hat man immer L2- BSA und wäre bezüglich 1&1 immer im Versatel Peering .
Ein Kunde, der seinen Anschluss bei Easybell FTTH hat (und bei dem auch Maingau FTTH anbieten würde), befindet sich im Ecotel Netz (AS-12312).
Dasselbe gilt für mich, hier aber als DSL-Anschluss.
Es geht hier um den generellen L2- BSA Zugang, dass man nicht über WIA auf das Telekom Peering angewiesen ist. Easybell nutzt dafür teilweise die Versatel Backbones zur Weiterleitung an Ecotel.
0
Uneingeloggter Nutzer
von
Akzeptierte Lösung
akzeptiert von
vor 11 Stunden
@dominik.lehnen , Du könntest meine Workarounds probieren.
0
9
von
vor 3 Stunden
Wofür?
Das ist eine berechtigte Frage.
von
vor 2 Stunden
gleiche probleme seit 2 wochen etwa mit discord und telekom. EInen channel joinen dauert ewig, verliert random die verbindung zu discord.
von
vor einer Stunde
Ich hab auch gleiche Probleme seit 2 oder 3 wochen:
4.|-- ae5.edge6.dus1.sp.lumen.tech 0.0% 200 11.0 12.6 9.3 54.2 5.9
5.|-- ae2.3221.edge8.frf1.neo.colt 51.5% 200 14.2 20.5 12.2 69.9 11.3
6.|-- 212.162.9.130 26.5% 200 16.5 14.7 12.1 17.8 1.5
7.|-- 162.158.84.221 26.0% 200 14.9 19.3 13.1 85.8 8.5
8.|-- 104.16.56.40 96.0% 200 13.7 13.8 13.6 14.2 0.2
51.5% TCP-Pakete verloren...
Dieses Thema wird auch auf Reddit aktiv diskutiert
https://www.reddit.com/r/de_EDV/comments/1qqhti3/cloudflare_telekom_peering_was_sagen_eigentlich/
Uneingeloggter Nutzer
von
vor 11 Stunden
@dominik.lehnen
Zum Thema Peering findest Du hier Informationen
-Klick-
Hier für Cloudflare mal ein
-Workaround-
0
0
vor 4 Stunden
@dominik.lehnen @froeschi62 @der_Lutz @chrisss3qwqwe @Max Ba. @CyberSW @Carsten_MK2 @Telekom_hat_schlechtes_Peering @Marcel2605 @CobraCane @staengfoenster
Ich habe die Mitarbeiter einer von Cloudflare gehosteten Anwendung kontaktiert und diese Antwort zur Problematik erhalten - Übersetzung aus dem Englischen ins Deutsche:
Vielen Dank für die detaillierte Analyse und die Bereitstellung der Traceroutes und Paketverlusttests – das ist sehr hilfreich.
Zur Klarstellung einiger wichtiger Punkte:
Roon nutzt Cloudflare als CDN und Edge-Netzwerk für Metadaten, Bilder und API-Traffic (z. B. api.roonlabs.net und imagecache.roonlabs.net). Wir haben keinen Einfluss darauf, wie einzelne ISPs und Cloudflare die Routen untereinander auswählen, und können auch nicht beeinflussen, zu welcher spezifischen Cloudflare-Edge-IP ein Client jeweils geleitet wird.
Ihre Tests zeigen Folgendes:
Eine Cloudflare-Edge-IP (104.20.47.62) weist zeitweise Paketverluste von der Deutschen Telekom auf.
Eine andere Cloudflare-Edge-IP (172.66.148.147) ist stabil. Das Routing über ein VPN (oder die Verwendung der stabilen IP) behebt das Problem vollständig.
Dies deutet stark auf ein Routing-/ Peering -Problem zwischen der Deutschen Telekom und einem Teil des Cloudflare-Netzwerks hin, nicht auf ein Problem in der Roon-Anwendung selbst.
Zu Ihrer Frage bezüglich Kosten oder kommerzieller Vereinbarungen: Wir können uns nicht zu Peering -Vereinbarungen, Finanzverhandlungen oder ISP -zu- CDN -Richtlinien äußern. Aus Roon-Sicht funktioniert Cloudflare wie vorgesehen, und Routing-Entscheidungen werden dynamisch zwischen Cloudflare und dem ISP getroffen.
Aktuell bieten sich folgende praktische Lösungsansätze an:
Verwendung eines VPN auf dem Roon-Server
Warten, bis sich das Routing auf den Telekom/Cloudflare-Pfaden normalisiert hat
Weiterhin Meldung des Problems an Telekom und/oder Cloudflare mit den bereits erfassten Traceroute- und Paketverlustdaten
Wir schätzen Ihre gründliche Untersuchung – sie entspricht genau unseren Erwartungen bei Routing-Instabilität als Ursache.
Bitte informieren Sie uns, falls sich etwas ändert oder das Problem weiterhin besteht, selbst wenn sich die Routing-Bedingungen verbessern.
https://community.roonlabs.com/t/timeouts-during-searching-and-browsing-artists-and-albums-ref-6xa505/314643/13?u
3
von
vor 4 Stunden
Verwendung eines VPN auf dem Roon-Server
@dominik.lehnen @froeschi62 @der_Lutz @chrisss3qwqwe @Max Ba. @CyberSW @Carsten_MK2 @Telekom_hat_schlechtes_Peering @Marcel2605 @CobraCane @staengfoenster
Ich habe die Mitarbeiter einer von Cloudflare gehosteten Anwendung kontaktiert und diese Antwort zur Problematik erhalten - Übersetzung aus dem Englischen ins Deutsche:
Vielen Dank für die detaillierte Analyse und die Bereitstellung der Traceroutes und Paketverlusttests – das ist sehr hilfreich.
Zur Klarstellung einiger wichtiger Punkte:
Roon nutzt Cloudflare als CDN und Edge-Netzwerk für Metadaten, Bilder und API-Traffic (z. B. api.roonlabs.net und imagecache.roonlabs.net). Wir haben keinen Einfluss darauf, wie einzelne ISPs und Cloudflare die Routen untereinander auswählen, und können auch nicht beeinflussen, zu welcher spezifischen Cloudflare-Edge-IP ein Client jeweils geleitet wird.
Ihre Tests zeigen Folgendes:
Eine Cloudflare-Edge-IP (104.20.47.62) weist zeitweise Paketverluste von der Deutschen Telekom auf.
Eine andere Cloudflare-Edge-IP (172.66.148.147) ist stabil. Das Routing über ein VPN (oder die Verwendung der stabilen IP) behebt das Problem vollständig.
Dies deutet stark auf ein Routing-/ Peering -Problem zwischen der Deutschen Telekom und einem Teil des Cloudflare-Netzwerks hin, nicht auf ein Problem in der Roon-Anwendung selbst.
Zu Ihrer Frage bezüglich Kosten oder kommerzieller Vereinbarungen: Wir können uns nicht zu Peering -Vereinbarungen, Finanzverhandlungen oder ISP -zu- CDN -Richtlinien äußern. Aus Roon-Sicht funktioniert Cloudflare wie vorgesehen, und Routing-Entscheidungen werden dynamisch zwischen Cloudflare und dem ISP getroffen.
Aktuell bieten sich folgende praktische Lösungsansätze an:
Verwendung eines VPN auf dem Roon-Server
Warten, bis sich das Routing auf den Telekom/Cloudflare-Pfaden normalisiert hat
Weiterhin Meldung des Problems an Telekom und/oder Cloudflare mit den bereits erfassten Traceroute- und Paketverlustdaten
Wir schätzen Ihre gründliche Untersuchung – sie entspricht genau unseren Erwartungen bei Routing-Instabilität als Ursache.
Bitte informieren Sie uns, falls sich etwas ändert oder das Problem weiterhin besteht, selbst wenn sich die Routing-Bedingungen verbessern.
https://community.roonlabs.com/t/timeouts-during-searching-and-browsing-artists-and-albums-ref-6xa505/314643/13?u
Das klingt doch ganz gut erstmal...?
0
von
vor 4 Stunden
Das klingt doch ganz gut erstmal...?
Verwendung eines VPN auf dem Roon-Server
@dominik.lehnen @froeschi62 @der_Lutz @chrisss3qwqwe @Max Ba. @CyberSW @Carsten_MK2 @Telekom_hat_schlechtes_Peering @Marcel2605 @CobraCane @staengfoenster
Ich habe die Mitarbeiter einer von Cloudflare gehosteten Anwendung kontaktiert und diese Antwort zur Problematik erhalten - Übersetzung aus dem Englischen ins Deutsche:
Vielen Dank für die detaillierte Analyse und die Bereitstellung der Traceroutes und Paketverlusttests – das ist sehr hilfreich.
Zur Klarstellung einiger wichtiger Punkte:
Roon nutzt Cloudflare als CDN und Edge-Netzwerk für Metadaten, Bilder und API-Traffic (z. B. api.roonlabs.net und imagecache.roonlabs.net). Wir haben keinen Einfluss darauf, wie einzelne ISPs und Cloudflare die Routen untereinander auswählen, und können auch nicht beeinflussen, zu welcher spezifischen Cloudflare-Edge-IP ein Client jeweils geleitet wird.
Ihre Tests zeigen Folgendes:
Eine Cloudflare-Edge-IP (104.20.47.62) weist zeitweise Paketverluste von der Deutschen Telekom auf.
Eine andere Cloudflare-Edge-IP (172.66.148.147) ist stabil. Das Routing über ein VPN (oder die Verwendung der stabilen IP) behebt das Problem vollständig.
Dies deutet stark auf ein Routing-/ Peering -Problem zwischen der Deutschen Telekom und einem Teil des Cloudflare-Netzwerks hin, nicht auf ein Problem in der Roon-Anwendung selbst.
Zu Ihrer Frage bezüglich Kosten oder kommerzieller Vereinbarungen: Wir können uns nicht zu Peering -Vereinbarungen, Finanzverhandlungen oder ISP -zu- CDN -Richtlinien äußern. Aus Roon-Sicht funktioniert Cloudflare wie vorgesehen, und Routing-Entscheidungen werden dynamisch zwischen Cloudflare und dem ISP getroffen.
Aktuell bieten sich folgende praktische Lösungsansätze an:
Verwendung eines VPN auf dem Roon-Server
Warten, bis sich das Routing auf den Telekom/Cloudflare-Pfaden normalisiert hat
Weiterhin Meldung des Problems an Telekom und/oder Cloudflare mit den bereits erfassten Traceroute- und Paketverlustdaten
Wir schätzen Ihre gründliche Untersuchung – sie entspricht genau unseren Erwartungen bei Routing-Instabilität als Ursache.
Bitte informieren Sie uns, falls sich etwas ändert oder das Problem weiterhin besteht, selbst wenn sich die Routing-Bedingungen verbessern.
https://community.roonlabs.com/t/timeouts-during-searching-and-browsing-artists-and-albums-ref-6xa505/314643/13?u
Das klingt doch ganz gut erstmal...?
Nee :(
Geht nur beispielsweise auf einem Windows PC oder entsprechender Maschine, die 24/7 läuft. Geht nicht auf meinem Headless Linux OS NUC.
ROCK OS von Roon Labs ist ein geschlossenes System für Intel NUC, das keine Anpassungen oder die Installation zusätzlicher Software erlaubt.
0
von
vor 3 Stunden
Aus Roon-Sicht funktioniert Cloudflare wie vorgesehen, und Routing-Entscheidungen werden dynamisch zwischen Cloudflare und dem ISP getroffen.
@dominik.lehnen @froeschi62 @der_Lutz @chrisss3qwqwe @Max Ba. @CyberSW @Carsten_MK2 @Telekom_hat_schlechtes_Peering @Marcel2605 @CobraCane @staengfoenster
Ich habe die Mitarbeiter einer von Cloudflare gehosteten Anwendung kontaktiert und diese Antwort zur Problematik erhalten - Übersetzung aus dem Englischen ins Deutsche:
Vielen Dank für die detaillierte Analyse und die Bereitstellung der Traceroutes und Paketverlusttests – das ist sehr hilfreich.
Zur Klarstellung einiger wichtiger Punkte:
Roon nutzt Cloudflare als CDN und Edge-Netzwerk für Metadaten, Bilder und API-Traffic (z. B. api.roonlabs.net und imagecache.roonlabs.net). Wir haben keinen Einfluss darauf, wie einzelne ISPs und Cloudflare die Routen untereinander auswählen, und können auch nicht beeinflussen, zu welcher spezifischen Cloudflare-Edge-IP ein Client jeweils geleitet wird.
Ihre Tests zeigen Folgendes:
Eine Cloudflare-Edge-IP (104.20.47.62) weist zeitweise Paketverluste von der Deutschen Telekom auf.
Eine andere Cloudflare-Edge-IP (172.66.148.147) ist stabil. Das Routing über ein VPN (oder die Verwendung der stabilen IP) behebt das Problem vollständig.
Dies deutet stark auf ein Routing-/ Peering -Problem zwischen der Deutschen Telekom und einem Teil des Cloudflare-Netzwerks hin, nicht auf ein Problem in der Roon-Anwendung selbst.
Zu Ihrer Frage bezüglich Kosten oder kommerzieller Vereinbarungen: Wir können uns nicht zu Peering -Vereinbarungen, Finanzverhandlungen oder ISP -zu- CDN -Richtlinien äußern. Aus Roon-Sicht funktioniert Cloudflare wie vorgesehen, und Routing-Entscheidungen werden dynamisch zwischen Cloudflare und dem ISP getroffen.
Aktuell bieten sich folgende praktische Lösungsansätze an:
Verwendung eines VPN auf dem Roon-Server
Warten, bis sich das Routing auf den Telekom/Cloudflare-Pfaden normalisiert hat
Weiterhin Meldung des Problems an Telekom und/oder Cloudflare mit den bereits erfassten Traceroute- und Paketverlustdaten
Wir schätzen Ihre gründliche Untersuchung – sie entspricht genau unseren Erwartungen bei Routing-Instabilität als Ursache.
Bitte informieren Sie uns, falls sich etwas ändert oder das Problem weiterhin besteht, selbst wenn sich die Routing-Bedingungen verbessern.
https://community.roonlabs.com/t/timeouts-during-searching-and-browsing-artists-and-albums-ref-6xa505/314643/13?u
Und hier ist der Fehler.
Cloudflare will von Roon Geld um deren Traffic zu "optimieren".
Wenn man diese "Argo Smart Routing" aktiviert, sind die Probleme plötzlich verschwunden - dafür hast dann Kosten die bei 0,10 USD pro GB beginnen.
Da kommen dann schnell einige USDs zusammen, wenn man ein größeres Angebot hat.
Die machen genau das, was so klassisch ist.
Glauben Cloudflare würde für sie alles machen und verlagern die Probleme einfach an Cloudflare.
Die sind keine eierlegende Wollmilchsau mit großen Sozialkomplexx - der für die ganze Welt alles für lau macht.
Ja - sie machen sehr viel, sie haben gute Funktionen, sie sichern große DDoS Angriffe ab.
Wobei man gerade letzteres auch merkt, fast immer wenn sie wieder feiern was sie abgewehrt haben - hat man das als User vorher bemerkt.
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von