Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar

Gelöst

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?

3 AKZEPTIERTE LÖSUNGEN
Lösung

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



@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  

Lösung
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  

Lösung

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

2021-01-13 10_34_03-The Fastest Free Proxy _ hide.me.png

Lösung in ursprünglichem Beitrag anzeigen  


@bernds.rodgau  schrieb:

Sieht bei mir quasi genauso aus. Wobei ich persönlich den Output von wget sprechender finde.


Was genau ist an wget sprechender?

wget https://github.com/nextcloud/desktop/releases/download/v3.1.1/Nextcloud-3.1.1-x64.msi
--2020-12-31 15:04:24-- https://github.com/nextcloud/desktop/releases/download/v3.1.1/Nextcloud-3.1.1-x64.msi
Resolving github.com (github.com)... 140.82.121.3
Connecting to github.com (github.com)|140.82.121.3|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/105010691/26429380-444d-11eb-8d91-19... [following]
--2020-12-31 15:04:24-- https://github-production-release-asset-2e65be.s3.amazonaws.com/105010691/26429380-444d-11eb-8d91-19...
Resolving github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)... 52.217.107.108
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)|52.217.107.108|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 88793088 (85M) [application/octet-stream]
Saving to: ‘Nextcloud-3.1.1-x64.msi’

Nextcloud-3.1.1-x64.msi 8%[===> ] 7.29M 45.0KB/s eta 27m 40s

Naja, man sieht nicht die Zwischenschritte, aber man kann gut sehen, was für mich als User interessant ist: ein Dateichen mit x kB braucht y Minuten bis es bei mir ist. Sagt mir als Laie halt mehr.

Ist eh wurscht, was wir hier alle disktuieren und an Fakten zusammenzutragen versuchen. Wenn der Telekom-Service das nutzt und es ihm weiterhilft: schön. Aber wenn sie das brauchen, um das Problem zu verstehen, dann ist sowieso Hopfen und Malz verloren; auf solche Ideen sollten sie hoffentlich inzwischen selbst gekommen sein. Und vermutlich liest es da sowieso kaum einer. Wenn sie sagen, sie sind dran, können wir das glauben oder nicht. Das Problem bleibt erstmal bestehen.

@msp78 

 

Stimmt, WINMTR hört nach 30 Hops auf, die Route ist aber 40 lang.

Brauchst du ein besseres Tool

Pingplotter Free z.B.


@bernds.rodgau  schrieb:

Sagt mir als Laie halt mehr.

Und? was sagt dir das darüber wo das Problem liegt? Natürlich liest hier keiner mit, der an dem Problem arbeitet, wozu auch.

Da liefert die Netzüberwachung viel genauere Angaben.

 

Target Name: s3.amazonaws.com
IP: 52.217.77.14
Date/Time: 31.12.2020 15:34:22 - 31.12.2020 15:44:22

Hop Sent PL% Min Max Avg Host Name / [IP]
1 39 0 0,57 6,16 1,00 fritz.box [192.168.10.1]
2 39 0 4,18 66,54 7,17 xxx.dip0.t-ipconnect.de [xxx]
3 39 0 6,94 9,22 7,72 pd900cb16.dip0.t-ipconnect.de [217.0.203.22]
4 39 0 13,07 26,72 14,67 80.156.162.178 [80.156.162.178]
5 39 3 89,67 108,06 91,99 if-ae-45-2.tcore1.fr0-frankfurt.as6453.net [195.219.50.20]
6 39 3 89,52 102,83 91,03 if-ae-55-2.tcore2.pvu-paris.as6453.net [80.231.245.6]
7 39 0 91,58 108,65 93,35 if-ae-49-2.tcore1.pvu-paris.as6453.net [80.231.153.20]
8 39 0 89,80 93,61 90,82 if-ae-11-2.tcore1.pye-paris.as6453.net [80.231.153.50]
9 38 47 92,23 108,44 94,21 if-ae-3-2.tcore1.l78-london.as6453.net [80.231.154.143]
10 39 0 91,88 105,54 93,96 if-ae-66-2.tcore2.nto-newyork.as6453.net [80.231.130.106]
11 39 0 91,44 98,38 92,88 if-ae-12-2.tcore1.n75-newyork.as6453.net [66.110.96.5]
12 39 0 100,10 114,28 102,12 66.110.96.157 [66.110.96.157]
13 39 0 93,92 99,79 95,45 52.93.31.45 [52.93.31.45]
14 39 0 100,16 119,72 101,30 52.93.4.12 [52.93.4.12]
15 38 100 0 0 0 [-]
16 39 0 99,41 104,50 100,45 150.222.242.132 [150.222.242.132]
17 38 100 0 0 0 [-]
18 38 100 0 0 0 [-]
19 38 100 0 0 0 [-]
20 38 100 0 0 0 [-]
21 38 3 99,11 109,91 100,58 150.222.243.213 [150.222.243.213]
22 38 100 0 0 0 [-]
23 38 100 0 0 0 [-]
24 38 100 0 0 0 [-]
25 38 100 0 0 0 [-]
26 38 100 0 0 0 [-]
27 38 100 0 0 0 [-]
28 38 100 0 0 0 [-]
29 38 100 0 0 0 [-]
30 38 100 0 0 0 [-]
31 38 3 98,93 113,31 100,80 52.93.28.234 [52.93.28.234]
32 38 100 0 0 0 [-]
33 38 100 0 0 0 [-]
34 38 100 0 0 0 [-]
35 38 100 0 0 0 [-]
36 38 100 0 0 0 [-]
37 38 100 0 0 0 [-]
38 38 100 0 0 0 [-]
39 38 100 0 0 0 [-]
40 38 100 0 0 0 [-]
41 38 100 0 0 0 [-]
42 38 100 0 0 0 [-]
43 38 3 104,58 111,51 105,68 s3.amazonaws.com [52.217.77.14]

