AW: Routing zu BitBucket.org fehlerhaft / langsam

[#1]

Ich bin aktuell aus Brandenburg per IPv4 im Telekom-Netz verbunden und jegliche Downloads von Bitbucket.org sind unterirdisch schlecht. Geprüft habe ich bereits meine PC's / DNS Settings und auch ein Router Reconnect respektive Neustart brachte keine Abänderung außer einer neuen IP.

Mit unterirdisch meine ich bei einem 

git clone https://bitbucket.org/mirror/git.git läuft die Anzeige bei mir mit 20kib/s 

Wechsle ich auf meinem vServer bei Netcup bekomme ich mit gleichem Command 18MB/s 

Mir scheint als ob das Routing der Telekom an irgendeiner Stelle stark bremst - ist hier etwas bekannt?

Mit freundlichen Grüßen

[#2]

Ich habe seit einer Woche ähnliche Probleme bei allen Downloads von us-east-1.amazonaws.com (Amazon RZ in Ashburn/Virginia), Download-Raten, die an alte Modem-Zeiten erinnern, und permanent Abbrüche.

wget -O /dev/null https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg
--2019-11-01 15:03:49--  https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg
Resolving ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)... 52.216.132.219
Connecting to ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)|52.216.132.219|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10486107 (10M) [image/jpeg]
Saving to: ‘/dev/null’

/dev/null                       5%[=>                                                ] 602.64K  11.6KB/s    eta 13m 1s

Bitbucket hostet seine Files auch dort. 

Ähnliche Probleme gab es wohl schon öfter mit Amazon AWS un Telekom, zumindest, was ich hier gefunden habe. Hilfreiche Antworten gab es allerdings nicht. 

Andere Amazon-Datacenter, zB us-east-2, funktionieren dagegen problemlos:

wget -O /dev/null https://ch-us-east-2.s3.amazonaws.com/probe/test10mb.jpg
--2019-11-01 15:03:24--  https://ch-us-east-2.s3.amazonaws.com/probe/test10mb.jpg
Resolving ch-us-east-2.s3.amazonaws.com (ch-us-east-2.s3.amazonaws.com)... 52.219.96.100
Connecting to ch-us-east-2.s3.amazonaws.com (ch-us-east-2.s3.amazonaws.com)|52.219.96.100|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10486107 (10M) [image/jpeg]
Saving to: ‘/dev/null’

/dev/null                     100%[=================================================>]  10.00M  4.72MB/s    in 2.1s

[#3]

Habe dasselbe Problem mit GitHub.

Siehe https://cloudharmony.com/speedtest-for-aws

Mein Download-Speed von AWS S3 Instanzen in Europa ist bei ~60 Mbit/s.

Von der US-East-Region allerdings nur 1 Mbit/s.

Das Routing der Telekom war immer etwas wackelig, aber das ist ein neuer Tiefpunkt 

[#4]

@xenusle  Kannst du bitte einen Download von US-East-1 testen 

https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg?

EDIT: BTW, Bayern hier. Ist das ein deutschlandweites Problem?

US-East-2 ist bei mir flott:

➜ ~ wget https://ch-us-east-2.s3.amazonaws.com/probe/test10mb.jpg
--2019-11-03 12:17:35--  https://ch-us-east-2.s3.amazonaws.com/probe/test10mb.jpg
Auflösen des Hostnamens ch-us-east-2.s3.amazonaws.com (ch-us-east-2.s3.amazonaws.com)… 52.219.88.34
Verbindungsaufbau zu ch-us-east-2.s3.amazonaws.com (ch-us-east-2.s3.amazonaws.com)|52.219.88.34|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 10486107 (10M) [image/jpeg]
Wird in »test10mb.jpg« gespeichert.

test10mb.jpg                       100%[===============================================================>]  10,00M  2,23MB/s    in 6,5s

US-East-1 hingegen unbrauchbar:

➜  ~ wget https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg
--2019-11-03 12:18:19--  https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg
Auflösen des Hostnamens ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)… 52.216.131.163
Verbindungsaufbau zu ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)|52.216.131.163|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 10486107 (10M) [image/jpeg]
Wird in »test10mb.jpg.1« gespeichert.

test10mb.jpg.1                      17%[=========>                                                      ]   1,70M  32,3KB/s    ETA 4m 34s

