crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
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?
Gelöst! Gehe zu Lösung.
29.01.2021 14:15
@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.
19.01.2021 20:39 Zuletzt bearbeitet: 24.01.2021 14:52 von Stefan
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...
13.01.2021 10:35 Zuletzt bearbeitet: 18.01.2021 11:37 durch den Autor
der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen
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
31.12.2020 15:06
@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?
31.12.2020 15:07
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
31.12.2020 15:13
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.
31.12.2020 15:35
Stimmt, WINMTR hört nach 30 Hops auf, die Route ist aber 40 lang.
Brauchst du ein besseres Tool
Pingplotter Free z.B.
31.12.2020 15:45 Zuletzt bearbeitet: 31.12.2020 15:52 durch den Autor
@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.
31.12.2020 15:45
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]
31.12.2020 15:51
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.
31.12.2020 16:26
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.
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!
02.01.2021 21:46
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!
02.01.2021 21:46
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
03.01.2021 09:44
@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
Dein Nachbarort bekommt ne andere Route zu S3 welche nicht überlastet ist.
Wurde hier schon oft erklärt.
03.01.2021 12:44
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
03.01.2021 12:45
Ist der gleiche Trace wie die letzten 100 auch
03.01.2021 13:05
Dann ist ja super. Viel hilft viel.
03.01.2021 13:56
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
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.
03.01.2021 17:06
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.
03.01.2021 17:09
@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.
Das Thema ist nicht gelöst, nur als so markiert damit die Antwort oben als erstes steht.
03.01.2021 19:57 Zuletzt bearbeitet: 03.01.2021 19:58 durch den Autor
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?
04.01.2021 02:58
@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.
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.
04.01.2021 17:31
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
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.
04.01.2021 22:09 Zuletzt bearbeitet: 04.01.2021 22:13 durch den Autor
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.
04.01.2021 22:14
@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
04.01.2021 22:17
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.
04.01.2021 22:31
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
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.