@msp78 

wie von mir prognostiziert.

 

Ab dem Hop 5 ist es bei der Telekom raus.

in deiner Grafik vorher sieht man deutlich, dass es bis dahin keine Verluste gibt. 

es gibt somit auch auf der Route HINZUS kein erkennbares Peeringproblem.

Das ist auch nicht zu erwarten gewesen.

 

Für die Datenpakete Rückwärts bräuchte man aber eine  Lookingglas Server auf der AWS.

 

 

 

Also ich habe gerade die Nextcloud-Client-Datei (über github-production-release-asset-2e65be.s3.amazonaws.com) über LTE mit 4,3 MB/s geladen. Tracert liefert über LTE:

 

tracert github-production-release-asset-2e65be.s3.amazonaws.com

Routenverfolgung zu s3-1-w.amazonaws.com [52.217.87.124]
über maximal 30 Hops:

1 2 ms 2 ms 1 ms 192.168.43.1
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 * * * Zeitüberschreitung der Anforderung.
8 * * * Zeitüberschreitung der Anforderung.
9 33 ms 29 ms 30 ms 80.156.5.97
10 39 ms 32 ms 32 ms 62.159.98.98
11 42 ms 68 ms 38 ms l-sa1-i.L.DE.NET.DTAG.DE [62.154.89.169]
12 38 ms 37 ms 33 ms 62.159.98.98
13 42 ms 42 ms 34 ms 80.156.162.178
14 165 ms 121 ms 134 ms if-ae-45-2.tcore1.fr0-frankfurt.as6453.net [195.219.50.20]
15 129 ms 121 ms 118 ms if-ae-55-2.tcore2.pvu-paris.as6453.net [80.231.245.6]
16 132 ms 125 ms 117 ms if-ae-49-2.tcore1.pvu-paris.as6453.net [80.231.153.20]
17 133 ms 117 ms 128 ms if-ae-11-2.tcore1.pye-paris.as6453.net [80.231.153.50]
18 134 ms 121 ms * if-ae-3-2.tcore1.l78-london.as6453.net [80.231.154.143]
19 121 ms 119 ms 133 ms if-ae-66-2.tcore2.nto-newyork.as6453.net [80.231.130.106]
20 152 ms 119 ms 128 ms if-ae-12-2.tcore1.n75-newyork.as6453.net [66.110.96.5]
21 133 ms 125 ms 127 ms 66.110.96.157
22 150 ms 126 ms 125 ms 52.93.31.39
23 140 ms 125 ms 127 ms 52.93.4.38
24 * * * Zeitüberschreitung der Anforderung.
25 * * * Zeitüberschreitung der Anforderung.
26 * * * Zeitüberschreitung der Anforderung.
27 * * * Zeitüberschreitung der Anforderung.
28 * * * Zeitüberschreitung der Anforderung.
29 * * * Zeitüberschreitung der Anforderung.
30 135 ms 127 ms 128 ms 150.222.243.139

 

Also ich habe gerade die Nextcloud-Client-Datei (über github-production-release-asset-2e65be.s3.amazonaws.com) über DSL mit 25Kb/s geladen.

DSL_Nextcloud.PNG

Tracert liefert über DSL:

tracert github-production-release-asset-2e65be.s3.amazonaws.com