Zur Kontrolle, von anderen Servern außerhalb des Telekom-Netzes ist der Download auf beiden Servern ca. ~20MB/s schnell.

Das Problem liegt also eindeutig bei der Telekom.

[#5]

Ähnliche Meldungen zu AWS-Performanceeinbrüchen:

 - https://forums.aws.amazon.com/thread.jspa?threadID=311989

 - https://telekomhilft.telekom.de/t5/Telefonie-Internet/Extrem-langsame-Verbindung-zu-AWS-us-west-2-vi...

 - https://telekomhilft.telekom.de/t5/Telefonie-Internet/Peering-zu-NTT-u-a-Amazon-ueberlastet/td-p/129...

 - https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-S3-abends-wg-Uberlast-nicht-nutzbar-Pee...

[#6]

---

@diethard-günther-932  schrieb:

Das Problem liegt also eindeutig bei der Telekom.

---

Deine Schlußfolgerung ist falsch und basiert sicherlich auf fehlende Kenntnisse von Netzzusammenschaltungen, technisch und wirtschaftlich.

[#7]

Hallo @xenusle,

herzlich willkommen in der Community.

Vorab habe ich ein paar Fragen an dich. Welche Endgeräte werden genutzt? Ist WLAN oder LAN bei dir betroffen? Tritt das Problem auch bei anderen Webseiten / Diensten auf?

Fülle bitte in deinen Benutzerdaten die Felder „Kundennummer“ und/oder „Telefonnummer“ aus. Über folgenden Link gelangst du sofort zur richtigen Stelle in deinem Profil http://bit.ly/Kundeninfos Im Anschluss freue ich mich über eine kurze Rückmeldung.


Beste Grüße
Tabea L.

[#8]

Zumindest kann man sagen, dass das Problem ziemlich eindeutig auftritt, wenn man aus dem Telekom-DSL-netz auf das US-east1-Datacenter von Amazon zugreift. Aus anderen Netzen (Vodafone, Netcologne) nicht, soweit ich bisher testen konnte. Woran das genau liegt, ist mir schlussendlich als Kunde auch schnurz. Ich kann Dienste, für die ich Geld bezahle, aus dem Telekom-Netz praktisch nicht mehr nutzen, da Downloads mit Modemgeschwindigkeit vonstatten gehen und des öfteren komplett abbrechen... Ich habe jetzt gerade zusätzlich Geld in die Hand genommen, um mir einen externen Server zu mieten und einen Socks-Proxy aufzusetzen...

[#9]

---

@Tabea L.  schrieb:
Vorab habe ich ein paar Fragen an dich. Welche Endgeräte werden genutzt? Ist WLAN oder LAN bei dir betroffen? Tritt das Problem auch bei anderen Webseiten / Diensten auf?

Hallo Tabea,

es liegt definitiv nicht an den Endgeräten oder WLAN/LAN. Ich habe hier stationären Rechner mit LAN als auch Tablet mit WLAN getestet. Ganz eindeutig ist auch die Testsuite von https://cloudharmony.com/speedtest-for-aws, siehe den Post von diethard-günther-932 und die Screenshots, meine Ergebnisse sahen sehr änlich aus. Gute Downloadraten von allen europäischen AWS-Datancentern, brauchbare von zb us-east-2, katastrophale von us-east-1 (Ashburn/Virginia). Mit einem externen Proxy von mir (bei netcup.de) sind auch die Downloadraten von us-east-1 wieder akzeptabel:

tsocks wget https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg
--2019-11-03 16:18:10--  https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg
Resolving ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)... 52.216.96.211
Connecting to ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)|52.216.96.211|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10486107 (10M) [image/jpeg]
Saving to: ‘test10mb.jpg’

test10mb.jpg                  100%[=================================================>]  10.00M  4.92MB/s    in 2.0s

Dagegen ohne Proxy:

 wget https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg
--2019-11-03 16:18:28--  https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg
Resolving ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)... 52.216.96.211
Connecting to ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)|52.216.96.211|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10486107 (10M) [image/jpeg]
Saving to: ‘test10mb.jpg.1’

test10mb.jpg.1                100%[=================================================>]  10.00M  29.3KB/s    in 5m 21s

[#10]

---

@olliMD  schrieb:

---

@diethard-günther-932  schrieb:

Das Problem liegt also eindeutig bei der Telekom.

---

Deine Schlußfolgerung ist falsch und basiert sicherlich auf fehlende Kenntnisse von Netzzusammenschaltungen, technisch und wirtschaftlich.

---

Mag schon sein dass Amazon einen Teil der Schuld trägt aber ein riesen Rechenzentrum riskiert mit solch trivialen Netzwerkfehlern einiges mehr als eine ISP für Heimkunden. Mit Fachbegriffen um sich werfen macht das Problem trotzdem nicht ungeschehen. Die wirtschaftlichen Umstände für die Telekom sind mir als Kunde egal und spielen hier auch keine Rolle, denn 50 kB/s an Bandbreite sind so gut wie gar kein Internet.

Es gibt mehrere unabhängige Meldungen, dass die Verbindung zwischen AWS us-east-1 und dem Telekom DSL Anschluss unter miserabler Performance leidet. Kein anderer Provider hat meines Wissens solche Verbindungsprobleme zu AWS. Der schlechte Ruf der Telekom in Peering-Angelegenheiten ist bestimmt nicht unerheblich: https://wiki.hetzner.de/index.php/Double_Paid_Traffic/en

Letztendlich bin ich froh, nicht der einzige mit diesem Problem zu sein. Die Dunkelziffer der Meldungen ist sicher höher.

Ich hoffe auf schnelle Fehlersuche seitens Telekom, bis jetzt war ich sehr zufrieden mit meinem VDSL-Anschluss!

Übrigens: Scheint so als ob das Problem auf unzureichendes Peering zu Telia zurückzuführen ist (Teil der Route zu us-east-1): https://telekomhilft.telekom.de/t5/Telefonie-Internet/60-80-Paketverlust-zum-Carrier-Telia/m-p/42394...

[#11]

Guten Morgen @tabea,

Wie sie sehen können scheint es kein unmittelbares Endkunden-Problem zu sein, eine Eskalation in die unteren Techniker-Ebenen wäre also hier eindeutig angebracht.
Vielleicht existiert dieses Problem dort allerdings schon und man hatte noch nicht genügend Zeit es in den Griff zu kriegen - aus Kundensicht wäre hier natürlich eine schnelle Lösung willkommen.

Das es ein überregionales Problem sein muss hatte ich bereits mit einem Arbeitskollegen erörtert, da dieser in einem ganz anderen Bundesland lebt aber ebenso über Telekom-Netz verbunden ist und jene Probleme hat.

@all
Vielen Dank auch für den regen Input, da fühlt man sich dann doch nicht mehr so allein mit dem Problem

[#12]

Bei mir sieht es besser aus, doanloads von us-east-1 und us-east-2 sind ähnlich schnell.

Die Routen bis zum Übergang zu gtt.net sehen heute auch ähnlich aus, ich meine, dass gestern noch Hop 3 oder vier bei us-east-1 ein anderer war (leider habe ich die traceroutes von gestern nicht mehr)

traceroute to ch-us-east-1.s3.amazonaws.com (52.217.37.28), 30 hops max, 60 byte packets
 1  172.16.0.1 (172.16.0.1)  0.609 ms  0.607 ms  0.516 ms
 2  62.155.241.133 (62.155.241.133)  8.206 ms  8.142 ms  8.392 ms
 3  d-ed5-i.D.DE.NET.DTAG.DE (62.154.5.213)  12.560 ms  12.487 ms  12.691 ms
 4  80.157.204.58 (80.157.204.58)  12.620 ms  12.550 ms  12.480 ms
 5  et-0-0-35.cr3-nyc6.ip4.gtt.net (213.200.121.2)  110.386 ms  110.323 ms  110.252 ms

traceroute to ch-us-east-2.s3.amazonaws.com (52.219.100.44), 30 hops max, 60 byte packets
1 172.16.0.1 (172.16.0.1) 0.648 ms 0.679 ms 0.861 ms
2 62.155.241.133 (62.155.241.133) 9.147 ms 9.105 ms 9.062 ms
3 d-ed5-i.D.DE.NET.DTAG.DE (62.156.131.165) 11.426 ms 11.386 ms 11.343 ms
4 80.157.204.58 (80.157.204.58) 12.897 ms 12.843 ms 13.192 ms
5 et-0-0-35.cr3-nyc6.ip4.gtt.net (213.200.121.2) 95.798 ms 96.199 ms 96.155 ms

Egal, hauptsache geht wieder

[#13]

Tatsächlich scheint es heute besser zu sein - hoffen wir es bleibt wieder so!

[#14]

Es hat sich leider nichts gebessert. Bei mir wird auch immer noch über ffm-b4-link.telia.net geroutet, so wie viele andere Dienste die unfassbar langsam laden. Wenn ich gegen Mittag etwas von Github herunterladen will, lädt es im Durchschnitt mit 50 KB. Wir zahlen aber für 100 Mbit! Das ist echt nicht OK liebe deutsche Telekom. Bitte bessert da endlich etwas! Danke.

[#15]

---

@Gordon_R  schrieb:

Es hat sich leider nichts gebessert. Bei mir wird auch immer noch über ffm-b4-link.telia.net geroutet, so wie viele andere Dienste die unfassbar langsam laden. Wenn ich gegen Mittag etwas von Github herunterladen will, lädt es im Durchschnitt mit 50 KB. Wir zahlen aber für 100 Mbit! Das ist echt nicht OK liebe deutsche Telekom. Bitte bessert da endlich etwas! Danke.

---

Jep, ist wieder auf Modemgeschwindigkeit...

Bei mir wurde aber nie über telia geroutet (von meinem externen Server  aus ja, aber da ist der d/l schnell). Bei mir geht es immer über Telekom Frankfurt (80.157.204.58) -> et-0-0-31.cr3-nyc6.ip4.gtt.net, und von gtt geht das direkt ins Amazon-Netz.

[#16]

Ja, bei mir auch
Die letzten Tage war es kurzzeitig okay, aber abends ist es wieder langsam.

[#17]

Also bei mir führt das Routing zu Bitbucket über Telia und da ist bekannt, dass das seit Monaten kaputt ist.

Die Telekom hat hier einfach nicht genug Traffic eingekauft und baut offenbar auch nicht aus. Bitte beschwert euch bei der Bundesnetzagentur darüber, dass die Telekom euch (den Endkunden) Bandbreite verkauft, die sie an anderer Stelle aber nicht eingekauft hat. Der Link dazu ist in meiner Signatur.

[#18]

---

@direx  schrieb:

Die Telekom hat hier einfach nicht genug Traffic eingekauft

---

Oder Telia hat nicht genug Bandbreite bei der Telekom eingekauft, trifft es wohl eher. Aber schon der Verweis auf die BNA läßt tief blicken in die Aufgaben der BNA....

[#19]

Hallo zusammen,

wie ist denn jetzt der Status? Läuft es wieder einigermaßen? Das Bild war ja nicht ganz einheitlich, was die Routen betrifft und zeitweise lief es bei einigen zwischendurch ja wieder zufriedenstellend. Grundsätzlich hängt die Qualität der Verbindung nicht nur vom eigenen Anschluss ab, sondern auch davon, wie der Dienstanbieter angebunden ist. Dazu ist hier an anderen Stellen in der Community ja auch schon einiges geschrieben worden.

Grüße
Peter

[#20]

Ich war jetzt ein paar Tage weg, aber heute abend scheinen zumindest meine Testdownloads von us-east-1 akzeptabel zu laufen. Aber das war ja zwischendurch auch schon mal so.
Routing wechselt sich bei mir gerade zwischen gtt und level3 ab telia habe ich nie gesehen.

[#21]

---

@olliMD  schrieb:

---

@direx  schrieb:

Die Telekom hat hier einfach nicht genug Traffic eingekauft

---

Oder Telia hat nicht genug Bandbreite bei der Telekom eingekauft, trifft es wohl eher. Aber schon der Verweis auf die BNA läßt tief blicken in die Aufgaben der BNA....

---

Die Telekom verkauft uns Endkunden hier das Produkt „Bandbreite“. Also muss sie auch dafür Sorge tragen, dass die Bandbreite, die sie den Kunden verkauft, auch auf der anderen Seite ihres Netzes zur Verfügung steht (also beim Übergang zu anderen Carriern), ansonsten ist das eine Mogelpackung. Dafür dürfte sich die BNetzA schon interessieren.

Und ob sie die Bandbreite am anderen Ende ihres Netzes einkauft oder geschenkt bekommt, ist dem Endkunden ja erstmal egal - er hat ja schließlich dafür bezahlt.