AW: Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar

[#1]

Hallo,

seit ca. einer Woche habe ich starke Probleme beim Zugriff auf Inhalte von Github / Amazon AWS S3. Es ist nahezu unmöglich größere Dateien herunterzuladen. Ich erreiche lediglich Geschwindigkeiten im einstelligen kb/s Bereich. Aufgefallen ist es mir nach der Neu-Installation meines Desktop Rechners und ich hatte erst vermutet es sei ein lokales Problem mit dem Rechner. Ich habe jedoch heute auch mit 3 weiteren Geräten im lokalen Netz das gleich Problem gehabt. Da das Problem nun an min 3 Tagen in der letzten Woche aufgetreten ist, und ich über z.B. LTE ordentliche Bandbreiten erreiche habe ich nun ein Problem mit dem Anschluss in Verdacht.

Die Generelle Bandbreite des Anschlusses ist i.O., lediglich mit S3 habe ich Probleme. Ich habe in älteren Posts von Problemen mit dem Peering gelesen, konnte dazu allerdings nichts aktuelles finden. Wie kann ich mein Problem lösen?

[#2 · Accepted solution]

---

@Thomas_Herrmann  schrieb:

Bei mir auch Wirespeed, 11MB/s.

Danke Telekom/AWS/wer auch immer - auch wenn's lange gedauert hat.

---

---

@viper.de  schrieb:

Bei mir ca. 9 MB/s an einem VDSL100, IP Adresse 91.23.xxx.yyy

---

---

@rtel  schrieb:

Auf einmal 12.1Mb/sec anstatt zuvor 1-2 Kb. Kann bestätigen, dass es wieder schnell ist. Keine Ahnung, wer was genau gemacht hat, aber auf jeden Fall vielen Dank!

---

---

@soupdiver  schrieb:

Ich kann von 84.161.x.x auch bestätigen, dass wieder >10MB/s durch die Leitung gehen.

Top!!... danke an die vielen sinnvollen Beiträge hier... und das ganze Gemecker vergessen wir mal

---

---

@tm_107  schrieb:

Hier auch wieder ordentliche Downloadgeschwindigkeiten ...

---

---

@Jaffi  schrieb:

ES FUNZT WIEDER!!! FULLSPEED, DANKE!!! 🚀

---

---

@luddinho  schrieb:

Auch ich kann von meiner Seite berichten, dass seit heute Nachmittag ca. 16:45 Uhr die Downloadgeschwindigkeit enorm zugenommen hat.

---

@Thomas_Herrmann @viper.de @rtel @soupdiver @tm_107 @Jaffi @luddinho Danke für die positiven Rückmeldungen und es freut uns, dass die von euch genutzten Dienste, die von Amazon gehostet werden, nun wieder in der gewünschten Geschwindigkeit zur Verfügung stehen. 👍 😊

@luddinho  schrieb:

Interessieren würde mich dennoch was im Hintergrund geschehen ist was zur Besserung beigetragen hat.

---

Wie zuvor erwähnt: Von unserer Seite gibt es keine Engpässe bezüglich der Verkehre mit Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Die Verkehrssteuerung obliegt am Ende aber Amazon selbst. Seit Anfang der Woche sehen wir wieder eine optimalere Verkehrsverteilung und sind guter Dinge, das damit die Probleme für unsere Kunden gelöst sind. Auch stehen wir mit Amazon in direktem Kontakt, um solche Vorfälle in Zukunft hoffentlich vermeiden zu können.

Liebe Grüße

Waldemar H.

[#3 · Accepted solution]

Telekom/AWS update

eine kleine Zusammenfassung für Neuankömmlinge als Living-Post (ich bin kein Experte nur Zusammenfassender):

Das Problem ist noch nicht gelöst!
Der Thread ist nur als "Gelöst" markiert, weil das die einzige Möglichkeit ist, Beiträge anzupinnen.

Es betrifft offenbar AWS-Server an der Ostküste der USA und Dienste wie github die dort gehostet werden.
Das aber nur bei Kunden der Telekom und bei Wiederverkäufern, wahrscheinlich auch bei Providern die Infrastruktur der Telekom nutzen.

Die grundsätzliche Ursache liegt wohl in der Route auf dem Rückweg.
(Posts mit Traceroutes in Hinrichtung nützen deswegen übrigens nichts)

Zur Stellungnahme des Telekom-Teams siehe anderer angepinnter Beitrag.
Außerdem fand ich diesen Beitrag in einem anderen Thread recht klar:
"von unserer Seite gibt es keine Engpässe in Richtung Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Warum Amazon seinen Datenverkehr von der Ostküste darüber hinaus auch über andere Verkehrswege verschickt, können wir nicht sagen und ist die Entscheidung von Amazon.
Selbstverständlich befinden wir uns mit dem Anbieter in Gesprächen, um eine bessere Lösung für unsere Kunden zu schaffen."

Die Rückroute geht im langsamen Fall z.B. über Cogent an die Telekom.
Die Anbindung ist wohl suboptimal um es nett zu sagen.
Warum dabei die Geschwindigkeit auf 1/100 bis 1/1000 sinkt ist [für mich] rätselhaft.

Eine Frage ist, ob die Ursachen in firmenpolitischen Zusammenhängen liegen, siehe interessante Links ganz unten.

Workarounds:

Von der IP die man zugewiesen bekommt, hängt offenbar das Routing ab.
Man kann versuchen, durch z.B. "Neu Verbinden" in der Fritzbox oder entsprechendes bei anderen Routern (ohne Trennen des DSL) einen anderen IP-Bereich zu bekommen.
Aber nicht jeder bekommt IPs aus mehreren Bereichen.

Bekannte kritische Bereiche:
79.192.0.0/10 (79.192.0.1 - 79.255.255.254)

80.128.0.0/11 (80.128.0.1 - 80.159.255.254)

84.128.0.0/10 (84.128.0.1 - 84.191.255.254)

87.128.0.0/10 (87.128.0.1 - 87.191.255.254)

91.0.0.0/10 (91.0.0.1 - 91.63.255.254)

93.192.0.0/10 (93.192.0.1 - 93.255.255.254)

...

scheint wieder zu funktionieren:
84.136.0.0 bis 84.191.255.255 (siehe Link unter Entwicklungen)
darunter 84.166.*.* aus eigener Erfahrung

anscheinend unkritisch:
93.* (ausgenommen obiger Teilbereiche)
217.*
...

(weitere bitte posten...wird ergänzt, wenn Zeit ist)

Durch einen Proxy oder ein VPN kann man ebenfalls einen anderen IP-Bereich bekommen und damit auch ein anderes Routing.
(ich denke, der Proxy/VPN darf dann selbst nicht bei der Telekom und in einem schlechten Bereich liegen, z.B. bei einem eigenen VPN-Server und auch nicht auf AWS us-east für die Verbindung zu Dir)

Kleine Zusammenfassung der "Lösungen" in einem älteren Post:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

zusätzlich für einzelne Dateien auch:
"der einfachste Workaround ist
diese URL aufrufen
https://hide.me/en/proxy
und da die eigentliche URL zu github einfügen.
Braucht kein VPN und kostet nichts -
für einzelne Dateien ist das nicht mal ein nennenswerter Mehraufwand - was an dem Problem nichts ändert"
(von Stefan)

Der obige Proxy scheint auch nicht immer zu funktionieren, stattdessen aber dieser:
https://www.hidemyass.com/de-de/proxy


Test der Rückroute:
https://mtr.sh
AWS US-OH Ohio für us-east
AWS US-OR Oregon für us-west zum Vergleich
oben eigene externe IP eintragen und "mtr" wählen
(interessanterweise ist US-VA, das ja auch an der Ostküste liegt mit kurzer Route)

weitere interessante Links/Posts:

Entwicklungen:
84.136.0.0 bis 84.191.255.255
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

Messung:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
(sehr interessant, mag etwas über die Ursachen aussagen)

bzgl. Route:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

bzgl. älterer Peering-Verwicklungen der Telekom:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

eventuelle Gegenargumente:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

zu Rückmeldungen von Amazon:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

Abhandlung der Telekom über Peering-Probleme:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung...

[#4 · Accepted solution]

der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen

https://hide.me/en/proxy 

oder falls es da Probleme gibt: 

https://www.hidemyass.com/de-de/proxy

und da  die eigentliche URL zu github einfügen.

Braucht kein VPN und kostet nichts - 

Für einzelne Dateien ist das nicht mal ein nennenswerter Mehraufwand - was an dem Problem nichts ändert

[#5]

---

@Zoltux_1  schrieb:

---

---

Unwahrscheinlich 😅

Was ich gelernt habe ist: Wenn DIR die Argumente ausgehen, wechselst du auf das ad hominem Argument 🙄

---

Was kann ich dafür, wenn du den Arguemten nicht folgen kannst?

Erklär mir doch einfach, warum ich ohne Problem von Github laden kann, wenn die Telekom doch mehr Geld von Amazon haben will.

[#6]

---

@Stefan  schrieb:

---

@Zoltux_1  schrieb:

---

---

Unwahrscheinlich 😅

Was ich gelernt habe ist: Wenn DIR die Argumente ausgehen, wechselst du auf das ad hominem Argument 🙄

---

Was kann ich dafür, wenn du den Arguemten nicht folgen kannst?

Erklär mir doch einfach, warum ich ohne Problem von Github laden kann, wenn die Telekom doch mehr Geld von Amazon haben will.

---

Der Telekom ist es schlicht egal, ob eben ein Teil der Kunden hier ein Problem haben. Das war die Variante 2.

[#7]

---

@Zoltux_1  schrieb:
Der Telekom ist es schlicht egal, ob eben ein Teil der Kunden hier ein Problem haben. Das war die Variante 2.

---

das kann ich mir nicht vorstellen, dazu hat die Telekom in den letzten Jahren Zuviel investiert um die Peeringproblematik loszuwerden.

Cui bono?

[#8]

---

@der_Lutz  schrieb:

---

@Zoltux_1  schrieb:
Der Telekom ist es schlicht egal, ob eben ein Teil der Kunden hier ein Problem haben. Das war die Variante 2.

---

das kann ich mir nicht vorstellen, dazu hat die Telekom in den letzten Jahren Zuviel investiert um die Peeringproblematik loszuwerden.

Cui bono?

---

Das wäre wieder die Variante mit double paid 😅

Also: Egal wie, die Telekom informiert die betroffenen Kunden nicht, bzw speist sie ab mit "frag den Anbieter / Amazon". Ich habe einen Vertrag mit der Telekom und nicht mit Amazon, ich bin über iRacing indirekt betroffen und muss wegen dieses Problems ein VPN zum Login nutzen.

Die Telekom kommt hier seit Wochen nicht in die Schuhe, das Problem zu beheben und will es laut eigener Aussage auch nicht beheben.  

[#9]

---

@Zoltux_1  schrieb:
Die Telekom kommt hier seit Wochen nicht in die Schuhe, das Problem zu beheben und will es laut eigener Aussage auch nicht beheben.  

---

wie soll sie das auch wenn sie es nicht kann, da sind wir wieder bei den Technikern die die Telekom zu Amazon schickt...

[#10]

@der_Lutz 

Sorry, falscher Beitrag editiert - tut mir leid

[#11]

---

@der_Lutz  schrieb:

---

@Zoltux_1  schrieb:
Die Telekom kommt hier seit Wochen nicht in die Schuhe, das Problem zu beheben und will es laut eigener Aussage auch nicht beheben.  

---

wie soll sie das auch wenn sie es nicht kann, da sind wir wieder bei den Technikern die die Telekom zu Amazon schickt...

---

Wir können hier nur spekulieren, ob das nun Absicht ist - von beiden Seiten - oder ob Amazon tatsächlich das nicht auf die Kette bringt. Als Kunde der Telekom erwarte ich von ihr, dass sie sich um dieses Problem kümmert und das auch transparent macht. Und die betroffenen Kunden nicht abspeist mit "frag den Anbieter". Ich hatte letztes Jahr meine kafkaeske Erfahrung mit der Telekom, so dass ich hier zugegebenermaßen eher negativ gegenüber der Telekom eingestellt bin. Leider gibt es im Gesamtpaket für mich keine Alternative, so dass ich gezwungenermaßen eben bei der Telekom bleibe und mit dem für mich handhabbaren Problem lebe.

[#12]

---

@Zoltux_1  schrieb:
Als Kunde der Telekom erwarte ich von ihr, dass sie sich um dieses Problem kümmert und das auch transparent macht. 

---

Hat sie doch

---

@Zoltux_1  schrieb:
Und die betroffenen Kunden nicht abspeist mit "frag den Anbieter". 

---

das ist dann die Variante um den Druck in andere Bahnen zu lenken, vielleicht einfach auch an den Verursacher?

Genaugenommen ist das auch korrekt, die Telekom hat ausreichend Bandbreite zu Amazon, es gibt keine generellen Probleme nur wenn Amazon die falsche Router weiterhin nutzt kann die Telekom nichts machen. Du schimpfst ja auch nicht auf den Hersteller deines Autos wenn du im Stau stehst, oder?

[#13]

Also mir gegenüber wurde von der Telekom gesagt, dass sie sich bewusst sind, dass es dort ein Problem gibt und sie an der Lösung arbeiten. Außerdem wurde mir eine kleine Kompensation angeboten. Insofern finde ich das Verhalten der Telekom aktuell ganz OK, wenn sie denn wirklich irgendwann das Problem gelöst bekommen (unabhängig davon, ob sie es selbst lösen oder Amazon dazu bringen, es zu lösen).

[#14]

---

@Stefan  schrieb:

---

---

Variante 3 , du bist zu ignorant ode lernresistent um auch andere Möglichkeiten in bedracht zu ziehen.

---

Was für ein Tonfall der Community Guides hier schon wieder herrscht...

Wie man es auch dreht und wendet, das Problem liegt ja wohl eindeutig bei der Telekom. Selbst wenn Amazon - aus Versehen oder mit Absicht - den Traffic über Cogent zur Telekom schickt, dann ist eben das Peering zwischen Cogent und Telekom überlastet. Und das liegt sicher nicht an Cogent - ich habe einen Server hier in Deutschland, der ausschließlich über Cogent angebunden ist und erreiche knapp 200 Mbit/s von AWS (Region USA EAST). Bandbreite zwischen Amazon, Cogent USA und Deutschland ist also mehr als genug vorhanden.

Meine Arbeitshypothese ist weiterhin, dass die Telekom nur ein Alibi-Peering mit Amazon unterhält (ähnlich dem 1 GBit/s Link zum DE-CIX....) Ein Kommunikationsproblem auf technischer Ebene halte ich für fast ausgeschlossen. Ich bin mir sicher, dass zwei Techniker aus den NOCs von Telekom und Amazon sich soweit verständigen könnten, um ein ausreichend dimensioniertes direktes Peering auch korrekt zu konfigurieren.

[#15]

---

@jkammann  schrieb:
Meine Arbeitshypothese ist weiterhin, dass die Telekom nur ein Alibi-Peering mit Amazon unterhält (ähnlich dem 1 GBit/s Link zum DE-CIX....) 

---

da weder das eine noch das andere stimmt bricht die Hypothese im Ansatz zusammen, dumm gelaufen.

[#16]

> Was für ein Tonfall der Community Guides hier schon wieder herrscht...

Ich glaube das gilt für den generellen Tonfall im Forum. Alle meckern nur rum, keine Erklärung wird akzeptiert und auch wenn man Sachen schon 10x geschrieben hat macht sich keiner die Mühe das zu lesen. Man brüllt einfach noch mal "TELEKOM IST SCHULD" auch wenn man keinen Sachverstand hat.

🍿

[#17]

---

@soupdiver  schrieb:

---

@Nextcloud4All  schrieb:

---

@der_Lutz  schrieb:

@Nextcloud4All 

Und was ist daran jetzt nicht zu verstehen?

Wende dich an Amazon ob oder ob nicht dazu weitere Abstimmungen im Hintergrund laufen wirst du nicht erfahren. 

Die Bandbreite der Telekom zu Amazon ist jedenfalls ausreichend dimensioniert warum Amazon meint die Datenpakete jetzt über den Feldweg zu schicken musst du aber tatsächlich Amazon fragen. 

---

Das Beispiel mit dem Feldweg ist doch falsch. Ich bezahle die Telekom dafür, dass diese meine Daten schnell versendet und angeforderte Daten zurücksendet. Ob sie dabei die Autobahn oder den Feldweg ist die Entscheidung der Telekom und deren Partnern. Ich habe ja einen Vertrag mit der Telekom geschlossen und nicht mit AWS oder den Partnern dazwischen. Gegenüber der Telekom besteht die Forderung alle Daten neutral zu behandeln. Ich als Kunde bekomme nur mit, Alles ist schnell außer AWS/GitHub oder andere Dienste die bei AWS liegen. Dann Stelle ich meine Forderung mir alle Daten gleich schnell auszuliefern. Wie die Telekom das anstellt ist mir egal. Wenn sie es über den Feldweg schafft und damit ausreichend schnell ist, ist das doch okay. Aber wenn es nur über die Telekom langsam ist und über O2 oder LTE schnell geht, scheint doch die Telekom falsch abzubiegen. Und wenn die Telekom die halbe Strecke nicht selbst fährt sondern ein anderer Dienstleister über den Teich segelt, dann hat die Telekom die falschen Partner oder ein Problem, welches zu lösen gilt. 

---

Technisch ist das so leider einfach nicht richtig. Die Telekom hat in der Tat wenig Einfluss darauf, über welchen Weg AWS die Daten verschickt.

Daher ist auch deine  Schlussfolgerung falsch. Gegenbeispiel:

Wenn du jemanden anrufst, diese Person aber nicht ans Telefon geht oder ganz ganz langsam spricht, beschwerst du dich dann auch bei deinem Telefonanbieter?

---

Ich greife mal dein Beispiel auf: ich weiß aber das die Person schnell spricht (über eine andere Verbindung VPN/LTE) redet ja die Person schnell >2MB/s.

Die Sprache kommt aber langsam/stockend bei mir an. Dann beschwere ich mich bei meinem Telefonanbieter. Weil ich habe ja gesehen, ich kann schnell reden und die Gegenseite auch, aber nur wenn ich nicht Telekom verwende.

Wir sehen nur, das auf dem Weg über das Netz der Telekom die Leitung langsam ist. Es ist ja spätestens bei mir im DSL die Datenpakete wieder zusammen geführt werden (1 Leitung). In der Tat kann aber natürlich AWS einen anderen Weg gehen, aber AWS kann das maximal bis zur Übergabestelle zur Telekom beeinflussen. Wahrscheinlich nur bis zu deren Anbieter. Der Weg dazwischen ist Verhandlungsgebiet der Partner von Telekom und AWS. Welche Rechtsgrundlage sollte ich haben, mit den Partnern zu reden? Der ist ja Lieferant/Kunde der Telekom. Also beauftrage ich die Telekom (Ticket) sich diesem Problem zu widmen. Da ist einfach meine Erwartungshaltung , dass die Telekom für ihre Kunden (wir bezahlen sie) auch etwas unternimmt.

Und leider gewinne ich hier den Eindruck, dass hier die Antworten der Telekom immer verdreht werden. Wenn ich die letzte Antwort zitiere, wird drauf verwiesen das es noch in Klärung ist. Wenn ich die Antwort mit der Klärung in Arbeit herannehme, wird darauf verwiesen das man sich doch an den Anbieter wenden soll. Bzw auch umgekehrt. Eine Lösung ist hier nicht in Sicht. Für mich ist leider erst in 1,5 Jahren ein Vertragswechsel möglich. Aber dann geh ich halt wieder zu o2. Ähnlicher Preis, gleiche Leitung, aber wenigstens keine Beschränkung auf der Route.

[#18]

Kunden könnten da auch durchaus Druck machen indem entsprechende Erfahrungsberichte vermehrt über Social Media gepostet werden

Nicht zuletzt ist das ja eben auch eine Marktwirtschaftliche Frage, wenn wegen der Double Paid Peering Politik der Telekom zu viele Kunden kündigen oder erst gar nicht Kunden werden. Erst dann wird es aus Betriebswirtschaftlicher Perspektive Sinnvoll sein auf diese Strategie zu verzichten.

[#19]

> 

Ich greife mal dein Beispiel auf: ich weiß aber das die Person schnell spricht (über eine andere Verbindung VPN/LTE) redet ja die Person schnell >2MB/s.

Die Sprache kommt aber langsam/stockend bei mir an. Dann beschwere ich mich bei meinem Telefonanbieter. Weil ich habe ja gesehen, ich kann schnell reden und die Gegenseite auch, aber nur wenn ich nicht Telekom verwende.

Wir sehen nur, das auf dem Weg über das Netz der Telekom die Leitung langsam ist. Es ist ja spätestens bei mir im DSL die Datenpakete wieder zusammen geführt werden (1 Leitung). In der Tat kann aber natürlich AWS einen anderen Weg gehen, aber AWS kann das maximal bis zur Übergabestelle zur Telekom beeinflussen. Wahrscheinlich nur bis zu deren Anbieter. Der Weg dazwischen ist Verhandlungsgebiet der Partner von Telekom und AWS. Welche Rechtsgrundlage sollte ich haben, mit den Partnern zu reden? Der ist ja Lieferant/Kunde der Telekom. Also beauftrage ich die Telekom (Ticket) sich diesem Problem zu widmen. Da ist einfach meine Erwartungshaltung , dass die Telekom für ihre Kunden (wir bezahlen sie) auch etwas unternimmt.

Wie das mit den Beispielen immer so ist, so richtig treffen sie die Realität ja nicht.

> Wir sehen nur, das auf dem Weg über das Netz der Telekom die Leitung langsam ist.

Falsch. Wir wissen, dass der Rückweg langsam ist aber nicht das Telekomnetz an sich.

In einem anderen Thread haben wir die Sache auch schon detaillierter debugged. Der Hinweg ist ok aber beim Rückweg sendet AWS die Daten nicht über das direkte Telekompeering sondern über Cogent (glaub ich). Und genau an der Stelle scheint auch der Flaschenhals zu liegen. Also NICHT im Telekomnetz, eher an einem Übergabepunkt.

Jemand aus dem Forum hatte dann auch Kontakt zu jemandem im AWS NOC (sportlich!). AWS hat, laut der Aussage, kein Interesse die Route zu verkrüppeln da sie ja für ausgehenden Traffic kassieren. Sie nutzen, laut Aussage, alle direkten Peerings/Routen.

Das Problem könnte also sein, dass die Telekom ihre Routen nicht richtig Preis gibt an dieser Stelle. Es sollen Details folgen aber sind es noch nicht glaube ich. Die ganze Thematik ist also hinreichend komplex... Aber gut die Details werden wohl auch niemanden weiter interessieren da es das Problem ja nicht löst und auf "aber ich zahle doch also muss es gehen" auf keine Antwort gibt.

Aber das sind so grob die Hintergründe.

Versteht mich nicht falsch, ich bin nicht vom Magenta T und mich kotzt dieses Problem auch extrem an aber mit dem üblichen Gemecker kommt auch niemand weiter. Und dann werden die Antworten auch immer unfreundlicher.

[#20]

@Nextcloud4All also ich bin auch wie schon mehrfach beschrieben von dem Problem betroffen. 79.er IP Bereich. VPN (in meinem Fall Bitdefender 40€ pro Jahr) behebt das Problem (logisch).

Allerdings wurde hier schon hoch und runter (ja ich habe alle 63 Seiten gelesen) Lösungen und Antwortvorschläge gebracht. Es macht einfach keinen Sinn, dass manche Routen betroffen sind und manche nicht. Wenn Amazon/Telekom hier wirklich in einem Vertragskampf sind und Druck machen wollen, dann wäre das ganze m.M.n. flächendeckend und vermutlich auch illegal.

Es wurde ja sogar von Amazon bestätigt, dass speziell Github hauptsächlich aus East-US operiert und NICHT die vorgesehene Infrastruktur zur Lastverteilung nutzt.. WARUM? Das ist ein Amazon eigener Service der offensichtlich nicht durchdacht umgesetzt wurde... Da greife ich mir doch an den Kopf... Warum greift niemand Amazon an, dass der/die Github Server nicht in Deutschland stehen/repliziert werden?

Außerdem wurde ebenfalls beschrieben, dass Telekom ihren Vertrag hinsichtlich Leistungserbringung anhand der gemessenen Bandbreite erfüllt. Ich kann mich nicht beschweren, wenn ich z.B. einen 1000ms Ping auf ein Gaming Server in Buxdehude habe und bestimmt keine Forderung mit Ersatzansprüchen stellen, dass die Telekom dieses Problem beheben muss. Ich kann mich stattdessen freundlich an den Support wenden und hoffen, dass sie eine Lösung haben.

Und das Thema wurde ja Telekom-seitig aufgegriffen, untersucht und weitergegeben. Und aus eigener beruflichen Erfahrung kann ich versichern, dass auf beiden Seiten Amazon/Telekom ein recht hohes Mitglied des Mgmt. beteiligt ist bei einem Thema mit solcher Tragweite.

Und die Unterstellung, der Telekom wären ihre Kunden egal, kann ich in keiner Weise folgen... Welchem Unternehmen ist seine Einnahmequelle egal? ...

In diesem Sinne einen Schönen Tag

[#21]

---

@CarstenWeber22  schrieb:

Es wurde ja sogar von Amazon bestätigt, dass speziell Github hauptsächlich aus East-US operiert und NICHT die vorgesehene Infrastruktur zur Lastverteilung nutzt.. WARUM? Das ist ein Amazon eigener Service der offensichtlich nicht durchdacht umgesetzt wurde... Da greife ich mir doch an den Kopf... Warum greift niemand Amazon an, dass der/die Github Server nicht in Deutschland stehen/repliziert werden?

Github gehört seit 2018 Microsoft und war auch vorher nicht in irgendeiner Weise mit Amazon verbunden. Wenn man sich an den Kopf greifen möchte, dann aus Verwunderung darüber, dass Microsoft es binnen zwei Jahren nicht geschafft hat, den Dienst auf die eigene Cloud-Plattform zu migrieren.

Das CDN-Feature von Amazon kostet übrigens für den AWS-Kundenzum Teil erheblich mehr (insb. Verkehr von/nach Asien ist teuer), auch die interne Verteilung zu den CDN-Knoten lässt sich AWS bezahlen. Daher nutzen viele AWS-Kunden nur eine Verfügbarkeits-Region - und da bietet sich die USA Ost eben an, da von dort (normalerweise) Europa genauso gut erreicht wird wie z.B. die Westküste der USA. Insofern ist es zumindest nachvollziehbar, dass Microsoft einem Wettbewerber nicht unbedingt mehr zahlen möchte als nötig. Github scheint aber selbst überhaupt nicht erreichbar zu sein, denn dort könnte man das Problem natürlich auch platzieren. Eine Rückfrage eines solchen umsatzstarken Kunden bei Amazon würde vermutlich mehr bewegen, als mein offenes Ticket dort bei einem Umsatz von $10 pro Monat...

Die Anbindung der Microsoft Cloud an das Netz der Telekom ist übrigens einwandfrei - egal ob man die Daten bei Microsoft USA  hostet oder in Europa. Bei Google Cloud ebenso - insofern kann man Amazon zumindest vorwerfen, die Daten nicht im eigenen Netz transportieren zu wollen.

[#22]

Das ist natürlich korrekt so. Und auch irgendwo nachvollziehbar. Mir geht es hier vor allem darum, dass es wiederholt gesagt wurde, dass das Problem kein einfaches ist und allem Anschein nach, nicht nur auf Telekom zurückfällt. Hier sind einige Parteien beteiligt und dies ist bestimmt auch nicht ganz einfach zu handhaben.
Aber egal wohin man schaut, jede Partei hat eigentlich nur Verluste von dieser Störung.. Hier dann von Vorsatz zu sprechen macht es einem natürlich sehr einfach.

Naja und man darf auch nicht vergessen, selbst bei solch großen Firmen arbeiten auch nur Menschen, die Fehler machen, sowie Manager, die teilweise interne Firmenpolitik betreiben bzw. sich über interne Zuständigkeiten streiten (kann ich auch aus Erfahrung sprechen). So werden dann aus eigentlich einfachen Sachverhalten, größere Geschichte. Wenn das ganzen dann noch rechtliche Auswirkungen hat sowieso.

[#23]

WinMTR statistics |

MTR-Record für "github-production-release-asset-2e65be.s3.amazonaws.com"

Host - % Sent Recv Best Avrg Wrst Last

fritz.box - 0	2826	2826	2	8	105	22
Deutsche Telekom AG and located in Frankfurt am Main, Germany p3e9bf5b1.dip0.t-ipconnect.de - 0	2826	2826	7	14	121	33
217.5.113.74 - 1	2730	2729	12	123	3239	15
217.5.113.74 - 0	2821	2821	12	44	2186	31
Deutsche Telekom AG and located in Frankfurt am Main, Germany 80.156.162.178 - 0	2826	2826	24	31	214	49
TATA Communications and located in Frankfurt am Main, Germany if-ae-45-2.tcore1.fr0-frankfurt.as6453.net - 17	1722	1445	97	111	223	120
if-ae-55-2.tcore2.pvu-paris.as6453.net - 13	1893	1659	97	111	248	110
if-ae-49-2.tcore1.pvu-paris.as6453.net - 13	1901	1669	97	111	270	106
if-ae-11-2.tcore1.pye-paris.as6453.net - 26	1390	1030	97	111	248	101
if-ae-3-2.tcore1.l78-london.as6453.net - 54	899	416	97	117	263	123
if-ae-66-2.tcore2.nto-newyork.as6453.net - 13	1898	1665	97	111	272	114
if-ae-12-2.tcore1.n75-newyork.as6453.net - 12	1923	1696	96	111	244	154
Tata Communications (America) Inc and located in New York, New York, United States 66.110.96.157 - 1	2815	2812	105	112	240	122
52.93.31.43 - 1	2819	2817	100	108	225	122
52.93.4.26 - 1	2804	2798	105	112	228	119
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
Amazon Technologies Inc. and located in Seattle (South Lake Union), Washington, United States 150.222.243.197 - 17	1688	1402	110	118	222	154
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0
No response from host - 100	567	0	0	0	0	0

So sieht bei mir die Statistik aus, wenn ich versuche was von AWS S3 zu ziehen…
Allem Anschein übergibt die Telekom in Frankfurt mit dem 5. Hop an TATA Telecommunications (Indernet).
Dort bekomme ich endlos packet loss und besch… Zeiten.
Aber auch bei Amazon Technologies Inc. sieht es nicht viel besser aus.

[#24]

Hallo,

ich habe das Problem seit Mitte Dezember und kann im Home-Office kaum arbeiten. Ich möchte mal ein paar einfache Ja/Nein Frage in die Runde stellen und sie aus meiner Perspektive beantworten. 

Haben alle Telekom Kunden dieses Problem?

Nein.

Ein Kollege und ich haben das Problem. Ein anderer Kollege, der bei der Telekom ist, hat keine Probleme

Haben Kunden von anderen Providern ein Problem?

Nach meinem Kenntnisstand: Nein!

Ist dies ein Telekom Problem?

Aufgrund meiner vorherigen Antworten würde ich eindeutig sagen: Ja

[#25]

@JoeH1 

Wann hast Du gemessen und mit welche Datenrate war ein Download möglich? Die Dir zugeordnete IP aus dem Bereich 62.155.0.0/16

weist nämlich im wesentlich interessanteren Routing von Amazon (USA EAST) zur Telekom eine direkte Verbindung auf, d.h. ein Download müsste mit normaler Datenrate erfolgen - falls nichts, wäre auch das direkte Peering zwischen Amazon und der Telekom überlastet.

Das von Dir gepostete Routing zu Amazon sagt nicht viel aus, das der Zielhost nicht auf ping-Anfragen reagiert (hier wäre aber der Packetloss relevant). Alle Router auf dem Weg dorthin beantworten ping-Anfragen entweder gar nicht (*  * *) oder nur mit geringer Priorität, so dass man fehlende Antworten nicht nachteilig interpretieren darf.

[#26]

TATA Communications ist vermutlich eins der Atlantik-Seekabel. Die sind vermutlich überlastet im Moment.

z.B. https://www.submarinecablemap.com/#/submarine-cable/tata-tgn-atlantic

[#27]

Hallo, bei mir bei Github und einigen anderen Seiten dasselbe. Schneckenlangsamer Download. Lade ich übers Handy (O2) herunter, geht's problemlos.

[#28]

---

@bernds.rodgau  schrieb:

TATA Communications ist vermutlich eins der Atlantik-Seekabel. Die sind vermutlich überlastet im Moment.

z.B. https://www.submarinecablemap.com/#/submarine-cable/tata-tgn-atlantic

---

Es gibt keinerlei Hinweise darauf, dass eine Überlastung von Fremdnetzen ursächlich für die Einschränkung der Telekom-Kunden beim Download von Daten von Amazon AWS sind. Die Telekom nutzt TATA nur für die Route in Richtung AWS USA. Die deutlich höher ausgelastete Rückroute erfolgt über primär über Cogent und für einige wenige IP-Adressbereiche (z.B. für das Telekom-Mobilnetz) über eine direkte Anbindung der Telekom an AWS. Da Cogent selbst keinerlei Überlastung zu anderen europäischen Anbietern aufweist, liegt es nahe, dass ein Engpass am Übergang zwischen Cogent und der Telekom vorliegt. Die Telekom behauptet von sich, Tier-1 Provider zu sein (das sind Provider, die keinen IP-Transit zukaufen müssen, da sie alle anderen Tier-1 Provider direkt erreichen). Somit liegt es ausschließlich an der Telekom, für genügend Bandbreite aus dem Netz von Cogent zu sorgen.

Aktuell (11:230 Uhr)werden übrigens 8KB/s erreicht, Hurra, wir sind wieder auf ISDN-Niveau angekommen...

[#29]

Ich habe jetzt einen deutlich größeren Hebel in Bewegung gesetzt. Der Anbieter Asana wird nun Amazon kontaktieren und in die Pflicht nehmen. Sobald ich Rückmeldungen habe melde ich mich.