Routenverfolgung zu s3-1-w.amazonaws.com [52.216.237.99]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms 192.168.178.1
2 11 ms 11 ms 11 ms p3e9bf791.dip0.t-ipconnect.de [62.155.247.145]
3 20 ms 20 ms 20 ms 62.159.98.166
4 31 ms 32 ms 31 ms 80.156.162.178
5 105 ms 105 ms 105 ms if-ae-45-2.tcore1.fr0-frankfurt.as6453.net [195.219.50.20]
6 108 ms 108 ms 108 ms if-ae-55-2.tcore2.pvu-paris.as6453.net [80.231.245.6]
7 104 ms 104 ms 106 ms if-ae-49-2.tcore1.pvu-paris.as6453.net [80.231.153.20]
8 108 ms 108 ms 108 ms if-ae-11-2.tcore1.pye-paris.as6453.net [80.231.153.50]
9 105 ms 105 ms 104 ms if-ae-3-2.tcore1.l78-london.as6453.net [80.231.154.143]
10 124 ms 108 ms 109 ms if-ae-66-2.tcore2.nto-newyork.as6453.net [80.231.130.106]
11 108 ms 108 ms 108 ms if-ae-12-2.tcore1.n75-newyork.as6453.net [66.110.96.5]
12 113 ms 114 ms 113 ms 66.110.96.157
13 113 ms 113 ms 113 ms 52.93.31.43
14 119 ms 112 ms 112 ms 52.93.4.58
15 * * * Zeitüberschreitung der Anforderung.
16 118 ms * 117 ms 150.222.242.118
17 * * * Zeitüberschreitung der Anforderung.
18 * * * Zeitüberschreitung der Anforderung.
19 * * * Zeitüberschreitung der Anforderung.
20 * * * Zeitüberschreitung der Anforderung.
21 118 ms 117 ms 126 ms 150.222.243.201
22 * * * Zeitüberschreitung der Anforderung.
23 * * * Zeitüberschreitung der Anforderung.
24 * * * Zeitüberschreitung der Anforderung.
25 * * * Zeitüberschreitung der Anforderung.
26 * * * Zeitüberschreitung der Anforderung.
27 * * * Zeitüberschreitung der Anforderung.
28 * * * Zeitüberschreitung der Anforderung.
29 * * * Zeitüberschreitung der Anforderung.
30 * * * Zeitüberschreitung der Anforderung.

 

Man sieht aber daran Punkt 4 bei DSL (80.156.162.178) ist über LTE Punkt 13. Daher muss die Verlangsamung ja vorher passieren. Im Telekomnetz!

Also TSCHULDIGUNG mal! Der Flotz ist hier von Mitte Dezember und die Antwort von Ihnen hat "nur" fünf Tage gebraucht, das Thema ist als "gelöst" gekennzeichnet. Heute sind wir fast zwei Wochen weiter und das Problem BESTEHT IMMER NOCH!!!

Downloads von GitHub für eine 2,5 MB Datei von über zwei (!!!) Stunden, an was grösseres darf man gar nicht denken. Da waren ja 56k-Modems echte Renner dagegen.

 

Download per Mobilfunk hat dann innerhalb von Sekunden geklappt, mit einer 250 MB-Datei.

 

Ist das so wahnsinnig schwierig, oder muss man da erst ein neues Kabel über den Atlantik ziehen?

 

Bin einigermaßen entsetzt!

Moin!

Leider habe ich hier selbiges Problem beim Zugriff auf github. Ein Kollege im Nachbarort hat es nicht. Wie kann das denn sein?

 

Grüße

Jörg Menke


@JörgMenke  schrieb:

Moin!

Leider habe ich hier selbiges Problem beim Zugriff auf github. Ein Kollege im Nachbarort hat es nicht. Wie kann das denn sein?

 

Grüße

Jörg Menke


@JörgMenke 

Dein Nachbarort bekommt ne andere Route zu S3 welche nicht überlastet ist.

 

Wurde hier schon oft erklärt.

Moin!

Vielleicht hilft es ja bei der Lösungsfindung:

 

