Vielen Dank für die Info. Ich glaube Feedback ist wichtig, dann hat man hoffnung, dass es besser wird. Ich musste den Umweg über VPN gehen um meine Anwendungen zu installieren.

Ich hoffe, dass Ihr das demnächst gelöst bekommt.

Danke!

Ja, auch bei den Blauen tritt das Problem auf. Ist bei mit so. Habe ein VDSL100.

Beim blauen Anbieter hatte ich bei früheren Tests keine Probleme (Anschluss in Berlin, scheinbar nicht am Telekom-Backbone). Bei meinem Nachbarn (ebenfalls beim Blauen) treten allerdings die gleichen Probleme auf wie bei mir, das Routing sieht identisch aus und die IP stammt auch aus dem gleichen Subnetz.

Es scheint also je nach Wohnort unterschiedlich und eher ein Glücksspiel zu sein, ob ein Anbieterwechsel dorthin hilft.

hg42

nee, aber ich in der Vergangenheit war es halt auch mal us-east-2 und aktuell ist es us-east-1 und zumindest bei mir ist us-east-2 in Ordnung, auch wenn ich eine falsche IP habe (aktuell eigentlich nur noch 84.166.166.* die ich aber nicht mehr bekomme).
Es scheint also auch zu wechseln. Vielleicht wird ständig öfter umkonfiguriert, oder man gibt tagsüber den Unternehmen die guten Routen und nachts den Privatleuten. Aber alles Spekulation, ich weiß nur, dass man Pakete markieren kann und das beim Routen berücksichtigt werden kann(!). Technisch könnte es also möglich sein.

Es scheint sich tatsächlich etwas zu rühren: Aktuell wird der größte zusammenhängene IP-Pool von 84.136.0.0 bis 84.191.255.255 direkt von AWS zur Telekom geroutet - das wären immerhin potentiell über 4 Mio Anschlüsse, die davon profitieren.

Andere Bereiche (ich habe gerade eine IP aus dem Bereich 91.0.0.0/10) laufen weiterhin über Cogent.

Verschiedene Verfügbarkeitszonen bei AWS (also us-east-2 statt ua-east-1) haben definitiv nichts mit dem Problem zu tun, da AWS Kunden die IP-Adressen zonen-übergreifend verwalten. Unterschiedliche Zonen haben nur AWS-intern ein unterschiedliches Routing über private IP-Adressen. Nach außen hin ist den IP-Adressen nicht "anzusehen", welcher Zone sie aktuell zugeordnet sind. Sollten sich doch unterschiedliche Downloadraten aus den unterschiedlichen Zonen zeigen, dann würde das Problem alle Endkunden betreffen, nicht nur die der Telekom und deren Reseller.

Wer also gerade eine Adresse aus dem Bereich 84.136.x.x.-84.191.255.255 hat, bitte wieder den Datendurchsatz messen - Falls dieser in Ordnung ist, dann wüssten wir zumindest, dass das direkte Peering der Telekom mit AWS funktioniert und nicht überlastet ist.

