Hallo,
ich betreibe diverse Webseiten, welche Cloudflare Services als Proxy davor geschalten haben.
Ich habe bei meinen eigenen und bei anderen Cloudflare Seiten seit 3 Tagen große Probleme.
Das Aufrufen dieser Seiten reicht mal von 10 Sekunden bis 3 Minuten.
Ich habe in Cloudflare alles richtig eingestellt und habe sichergestellt, dass das Aufrufen dieser in anderen Regionen normal funktioniert.
Gibt es dort Möglichkeiten zu sehen ob daran schon gearbeitet wird? Und ob es ein Telekom Problem ist oder ein Cloudflare Problem?
Ein Geschäftspartner hat mit einem anderen Anbieter in einer anderen Stadt keinerlei Probleme.
Es gibt auch bereits ein paar Berichte im Cloudflare Forum von Nutzern aus Berlin mit gleichen Problemen.
Ich persönlich komme aus Ecke NRW, daher denke ich es könnte schon ein Deutschland weites Problem sein.
Danke für Ihre Antworten.
vor 2 Jahren
Dass liegt daran, dass cloudflare keine direkte Anbindung an das Telekom Backbone hat, geht also vermutlich über den DE-CIX
Google mal "telekom Peering ", da wird einiges erklärt dazu und wieso es dann zu solchen Einschränkuingen kommen kann.
Kurzform: Telekom Problem, die wollen für das direkte Peering Geld von Anbietern wie cloudflare. Die wollen aber logischerweise nicht extra dafür zahlen.
2
Antwort
von
vor 2 Jahren
Okay, allerdings ist das jetzt seit 5 Jahren, das erste Mal so, dass ich es überhaupt bemerke, und dann Ladezeiten von 3 Minuten.
Antwort
von
vor 2 Jahren
Dass liegt daran, dass cloudflare keine direkte Anbindung an das Telekom Backbone hat, geht also vermutlich über den DE-CIX
Die Telekom peert nur ein Bruchteil des Traffic am DE-CIX, bevorzugt werden dezentrale und regionale Peerings. Bei mir z.B. meistens über Düsseldorf an fast alle Carrier.
W:\Temp>tracert cloudfare.com
Routenverfolgung zu cloudfare.com [172.67.211.231]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms pfSense.localnet [10.253.0.1]
2 4 ms 4 ms 4 ms p3e9bf44a.dip0.t-ipconnect.de [62.155.244.74]
3 7 ms 7 ms 7 ms d-ed5-i.D.DE.NET. DTAG .DE [217.5.117.54]
4 7 ms 7 ms 7 ms d-ed5-i.D.DE.NET. DTAG .DE [217.5.117.54]
5 33 ms 20 ms 16 ms 4.68.71.113
6 7 ms 7 ms 7 ms CLOUDFLARE.edge6.Dusseldorf1.Level3.net [62.67.22.246]
7 7 ms 7 ms 7 ms 172.67.211.231
Ablaufverfolgung beendet.
Sieht sogar nach einer Colocation da aus, weil geht nicht mal über den Teich.
Uneingeloggter Nutzer
Antwort
von
vor 2 Jahren
Cloudflare ist nicht gleich Cloudflare - man kann bei denen auch verschiedene QoS Stufen buchen.
UND oftmals wird bei denen auch NUR der Schutz vor DDoS genutzt ... heißt die IP von Cloudflare ist NICHT das Ende der Kette.
Heißt nach der IP von denen geht das Routing noch weiter und da kann es auch Probleme geben.
Das ist dann nicht das Peering Cloudflare <--> Telekom sondern Cloudflare <--> HostingPartnerCFKunde.
2
Antwort
von
vor 2 Jahren
Ich hoste meine Seiten auf Hetzner Servern, und da sollte es meiner Erfahrung nach zumindest kein dauerhaftes Problem geben.
Zudem passiert dieses lange Laden nicht nur auf meinen Seiten sondern auf anderen Cloudflare Proxy Seiten mit ganz anderen Hostern im Hintergrund.
Antwort
von
vor 2 Jahren
Hallo @MarvinD
Willkommen in unserer Community. Da es sich dabei um Peering handelt, kann ich dir zu den bereits erhaltenen Infos von den anderen Usern (danke dafür) folgende Seite an die Hand geben: https://telekomhilft.telekom.de/t5/Festnetz-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung-hohe-PING-Zeiten/ta-p/4265259
Ich hoffe, dies hilft weiter. 😉
Viele Grüße & ein schönes Wochenende.
Nadine H.
Uneingeloggter Nutzer
Antwort
von
Akzeptierte Lösung
akzeptiert von
vor 2 Jahren
Hallo @MarvinD
Willkommen in unserer Community. Da es sich dabei um Peering handelt, kann ich dir zu den bereits erhaltenen Infos von den anderen Usern (danke dafür) folgende Seite an die Hand geben: https://telekomhilft.telekom.de/t5/Festnetz-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung-hohe-PING-Zeiten/ta-p/4265259
Ich hoffe, dies hilft weiter. 😉
Viele Grüße & ein schönes Wochenende.
Nadine H.
0
vor 2 Jahren
Habe das selbe Problem, nutze für meine diverse Webseiten Cloudflare als CDN . Seit etwa drei Wochen kommt es sehr regelmäßig zu extrem langsamen Ladezeiten welche die Webseiten komplett unbenutzbar machen wenn ich diese aus Berlin aufrufe. Ich kann allerdings in meinen Cloudflare Analytics sehen dass die Seiten weltweit durchschnittlich normalen traffic haben, und ein Dienst, der mir Screenshots zeigt wie meine Webseiten in anderen Ländern geladen werden, zeigt dass das Problem nur hier besteht. Gefühlt sind meine Webseiten für mich in Berlin 50% der Zeit in den letzten drei Wochen nicht erreichbar.
@MarvinD Würde mich sehr freuen falls Du weitere eigene Erkenntnisse dazu teilen kannst.
0
vor 2 Jahren
Ich schließe mich den Problemen mit an. Anscheinend gibt es ein Bandbreitenproblem, welche bei mir dann mehrere Seiten betrifft, die über den gleichen Cloudflare Punkt laufen. Wenn es der Fall ist, da lahmen die Seiten alle gleichzeitig.
als Beispiel
hardwareluxx.de
pcgh.de
igorslab.de
caseking.de
mydealz.de
Die laufen alle darüber cloudflare-svc079341-ic369090.c.telia.net [2001:2000:3080:1ba6::2]
Ich bin nicht der einzige. Auch im Hardwareluxx gibt es mehrere Berichte über Verbindungsprobleme.
0
vor 2 Jahren
Jemand hat im Cloudflare Forum erwähnt, dass es hilft HTTP3 zu deaktivieren, dies lässt meine Webseiten wieder schnell laden:
https://community.cloudflare.com/t/severe-problems-with-super-slow-speeds-occuring-since-3-weeks-on-all-my-sites-when-visiting-from-germany-berlin/555456
3
Antwort
von
vor 2 Jahren
Also bei (teilweisen) 50% ping-Verlusten bezweifel ich, dass dass HTTP3 deaktivieren eine Lösung ist.
Antwort
von
vor 2 Jahren
Also bei (teilweisen) 50% ping-Verlusten bezweifel ich, dass dass HTTP3 deaktivieren eine Lösung ist.
Also bei (teilweisen) 50% ping-Verlusten bezweifel ich, dass dass HTTP3 deaktivieren eine Lösung ist.
Was ist dein Ansatz zur Problemlösung? @DDDDDDDDDDD
Antwort
von
vor 2 Jahren
Ich hoffe das jemand von der Telekom mal den Backbone repariert. Anscheinend tritt das Problem verstärkt mit IPv6 auf. Mit IPv4 hat man keine Paketverluste.
Traurig, dass die Telekom das nicht im Griff hat. Gerade der Telekom hätte ich es zugetraut.
Uneingeloggter Nutzer
Antwort
von
vor 2 Jahren
@MarvinD Hab seit einigen Tagen das gleiche Problem.
Unser Server ist ebenfalls bei Hetzner und der CDN läuft über Cloudflare Pro. Die Website lädt aber aktuell meist nur sehr langsam. Server Response für einzelne Bilder liegt bei 1+ Sekunde (Chrome Developer Tools / Network / Timing für einzelne Objekte wie Bilder).
Im Cloudflare Speedtest per Ethernet habe ich aktuell einen Packet Loss von bis zu 50%.
Interessanterweise tritt der Packet Loss nicht über Mobilfunk (Telekom 5G ) auf. Es liegt also nicht an Cloudflare sondern tritt nur per Telekom VDSL auf.
0
vor 2 Jahren
Wie steht das eigentlich hier auf "gelöst"? Für mich ist das keine Lösung.
Oder ist die Lösung den Provider zu wechseln?
0
vor 2 Jahren
Guten Morgen!
Ich möchte auch mal meinen Erfahrungsbericht hier einbringen:
Auch bin aus dem Rhein-Neckar-Raum und auch hier gibt es massive Performance-Einbrüche beim Laden von Seiten wie caseking.de oder mydealz.de, aber auch bei diversen Amerikanischen Foren und Seiten aus UK, auf denen ich unterwegs bin.
Soweit ich nun herausgefunden habe, hängt auch bei den o.g. Amerikanischen Seiten Cloudflare mit drin, teils als vorgeschaltete Sicherheitsmaßnahme. Auch ich kann bestätigen, dass diese Seiten teils Minuten benötigen, bis diese komplett geladen haben. Sehr schön ist dies an Grafiken zu sehen, die sich dann Zeile für Zeile aufbauen (wie damals in den Kinderzeiten des Internet).
Ich habe ebenfalls PINGs und TRACERTs durchgeführt und es sieht in der Tat katastrophal aus, da habe ich einen Packet Loss von bis zu 50%, Pings kommen mitunter garnicht zum Ziel, etc.
Die weiter oben erwähnte Lösungsidee aus dem Cloudflare Forum, nämlich das HTTP3 zu deaktivieren (in meinem Firefox-Browser), hilft bei manchen Seiten geringfügig, jedoch nicht bei allen betroffenen Seiten.
Die von Nadine H. erwähnte "Lösung" ist in meinen Augen auch keine wirkliche Lösung, lediglich eine Information über das Peering und damit verbundene mögliche Probleme, sowie eine Auflistung an Maßnahmen, was alles nicht hilft. Ich kann daher nicht nachvollziehen, dass dieser Post als Lösung für das hier benannte Problem ausgewiesen ist, da dieses ja weiterhin besteht.
Mir sind jedoch noch folgende 3 Dinge aufgefallen, die hier noch nicht erwähnt worden sind:
1. Jetzt wo ich diesen Beitrag hier schreibe, habe ich die weiter oben erwähnten betroffenen Seite mal angetestet, durch einfaches Laden, PINGs und TRACERTs. Ich habe diese Tests ünrigens bereits in den letzten 2 Wochen (seit dem ist mir diese Problematik nämlich aufgefallen) zu verschiedenen Tageszeiten durchgeführt:
Im moment (ca. 9:30 Uhr) gibt es hier keinerlei Probleme. Die o.g. Probleme treten erst in der Zeit ab ca. 18:00 Uhr auf und halten dann an bis in späten Abendstunden. Es macht für mich den Eindruck einer tages-temporären Überlastung (von was auch immer). (?)
2. Gestern Abend, so gegen 21:00 Uhr, hatte ich diese Problematik mit Freunden besprochen und wir haben ein paar Seiten ausgetestet, per PING, TRACERT, etc. Drei der besagten Freunde haben die Telekom als Provider, zwei sind bei 1&1, und zwei sind bei anderen Providern.
Im Ergebnis sind die o.g. Performace- bzw. Cloudflare-Probleme (gestern) lediglich und nachweislich bei den Telekom- und 1&1-Kollegen aufgetreten, nicht aber bei den beiden Kollegen mit anderen Providern.
3. Da ich zu Beginn zunächst die Vermutung gehabt habe, dass die von mir weiter oben angesprochenen Amerikanische Seiten selbst Probleme machen, habe ich diese mal zum Test mit aktivierter VPN (mit virtuellem Standort USA) geladen. Interessanterweise haben diese dann sauber und ohne Performance-Verluste geladen!
Auch gestern Abend, als die Problematik mal wieder massiv war, habe ich mal das Laden mehrerer betroffener Seiten mit meiner VPN getestet, u.a. auch solche, die mit einem vorgelagerten CloudFlare-Service abgesichert sind. Auch hier das Ergebnis: Alles lädt sauber und ohne Probleme.
Mich würde nun mal interessieren, ob andere hier im Forum das ggf. bestätigen können? Also die Uhrzeit-abhängigen Performance-Einbrüche, sowie den "Workaround" mittels einer VPN .
2
Antwort
von
vor 2 Jahren
Kann das alles bestätigen:
Antwort
von
vor 2 Jahren
Vielen Dank für das Feedback!
Dann bin ich mal gespannt, ob und wann dieses Problem gelöst wird, und ob sich zu diesem Fall (hier) noch jemand von der entsprechenden Telekom-Fachabteilung äußert. Unsereins kann hier ja nicht wirklich etwas lösen, von daher liegt das Ball ab jetzt wieder bei der Telekom...
Uneingeloggter Nutzer
Antwort
von
vor 2 Jahren
Guten Abend in die Runde.
Auch vom meiner Seite aus kann ich das alles bestätigen. Habe hier eine 100/40er Leitung und gegen Abend sehe ich bei Seiten "hinter" Cloudflare regelmäßig Ladezeiten im Minutenbereich. Habe eben (20:24 Uhr) mal wieder ping/tracert laufen lassen (Ergebnisse siehe unten). Zusammengefasst habe ich über IPv4 keine Probleme. Über IPv6 ist das ne reine Katastrophe 😱 Da ich beruflich in den letzen Monaten(!) abends immer mal wieder mit einer Seite "hinter" Cloudflare arbeiten muss, und ich das Problem entsprechend auch seit Monaten beobachte, behelfe ich mir seitdem damit auf meiner Windows-Kiste IPv6 einfach abzuschalten. Ist keine Dauerlösung, für mich hier im Kreis DÜW aber ein machbarer Workaround.
> ping bzw. tracert -4 cloudflare.com
Antwort von 104.16.132.229: Bytes=32 Zeit=20ms TTL=54
Antwort von 104.16.132.229: Bytes=32 Zeit=19ms TTL=54
Antwort von 104.16.132.229: Bytes=32 Zeit=19ms TTL=54
Antwort von 104.16.132.229: Bytes=32 Zeit=19ms TTL=54
Ping-Statistik für 104.16.132.229:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 19ms, Maximum = 20ms, Mittelwert = 19ms
1 <1 ms 1 ms 1 ms fritz.box [192.168.4.1]
2 6 ms 5 ms 4 ms p3e9bf6da.dip0.t-ipconnect.de [62.155.246.218]
3 9 ms 9 ms 9 ms f-ed14-i.F.DE.NET. DTAG .DE [217.5.70.54]
4 9 ms 8 ms 8 ms f-ed14-i.F.DE.NET. DTAG .DE [217.5.70.54]
5 14 ms 14 ms 13 ms 80.156.162.178
6 15 ms 14 ms * if-be-60-2.ecore1.f2c-frankfurt.as6453.net [80.231.27.2]
7 * * 33 ms 195.219.148.122
8 14 ms 9 ms 8 ms 172.70.240.3
9 8 ms 7 ms 7 ms 104.16.133.229
> ping/tracert -6 cloudflare.com
Ping wird ausgeführt für cloudflare.com [2606:4700::6810:85e5] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 2606:4700::6810:85e5: Zeit=109ms
Ping-Statistik für 2606:4700::6810:85e5:
Pakete: Gesendet = 4, Empfangen = 1, Verloren = 3
(75% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 109ms, Maximum = 109ms, Mittelwert = 109ms
1 <1 ms <1 ms <1 ms fritz.box [2003:f4:6707:cd00:9a9b:cbff:fe5a:526f]
2 5 ms 5 ms 4 ms 2003:0:8306:d800::1
3 * * * Zeitüberschreitung der Anforderung.
4 110 ms * 110 ms 2003:0:f00::69f
5 * 109 ms 108 ms 2001:668:0:2:ffff:0:d5c8:74e1
6 112 ms * * 2001:668:0:3:ffff:1:0:b06
7 120 ms * 109 ms 2400:cb00:470:3::
8 * * 109 ms 2606:4700:3034::6815:3735
1
Antwort
von
vor 2 Jahren
Guten Morgen!
Besten Dank für das weitere Feedback! Ping bzw. Tracert sehen bei mir in den Abendstunden ähnlich katastrophal aus. Ich sitze in Ludwigshafen (am Rhein), auch mit einer 100/40er Leitung, also quasi in der Nachbarschaft zu DÜW. Als Selbständiger muss ich immer mal wieder, auch in den Abendstunden, auf Seiten (von Kunden) arbeiten, die 'hinter' Cloudflare sitzen.
Das mit der Abschaltung von IPv6 werde ich auch mal ausprobieren, mal sehen ob das eine Alternativer zur VPN für mich sein könnte. Wie aber richtigerweise gesagt wurde, ist das ja auch nur ein weiterer Workaround undlediglich die Bekämpfung der Symptome, aber nicht der Ursache.
Ich scheue mich davor, bei der Telekom ein offizielles Störungsticket aufzumachen, denn bei dem Gedanken, dass der Kundendienst mit "Haben sie mal versucht, die FritzBox neu zu starten" oder ähnlichem aufwartet, bekomme ich jetzt schon Schnappatmung...
Uneingeloggter Nutzer
Antwort
von
vor 2 Jahren
Puhhh. Wenn man das so liest, da vergeht einem ja irgendwie der Spaß. Da ist man bei einem Premium-Anbieter mit den höchsten Preisen und bekommt eher schlechteres Netz, da ich mich nicht nur im "Telekom-Netz" aufhalte(n) will, sondern das ganze Internet nutze.
Hoffentlich kommt die Telekom hier mal auf den Boden zurück und betreibt gescheites Peering .
0
vor einem Jahr
Liebes Telekom-Community- und Support-Team,
wir stehen weiterhin vor einem ungelösten Problem, und die Tatsache, dass sich seit Monaten nichts verändert hat, ist erschreckend.
Kurz zu uns: Wir sind ein Anbieter von SaaS-Software im Gesundheitssektor im DACH-Raum. Unser Produkt, ein Praxisverwaltungssystem, ist für unsere Kunden unerlässlich, um ihre Patienten effizient zu betreuen. Die Natur unserer Dienstleistung erfordert höchste Standards an Zuverlässigkeit und Sicherheit, weshalb wir unter anderem auf Dienste wie Cloudflare (WAF etc.) setzen.
Ist es wirklich so, dass dieser Thread als gelöst markiert wurde, ohne eine echte Lösung anzubieten? Wir nutzen Cloudflare, während unsere Kunden auf die Telekom angewiesen sind. Es scheint unwahrscheinlich, dass wir Cloudflare zu einem Peering -Vertrag mit der Telekom bewegen können, und gleichzeitig scheint der Telekom das völlig egal zu sein. Dies führt dann dazu, dass wir und unsere Kunden im Konflikt zwischen diesen beiden Parteien leiden?
Sollten wir die Situation wirklich richtig verstanden haben, werden wir ab jetzt unseren über 250 Business Kunden aktiv von einem Tarif bei der Telekom abraten und ich kann jedem anderen nur das gleiche empfehlen.
3
Antwort
von
vor einem Jahr
Guten Tag @Johannes A,
natürlich ist es nicht wirklich zufriedenstellend, wenn die markierte "Lösung" das Problem nicht behebt.
Beim Thema Peering ist aber leider der Punkt, dass wir als Servicemitarbeiter*innen keinen Einfluss darauf haben. Welche Übertragungswege zwischen uns als Provider und anderen Instanzen genutzt werden, ist nicht allein unsere Entscheidung als Deutsche Telekom.
Der in der Lösung verlinkte Text erklärt die Lage tatsächlich sehr gut. Und auch, wenn es die Lage nicht ändert und vielleicht nicht zufriedenstellend ist, ist das leider alles, was wir an dieser Stelle dazu sagen können.
Beste Grüße
Louisa G.
Antwort
von
vor einem Jahr
Ja, wirklich traurig, dass jeder anderer Provider ein sauberes Peering zu Cloudflare hinbekommt und eine große Telekom mit teuren Preisen es ignoriert.
Ein besserer Workaround als QUIC/http3 zu deaktivieren ist IMHO noch IPv6 zu deaktivieren. Ich habe leider keine Ahnung von CF, aber auch da müsste man es deaktivieren können. Das müsste AAAA Records oder so ähnlich heißen. Alternativ das DNS zu einem anderen Provider verlagern und dort deaktivieren.
Ich filter bei mir die AAAA Records von CF. Seitdem läuft es bei mir zügig und die IPv6 Probleme (und nicht IPv4) zeigen sich auch bei mir im Monitoring.
https://telekomhilft.telekom.de/t5/Festnetz-Internet/Cloudflare-IPv6-in-der-Rushhour-gestoert-aber-NICHT-per-IPv4-mit/m-p/6435993
Mit Hetzner habe ich super pings zu CF (auch mit IPv6). Wenn ihr eine normale Webseite habt könnte man bei Hetzner einen Webserver laufen lassen, der die Daten annimmt und dann weiter zu CF sendet. Je nach Größe der Webseite benötigt man vermutlich mehr als einen Server bei Hetzner....
Antwort
von
vor einem Jahr
Hallo @Louisa G.
Ihr als Servicemitarbeiter habt aber in unseren Kundenaugen die Pflicht solche Probleme an den Support zu schicken. Wozu ´gibts denn das Forum sonst?^^ Für Kaffe und Kuchen melde ich mich hier nicht an
Nicht böse nehmen aber das ist gegenüber euren Kunden echt nicht die feine Art.
Es hilft uns halt absolut nicht weiter. Wir bezahlen Geld, Leistung bekommen wir aber keine. Da kann ich das Geld auch in den Main werfen
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
Hallo Louisa,
das ist sehr schade! Euer Artikel umschreibt das Problem natürlich sehr wohlwollend für die DTAG . Wer sich zum Thema etwas unvoreingenommere Quelle ansehen will
kann gerne mal hier oder Peering -Anbieter-4886694.html?seite=2" target="_blank" rel="noopener nofollow noreferrer">hier schauen oder einfach mal DTAG Peering googlen.
Alternativ stelle ich mal die Frage: Wieso kriegt es eigentlich jeder 08/15 VPN Betreiber besser hin als die DTAG mit Ihrem "Premium Netz"?
Wie auch immer; da dies eher ein strategisches Thema der DTAG ist, sind @Louisa G. und allen anderen die Hände gebunden. Deswegen tut es mir Leid, dass du hier den ganzen Ärger abkriegst!
Da wir einen Workaround brauchen:
Mal angenommen wir wollen unseren speziellen Telekomkunden einen alternativen Backup-Server bereitstellen, falls das public Peering mit der DTAG mal wieder nicht funktioniert: Welche Hostingprovidern sind Privater Peering Partner der Telekom?
Mit welchen Anbietern müsste man das ganze denn aufsetzen? Azure, GCP, AWS, Hetzner? Gibt es eine vollsändige Liste?
Vielen Dank!
VG
Johannes
0
vor einem Jahr
Ob Artikel aus 2014 bzw. 2020 immer noch so hilfreich sind, ist allerdings fraglich.
0
vor einem Jahr
Man suche sich einen vernünftigen Hoster, programmiere seine Seiten selber oder lasse sich seine Seiten nach eigenen Maßgaben erstellen, und verzichte auf das ganze Cloud-Zeugs.
0
vor einem Jahr
@Mister Burny
Das stimmt natürlich, jedoch soll dies hier eher die strategische Unternehmenshaltung der Telekom zeigen und verdeutlich, dass dies Vorwürfe nicht aus der Luft gegriffen sind und scheinbar nach Jahren immer noch ein Problem darstellen.
@wizer
Ihnen ist bewusst dass Cloud letzendlich nur ein Begriff für Hosting Provider ist? Schon allein deshalb macht der Satz so keinen Sinn.
Ich verstehe jedoch sinngemäß was Sie meinen und Ihr Vorschlag, auf eigene Hosting-Lösungen umzusteigen und "das ganze Cloud-Zeugs" zu meiden, klingt ja reizend nostalgisch, ist aber leider absolut praxisfern.
Nicht jedermann betreibt eine einfache Website für den kleinen Einzelhändler ums Eck. Viele nutzen das Internet für kritische Anwendungen, bei denen unter anderem Skalierbarkeit (z.B. durch k8s), Ausfallsicherheit usw. unerlässlich sind. Dies ist nicht so leicht selbst gemacht, besonders wenn die eigene Anwendung nicht eine einfach Website ist. Viele Cloud Provider bietet genau dafür Dienste an. Unabhänig davon haben wir keinerlei Probleme mit der bösen Cloud sondern lediglich mit dem schlechten Public Peering im "Besten Netz" der DTAG .
Außerdem: Was zeichnet einen "vernünftigen Hoster" aus? Das er der Telekom Schutzgeld für Private Peering zahlt?
Lassen wir das lieber und konzentrieren wir uns auf eine Lösung. Folgende Frage bleibt:
Mal angenommen wir wollen unseren speziellen Telekomkunden einen alternativen Backup-Server bereitstellen, falls das public Peering mit der DTAG mal wieder nicht funktioniert: Welche Hostingprovidern sind Privater Peering Partner der Telekom?
Mit welchen Anbietern müsste man das ganze denn aufsetzen? Azure, GCP, AWS, Hetzner? Gibt es eine vollsändige Liste?
2
Antwort
von
vor einem Jahr
Azure und AWS kann ich aktuell bestätigen, Hetzner glaube ich nicht. Zumindest gibt es da auch immer wieder Berichte über "schlechtes" Peering .
Als GK kannst du sogar direkt Anbindungen dort beauftragen:
https://www.t-systems.com/de/de/cloud-services/loesungen/public-cloud/aws-managed-services/aws-direct-connect
https://geschaeftskunden.telekom.de/magenta-business-networks/netzwerke-fuer-standorte-und-clouds/cloudconnect/azure-expressroute
Antwort
von
vor einem Jahr
Was zeichnet einen "vernünftigen Hoster" aus?
Z.B. wenn er auf das ganze amerikanische Zeugs wie "Cloudflare" verzichtet.
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
@Mister Burny
Hast du dafür eine Quelle, oder worauf beziehst du dich?
Edit. Danke für die Links!! Jetzt erst gesehen.
In Google finde ich zumindest einen Artikel auf Hetzner: "Ab sofort direktes Peering mit der Deutschen Telekom". Da kommt jedoch eine 404. In wieweit das also aktuell ist, kann ich nicht sagen. Evtl. hat @Louisa G. eine Info dazu?
@wizer
Ah gut, amerikanisch ist böse. Na dann doch direkt auf die unzähligen deutschen Marktführer im Bereich Cloud Services/Architecture, Hosting, CDN , DDoS/Web Security setzen. Am besten noch gleich einen deutschen Browser/ OS installieren. Ohhh.. wait a minute 😉
2
Antwort
von
vor einem Jahr
@Johannes A
Ich wollte nur sagen, dass ich von Dezentralisierung im Netzt nicht viel halte. Und was die USA von Datenschutz halten, muss man nicht extra erwähnen.
Antwort
von
vor einem Jahr
Gut, im Endeffekt agieren amerikanische Unternehmern wie Cloudflare, Azure, AWS usw. in Deutschland und fallen somit auch in Deutsches Recht, besonders für Business-Kunden gibt es erweiterte Agreements. Ob man diesem nun glauben schenkt oder nicht ist whrl. eher eine Grundsatzfrage.
Wenn ich dies für mich jedoch verneine, müsste ich letztendlichen auch meinem Browser/ OS /Smartphone usw. mistrauen.
Kann ja alles sein, aber das ist mir persönlich viel zu viel Stress. Mir reichen da Peering Probleme schon völlig aus.
Aber genug off topic.
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
Guten Tag in die Runde.
@Johannes A Wir hatten noch bis Anfang Dezember mit unserer SaaS-Website die gleichen Probleme über die Telekom. Ladezeiten zwischen 1 Sekunde und 5-10 Minuten in den Abendstunden. Nach entsprechenden Hinweisen hier und im Cloudflare-Forum haben wir dann mal über das CF-Dashboard http/3 (QUIC) für unsere Website komplett deaktiviert (CF-Dashboard > Home > Website (Domain) > Speed > Optimization > http/3). Danach hat sich unsere Site über die Telekom auch in den Abendstunden wieder problemlos laden lassen, während der zeitgleiche Zugriff auf das Cloudflare-Dashboard weiterhin wg. der o.g. Ladezeiten für Probleme sorgte.
Um auch dieses Problem in den Griff zu bekommen, haben meine Kollegen (ebenfalls Telekom-Kunden) und ich im Chrome über chrome://flags/#enable-quic http/3 auch im Browser abgeschaltet. Der Link funktioniert so auch beim Edge. Voreinstellung ist jeweils "Default" und damit ist http/3 aktiviert. Nach der Umstellung auf "Disabled" muss Chrome neu gestartet werden! Nach dieser Änderung konnten wir wieder problemlos auf das CF-Dashboard und andere CF-"Problemseiten" zugreifen, während Firefox und Edge auf den gleichen Maschinen weiterhin Probleme mit CF-Seiten hatten. Nachdem wir http/3 auch für FF/Edge deaktiviert hatten, waren auch dort die langen Ladezeiten verschwunden. Im Firefox kann man die http3-Settings übrigens via about:config und Eingabe von http3 abrufen. Hier muss dann der Eintrag network.http.http3.enable über den Button rechts auf false umgeschaltet werden.
Nach ein paar Tagen haben wir dann testweise http/3 für unsere Website wieder aktiviert. Browser bei denen http/3 deaktiviert war, hatten weiterhin keine Probleme mit unserer Site. Erst das erneute Aktivieren von http/3 im Browser hat die altbekannten Probleme in den Abendstunden zurückgebracht. Von daher sind wir davon überzeugt, dass QUIC zumindest ein Teil des Problems ist.
Vieleicht kannst Du das ja mal für Euer Praxisverwaltungssystem testen und hier kurz berichten ob es Euch etwas gebracht hat.
Abschließend möchte ich noch erwähnen, dass sich dadurch natürlich nichts an dem grundsätzlichen Telekom <> Cloudflare Peering Problem ändert, denn die PING/TRACEROUTE-Zeiten sind in den Abendstunden natürlich immer noch unterirdisch und für viele Realtime-Anwendungen nach wie vor ein Problem. Das betrifft uns allerdings nicht und wir sind vorerst mit der gefundenen Lösung zufrieden. Außerdem möchte ich hier auch noch den Hinweis loswerden, dass QUIC (basiert ja auf UDP) im Chrome/Edge immer noch als experimental gekennzeichnet ist.
HTH 😊
1
Antwort
von
vor einem Jahr
Hey @DevOpsPipe
vielen herzlichen Dank für deinen ausführlichen Bericht und deine Mühe!
Ich werde das ganze heute und die nächsten Tage mal checken.
Besten Dank und VG
Johannes
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
@DDDDDDDDDDD
Interessanter Thread, vielen Dank dafür! In dem verlinkten Thread besteht ja wirklich absolut kein Verständnis oder Einsicht. Nun gut!
Für alle die zukünftig mit dem selben Problem kontriert sind:
1. Versucht die Lösungsvorschläge von @DDDDDDDDDDD oder @DevOpsPipe. Sollte jemand einen besseren finden dann sehr gerne hier teilen!
2. Jeder sollte wissen, dass die DTAG das Problem leicht beheben könnte, aber kein Interesse für eine Lösung besteht, solange diese nicht auch den Umsatz steigert. Der Kunde wird dafür in Geiselhaft genommen (siehe Hetzner und DTAG ). Wie bereits erwähnt, ist dies eine gültige Position. Ob sie nun aber kundenorientiert ist oder den Standards eines Premiumanbieters entspricht, kann jeder selbst entscheiden.
Im Allgemeinen ist es für uns leider wieder einmal eine enttäuschende Erfahrung. Leider nicht die Erste; für Interessierte hier eine nette Anekdote über E-Mails, RFC Standards und die DTAG eines Leidtragenden Bloggers (genau auf dieses Problem sind wir wenig später auch gestoßen). Als Softwareanbieter kämpft man immer wieder einmal mit den "Besonderheiten" der DTAG ; die leidtragenden sind leider immer die gemeinsamen Kunden.
0
vor einem Jahr
Cloudflare ist auch hier seit Wochen ein Desaster per IPv6. Betrifft mehrere meiner meist angesurften Dienste. Für mich ist das Fass jetzt auch mal voll, bei der nächsten Gelegenheit wird gewechselt. Ist mir klar, dass das hier keinen interessiert, und die Telekom schon gar nicht, musste trotzdem mal raus.
Ich bin kein Fan von Cloudflare, aber Tatsache ist nunmal, dass sie mittlerweile vor einem Großteil der Internetdienste sitzen. Wenn der dem größten deutschen ISP mit dem besten Netz tm und entsprechenden Preisen das egal ist, wiegen das auch die bisherigen Bleibegründe wie Stabilität der Hausleitung und Telekom Hilft nicht mehr auf. Die Netzneutralität existiert in Deutschland offenbar nur auf dem Papier.
Bei anderen ISPs mag es auch genug Probleme geben, aber immerhin ohne Telekom-Preise.
0
vor einem Jahr
Hallo zusammen,
hier ein kurzes Update von uns: Als SaaS Provider, der CF nutzt, stehen wir vor einem ernsten Dilemma. Da für uns keine Lösung leider inakzeptabel ist, die DTAG das ganze aber nicht interessiert bleibt leider nur ein eigner Workaround.
Eine Möglichkeit wäre natürlich nicht mehr CF Dienste zu nutzen, sondern dafür einfach komplett auf einen Private- Peering -Partner der DTAG umzusteigen. Am Besten noch direkt alles in die Open Telekom Cloud – haha, eine geniale Idee!
Natürlich kommt das für uns nicht infrage; wir lassen uns doch nicht von der DTAG diktieren welche Dienste wir verwenden.
Hier nun unser Workaround:
Wir haben einen Reverse Proxy bei Hetzner für unsere Services eingerichtet. Sollte ein Kunde als die DTAG als ISP nutzt und wir stellen ein Peering -Problem fest (MTR), leitet wir diese Kunden über den Reverse Proxy in Hetzner um (bevor diese dann wie gewohnt über CF und/oder andere Dienste geroutet werden). Da Hetzner ( Peering Points von Hetzner) ein Double-Paid-Traffic Vertrag mit der DTAG abgeschlossen hat (nach eigener Aussage widerwillig, gerne mal googlen), umgehen wir somit also das Peering Problem DTAG <--> CF. Hetzner selbst bietet dann Private Peering zu CF.
Die Lösung ist natürlich nicht optimal. Wir müssen nun eine zusätzliche RSS managen. Außerdem muss der Hetzner-Server auch gesondert abgesichert werden (da ja leider keine CF WAF/DDoS-Schutz möglich).
Gleichzeitig entsteht uns natürlich erstmal zusätzliche Kosten, sowie eine höhere RTT für unsere Kunden und auch unser eigentlicher Load-Balancer kann nicht wie gewohnt alle Request abgreifen (somit greift die horizontale Skalierung unsere Clusters leider nicht). Da wir diese Zwischenroute über Hetzner jedoch nur bei Packet-Loss am Peering -Punkt gehen und nicht immer, ist das für uns unter den gegebenen Umständen aktuell der beste Weg. Langfristig könnte man whrl. auch über eine automatische Bereitstellung der RSS über IaC nachdenken.
Für alle betroffenen Privatkunden ist das alles leider keine Lösung...
VG
Johannes
5
Antwort
von
vor einem Jahr
@Julia U. Wenn die Kollegen etwas Anregungen brauchen...
Es ist primär IPv6 betroffen. Für mydealz.de per IPv6 (2606:4700::6811:5149) (cloudflare.com sieht genauso aus)
Per IPv4 sieht es viel besser aus. Könnte aber auch besser sein
An meinem Anschluss liegt es nicht. DTAG DNS per v6 (2003:180:2:8000::53)
Antwort
von
vor einem Jahr
@DDDDDDDDDDD
Ja, für einige Kunde.
Zusätzlich haben wir aber auch eine einfache sub-domain für unsere Plattform, welche dann generell über Hetzner geht. Zusätzlich können wir Kunden der DTAG natürlich nach dem ersten Request auch einfach aktiv auf die sub-domain umleiten. Unsere anderen Kunden laufen dann immer über die default Domain und werden nie umgeleitet.
Wir nutzen z.B. auch CF Pages, dabei wird der Content direkt von CF gehostet und die IPv6 Einstellung im Dashboard greift hier leider nicht...
VG
Johannes
Antwort
von
vor einem Jahr
Reicht das? @KevinM2590
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
Ich kann die Probleme 1:1 bestätigen und zwar alle, wie sie hier stehen. Die DTAG hat definitiv ein massives Problem, es betrifft vor allem Cloudflare über IPv6 (IPv4 ist mittlerweile besser geworden), aber auch andere Anbieter wie z.B. Contabo.
Hier hab ich auch einen Thread am laufen: https://telekomhilft.telekom.de/t5/Festnetz-Internet/Routing-zu-Cloudflare-abends-schlecht-hoher-Ping/m-p/6505941#M2188961
0
vor einem Jahr
@Espresso doppio Ich bin Itler und arbeite im Support.
Ich mach mir da aktuell keine Hoffnungen. Habe gerade schon nach der Vertragslaufzeit geschaut ^^
0
vor einem Jahr
Kann mich hier nur anschließen, seit über 1 Jahr Kunde bei Telekom, nie Probleme gehabt und jetzt seit ca. 3-4 Wochen oder sowas ab 15 Uhr bis 0 Uhr Probleme Internetseiten die hinter Cloudfare sitzen aufzurufen. Laden ewig oder unendlich. Ab 0 Uhr läufts schnell wie gewohnt, genauso wie mit VPN . Das kann ja kein Dauerzustand sein!
0
vor einem Jahr
bei mir seit gut nem 3/4 jahr. kunde seit 2016.
allerdings hab ich es jetzt erstmal "lösen" können indem ich in windows auf meinem client ipv6 deaktiviert habe.
damit sollte das Peering über v4 laufen und die probleme hoffentlich erstmal größenteils gelöst sein.
schön ist es dennoch nicht.
Bei so nem Hinterhofverein wie 1&1 hätte ich sowas erwartet aber nicht bei der Telekom.
0
vor einem Jahr
Ja richtig peinliche Leistung von der Telekom, freue mich dass ich bald wechseln kann wenn die Vertragslaufzeit abgelaufen ist.
0
vor einem Jahr
Hier war es die letzten zwei Abende etwas besser. Glück/Zufall oder hat jemand was gemacht?
4
Antwort
von
vor einem Jahr
Ja, seit dem 8.1. sieht es ziemlich gut aus
Antwort
von
vor einem Jahr
Zu früh gefreut. Seit 19 Uhr wieder hohen ping und Packetverluste
$ ping -c 10 cloudflare.com
PING cloudflare.com(2606:4700::6810:84e5 (2606:4700::6810:84e5)) 56 data bytes
64 bytes from 2606:4700::6810:84e5 (2606:4700::6810:84e5): icmp_seq=1 ttl=56 time=47.9 ms
64 bytes from 2606:4700::6810:84e5 (2606:4700::6810:84e5): icmp_seq=2 ttl=56 time=47.7 ms
64 bytes from 2606:4700::6810:84e5 (2606:4700::6810:84e5): icmp_seq=3 ttl=56 time=45.5 ms
64 bytes from 2606:4700::6810:84e5 (2606:4700::6810:84e5): icmp_seq=4 ttl=56 time=44.9 ms
64 bytes from 2606:4700::6810:84e5 (2606:4700::6810:84e5): icmp_seq=5 ttl=56 time=47.8 ms
64 bytes from 2606:4700::6810:84e5 (2606:4700::6810:84e5): icmp_seq=6 ttl=56 time=46.8 ms
64 bytes from 2606:4700::6810:84e5 (2606:4700::6810:84e5): icmp_seq=8 ttl=56 time=46.1 ms
64 bytes from 2606:4700::6810:84e5 (2606:4700::6810:84e5): icmp_seq=9 ttl=56 time=44.1 ms
--- cloudflare.com ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9013ms
rtt min/avg/max/mdev = 44.065/46.341/47.882/1.353 ms
Antwort
von
vor einem Jahr
Und jetzt sogar per IPv4
$ ping -4 -c 10 cloudflare.com
PING cloudflare.com (104.16.132.229) 56(84) bytes of data.
64 bytes from 104.16.132.229 (104.16.132.229): icmp_seq=1 ttl=56 time=46.5 ms
64 bytes from 104.16.132.229 (104.16.132.229): icmp_seq=3 ttl=56 time=45.5 ms
64 bytes from 104.16.132.229 (104.16.132.229): icmp_seq=4 ttl=56 time=43.9 ms
64 bytes from 104.16.132.229 (104.16.132.229): icmp_seq=5 ttl=56 time=44.7 ms
64 bytes from 104.16.132.229 (104.16.132.229): icmp_seq=6 ttl=56 time=44.8 ms
64 bytes from 104.16.132.229 (104.16.132.229): icmp_seq=8 ttl=56 time=46.5 ms
64 bytes from 104.16.132.229 (104.16.132.229): icmp_seq=9 ttl=56 time=46.2 ms
64 bytes from 104.16.132.229 (104.16.132.229): icmp_seq=10 ttl=56 time=46.0 ms
--- cloudflare.com ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9054ms
rtt min/avg/max/mdev = 43.933/45.519/46.483/0.879 ms
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
Hier auch wieder schlechter, aber noch erträglich.
Also keine Abhilfe, sondern nur Rumgebastel.
0
vor einem Jahr
Nach 8+ Tagen ohne Probleme auch bei mir wieder deutlich schlechter heute Abend.
Sehe ähnliche Ping-Zeiten wie @DDDDDDDDDDD , sowohl mit IPv6 als auch IPv4.
Bin gespannt, ob sich das jetzt wieder jeden Abend so einpendelt ☹️
0
vor einem Jahr
Hier das gleiche… IPv6 Cloudflare
0
Uneingeloggter Nutzer
Frage
von