traceroute to github-production-release-asset-2e65be.s3.amazonaws.com (52.217.72.156), 30 hops max, 60 byte packets
 1  fritz.box (192.168.0.244)  0.902 ms  0.927 ms  1.154 ms
 2  p3e9bf327.dip0.t-ipconnect.de (62.155.243.39)  14.499 ms  14.809 ms  15.369 ms
 3  217.5.111.114 (217.5.111.114)  25.280 ms  25.854 ms  25.842 ms
 4  80.156.162.178 (80.156.162.178)  25.982 ms  26.072 ms  33.995 ms
 5  if-ae-45-2.tcore1.fr0-frankfurt.as6453.net (195.219.50.20)  109.109 ms  109.092 ms  109.349 ms
 6  if-ae-55-2.tcore2.pvu-paris.as6453.net (80.231.245.6)  110.036 ms  103.452 ms  103.412 ms
 7  if-ae-49-2.tcore1.pvu-paris.as6453.net (80.231.153.20)  107.961 ms  106.985 ms  106.900 ms
 8  if-ae-11-2.tcore1.pye-paris.as6453.net (80.231.153.50)  103.365 ms  103.350 ms  105.251 ms
 9  if-ae-3-2.tcore1.l78-london.as6453.net (80.231.154.143)  109.319 ms  110.425 ms  110.415 ms
10  if-ae-66-7.tcore2.nto-newyork.as6453.net (80.231.130.23)  106.743 ms  102.915 ms if-ae-66-2.tcore2.nto-newyork.as6453.net (80.231.130.106)  102.891 ms
11  if-ae-12-2.tcore1.n75-newyork.as6453.net (66.110.96.5)  102.778 ms  102.808 ms  103.328 ms
12  66.110.96.157 (66.110.96.157)  112.647 ms  112.633 ms  113.147 ms
13  52.93.31.39 (52.93.31.39)  111.179 ms 52.93.31.33 (52.93.31.33)  111.156 ms 52.93.31.35 (52.93.31.35)  110.322 ms
14  52.93.4.36 (52.93.4.36)  110.593 ms 52.93.4.32 (52.93.4.32)  110.842 ms 52.93.4.2 (52.93.4.2)  111.052 ms
15  * * *
16  150.222.242.146 (150.222.242.146)  114.011 ms * 150.222.242.114 (150.222.242.114)  115.353 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  150.222.243.143 (150.222.243.143)  113.455 ms 150.222.241.193 (150.222.241.193)  115.305 ms 150.222.243.203 (150.222.243.203)  117.129 ms
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

 

Grüße

Jörg

@JörgMenke 

Ist der gleiche Trace wie die letzten 100 auch Zwinkernd

Dann ist ja super. Viel hilft viel.

Hallo,

seit Ende 2020 habe ich auch das Problem, dass der Download von AWS extrem langsam ist. Ich habe dazu auch ein Ticket aufgemacht. Der AWS Rechner ist von meinem Arbeitgeber. Das Problem besteht weiterhin. Ich hatte gehofft, dass das Problem während meines Urlaub gelöst wird. Leider ist dem nicht so. Morgen werde ich nicht wirklich von zu Hause arbeiten können Traurig

Der Download von diesem Rechner ist nur über Telekom langsam. Meine Kollegen, die kein Telekom haben, haben das Problem nicht. Wenn ich die Downloadgeschwindigkeit mit meinem Vodafone Handy test, dann ist der Server schnell. Wenn ich ein kostenloses VPN benutze dann komme ich auf 2000k - was für mich nicht schnell genug ist. Mit Telekom komme ich z.Z. auf 100k - was Arbeiten unmöglich macht.

  

Wieso zum Henker ist dieses Problem auf "Gelöst" gestellt worden?

Nur weil man es bestätigt hat, dass es ein Problem gibt, heißt es noch lange nicht, dass es gelöst ist.

 

Das Problem besteht weiterhin.

Konzentriert sich hauptsächlich auf die US Server von AWS.


@Sagamir  schrieb:

Wieso zum Henker ist dieses Problem auf "Gelöst" gestellt worden?

Nur weil man es bestätigt hat, dass es ein Problem gibt, heißt es noch lange nicht, dass es gelöst ist.

 

Das Problem besteht weiterhin.

Konzentriert sich hauptsächlich auf die US Server von AWS.


@Sagamir 

Das Thema ist nicht gelöst, nur als so markiert damit die Antwort oben als erstes steht.

Die Ursache des Problem ist wohl #doublepaidtraffic. Im Gegensatz zu den meisten Providern verlangt Telekom für Peering zusätzliche Gebühren. Wie auch immer: Mit Telekom als Provider könnte ich seit über zwei Wochen nicht im Home-Office arbeiten. Zum Glück hatte ich Urlaub, aber morgen werde ich wieder arbeiten - was bei diesen Downloadgeschwindigkeiten aber nicht möglich ist. Habe ich hier ein Sonderkündigungsrecht?  

 


@Rust   schrieb:

Habe ich hier ein Sonderkündigungsrecht?  


Nein


@tamara.jost  schrieb:

