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

das mit Alibaba und Heroku ist interessant... dann wäre es ja sehr unwahrscheinlich, dass eine Fehlkonfiguration nur bei Amazon dafür verantwortlich ist und auch nicht dass eine bei Amazon bei allen das Problem verursacht, außer wenn das z.B. auf Fehlinformationen der Telekom beruht, das könnte dann vielleicht auch kopiert worden sein.

das mit Alibaba und Heroku ist interessant...
dann wäre es ja sehr unwahrscheinlich, dass eine Fehlkonfiguration nur bei Amazon dafür verantwortlich ist und auch nicht dass eine bei Amazon bei allen das Problem verursacht, außer wenn das z.B. auf Fehlinformationen der Telekom beruht, das könnte dann vielleicht auch kopiert worden sein.

 

das mit Alibaba und Heroku ist interessant...
dann wäre es ja sehr unwahrscheinlich, dass eine Fehlkonfiguration nur bei Amazon dafür verantwortlich ist und auch nicht dass eine bei Amazon bei allen das Problem verursacht, außer wenn das z.B. auf Fehlinformationen der Telekom beruht, das könnte dann vielleicht auch kopiert worden sein.

 

Das ist tatsächlich interessant. Denn ein Trace aus der Alibaba Cloud (US-East Virgina) liefert das folgende Ergebnis:

 2  11.209.8.105 (11.209.8.105)  0.206 ms  0.218 ms  0.260 ms
 3  11.63.103.41 (11.63.103.41)  1.028 ms  1.040 ms  1.123 ms
 4  11.83.227.113 (11.83.227.113)  0.393 ms  0.405 ms  0.419 ms
 5  47.246.112.210 (47.246.112.210)  0.570 ms  0.580 ms  0.579 ms
 6  38.142.225.9 (38.142.225.9)  2.435 ms  2.236 ms  2.243 ms
 7  be2231.ccr42.dca01.atlas.cogentco.com (154.54.83.69)  1.940 ms  1.837 ms  1.887 ms
 8  be3084.ccr41.iad02.atlas.cogentco.com (154.54.30.66)  1.788 ms  1.961 ms  2.051 ms
 9  80.156.162.241 (80.156.162.241)  2.446 ms  2.386 ms  2.452 ms

Es wird also auch über Cogent geroutet. Ich würde mal behaupten, dass es zur Alibaba Cloud kein direktes Peering der Telekom gibt.

Daher nochmals die Frage an die Telekom, warum der Flaschenhals Cogent nicht erweitert wird? 

Viele Grüße,

Lars

hg42

Anschluss #1 (mein Anschluss welcher auch von schlechten Downloadraten betroffen ist) IP: 92.50.x.x ... Anschluss #1: Telekom-AWS-download-cycle-1week-line1-IP-91.50.x.x.png ... Man kann genau erkennen, dass tagsüber von exakt 8:00 Uhr Morgens bis 0:00 (23:30-0:30 Übergang) die Bandbreite "gut" und damit auch vollkommen ausreichend ist mit durchschnittlich 8MB/s. Von 0:00 Uhr bis 8:00 Uhr sieht es dann anders aus. Die Bandbreite ist limitiert. Am Sa und Sonntag sogar etwas später als 8:00 (Sa. 9:30, So. 10:00)

Anschluss #1 (mein Anschluss welcher auch von schlechten Downloadraten betroffen ist)

IP: 92.50.x.x

...

Anschluss #1: Telekom-AWS-download-cycle-1week-line1-IP-91.50.x.x.png

...
Man kann genau erkennen, dass tagsüber von exakt 8:00 Uhr Morgens bis 0:00 (23:30-0:30 Übergang) die Bandbreite "gut" und damit auch vollkommen ausreichend ist mit durchschnittlich 8MB/s. Von 0:00 Uhr bis 8:00 Uhr sieht es dann anders aus. Die Bandbreite ist limitiert. Am Sa und Sonntag sogar etwas später als 8:00 (Sa. 9:30, So. 10:00)

Anschluss #1 (mein Anschluss welcher auch von schlechten Downloadraten betroffen ist)

IP: 92.50.x.x

