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]

Hi,

scheint wieder in Ordnung zu sein... seit heute sind die Downloadzeiten wieder normal.

[#6]

Ich hab deshalb schon öfter Überlegt denn Anbieter zu wechseln.

Andere Konkurrenten kommen dann aber mit Kabel daher, und so richtig ne ipv4 will und kann ich mir nicht teilen genauso wie ich keine "stabilität" die mal wieder auch bei der telekom am bröckeln ist, missen möchte.

Dennoch ist es als Entwickler nen Riesen problem, ich hab schon öfter darüber nachgedacht nen server zu nehmen bei dem VPN drauf zu klatschen und die Route dann zu erzwingen. Damit Github endlich schnell ist.

Und hier hab ich jetzt sehr viele Kommentare gelesen, wie die Telekom muss sich ja nicht darum kümmern. 

Dazu will ich sagen, ja das stimmt, sie haben keinen Einfluss auf den Server, aber wie hier auch schon viel gesagt, sie haben Einfluss auf die Infrastruktur dazwischen, zumindest hier in Deutschland, und die TK gehört auch zu einem Anbieter der eigendlich das ganze Internet erreichbar machen möchte oder sogar muss!?. Dafür gibts ein Fachbegriff kp gerade..

Aber man hört ja immer wieder das das Peering verhalten der Telekom sehr unsozial ist. und wenn man dann sowas liest:

https://www.hetzner.com/de/news/03-20-dtag/ (Achtung Telekom Kunden könnten Probleme bekommen beim Laden dieser Seite wie bei mir gerade auch ...............)

Dann könnte man einfach nur ausrasten und einfach Kündigen und kp das ist einfach so ******. Kann man nich anders sagen.

Oder die faxen das sie verschiedenen Traffic bevorzugen wollen. 

Und mal von dem allem abgesehen. Warum wenn Ihr meint das is nich so das hat kein Effekt, wahrscheinlich is der Server schuld.

Dann mal ganz ehrlich WAAARRRRUMMMM Bitte, ist der Server langsam über die Telekom Leitung, aber über Leitungen von Vodafone am gleichen Standort mit weniger Bandbreite, getestet mit gleichen Servern etc. WARUM hat dann diese Schlechtere Leitung ein 100 Mal schnelleres Ergebnis beim Download?? By the way, gleiche nameserver etc. 

Dafür würde ich gern mal ne Vernünftige Begründung hören, die nachvollziehbar und Akzeptabel ist, da ich hier für 90 MB nen Ganzen Nachmittag brauche, und über Hotspot 5 minuten. Weil da die Bandbreite einfach schlecht ist. Dennoch Tausend mal schneller. 

Meine aktuelle Begründung, siehe Hetzner,  Telekom will einfach alle **** und Abkassieren. Genauso wie es die Rundfunkanstalten machen und alle anderen in diesem die sich nicht ernsthaftem Wettbewerb ausgesetzt fühlen / sind.

Das is Deutschland. 

[#7]

Schade, dass Hetzner nicht die Gelegenheit ergriffen hat gegen die Telekom eine Wettbewerbsklage zu starten wegen Monopolmissbrauch. 

[#8]

@Rob.A. 

Wo bitte hat die Telekom denn ein Monopol? 😂

Klar das von der Telekom mit "Double Paid Traffic" ist ungewöhnlich, aber meiner Meinung in den letzten Jahren schon besser geworden. Was bei GitHub hier aber das Problem darstellt ist nicht Strecke Telekom -> GitHub sondern der Rückweg der aus irgendwelchen Gründen über die USA läuft.

Bei mir auf dem Handy rennt GitHub problemlos, scheint also auch nur wenige zu betreffen.

[#9]

---

@trackhe  schrieb:
Dafür würde ich gern mal ne Vernünftige Begründung hören, die nachvollziehbar und Akzeptabel ist, da ich hier für 90 MB nen Ganzen Nachmittag brauche, und über Hotspot 5 minuten.

Magst Du uns konkrete Beispiele nennen? Github nutzt seit ca. einem Jahr ein CDN, das zumindest nach meinen Erfahrungen keinerlei Engpässe beim Ausliefern von Daten ins Netz der Telekom aufweist.

Beispiel (575 MB File, lädt bei mir aktuell fullspeed mit 100 Mbit/s):

https://github.com/gamer-os/install-media/releases/download/2020-10-02/gameros-2020.10.02-x86_64.iso

[#10]

Gitub nutzt leider kein CDN für die Asset-Downloads, sondern direkt S3. 

Verstehe allerdings auch nicht, warum Github hier kein Cloudfront einsetzt.

Und wegen Monopolmissbrauch: Natürlich hat die Telekom eine marktbeherrschende Stellung gegenüber Hetzner und anderen Anbietern. Sonst würde sie mit ihren unberechtigten Forderungen nicht durchkommen.

[#11]

Github gehört seit 2018 zu Microsoft und es ist in der Tat verwunderlich, warum Github weiterhin auf eine eigene Cloud-Infrastruktur setzt bzw Amazon S3 nutzt. Die Verbindungsprobleme zwischen Amazon S3 und der Telekom sind aber gelöst (nach gefühlt 1000 Nachrichten hier im Thread...). Falls es bei Dir der Download von S3 Assets immer noch hakt, poste bitte mal eine Beispiel-URL. Wir haben uns hier bisher immer auf die Probleme bei der AWS Region US-EAST fokussiert, es könnte sein, dass andere Regionen weiterhin Probleme machen.

[#12]

Das nenn ich erstaunlich 😮

Heute gehts und das auch mit der vollen Leitung. https://github.com/gamer-os/install-media/releases/download/2020-10-02/gameros-2020.10.02-x86_64.iso 

Es war mal so extrem das ich 9 mb sogar auf mein eigenen Server geladen habe und dann da Runtergeladen habe.

Beispiel: 

https://github.com/docker/compose/releases

https://github.com/docker/compose/releases/download/1.29.1/docker-compose-Darwin-x86_64

Und ich mach mir ganz sicher nicht solch mühe ohne grund. Das war am 22 Dec 2020

Gestern Hatte ich das Problem bei denn Repositorys von ESP-IDF. Halben Tag gebraucht für lass mich lügen ca 400mb kp.

"Github nutzt seit ca. einem Jahr ein CDN" das wusste ich schon, nur ist damit nicht geklärt weshalb es bei dem einen Anbieter besser läuft als beim anderen, trotz gleicher nameserver und sogar geringerer leitungs Kapazität.

"Bei mir auf dem Handy rennt GitHub problemlos" ja bei mir auch mit vodafone und o2 xD das sind ja meine test netze fals die telekom über dsl mal wieder nen navi zum routen braucht.

---

@FelixKruemel  schrieb:
Wo bitte hat die Telekom denn ein Monopol?

Naja ich würde sagen da wo die Gerichte es auch gesehen haben, und deshalb das Netz an andere Bewerber weitervermieten müssen. Zb 1und1.

---

@FelixKruemel  schrieb:
Was bei GitHub hier aber das Problem darstellt ist nicht Strecke Telekom -> GitHub sondern der Rückweg der aus irgendwelchen Gründen über die USA läuft.

Das konnte ich noch nicht beobachten. Zumal ich keine Ahnung habe warum und wie das möglich sein soll, da die Antwort doch für gewöhnlich denn gleichen weg zurück nimmt oder nich? Hier muss ich sagen steh ich gerade nicht tief genug in der Materie, also wenn das echt so ist dann is das echt halt doof gelaufen.

Dennoch bleibt platz sich aufzuregen das sowas wie Double paid traffic offensichtlich existiert. Ich hab mich am ende geweigert 5 euro für jeden server extra zu zahlen und überlegt eher zu wechseln. wenn der Anschluss nich der telekom gehören würde aber das hab ich ja schon einmal beschrieben.

[#13]

---

@trackhe  schrieb:
Naja ich würde sagen da wo die Gerichte es auch gesehen haben, und deshalb das Netz an andere Bewerber weitervermieten müssen. Zb 1und1.

Das hatte doch völlig andere Hintergründe die mit dem Thema hier nichts zu tun hatten.  Auch da ging es aber nicht um ein Monopol. 

[#14]

---

@der_Lutz  schrieb:
Das hatte doch völlig andere Hintergründe die mit dem Thema hier nichts zu tun hatten.  Auch da ging es aber nicht um ein Monopol. 

ok: https://www.faz.net/aktuell/wirtschaft/telekommunikation-eu-verfahren-gegen-telekom-monopol-137510.h... 

https://www.rnd.de/wirtschaft/das-kabel-privileg-fur-mieter-steht-vor-dem-aus-KW34NQPZVFDIHPMHSQWT2I...

und noch viel mehr was in die Richtung geht, http://www.igfd.org/?q=DTAG+Monopol dazu werd ich nichts weiter schreiben. Jeder kann ja seine Meinung haben.

[#15]

@trackheOh man, manchmal möchte man nur schreiben..... Herr ..lass Hi.... regnen

[#16]

@trackhe 

liest du auch den Inhalt hinter deinen Links bevor du sie postest?

Ich behaupte mal nicht, denn sie unterstützen meinen Beitrag.

[#17]

@trackhe 

Der erste link ist 20 Jahre alt

m zweiten Link geht es um das Kabelnetz welches die Telekom ger nicht mehr besitzt

Im dritten Link ist der erste Treffer -- Vor 20 Jahren viel das Telekom Monopol

Das sind wirklich 1a Beweise für deine Theorie eines Monopols - nicht 

Dein Beitrag ist mit einem Wort gesagt: traurig.

[#18]

Die Telekom ist bei Breitbandanschlüssen klarer Marktführer und bildet zumindest mit Vodafone defakto ein Duopol. Und wenn die Telekom diese marktbeherrschende Stellung ausnutzt um Mitbewerber in anderen Bereichen (Serverhosting) zu schwächen, wäre dies IMHO schon eine Klage wert.

Aber etwas off-topic...

Ich hatte letzte Woche auch wieder massive Probleme beim GitHub S3 Download. Diese Woche ist wieder alles okay.