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]

---

@demboris  schrieb:

Wenn jemand Workarounds kennt - bitte gerne her damit

---

Einfach ein VPN/Tor nutzen.

Entweder die 2 immer kostenfreien VMs von Oracle Cloud dafür missbrauchen (haben ja 10TB Traffic drin und das nutz ich auch) oder Tor nutzen.

Irgendwann wird das sicherlich aber auch behoben sein.

[#6]

Habe gerade im November meinen Anschluss von 1&1 zur Telekom gewechselt. Vorher keinerlei Probleme, jetzt das hier beschriebene Probleme zu S3/Github mit absurd geringen Downloadraten. VPN an und es läuft mit hohen Geschwindigkeiten. Das kann doch nicht euer ernst sein? Gefühlt ist Youtube auch langsamer als vorher (aber erst in 4K zu merken), aber das ist nicht so stark, daß ich das auf jeden Fall darauf zurückführen kann. 

Man hat ja schon öfter mal gehört, daß die Telekom gerne für ihr Peering bezahlt werden möchte. Und die zahlenden Kunden müssen darunter dann leiden?!

[#7]

@technofrikus 

Das die Telekom dafür bezahlt werden möchte ist logisch, denn die Anbieter wollen schließlich auch das Telekom Netz nutzen um zum Kunden zu kommen. Ob jedoch die Strategie so ganz zielführend ist weiß ich nicht.

Dein Screenshot aber zeigt nicht den eigentlichen Endpunkt, bis zum Ende des Screenshots ist ja alles i.o.

[#8]

Soweit mir bekannt, ist es eigentlich üblich, daß man sich gegenseitig kostenlos Bandbreite zur Verfügung stellt, denn beide Seiten haben ja Kosten und Vorteile dadurch. Nur eben die Telekom möchte da gerne Geld für haben, damit die Firmen Zugang zu den Telekom-Kunden bekommen, die ja aber selbst schon Geld für eben diesen Dienst bezahlen. Mit Google/Youtube gab es da früher doch auch schon Probleme. Aber da stecke ich auch nicht super tief drin und kann mich irren. Quelle: Clemens Schrimpe im Podcast Freakshow vor längerer Zeit und aus meiner Erinnerung "zitiert".

Nach Punkt 19 kommt nichts mehr. Habe es gerade nochmal laufen lassen. 7% und 35% Packetloss sind in Ordnung?

[#9]

Du siehst aber schon das der Paket Loos nicht im Telekom Netz ist, somit ist dies auf der Route zum Ziel auch kein Peeringproblem

Das ist genau so, wenn du in Frankreich im Stau stehst und die Deutsche Autombahnmeisterei anrufst und dennen sagst - ich zahle schließlich KFZ Steuer.

Der Tracert zeigt nicht wo das Problem liegt - da könnt ihr ihn noch 100 mal posten.

Die Datei die ihr nicht laden könnt, wird bei mir heute in 2.7 Sekunden geladen. 

Ich habe exakt die Router auf dem Weg zum Server wie die anderen auch. 

die Ursache muss also wo anders liegen - z.B. auf dem Weg zurück, der gar nicht im tracert angezeigt wird.

Kostenloses Peering ist durchaus üblich, wenn die Datenvolumen in beide Richtungen vergleichbar sind.

Letzlich ist das eine Verhandlungssache. Mehr Geld ausgeben will ja der Kunde auch nicht

[#10]

@technofrikus 

Wichtig ist nur der letzte Hop. Der Paketverlust inmitten ist unwichtig, da i.d.R. die großen nodes eh nichta uf ICMP Pakete antworten wenn sie anderweitig beschäftigt sind. Und die 34% Paketverlust sind beim nächsten Hop ja wieder weg, d.h. es gibt bis dahin 0%.

[#11]

Verstehe ihr beiden. Dann ist das wohl nicht das Problem. Dann hoffen wir mal, daß die vom Telekom-Team erwähnte Erweiterung der Bandbreite zu S3 bald kommt und hilft.

[#12]

Hallo,

der Beitrag wurde ja scheinbar auf gelöst gesetzt. Ich würde mich freuen wenn nochmal aufgezeigt werden kann, was genau die Lösung sein soll?

[#13]

Auf der ersten Seite ist die entsprechende Antwort verlinkt:

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

Kurz: Die Bandbreite zu S3 ist wohl scheinbar etwas knapp und wird aber hoffentlich bald aufgestockt?

[#14]

Das Bestätigen dass ein Problem vorliegt und die Bitte zu warten kann man doch beim besten Willen nicht eine Lösung nennen.

[#15]

Sehe ich auch so. Vorschläge wie VPN sind auch nicht zielführend.

Hoffentlich kommt mein FTTH bald (anderer Anbieter). Auch wenn ich bisher mit dem Telekom Anschluß sehr zufrieden war.

[#16]

@EchoEcho 

@Kunde00815 

Es gibt hier keine Möglichkeit eine Beitrag oben anzupinnen außer ihn als Lösung zu markieren. @Henning H. ist da weiterhin dran, das Thema ist definitiv noch nicht gelöst

[#17]

Danke für den VPN Tipp. Ich habe mir mal Speedify installiert - gibt gerade 3 Jahre unlimitiert für um die 50€

damit konnte ich heute wenigsten arbeiten und zwei Downloads endlich abschließen. 

klar ist das keine Lösung weil ich das jetzt nicht auf jedem Rechner installieren möchte - aber es war ein guter Tipp um schnell wieder arbeitsfähig zu sein.  Danke. 

mich hoffe dennoch, dass ich die Software bald nicht mehr brauche!

[#18]

@demboris 
Wie gesagt, VPN's lösen sowas immer, wobei das natürlich kein echter Weg sein sollte. 

Im übrigen ist das selbe aktuell auch zu v.redd.it und i.redd.it ebenfalls, sodass bei meinem Freund mittlerweile automatisch sämtlicher Traffic zu reddit durch einen VPN geht und alles andere nicht.

Dadurch das Oracle ja auch zwei Server Instanzen gratis anbietet habe ich mir da ein VPN Endpunkt eingerichtet welchen ich auch für solche Fälle nutze. Zwar nicht sonderlich schnell (nur rund 10Mbit/s) aber reicht mir aus.

[#19]

---

@Stefan  schrieb:

das entscheidet der Loadbalancer der AWS das kannst du nicht beeinflussen.

Wüsste jedenfalls nicht wie.

---

Dazu ein vermutlich wichtiger Hinweis: Jenachdem, welcher DNS vom Kunden benutzt wird, wählt AWS das Ziel aus. Dieses Verhalten kann man auch mit nslookup manuell nachstellen, indem man unterschiedliche DNS nach demselben Hostnamen abfragt.

Ich bekomme jedenfalls verschiedene Gegenstellen bei AWS und anderswo genannt, wenn ich DNS von Google, Cloudflare, Telekom oder meinen eigenen verwende.

So könnte sich auch erklären, warum die User hier im Thread teilweise drastisch voneinander abweichende Erfahrungen schildern. Bei Verwendung vom Telekom-DNS wird man oftmals auf lokale Ziele geleitet, von denen dann gewohnt schnell heruntergeladen werden kann. Bei Verwendung von Cloudflare oder Google DNS wird hingegen aus den USA heruntergeladen. Die Geolocation greift da völlig anders.

Ihr könnt ja einfach mal mit nslookup den originalen Telekom-DNS abfragen, oder diesen testweise im Router wieder einschalten. Dann läuft der Download auch schnell, wenn ein lokaler Host verfügbar ist.

Das ändert natürlich nichts an der Tatsache, dass grundsätzlich ein schwerwiegendes Problem am Telekom-Internetzugang besteht.

[#20]

---

@KiRKman  schrieb: Das ändert natürlich nichts an der Tatsache, dass grundsätzlich ein schwerwiegendes Problem am Telekom-Internetzugang besteht.

Allerdings ist die Geooptimierung ja aktivier Ziel der AWS.

Wenn ein andere DNS diese aushobelte wirft das ja ein anderes Licht auf die Sache.

daran hatte ich auch noch nicht gedacht, aber das passt ja sehr gut, denn wie gesagt. 

Ich kann 30Mb in teilweise unter 2 Sekunden laden.

[#21]

Ich habe es bei mir mal mit dem Telekom, Google und Cloudflare DNS versucht, jedoch ohne nennenswerte Unterschiede. Interessanterweise erreiche ich gerade sogar knapp über 100 kb/s mit dem acme download. Immerhin das 10 fache im vergleich zu vor ein paar Tagen. Natürlich immer noch unterirdisch...

[#22]

Ich habe es auch nochmal geprüft und nutze den Standard Telekom DNS.

[#23]

habt ich auch den Rechner neu gestartet, nicht dass die alten Eintrage auch noch im Cache waren

[#24]

Ich habe es lokal geändert und auf dem System ein ipconfig /flushdns gemacht. Ich bin davon ausgegangen das das in der Regel reicht, ist dem nicht so?

[#25]

Ich hab nie einen anderen DNS drin gehabt außer den vom Speedport

[#26]

Interessanterweise ist der Download über das Firmen-VPN in voller Geschwindigkeit möglich - die Verbindung dort läuft ebenfalls über die Telekom, es gibt also einen Unterschied ob Firmenanbindung oder Privat.

[#27]

---

@MJPL1184  schrieb:

Interessanterweise ist der Download über das Firmen-VPN in voller Geschwindigkeit möglich - die Verbindung dort läuft ebenfalls über die Telekom, es gibt also einen Unterschied ob Firmenanbindung oder Privat.

---

Wie schon ein dutzend Mal geschrieben, funktioniert es bei mir auch mit voller Geschwindigkeit - und dies ist ein Privatkundenanschluss

[#28]

---

@lsup  schrieb:

Ich habe es lokal geändert und auf dem System ein ipconfig /flushdns gemacht. Ich bin davon ausgegangen das das in der Regel reicht, ist dem nicht so?

---

Doch, das reicht.

Wenn es aber nicht am verwendeten DNS liegt, muss ich mir noch weitere Gedanken machen. Vielen Dank jedenfalls fürs Ausprobieren.

Ich hoffe, dass man seitens der Telekom auch an der Sache arbeitet. Und damit meine ich keine Peering-Verhandlungen, in denen man den vierfachen Preis durchsetzen will. Sondern ich meine eine schnelle Lösung im Interesse der eigenen Kunden.

[#29]

Das ganze Thema ist echt erschreckend für mich. Ich komme mir vor als würde ich in einer Bar für ein Bier bezahlen und es nicht bekommen weil der Barkeeper kein Schutzgeld zahlt, denn scheinbar passiert genau das gerade hinter den Kulissen zwischen der Telekom und AWS wenn ich es richtig verstehe. 

Bei mir geht es zwar nur um Hobby-Kram und somit ist es nichts lebenswichtiges, aber verärgert bin ich trotzdem das ich momentan für einen Service monatlich bezahle, den ich über meinen DSL-Anschluss derzeit nicht erreichen kann, weil sie auf Services von AWS zurückgreifen. 

Ich bin jedoch froh das ich meinen Telekom-Anschluss gekündigt habe. Bis vor ein paar Tagen wollte ich die Kündigung zurückziehen, zum Glück habe ich das nicht getan.