Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar

lsup · ‎16.12.2020

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?

Waldemar H. · ‎29.01.2021

@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.

Lösung in ursprünglichem Beitrag anzeigen

hg42 · ‎19.01.2021

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...

Lösung in ursprünglichem Beitrag anzeigen

Stefan · ‎13.01.2021

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

Lösung in ursprünglichem Beitrag anzeigen

tm_107 · ‎08.01.2021

Von einem Telekom Business Anschluss (79.193.46.xx) an dem mitten im VDSL-Ausbaugebiet nur 12 MBit/s ADSL machbar ist:

wget http://54.198.87.21/testfile.zip
--2021-01-08 15:52:41-- http://54.198.87.21/testfile.zip
Verbindungsaufbau zu 54.198.87.21:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 52436980 (50M) [application/zip]
Wird in »»testfile.zip«« gespeichert.

testfile.zip 0% [ ] 446,88K 39,7KB/s etwa 21m 1s

Es sind also nicht nur Privatkunden betroffen.

Über provisorisch eingerichtete Web-Proxy bei Manitu und Goneo kommt die Datei mit dem Maximum der Leitung (ca. 1,4 MB/s).

jkammann · ‎08.01.2021

@tm_107

Routing wie bei mir über Cogent in Washington+Chicago:

traceroute to 79.193.46.1 (79.193.46.1), 30 hops max, 60 byte packets
 1  216.182.229.157 (216.182.229.157)  2.286 ms 216.182.229.159 (216.182.229.159)  6.137 ms 216.182.224.180 (216.182.224.180)  13.215 ms
(...)
 9  be4056.ccr41.dca01.atlas.cogentco.com (38.140.146.177)  2.095 ms 52.93.28.141 (52.93.28.141)  1.171 ms 100.100.2.72 (100.100.2.72)  11.132 ms
10  100.100.2.66 (100.100.2.66)  11.291 ms 100.100.28.8 (100.100.28.8)  1.148 ms be3083.ccr41.iad02.atlas.cogentco.com (154.54.30.54)  2.168 ms
11  be3083.ccr41.iad02.atlas.cogentco.com (154.54.30.54)  2.464 ms 80.156.162.241 (80.156.162.241)  3.414 ms  3.483 ms
12  100.100.2.78 (100.100.2.78)  10.095 ms 80.156.162.241 (80.156.162.241)  3.348 ms be3083.ccr41.iad02.atlas.cogentco.com (154.54.30.54)  2.322 ms
13  p4fc12e01.dip0.t-ipconnect.de (79.193.46.1)  126.274 ms p5b17c059.dip0.t-ipconnect.de (91.23.192.89)  107.900 ms *

Ich glaube auch nicht, dass die Telekom hier "absichtlich" zwischen Geschäfts- und Privatkunden unterscheidet. Hier liegt einfach ein Konfigurationsfehler vor und es ist eben Glück oder Pech, aus welchem IP-Adressbereich man gerade eine IP-Adresse erhalten hat. Aus dem Mobilfunknetz läuft es einwandfrei, da hier ja weitgehend NAT gemacht wird und die wenigen Gateways über das private Peering bedient werden.

Stefan · ‎08.01.2021

@jkammann schrieb:

Hier liegt einfach ein Konfigurationsfehler vor und es ist eben Glück oder Pech, aus welchem IP-Adressbereich man gerade eine IP-Adresse erhalten hat.

Das ist genau dass, was ich die ganze Zeit geschrieben habe.

Jetzt stellt sich nur die Frage, wer ihn beheben kann.

Und da ist leider die einzige Quelle die wir haben die Antwort hier vom Team.

Da aber bestimmt keine Stammtischbabbler im Netzwerkmanagement sitzen, gehe ich mal davon aus, dass da was dran ist.

Wenn es nämlich mit einem Fingerschnippen erledigt wäre, dann hätte schon jemand geschnippt.

soupdiver · ‎08.01.2021

Dickes Danke für das nice debugging! 💪

jkammann · ‎08.01.2021

