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?
vor 4 Jahren
Wann gibt es endlich eine Lösung?
7
Antwort
von
vor 4 Jahren
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!
Antwort
von
vor 4 Jahren
Ja, auch bei den Blauen tritt das Problem auf. Ist bei mit so. Habe ein VDSL100.
Antwort
von
vor 4 Jahren
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.
Uneingeloggter Nutzer
Antwort
von
vor 4 Jahren
Wie sind eure Anschlusseinstellungen?
168
Antwort
von
vor 4 Jahren
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.
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.
Antwort
von
vor 4 Jahren
Die Messung von @luddinho hat ja gezeigt dass hier absichtlich eingegriffen wird.
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:
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.
Antwort
von
vor 4 Jahren
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
Uneingeloggter Nutzer
Antwort
von
vor 4 Jahren
Und täglich grüßt das Murmeltier in der Telekom Edition. Der entsprechende Thread aus dem letzten Jahr dazu: https://telekomhilft.telekom.de/t5/Telefonie-Internet/Seit-gestern-Abend-25-03-2020-massive-Stoerungen-bei-ZWIFT-com/m-p/4487849#M1217321
Liebe Telekom, bitte baut doch euer Peering proaktiv aus und nicht erst nachdem eure zahlende Kundschaft sich darüber beschwert. Das würde uns allen einiges an Arbeit sparen und unsere nerven schonen.
0
vor 4 Jahren
Es ist ein Unding, dass eine so wichtiger Service quasi nicht nutzbar ist. Für viele ist ein normales arbeiten so nicht möglich. Für mich als Student noch verkraftbar, aber Programmierer, die drauf angewiesen sind, ist das doch ein echter wirtschaftlicher Schaden der da entsteht. Gibt es vielleicht schon eine Sammelklage, würde mich dem anschließen.
18
Antwort
von
vor 4 Jahren
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...
Antwort
von
vor 4 Jahren
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.
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...
(sorry ein bisschen Frotzelei muss sein).
Das mit den Server-Namen hat er vielleicht nicht verstanden...wie mir immer wieder versichert wird, haben Amerikaner oft weniger Englisch-Kenntnisse als Deutsche
Oder war das alles auf Deutsch? das könnte dann auch so ähnlich sein, nur eben auf deutscher Seite.
Antwort
von
vor 4 Jahren
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
Uneingeloggter Nutzer
Antwort
von
Uneingeloggter Nutzer
Frage
von