...

Anschluss #1: Telekom-AWS-download-cycle-1week-line1-IP-91.50.x.x.png

...
Man kann genau erkennen, dass tagsüber von exakt 8:00 Uhr Morgens bis 0:00 (23:30-0:30 Übergang) die Bandbreite "gut" und damit auch vollkommen ausreichend ist mit durchschnittlich 8MB/s. Von 0:00 Uhr bis 8:00 Uhr sieht es dann anders aus. Die Bandbreite ist limitiert. Am Sa und Sonntag sogar etwas später als 8:00 (Sa. 9:30, So. 10:00)

nebenbei: ich denke es war 91.50.x.x   (und von 0 - 8 gut und 8 - 0 schlecht...hast Du ja schon gemerkt)

Absolut korrekt. Auch mir passieren Fehler, und bei soviel Text habe ich selbst den Wald vor lauter Bäumen nicht gesehen 😀

Ich entschuldige mich für den Tipfehler und für das Vertauschen der beiden erwähnten Zeitbereiche "Gut" und "Schlecht".

Aber als ich es bemerkt hatte war es mir nicht mehr möglich den Beitrag zu ändern.

Die korrekte IP ist aus natürlich dem Bereich 91.50.x.x

Bilder sagen mehr als tausend Worte... Deshalb könnt ihr euch den exakten Tagesverlauf hier nochmals im Detail anschauen.

hg42

das mit us-east-1 und us-east-2 verwirrt mich etwas...

Hatte ich us-east-2 ins Spiel gebracht? Oder stehe ich gerade etwas auf dem Schlauch?

Ich kann von meiner Seite nur berichten, dass es sich in meinem Fall ausschließlich um Downloads von "s3.amazonaws.com" gehandelt hat bei denen ich Probleme feststellen musste. Und dieser Service von AWS liegt meines Wissens in der Zone us-east-1.

hg42

Und wo liegt nun github? in der Vergangenheit war das anscheinend mal auf us-east-1 und manchmal auf us-east-2.

Vermutlich in mehr als nur einer Zone. Bei mir waren es allerdings Downloads welche umgeleitet wurden auf github production release.

https://github-production-release-asset-2e65be.s3.amazonaws.com

hg42

das mit Alibaba und Heroku ist interessant...
dann wäre es ja sehr unwahrscheinlich, dass eine Fehlkonfiguration nur bei Amazon dafür verantwortlich ist und auch nicht dass eine bei Amazon bei allen das Problem verursacht, außer wenn das z.B. auf Fehlinformationen der Telekom beruht, das könnte dann vielleicht auch kopiert worden sein.

Damit wollte ich euch auch zeigen dass scheinbar nicht nur AWS betroffen ist sondern alle Dienste die sich in der Zone us-east-1 befinden. Das erweckt für mich den Anschein, als würde nicht einmal unbedingt AWS die Pakete falsch Routen. Ich habe mich bisher noch nicht im Detail mit den "mtr" beschäftigt. Aber ist es darin möglich zu sehen wer für das Abzweigen auf eine Falsche Route verantwortlich ist? Ich denke nicht, man sieht nur dass die Pakete über eine andere Route geschickt werden. Wer aber dafür verantwortlich ist sieht man meines Erachtens nicht in dem Trace.

Oder vielleicht kann mich jemand darüber Aufklären wenn es doch zu sehen ist.

Hat eigentlich jemand zufällig einen guten Draht zu GitHub? 

Klar ist, dass die Telekom das eigentliche Problem lösen muss.

Aber ich verstehe auch nicht ganz, wieso GitHub kein CDN , wie Cloudfront einsetzt. 

GitHub wird weltweit genutzt und es macht absolut keinen Sinn Dateien, die Hunderttausende Mal aus Europa angefragt werden, immer wieder um die ganze Welt zu schicken. Wahrscheinlich wäre das sogar günstiger für GitHub.

Kann dort jemand mit Connections Mal nachhaken?

Ist zwar, wie gesagt keine Lösung für das Gesamtproblem. Aber wie man hört, sind die meisten hier wegen GitHub auf das Problem aufmerksam geworden.

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