Zur Erinnerung: Das aktuelle Routing kann über die Webseite mtr.sh abgerufen werden. Dazu auf der Webseite oben die eigene IPv4-Adresse eingeben (vorausgefüllt ist die eigne IPv6-Adresse), dann "trace" anklicken und unter "North America" "US-VA / AWS", dann wieder oben "Run test". Eine direkte Route erkennt man am direkten Übergang von AS16509 (AWS) zu AS3320 (Telekom). Ein Umweg über Cogent erkennt man am AS174 auf dem Weg, bei den Hostnamen werden seitens Cogent Flughafen-Codes verwendet: IAD =Washington, JFK=New York und ORD=Chicago. Cogent routet zeit- und IP-abhängig, Routen über "JFK" und "ORD" liefern ordentliche Datenraten, nur IAD scheint überlastet zu sein (und zwar nicht in Washington, sondern am anderen Ende, vermutlich Frankfurt - das lässt sich aber wesentlich schlechter debuggen, weil die Telekom wohl MPLS-Routing macht, bei dem die einzelnen Hops auf IP-Ebene nicht sichtbar sind, d.h. man sieht nicht wo sich die Übergänge zwischen Cogent und der Telekom befinden und welche davon für die Paketverluste verantwortlich sind.

luddinho

Die Messung von @luddinho hat ja gezeigt dass hier absichtlich eingegriffen wird.

gefühlsmäßig sehe ich zwar auch eher die Telekom in der Verantwortung, aber bewiesen ist das anhand der Messdaten wohl auch nicht.
Dafür ist das Problem wohl zu kompliziert.

Allerdings:

• soweit ich das gelesen habe, sind Geschäftskundenanschlüsse nicht betroffen, das deutet für mich auf absichtliches Routen
• außerdem ist das zeitabhängig, wobei der Beginn der schnellen Zeit nach 23 oder 24 Uhr mich da etwas nachdenklich macht, das entspräche ja nicht unbedingt Geschäftszeiten (bzw. dem Gegenteil)
• wenn tatsächlich diese Alibaba und Heroku Server auch so langsam sind, spricht das für Netzüberlastung

Das führt für mich logisch zu dem Gedanken, dass das Netz eigentlich überlastet wäre, aber durch Kappen bestimmter Bereiche, die nicht von Geschäftskunden genutzt werden, die Überlastung für den Rest nicht mehr stattfindet.

Hallo zusammen,

Meldung von meiner Seite aus.

Hab eine Quell IP aus 84.128.0.0/10 und es kommt Full Speed bei einer 100MBit FTTH Magenta Zuhause Leitung bei mir an.

Getestet mit Sample Data von https://s3.amazonaws.com/ryft-public-sample-data/wikipedia-20150518.bin

Schaut also grad gut aus....zumindest in diesem Moment.

BG

MSL1

###EDIT: Hier noch der MTR

traceroute to 84.140.*.* (84.140.*.*), 50 hops max, 60 byte packets
1 216.182.231.215 (216.182.231.215) [AS14618] 2.131 ms 216.182.231.110 (216.182.231.110) [AS14618] 19.399 ms 216.182.231.201 (216.182.231.201) [AS14618] 2.350 ms 216.182.231.0 (216.182.231.0) [AS14618] 15.793 ms 216.182.229.66 (216.182.229.66) [AS14618] 2.222 ms
2 100.66.8.242 (100.66.8.242) [*] 3.028 ms 100.66.12.50 (100.66.12.50) [*] 18.892 ms 100.66.12.80 (100.66.12.80) [*] 20.490 ms 100.66.8.172 (100.66.8.172) [*] 668.741 ms 100.66.13.2 (100.66.13.2) [*] 18.843 ms
3 100.66.11.132 (100.66.11.132) [*] 20.752 ms 100.66.10.170 (100.66.10.170) [*] 13.731 ms 100.66.38.106 (100.66.38.106) [*] 19.980 ms 100.66.14.24 (100.66.14.24) [*] 12.800 ms 100.66.39.210 (100.66.39.210) [*] 18.434 ms
4 100.66.7.159 (100.66.7.159) [*] 12.386 ms 100.66.6.135 (100.66.6.135) [*] 233.911 ms 100.66.6.23 (100.66.6.23) [*] 219.671 ms 100.66.54.216 (100.66.54.216) [*] 20.358 ms 100.66.7.5 (100.66.7.5) [*] 16.727 ms
5 100.66.5.201 (100.66.5.201) [*] 18.105 ms 100.66.5.213 (100.66.5.213) [*] 17.133 ms 100.66.5.241 (100.66.5.241) [*] 15.619 ms 100.66.5.129 (100.66.5.129) [*] 22.294 ms 100.66.5.157 (100.66.5.157) [*] 22.276 ms
6 100.65.12.129 (100.65.12.129) [*] 1.221 ms 100.65.14.1 (100.65.14.1) [*] 2.209 ms 100.65.12.193 (100.65.12.193) [*] 0.324 ms 100.65.14.97 (100.65.14.97) [*] 0.362 ms 100.65.13.65 (100.65.13.65) [*] 0.294 ms
7 100.65.14.145 (100.65.14.145) [*] 0.466 ms 52.93.28.113 (52.93.28.113) [AS16509] 0.350 ms 52.93.28.79 (52.93.28.79) [AS16509] 0.511 ms 100.65.15.161 (100.65.15.161) [*] 0.494 ms 52.93.28.75 (52.93.28.75) [AS16509] 1.391 ms
8 52.93.28.89 (52.93.28.89) [AS16509] 0.499 ms 100.100.2.66 (100.100.2.66) [*] 1.010 ms 100.100.2.76 (100.100.2.76) [*] 0.637 ms 100.100.2.72 (100.100.2.72) [*] 0.626 ms 100.100.2.76 (100.100.2.76) [*] 0.544 ms
9 87.186.183.33 (87.186.183.33) [AS3320] 1.225 ms 87.186.183.37 (87.186.183.37) [AS3320] 1.167 ms 100.100.2.76 (100.100.2.76) [*] 2.385 ms 87.186.183.33 (87.186.183.33) [AS3320] 1.182 ms 87.186.183.37 (87.186.183.37) [AS3320] 1.036 ms
10 p5b17dc8d.dip0.t-ipconnect.de (91.23.220.141) [AS3320] 91.356 ms 91.345 ms 91.362 ms 87.186.183.33 (87.186.183.33) [AS3320] 1.145 ms 1.156 ms
<Home Sweet Home >

Aber ja, das ist ja unser Problem hier wir koennen nur spekulieren. Das eine ist das technische Problem, was jetzt vermutlich bekannt ist, aber vielleicht will man es nicht loesen solange irgendwelche Peering Verhandlungen etc. laufen. Aber dann ist es halt komisch wenn man sich da aus den grossen /10 blocken irgendwie einzelne /24 rauspickt und auf ne andere miesere Route schickt anstatt gleich den grossen Hammer auszupacken.

richtig...aber es kommt halt kaum was an Details von der Telekom, was denn nun genau das Problem ist.

[Verschwörungstheorie an]
Den großen Hammer nicht auszupacken könnte man sich eventuell erklären. Dann wäre die Sache eindeutig und das würde vermutlich zu einer Klage führen. Wenn man das mehr wie einen Fehler aussehen lässt, dann kann man es halt besser leugnen, wenn es Absicht wäre.
[Verschwörungstheorie aus]

so halb kaputt ist aber auch als Druckmittel nicht so richtig gut...würde ich mal sagen...

Danke für Deine Beiträge, das sind mal echte Infos...

Ich stehe übrigens noch immer im direkten Austausch mit AWS - als nicht Premium-Kunde kann ich nur über deren Buchhaltung kommunizieren, aber eine sehr engagierte Dame dort leitet meine Anfragen an und die Antworten von deren Netzmanagement weiter.

Ich stehe übrigens noch immer im direkten Austausch mit AWS - als nicht Premium-Kunde kann ich nur über deren Buchhaltung  kommunizieren, aber eine sehr engagierte Dame dort leitet meine Anfragen an und die Antworten von deren Netzmanagement weiter.

Ich stehe übrigens noch immer im direkten Austausch mit AWS - als nicht Premium-Kunde kann ich nur über deren Buchhaltung  kommunizieren, aber eine sehr engagierte Dame dort leitet meine Anfragen an und die Antworten von deren Netzmanagement weiter.

das würde ich mir bei der Telekom auch wünschen...es muss doch irgendjemand geben, der da näher dran ist und mal einen Draht aufbaut...

Das mit den Server-Namen hat er vielleicht nicht verstanden...wie mir immer wieder versichert wird, haben Amerikaner oft weniger Englisch-Kenntnisse als Deutsche (sorry ein bisschen Frotzelei muss sein).
Oder war das alles auf Deutsch? das könnte dann auch so ähnlich sein, nur eben auf deutscher Seite.

Wie wär's mit einem direkten Peering zum AWS Techniker? 😉 Dann spart man sich auch noch einen Hop und etwas Latenzzeit

das hatte @jkammann  ja auch schon:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-nicht-nutzbar/m-p/4953597#M1309992