Ich habe gerade einen Anruf eines network engineers von AWS erhalten, was ich an sich schon sehr anständig finde, denn solche Anrufe sind eigentlich Premium-Support Kunden vorbehalten. Er hat bestätigt, das AWS keinerlei Interesse daran hätte, existierende direkte Peerings nicht zu verwenden, schließlich verdiene Amazon am abgehenden Netzwerkverkehr seiner Kunden.

Verbindungsprobleme zu Github kenne er, leider sei Github sehr auf die Region USA Ost "fokussiert" was zu gelegentlichen Problemen beim Zugriff außerhalb der USA führen könnte (sprich Github nutzt nicht die eigentlich zur Lastverteilung vorgesehenen welweit verteilten AWS Zonen).

Sein Verständnis war auch, dass es an der Telekom läge, die verwendeten IP-Adressbereiche zu annoncieren. Ein "manual override" erfolge nur, wenn die direkte Route unerwartete Probleme aufweise. AWS nutze immer die netzwerktechnisch gesehen günstigste Route. Allerdings meinte er auch, dass es bei direkten Peering-Vereinbarung noch andere technische Parameter vertraglich geregelt werden könnten, z.B. eine tageszeitabhängige Begrenzung der Bandbreite und damit einhergehend ein unterschiedliches Routing je nach Tageszeit bzw Last (NB: Das habe ich bisher nicht feststellen können, auch z.B. frühmorgens erfolgt das Routing über Cogent).

Er versprach, die Sache an das NOC weiterzuleiten - ich habe ihm im Nachgang noch die betroffenen IP-Adressbereiche geschickt:
79.192.0.0/10

93.192.0.0/10

91.0.0.0/10

80.128.0.0/11

84.128.0.0/10

87.128.0.0/10

Also abwarten, was passieren wird...

sral96 · ‎08.01.2021

@jkammann

Also falls die Telekom noch Personal sucht, dir könnten sie ein Angebot machen 😂

bernds.rodgau · ‎08.01.2021

Danke für eure ausführlichen Untersuchungen. Bei mir ist es auch so:

wget -O /dev/null http://54.198.87.21/testfile.zip
--2021-01-08 18:32:58-- http://54.198.87.21/testfile.zip
Connecting to 54.198.87.21:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 52436980 (50M) [application/zip]
Saving to: `/dev/null'

0% [ ] 97.108 18,9K/s eta 46m 4s

Meine IP ist 79.204.xxx

Routenverfolgung zu ec2-54-198-87-21.compute-1.amazonaws.com [54.198.87.21]
ber maximal 30 Hops:

1 1 ms 1 ms 1 ms speedport.ip [192.168.2.1]
2 12 ms 10 ms 10 ms p3e9bf64f.dip0.t-ipconnect.de [62.155.246.79]
3 15 ms 11 ms 11 ms pd900cb1e.dip0.t-ipconnect.de [217.0.203.30]
4 24 ms 23 ms 23 ms 80.156.162.178
5 99 ms 97 ms 96 ms if-ae-45-2.tcore1.fr0-frankfurt.as6453.net [195.219.50.20]
6 99 ms 97 ms 97 ms if-ae-55-2.tcore2.pvu-paris.as6453.net [80.231.245.6]
7 98 ms 96 ms 96 ms if-ae-49-2.tcore1.pvu-paris.as6453.net [80.231.153.20]
8 100 ms 98 ms 97 ms if-ae-11-2.tcore1.pye-paris.as6453.net [80.231.153.50]
9 * 98 ms * if-ae-3-2.tcore1.l78-london.as6453.net [80.231.154.143]
10 97 ms 97 ms 97 ms if-ae-66-2.tcore2.nto-newyork.as6453.net [80.231.130.106]
11 98 ms 96 ms 96 ms if-ae-12-2.tcore1.n75-newyork.as6453.net [66.110.96.5]
12 148 ms 205 ms 204 ms 66.110.96.157
13 148 ms 105 ms 132 ms 52.93.31.47
14 102 ms 100 ms 100 ms 52.93.4.14
15 * * * Zeitberschreitung der Anforderung.
16 * * * Zeitberschreitung der Anforderung.
17 * * * Zeitberschreitung der Anforderung.

Ab da ist es dann tracert auch zu langweilig und es gibt nur noch Zeitüberschreitung.

Stefan · ‎08.01.2021

@bernds.rodgau schrieb:

Danke für eure ausführlichen Untersuchungen. Bei mir ist es auch so:

Ab da ist es dann tracert auch zu langweilig und es gibt nur noch Zeitüberschreitung.

nein, nur ist die Route zu lang und die ganzen Server antworten nicht auf ICMP Pakete

versuch mal

tracert /h 50 54.198.87.21

und lass ihn laufen. Da kommt er dann auch am. ziel an.

Rob.A. · ‎08.01.2021

Komisch, dass dann die Telekom in Deutschland der einzige Provider mit diesen Problemen ist. Du sagst also, dass AWS eine Abfrage macht: Wenn Telekom-User, dann Drossel die Verbindung auf 500 Byte/s ?

Edit: Antwort auf Stefan. Wieso wird denn hier nicht der Beitrag, auf den man antwortet zitiert?

Stefan · ‎08.01.2021

@Rob.A. schrieb:

Du sagst also, dass AWS eine Abfrage macht: Wenn Telekom-User, dann Drossel die Verbindung auf 500 Byte/s ?

Wo soll so was jemand geschrieben haben? Lies noch mal ganz von vorne

Fürs Zitieren würde ich den entsprechenden Knopf drücken.

tm_107 · ‎09.01.2021

@Stefan schrieb:
Fürs Zitieren würde ich den entsprechenden Knopf drücken.

Die Variante, dass man erst auf Antworten klicken muss und danach auf den "Zitieren"-Button kenne ich allerdings auch von keiner anderen Forensoftware.
Mehrere Zitate aus unterschiedlichen Postings in eine Antwort zu packen ist somit scheinbar nicht möglich. Jedenfalls habe ich noch keinen Weg gefunden.

Back to topic: Aktuell (Samstag, 09.01.21, 02:54 Uhr) kann ich von github mit vollem Speed herunterladen. Sowohl hier @work mit 12 MBit/s als auch @home mit 50 MBit/s (beides 79er IPs). Mal schauen wie das morgen bzw. nächste Woche aussieht ...

rommon · ‎09.01.2021

@tm_107 schrieb:
@Stefan schrieb:
Fürs Zitieren würde ich den entsprechenden Knopf drücken.
Die Variante, dass man erst auf Antworten klicken muss und danach auf den "Zitieren"-Button kenne ich allerdings auch von keiner anderen Forensoftware.
Mehrere Zitate aus unterschiedlichen Postings in eine Antwort zu packen ist somit scheinbar nicht möglich. Jedenfalls habe ich noch keinen Weg gefunden.

Back to topic: Aktuell (Samstag, 09.01.21, 02:54 Uhr) kann ich von github mit vollem Speed herunterladen. Sowohl hier @work mit 12 MBit/s als auch @home mit 50 MBit/s (beides 79er IPs). Mal schauen wie das morgen bzw. nächste Woche aussieht ...

Nachts funktioniert es prima, nur halt jetzt nicht mehr 😩

Habe ne 84er IP Adresse.

ich hatte gestern versucht meine FRITZBox auf nur IPv6 umzustellen (vlt hat man da das problem nicht), Aber dann funktioniert gar nichts mehr. Vlt. habe ich auch nicht die richtigen Einstellungen gemacht. War mir dann zu kompliziert und habe leider keine weiteren Nachforschungen betrieben.

Stefan · ‎09.01.2021

@rommon schrieb:

ich hatte gestern versucht meine FRITZBox auf nur IPv6 umzustellen (vlt hat man da das problem nicht),

wie soll das auch gehen, wo doch z.B. www.github.com oder ec2-54-198-87-21.compute-1.amazonaws.com gar keine IPv6 Adresse hat

rommon · ‎09.01.2021

Schade. Das Internet Protokoll braucht schon noch ein paar Jahre um ausgereift zu sein... 😔

soupdiver · ‎09.01.2021

@rommon schrieb:
Schade. Das Internet Protokoll braucht schon noch ein paar Jahre um ausgereift zu sein... 😔

Hmm... also wenn man sich die letzten 20 Beiträge anschaut, kann man glaub sagen, dass das Problem nicht das IP ist. Aber ok... Wenn github kein IPv6 konfiguriert, dann kann IPv6 auch keine Lösung sein, auch wenn es ausgereift ist. 😅

jkammann · ‎09.01.2021

IPv6 wäre tatsächlich die Lösung, denn das Peering zwischen Amazon und Telekom erfolgt bei IPv6 anscheinend direkt, wie man bei aktiviertem IPv6 auf der Webseite https://mtr.sh/ überprüfen kann ("trace" sowie "North America US-VA /AWS" auswählen).

Das sieht dann so aus:

traceroute to 2003:eb:573a:7800:e453:44af:8183:6083 (2003:eb:573a:7800:e453:44af:8183:6083), 50 hops max, 80 byte packets
 1  2620:107:4000:4009:8000:0:6441:1300 (2620:107:4000:4009:8000:0:6441:1300) [*]  9.551 ms  10.871 ms * *
 2  2620:107:4000:4009:8000:0:6442:c8c (2620:107:4000:4009:8000:0:6442:c8c) [*]  1.623 ms  1.630 ms
 3  2620:107:4000:4009:8000:0:6442:260a (2620:107:4000:4009:8000:0:6442:260a) [*]  10.707 ms 3.056 ms  [*]  0.716 ms
 4  2620:107:4000:400d:8000:0:6442:779 (2620:107:4000:400d:8000:0:6442:779) [*]  4.434 ms  10.106 ms 0.658 ms  8.691 ms  2.758 ms
 5  2620:107:4000:4009:8000:0:6442:53d (2620:107:4000:4009:8000:0:6442:53d) [*]  4.912 ms   6.093 ms  2.761 ms   2.799 ms
 6  2620:107:4000:4009:8000:0:6441:cc1 (2620:107:4000:4009:8000:0:6441:cc1) [*]  0.605 ms   0.583 ms   0.230 ms 2620:107:4000:4009:8000:0:6441:d61  0.657 ms  0.532 ms
 7  2620:107:4000:2000::d1   0.501 ms 0.437 ms  0.407 ms 0.413 ms 0.361 ms
 8  2620:107:4000:8002::24   0.592 ms  0.400 ms  0.517 ms  0.450 ms  0.464 ms
 9  * * 2003:3c0:1600:8013::1 (2003:3c0:1600:8013::1) [AS3320]  1.835 ms  1.724 ms  1.727 ms
10  2003:3c0:1600:8013::1 (2003:3c0:1600:8013::1) [AS3320]  2.014 ms 104.386 ms  104.377 ms  104.241 ms  104.346 ms
11  p200300eb57ff3a99de396ffffe43fd34.dip0.t-ipconnect.de (2003:eb:57ff:3a99:de39:6fff:fe43:fd34) [AS3320]  107.533 ms !X  107.554 ms !X  107.865 ms !X

Die mit 2620:107 beginnenden Adressen sie die von AWS, die mit 2003 gehören der Telekom, kein Transitprovider zwischen Hop9 und 10 erkennbar.

Der trace stammt wie gesagt von MRT.sh - ich dachte ich könnte mal schnell meinen Testserver bei AWS IPv6-fähig machen. Nach 2h habe ich aber gestern Abend aufgegeben. Null Dokumentation und mit eigenem Sachverstand konnte ich immerhin ein /56 Subnetz auf den virtuellen Adapter legen, der eigentlich das "lokale" Netz meines Testservers bedient. Eine Nutzung einer Adresse oder gar ein Routing nach außen ist mir aber nicht gelungen. Ich würde daher IPv6 bei AWS als experimentell bezeichnen, kein Wunder wenn Github oder Spieleanbieter dies nicht nutzen. Selbst amazon.de ist nicht per IPv6 erreichbar.

Eigentlich schade, denn aufgrund des direkten Routings wäre "unser" Problem mit IPv6 tatsächlich gelöst...

geraldFuchs · ‎10.01.2021

Bei mir ist das Problem noch vorhanden. Ich habe zu github (aws) einen downloadspeed von 56,3 KB/s

Auflösen des Hostnamens github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)… 52.217.83.28
Verbindungsaufbau zu github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)|52.217.83.28|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 604001788 (576M) [application/octet-stream]
Wird in »FreeCAD_0.18-16146-rev1-OSX-x86_64-conda-Qt5-Py3.dmg« gespeichert.

FreeCAD_0.18-16146-rev1-OSX-x86_64-conda-Qt5-Py   0%[                                                                                                       ]   2,70M  56,3KB/s    ETA 3h 4m

msp78 · ‎11.01.2021

Das Problem wird immer schlimmer! Asana Projektmanagement ist nahezu nicht mehr nutzbar.

Wann passiert hier endlich mal was?

Andrej Petras · ‎11.01.2021

Bei mir ist das Problem noch vorhanden.

sral96 · ‎11.01.2021

@Erdogan T.

könntest du uns ein kurzes Update geben, ob die Telekom noch in Klärung mit Amazon ist? Wie sehen die weiteren Schritte aus?

Zoltux_1 · ‎11.01.2021

@sral96 schrieb:
@Erdogan T.
könntest du uns ein kurzes Update geben, ob die Telekom noch in Klärung mit Amazon ist? Wie sehen die weiteren Schritte aus?

Es sieht so aus, als ob da nix geklärt wird und es auch keine weiteren Schritte gibt. Die Telekom sagt ja, Amazon ist schuld, Pech gehabt, wende dich an Amazon.

georgiee · ‎11.01.2021

Ich will mich mal in die Reihe der Betroffenen einreihen. Selbiges Problem bei mir. Zu keiner Tageszeit war bei mir der Download möglich, noch nie hatte ich eine IP, die keine Probleme mit Github/S3 hatte. Ich bin erst seit 2 Wochen Kunde der Telekom, erstaunlich womit ich mich direkt befassen muss.

Meine IP: 84.170.x.x

Zoltux_1 · ‎11.01.2021

@georgiee schrieb:
Ich will mich mal in die Reihe der Betroffenen einreihen. Selbiges Problem bei mir. Zu keiner Tageszeit war bei mir der Download möglich, noch nie hatte ich eine IP, die keine Probleme mit Github/S3 hatte. Ich bin erst seit 2 Wochen Kunde der Telekom, erstaunlich womit ich mich direkt befassen muss.

Meine IP: 84.170.x.x

Richte dir ein VPN ein, das ist zur Zeit neben Providerwechsel die einzige Lösung.

andy-ich · ‎11.01.2021

Ich habe genau das selbe Problem und komme über die Telekom Hotline nicht weiter. Die messen nur den Anschluss und wenn der passt zeigen sie kein Interesse es zu beheben. Mit Vodafone habe ich das Problem nicht.

Da dieser Beitrag bereits auf gelöst steht sollten wir neue einzelne Beiträge zu dem Fehler eröffnen. Habe Herrn Hennin H. auch nochmal folgende PN geschrieben, in der Hoffnung, dass er es eskalieren kann:

Guten Morgen,

auch ich habe dieses sehr lästige Problem:

Ich möchte Sie darüber Informieren, dass es noch bei sehr vielen Kunden akut ist, obwohl es bereits auf gelöst steht:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

Es wird weiter heiß diskutiert, mittlerweile 248 Beiträge, der letzte vor 30 Min.

Bitte geben Sie den Fall zur Eskalation weiter und setzten Sie den Status auf nicht gelöst bis es behoben ist.

Vielen Dank

der_Lutz · ‎11.01.2021

@andy-ich schrieb:
Da dieser Beitrag bereits auf gelöst steht sollten wir neue einzelne Beiträge zu dem Fehler eröffnen.

das würde gar nichts bringen und interessiert Amazon sowieso nicht.

Der Inhalt der "Lösung" ist ja unverändert gültig, Lösung heißt hier dann nicht gelöst sondern der Tag wird genutzt damit der derzeitige Stand an erster Stelle und sofort sichtbar steht.

Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar

Social Media