das ich nach 1 Stunde Intensiven Anprangern den Chat Mitarbeiter, dazu gebracht habe, OHNE mir einen Mobilfunkvertrag oder anderes anzubieten, geschweige den Tschüss zu sagen, den Chat zu Schliessen ... Das macht die Sache auch nicht besser.

 

Fröhlich


Ich war auch zweimal im Chat. Die avisierte Wartezeit ist ein Witz. Man soll etwa eine Minute warten, tatsächlich sind es dann 20 bis 40 Minuten.

 

Beim ersten Versuch sollte ich an die Fachabteilung weitergeleitet werden. Irgendwann nach einer Ewigkeit, eine Stunde oder so, kam dann der neue Mitarbeiter aus der Fachabteilung in den Chat und beendete ihn sofort.

 

Beim zweiten Versuch wurde ich gar nicht erst weitergeleitet, sondern der Chat wurde schnell beendet. Mein Gegenüber wusste sich wohl nicht anders zu helfen...

 

Sorry, aber der Service-Level bei der Telekom ist aktuell von meiner Seite nur als “unterirdisch“ zu bezeichnen.

 

Ich habe mittlerweile sehr viel vom heimischen Magenta Zuhause XL als auch vom Telekom-LTE aus getestet. Beides läuft gleich gut oder gleich schlecht, es gibt bei mir keinen Unterschied.

 

Am gestrigen Sonntag zwischen fünf und sechs Uhr morgens lief alles normal schnell. Am Sonntag zwischen 16 und 17 Uhr kam überhaupt nichts durch. Sonntagabend natürlich auch nicht.

 

Amazon Prime Video, Netflix, Disney+ und Zattoo sind aber zum Beispiel überhaupt nicht betroffen. Zur gleichen Zeit werden allerdings beim Amazon Shopping nicht einmal die Bilder geladen! Auch beim russischen VKontakte keine Bilder, oder nur zeilenweise ganz langsam. Über VPN dann alles rasend schnell, auch Amazon Shopping und VKontakte.

 

Ich habe gestern einige URLs an Bekannte in meiner ONKz geschickt, diese konnten die Probleme an ihren jeweiligen Telekom-Anschlüssen nachvollziehen. Dieselbe ONKz, jedoch andere AsB. BNG und LER identisch, also nicht verwunderlich.

 

Ich habe einen workaround für downloads beispielsweise von GitHub, die über die Telekom unerträglich langsam sind. Download über einen öffentlichen Proxy wie beispielsweise 

 

https://hide.me/en/proxy

 

Wenn es also nur um schnellen Download einzelner Dateien von den betroffenen Quellen geht, hier einfach den Link einfügen und sich freuen.

 

ACHTUNG: Die Seriosität und Sicherheit des verlinkten Proxies von hide.me habe ich weder überprüft noch kann ich dazu irgendwas sagen, das Netz ist aber voll von solchen Anonymisierungsproxies, die das Problem zumindest umschiffen.

 

Und ja: Eine Frechheit, dass das Problem hier als "gelöst" markiert ist, wirklich miserable Moderation.

Ich wiederhole meine Vermutung nochmals: Die Telekom verletzt hier absichtlich die Netzneutralität, um wen auch immer unter Druck zu setzen. Und das ist ein Fall für die Bundesnetzagentur. Wenn das ein technisches Problem wäre, wäre es schon längst gelöst. Aber bei 3 Wochen glaube ich nicht an technische Probleme. Das ist so gewollt.


@Zoltux_1  schrieb:

Ich wiederhole meine Vermutung nochmals: Die Telekom verletzt hier absichtlich die Netzneutralität, um wen auch immer unter Druck zu setzen. Und das ist ein Fall für die Bundesnetzagentur. Wenn das ein technisches Problem wäre, wäre es schon längst gelöst. Aber bei 3 Wochen glaube ich nicht an technische Probleme. Das ist so gewollt.


Durch Wiederholung wird es weder sinnvoller noch richtiger 

Naja, es gibt keine Infos warum das Problem besteht und wann es eine Lösung geben wird. Die unglaubliche Arroganz der Telekom habe ich auch schon in anderem Zusammenhang erfahren dürfen, so dass ich hier auch nicht daran glaube, dass die Telekom unschuldig ist. 

Ich denke man kann sich sicher sein, dass es kein technisches Problem ist sondern ein logistisches welches mit AWS ausgehandelt werden muss. Das dauert wie immer wie bei jedem anderen großen Ding auch (schau mal in andere Firmen die irgendwas verhandeln).

 

Und du solltest dich mal informieren was "Netzneutralität" bedeutet @Zoltux_1