Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar

Gelöst

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?

3 AKZEPTIERTE LÖSUNGEN
Lösung

@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 Lachend



@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.

 

Lösung in ursprünglichem Beitrag anzeigen  

Lösung
eine kleine Zusammenfassung für Neuankömmlinge als Living-Post (ich bin kein Experte nur Zusammenfassender):


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...

 

Lösung in ursprünglichem Beitrag anzeigen  

Lösung

der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen

https://hide.me/en/proxy 

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

2021-01-13 10_34_03-The Fastest Free Proxy _ hide.me.png

Lösung in ursprünglichem Beitrag anzeigen  

Danke @jkammann , das hab ich mir auch schon die ganze Zeit gedacht. Die AWS wird ja nicht der einzige Anbieter sein, der Traffic über Cogent schickt und wenn es dort einen Engpass gibt, der offensichtlich da ist, muss die Telekom meiner Ansicht nach auch dort nachbessern und Kapazitäten schaffen. Ist ja nun nicht so, dass Cogent ein kleiner Provider ist. 

Aber da sind wir vermutlich wieder beim Thema Peering-Politik der Telekom, aber das lassen wir jetzt mal dahin gestellt

 


@msp78  schrieb:

Ich habe jetzt einen deutlich größeren Hebel in Bewegung gesetzt. Der Anbieter Asana wird nun Amazon kontaktieren und in die Pflicht nehmen. Sobald ich Rückmeldungen habe melde ich mich.


Dann wünsche ich uns allen viel Glück in der Sache!


@msp78  schrieb:

Ich habe jetzt einen deutlich größeren Hebel in Bewegung gesetzt. Der Anbieter Asana wird nun Amazon kontaktieren und in die Pflicht nehmen. Sobald ich Rückmeldungen habe melde ich mich.


Es bleibt spannend 👍

Mit maximal 16kbit/s nen Tool runterladen um zu prüfen, warum man so langsam herunterladen kann. Klasse.

 

Bei mir kommen fehlerfrei 70MBit an mit 30MBit im Upload. Und von Github/AWS S3 fließen die Daten mit schnellen 12-16kbit/s. Das Problem besteht aber erst seit ein paar Wochen.

 

Tracert gibt zumindest eine mögliche Ursache an.

 

Routenverfolgung zu github.com [140.82.121.3]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms fritz.box [#####]
2 29 ms 13 ms 13 ms p3e9bf638.dip0.t-ipconnect.de [62.155.246.56]
3 20 ms 18 ms 18 ms pd900c96a.dip0.t-ipconnect.de [217.0.201.106]
4 10 ms 7 ms 8 ms pd900c96a.dip0.t-ipconnect.de [217.0.201.106]
5 20 ms 26 ms 18 ms 80.157.204.62
6 21 ms 28 ms 25 ms et-0-0-1.cr2-fra6.ip4.gtt.net [213.200.117.138]
7 18 ms 17 ms 16 ms 87.119.94.70
8 * * * Zeitüberschreitung der Anforderung.
9 * * * Zeitüberschreitung der Anforderung.
10 20 ms 19 ms 18 ms lb-140-82-121-3-fra.github.com [140.82.121.3]

 

Irgendwo nach der 87.119.94.70 und vor dem Github-Server gibt es ein Problem.

 

Seltsam sind auch die dip0.t-ipconnect.de Adressen. Mehrere hintereinander kaskadiert. Sind das nicht Adressen von Firmenanschlüssen?


@Haggi20  schrieb:

Irgendwo nach der 87.119.94.70 und vor dem Github-Server gibt es ein Problem.

 

Seltsam sind auch die dip0.t-ipconnect.de Adressen. Mehrere hintereinander kaskadiert. Sind das nicht Adressen von Firmenanschlüssen?


Auf der Router die du hier gepostet hast ist nicht mal die Spur eines Problems zu sehen.

Klassischer Fall von Fehlinterpretation einer Information


@Stefan  schrieb:

@Haggi20  schrieb:

Irgendwo nach der 87.119.94.70 und vor dem Github-Server gibt es ein Problem.

 

Seltsam sind auch die dip0.t-ipconnect.de Adressen. Mehrere hintereinander kaskadiert. Sind das nicht Adressen von Firmenanschlüssen?


Auf der Router die du hier gepostet hast ist nicht mal die Spur eines Problems zu sehen.

Klassischer Fall von Fehlinterpretation des einer Information


?

@Zoltux_1 

 

Was willst du uns mit dem Fragezeichen mitteilen?

Die Route des tracert die @Haggi20 gepostet hat, zeigt keine Auffälligkeiten - sie ist perfekt.

oder wo siehst du da ein Problem? Jetzt poste aber nicht die zwei Zeilen mit den Sternchen 😂

 


@Stefan  schrieb:

@Zoltux_1 

 

Was willst du uns mit dem Fragezeichen mitteilen?

Die Route des tracert die @Haggi20 gepostet hat, zeigt keine Auffälligkeiten - sie ist perfekt.

oder wo siehst du da ein Problem? Jetzt poste aber nicht die zwei Zeilen mit den Sternchen 😂

 


*

*

😁

 

Auf der Router die du hier gepostet hast ist nicht mal die Spur eines Problems zu sehen.

Klassischer Fall von Fehlinterpretation des einer Information

Auf dem Telefon getippt? Egal, deine zweite Antwort ist auf jeden Fall verständlich.

@Haggi20:
Du machst einen traceroute auf die Startseite von Github, diese wird aber gar nicht von Amazon AWS gehostet.

Die Schwierigkeiten treten beim Download von Repositories auf, die von Github auf dem S3-Speicherdienst von Amazon AWS liegen.

Kannst Du uns bitte mal einen Download-Link posten, bei dem du geringe Datenraten feststellst? Falls Du keinen hast, melde doch bitte mal die Datenrate, die du beim Download von

https://github.com/buchen/portfolio/releases/download/0.49.4/PortfolioPerformance-distro-0.49.4-win3...

erreichst.  Rein technisch wird die vorgenannte Datei vom Server github-production-release-asset-2e65be.s3.amazonaws.com heruntergeladen, dorthin wäre auch ggf. ein traceroute zu machen - wobei die Hinroute nicht wirklich spannend ist. Wenn Du die ersten 3 Bytes Deiner öffentlichen IP-Adresse postest (z.B. 91.34.24.x) dann kann ich dir die Rückroute schicken. Diese läuft mit hoher Wahrscheinlichkeit über den Transitcarrier Cogent, dessen Anbindung zur Telekom ist seitens der Telekom überlastet.

 

 

 

 

16KB/sec 😯😐

 

traceroute to github.com (140.82.121.3), 30 hops max, 60 byte packets
1 Linksys59687 (192.168.1.1) 0.618 ms 0.569 ms 0.698 ms
2 p3e9bf227.dip0.t-ipconnect.de (62.155.242.39) 7.804 ms 7.897 ms 7.794 ms
3 d-ed5-i.D.DE.NET.DTAG.DE (217.5.71.2) 15.802 ms 15.635 ms 15.715 ms
4 80.157.204.58 (80.157.204.58) 15.625 ms 15.308 ms 16.144 ms
5 et-0-0-1.cr2-fra6.ip4.gtt.net (213.200.117.138) 21.654 ms ae21.cr2-fra6.ip4.gtt.net (213.200.116.225) 20.373 ms et-0-0-1.cr2-fra6.ip4.gtt.net (213.200.117.138) 29.413 ms
6 87.119.94.70 (87.119.94.70) 19.679 ms 17.775 ms 27.030 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * *

Hui, 67 Seiten Kommentare... Gibt es auch schon einen Lösungsansatz oder sind wir noch beim Belegen, dass das Problem überhaupt auftritt? Mein Unternehmen nutzt tatsächlich auch Asana (AWS S3) und es ist dieser Tage von meinem privaten, sowie von unserem Office-Telekom-Anschluss nicht mehr nutzbar. Sobald wir aber zu unserem Netcologne-Zweitanschluss wechseln, dann ist alles kein Problem mehr. Ich hab die Geschwindigkeitsproblematik mal mit dem Download von @jkammann und einer Testdatei auf einem anderen Server nachvollzogen: https://vimeo.com/499782037/1ed0de2819 

@André Lung 

wüsste nicht, wer bestritten hat, dass das Problem existiert?

Weisst du denn, wo es liegt?

Die ganzen Spekulationen hier sind nämlich wenig zielführend


@Stefan  schrieb:

@André Lung 

wüsste nicht, wer bestritten hat, dass das Problem existiert?

Weisst du denn, wo es liegt?

Die ganzen Spekulationen hier sind nämlich wenig zielführend


Leute in dieser Tonart mit ihren ersten Beitrag im Forum zu begrüßen, zeigt was einen Community Guide ausmacht. Super!

 

Ansonsten, finde ich es erstaunlich wie viele neue Leute sich so melden. Es sind zieht dann doch ganz schön große Kreise.


@Nextcloud4All  schrieb:

Leute in dieser Tonart mit ihren ersten Beitrag im Forum zu begrüßen, zeigt was einen Community Guide ausmacht. Super!

Ansonsten, finde ich es erstaunlich wie viele neue Leute sich so melden. Es sind zieht dann doch ganz schön große Kreise.


Welche Tonart meinst du?

Das sich frage ob du weißt welches Problem besteht, oder ob du glaubst das hier Spekulationen zielführend sind.

Mir ist doch völlig egal, ob das dein erster oder 1000 Beitrag ist, das prüfe ich gar nicht, tut ja nichts zur Sache!

 

Ich bin Kunde wie du auch


@jkammann  schrieb:

@bernds.rodgau  schrieb:

TATA Communications ist vermutlich eins der Atlantik-Seekabel. Die sind vermutlich überlastet im Moment.

z.B. https://www.submarinecablemap.com/#/submarine-cable/tata-tgn-atlantic


Es gibt keinerlei Hinweise darauf, dass eine Überlastung von Fremdnetzen ursächlich für die Einschränkung der Telekom-Kunden beim Download von Daten von Amazon AWS sind. Die Telekom nutzt TATA nur für die Route in Richtung AWS USA. Die deutlich höher ausgelastete Rückroute erfolgt über primär über Cogent und für einige wenige IP-Adressbereiche (z.B. für das Telekom-Mobilnetz) über eine direkte Anbindung der Telekom an AWS. Da Cogent selbst keinerlei Überlastung zu anderen europäischen Anbietern aufweist, liegt es nahe, dass ein Engpass am Übergang zwischen Cogent und der Telekom vorliegt. Die Telekom behauptet von sich, Tier-1 Provider zu sein (das sind Provider, die keinen IP-Transit zukaufen müssen, da sie alle anderen Tier-1 Provider direkt erreichen). Somit liegt es ausschließlich an der Telekom, für genügend Bandbreite aus dem Netz von Cogent zu sorgen.

Aktuell (11:230 Uhr)werden übrigens 8KB/s erreicht, Hurra, wir sind wieder auf ISDN-Niveau angekommen...

 


Ich habe mittlerweile wenig Hoffnung, dass die Telekom hier überhaupt eine Lösung finden möchte, die Engpässe mit Cogent existieren schon seit über 10 Jahren:

 

2013:

 

"Razzien
Bei Europas Telekom-Riesen ist die EU unpatriotisch


Die EU-Kommission vermutet, dass die europäischen Internetanbieter die Netzbetreiber aus den USA beim Netz-Zugang benachteiligt haben. Sollte sich der Verdacht erhärten, drohen hohe Kartellstrafen.

 

[...]

 

Der Anfangsverdacht der EU-Behörden resultiert aus einer Beschwerde von US-Netzbetreibern: Der US-Anbieter Cogent beschwert sich bereits seit 2009 darüber, dass die Europäer ihn bei der Einbindung in ihr Netz benachteiligen.

 

[...]

 

Der Streit mit den US-Anbietern jedoch lässt sich nicht so einfach abtun – er berührt die Geschäftsmodelle der ehemaligen Staatskonzerne ebenso wie netzpolitische Grundsatzfragen: Zu den Kunden von Cogent und dem noch größeren US-Anbieter Level3 gehören diverse große US-Inhalteanbieter, Videoportale wie Youtube, aber auch Filesharing-Portale wie das inzwischen eingestellte Megaupload.

 

Sie alle bezahlen Netzbetreiber wie Cogent und Co dafür, ihre Server möglichst günstig und schnell an das Internet anzuschließen. Deswegen schaufeln die US-Netzbetreiber große Mengen Daten direkt in die Netze und zu den Kunden der europäischen Telekommunikationsfirmen. Gemeinsam sind Cogent und Level3 für etwa drei Viertel des transatlantischen Internetverkehrs verantwortlich.

 

[...]

 

Cogent hatte sich laut einem internen Schriftsatz, der der „Welt“ vorliegt, bereits 2009 bei der Bundesnetzagentur über das Peering-Verhalten der Telekom beschwert: Die Telekom weigere sich, ausreichende Kapazitäten an ihren Peering-Knotenpunkten parat zu halten. Die Anbindung der Cogent-Kunden ins Netz der Telekom sei zu langsam: Cogent benötige mindestens 100 Gigabit pro Sekunde, die Telekom halte weniger als die Hälfte dessen parat.

 

Der deutsche Konzern hält dagegen, dass Cogent bis zu zwölf Mal mehr Daten ins Netz der Telekom sende als diese ins Netz von Cogent. Cogent solle deswegen für den Ausbau und das große Datenvolumen zahlen. Die Bundesnetzagentur startete ein Verfahren, in dessen Verlauf die Streithähne einen vorläufigen Kompromiss fanden: Die Telekom baute auf 76 Gigabit pro Sekunde aus, und verzichtete auf Bezahlung. Die Netzagentur stellte das Verfahren im April 2010 ein.

 

Doch seit 2009 hat sich der Datenverkehr im Netz laut Berechnungen der US-Netzwerkexperten des Equipmentanbieters Cisco verdoppelt. Die Peering-Übergabeknoten der Telekom sind laut Insidern aus dem Umfeld des wichtigsten deutschen Netzknotens De-Cix in Frankfurt mittlerweile schon wieder unterdimensioniert – und die Telekom beeilt sich nach Ansicht der Netzexperten nicht sonderlich mit dem Ausbau. In Frankreich war eine ähnliche Beschwerde Cogents über Orange bei der dortigen Wettbewerbsbehörde im Herbst 2012 gescheitert."

https://www.welt.de/wirtschaft/article117963991/Bei-Europas-Telekom-Riesen-ist-die-EU-unpatriotisch....

 

2015:

 

"Peering
US-Carrier Cogent verklagt die Telekom

 

Tier-1-Netzbetreiber Cogent wirft der Deutschen Telekom Vertragsbruch vor und hat bei einem US-Gericht Klage eingereicht. Beim Peering sollen die Bonner zu wenig Kapazitäten vorhalten - man kann das als Beleg für Verletzung der Netzneutralität sehen.

 

US-Netzbetreiber Cogent hat die Deutsche Telekom wegen Vertragsbruchs vor einem US-Gericht verklagt. Das US-Unternehmen wirft der Telekom vor, beim Peering an den Übergabepunkten in Frankfurt (Main) und Ashburn (US-Bundesstaat Virginia) keine ausreichenden Kapazitäten vorzuhalten, was zu Beeinträchtigungen beim internationalen Netzverkehr führe. Cogent möchte die Telekom nun gerichtlich zwingen, die Kapazitäten zu erhöhen und fordert Schadensersatz, wie das Unternehmen am Dienstag mitteilte.

 

[...]

 

“In dem sie sich weigert, die Kapazitäten der Übergabeports für den Austausch von Traffic zu erhöhen, greift die Deutsche Telekom in den freien Fluss des Internetverkehrs zwischen Kunden von Cogent und der Telekom ein”, erklärte Cogent-Rechtsvorstand Robert Beury. Mit ihrer Marktmacht als größter DSL-Anbieter in Deutschland versuche die Telekom, direkt oder indirekt einen Zoll für US-Unternehmen zu erheben. "Cogent übergibt deutlich mehr Datenverkehr in unser Netz als umgekehrt", hält dem ein Telekom-Sprecher entgegen. "Warum sollten wir alleine für die Ausweitung der Kapazitäten der Netzzusammenschaltung aufkommen müssen? Das sollten Partner grundsätzlich gemeinsam leisten."

 

[...]

 

Beim Peering mit der Telekom komme es immer wieder zu Verstopfungen, sagt Cogent und unterstellt dem deutschen Netzbetreiber dabei Absicht. Normalerweise sei es unter Peering-Partnern üblich, die Kapazitäten an den Übergabepunkten so anzupassen, dass das Verkehrsaufkommen 70 Prozent der Kapazität nicht auf Dauer übersteigt. Doch die Telekom habe sich von der bisher mit Cogent gepflegten branchenüblichen Praxis verabschiedet."

https://www.heise.de/newsticker/meldung/Peering-US-Carrier-Cogent-verklagt-die-Telekom-3038484.html

 

Im Herbst 2014 hatte Level 3 ähnliche Vorwürfe erhoben wie Cogent:

https://www.heise.de/newsticker/meldung/Netzneutralitaet-Backbone-Betreiber-Level-3-aeussert-sich-zu...

 

Wie man an den Klagen sehen, kann man Cogent hier kein mangelndes Interesse an einer Aufrüstung vorwerfen.

 

Man vergleiche hierzu auch frühere Aussagen der Telekom bezüglich einer zusätzlichen Bezahlung:

 

2010: Obermann will Google zur Kasse bitten

Wir können nicht alles umsonst anbieten, zahlen müssen diejenigen, die die Netze stark beanspruchen.

2011, Focus Online: YouTube – Lange Ladezeit verärgert Telekom-Kunden

Der Konzernsprecher deutete an, dass die Telekom solche Engpässe künftig nicht kostenlos beheben wolle. „Wir werden uns darüber unterhalten müssen, dass verkehrsintensive Anbieter wie ‚Youtube’ dafür bezahlen, dass ihre großen Datenströme von uns gemanagt werden.“

Die Probleme werden seit Jahren regelmäßig gemeldet, auch z. B. letztes Jahr zu Beginn von Corona hier im Forum:

 

https://telekomhilft.telekom.de/t5/Telefonie-Internet/Probleme-beim-Zugriff-auf-Firmen-VPN-Peering-P...

 

Nachhaltig getan hat sich bisher nicht viel.

Ich habe schon den Eindruck, dass sich etwas tut: bei mir wird es nämlich von Tag zu Tag schlimmer...

Ich schließe mich mal an. Muss im HomeOffice öfter mit Github und Co arbeiten. Geht im Moment gar nicht. Traurig Traurig

Sorry, so war das gar nicht gemeint. Ich weiß leider nicht wo das Problem es liegt und wollte mich einfach fachdienlich als weiterer Nutzer melden, bei dem das Problem auftritt. In den letzten Beiträgen sah es so aus, als würde das Auftreten des Problems angezweifelt. Ich dachte, ein kurzes und praxisnahes Video hilft da vielleicht...

 

Der Beitrag ist "als gelöst" markiert, ohne dass (glaube ich), eine für mich umsetzbare Lösung gefunden wurde. Ich hatte mit dem Einstieg in die Diskussion zwei Dinge gehofft:

1. dass vielleicht jemand einen Workaround kennt, der in den anderen Beiträgen untergegangen ist

2. dass dieser Beitrag hier so groß wird, dass man das Problem, von Telekom-Seite nicht mehr ignorieren kann

Ein möglicher Workaround ist, sich einen VPN-Provider zuzulegen. Da VPN andere IPs und andere Routen "verursacht", kommt man dann in der Regel auf den besseren Weg. Telekom weigert sich ja, andere Routen zu geben. Zumindest nicht für alle Nutzer. Welche Routen genommen werden, hängt anscheinend von der IP ab; manche Telekom-Nutzer haben das Problem nicht. 

 

Ich benutze - wenn es um Web-Applikationen geht, die im Browser laufen - manchmal den Tor-Browser. Damit läuft es besser. Vermutlich weil Tor andere Routen durch eine Art VPN (?) bewirkt; ist ja eigentlich gedacht, um Internet-Aktivitäten nicht nachverfolgbar zu machen. Und da ja anscheinend so ziehmlich alle Routen funktionieren, außer denen, die Telekom uns gibt, ist das Ergebnis ganz gut.


@André Lung  schrieb:

Sorry, so war das gar nicht gemeint. Ich weiß leider nicht wo das Problem es liegt und wollte mich einfach fachdienlich als weiterer Nutzer melden, bei dem das Problem auftritt. In den letzten Beiträgen sah es so aus, als würde das Auftreten des Problems angezweifelt. Ich dachte, ein kurzes und praxisnahes Video hilft da vielleicht...

 

Der Beitrag ist "als gelöst" markiert, ohne dass (glaube ich), eine für mich umsetzbare Lösung gefunden wurde. Ich hatte mit dem Einstieg in die Diskussion zwei Dinge gehofft:

1. dass vielleicht jemand einen Workaround kennt, der in den anderen Beiträgen untergegangen ist

2. dass dieser Beitrag hier so groß wird, dass man das Problem, von Telekom-Seite nicht mehr ignorieren kann


Bestreiten tut es zum Glück keiner hier, es wird über die Verantwortung gestritten, wer kann etwas ändern und wer nicht sowie ob es ein bewusster oder unbewusster Fehler ist. Aber ich denke, die Meinungen sind dazu hinreichend diskutiert. Eine weitere Diskussionen darüber ist nicht hilfreich.

 

Es gibt folgende Workarounds (keine Lösung des Problems):

  • Verwenden eines VPNs
  • verwenden eines anderen Zugangs (LTE, anderer Anschluss)
  • Nutzung Tor-Browsers (eigentlich auch VPN)
  • Wechsel zu einem anderen Internet Provider (langfristig)

Alle Workarounds sind schneller als die aktuelle Verbindung der Telekom (wenn man betroffen ist).

 

Das der Beitrag aktiv bleibt, ist das auch meine Hoffnung. Sinnvoll ist es aus meiner Sicht auch selber Tickets zu öffnen. Aber leider kam keine neue Informationen der Telekom, wie die weitere Vorgehensweise ist. Zum Glück versuchen es einige Mitglieder über die andere Seite AWS, Asana die Problematik zu adressieren.

 

Angehängt ein Screenshot aus einer Trace App für Android. 

 

Mehr als 30 Hobs (39) zum Ziel ist zumindest ungewöhnlich.

 

Per Grafik (https://play.google.com/store/apps/details?id=org.skynetsoftware.itraceroute) sieht man auch, daß die Daten von New York zur Westküste fließen und dann wieder zurück. 


@Haggi20  schrieb:

Angehängt ein Screenshot aus einer Trace App für Android. 

 

Mehr als 30 Hobs (39) zum Ziel ist zumindest ungewöhnlich.

 

Per Grafik (https://play.google.com/store/apps/details?id=org.skynetsoftware.itraceroute) sieht man auch, daß die Daten von New York zur Westküste fließen und dann wieder zurück. 


Was du da zeigst ist die Route in Richtung AWS, die für das Problem hier erstmal weniger relevant ist. Wichtiger ist die Route zurück, die nicht selten anders ist, als die Route auf dem Hinweg. 

Von daher lässt sich daraus erstmal nicht feststellen, ob bzw. wo es ein Problem gibt.

Hallo, 

ich habe das gleiche Problem mit S3 und Github. Sitze im HomeOffice und kann nicht arbeiten.

 

Traceroute zu github assets: 



traceroute https://github-production-release-asset-2e65be.s3.amazonaws.com                                                                      
traceroute to s3-1-w.amazonaws.com (52.216.138.155), 64 hops max, 52 byte packets
 1  192.168.188.1 (192.168.188.1)  3.336 ms  2.445 ms  2.108 ms
 2  p3e9bf552.dip0.t-ipconnect.de (62.155.245.82)  4.759 ms  5.424 ms  4.360 ms
 3  217.5.113.70 (217.5.113.70)  11.475 ms  10.860 ms  11.456 ms
 4  217.5.113.70 (217.5.113.70)  11.477 ms  12.238 ms  10.458 ms
 5  80.156.162.178 (80.156.162.178)  18.883 ms  18.635 ms  18.467 ms
 6  if-ae-45-2.tcore1.fr0-frankfurt.as6453.net (195.219.50.20)  99.686 ms  96.438 ms  96.801 ms
 7  * if-ae-55-2.tcore2.pvu-paris.as6453.net (80.231.245.6)  96.416 ms  97.531 ms
 8  if-ae-49-2.tcore1.pvu-paris.as6453.net (80.231.153.20)  95.848 ms  95.908 ms  97.017 ms
 9  if-ae-11-2.tcore1.pye-paris.as6453.net (80.231.153.50)  97.147 ms  96.424 ms  96.209 ms
10  if-ae-3-2.tcore1.l78-london.as6453.net (80.231.154.143)  97.011 ms * *
11  if-ae-66-2.tcore2.nto-newyork.as6453.net (80.231.130.106)  96.818 ms
    if-ae-66-7.tcore2.nto-newyork.as6453.net (80.231.130.23)  96.585 ms  94.973 ms
12  if-ae-12-2.tcore1.n75-newyork.as6453.net (66.110.96.5)  97.454 ms  95.948 ms  96.301 ms
13  66.110.96.157 (66.110.96.157)  104.312 ms  102.811 ms  108.259 ms
14  52.93.31.45 (52.93.31.45)  101.682 ms
    52.93.31.37 (52.93.31.37)  103.728 ms  101.964 ms
15  52.93.4.2 (52.93.4.2)  101.389 ms
    52.93.4.60 (52.93.4.60)  107.933 ms
    52.93.4.58 (52.93.4.58)  101.231 ms
16  * * *
17  150.222.242.112 (150.222.242.112)  310.023 ms *
    150.222.242.120 (150.222.242.120)  333.529 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  150.222.241.171 (150.222.241.171)  270.780 ms
    150.222.243.141 (150.222.243.141)  222.623 ms *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
31  * * *
32  * * 52.93.28.176 (52.93.28.176)  343.345 ms
33  * * *
34  * * *
35  * * *
36  * * *
37  * * *
38  * * *
39  s3-1-w.amazonaws.com (52.216.138.155)  221.728 ms  221.027 ms  217.612 ms






Lösung

der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen

https://hide.me/en/proxy 

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

2021-01-13 10_34_03-The Fastest Free Proxy _ hide.me.png

Mit VDSL habe ich immer noch das Problem. Bei Telekom LTE funktoniert alles

 

VDSL

❯ traceroute to github-production-release-asset-2e65be.s3.amazonaws.com (52.217.86.156), 30 hops max, 60 byte packets
1  fritz.box (*.*.*.*)  2.511 ms  3.180 ms  3.156 ms
2  p3e9bf2b1.dip0.t-ipconnect.de (62.155.242.177)  47.931 ms  48.181 ms  48.167 ms
3  d-ed5-i.D.DE.NET.DTAG.DE (217.5.71.2)  26.281 ms  26.541 ms  26.528 ms
4  80.157.204.58 (80.157.204.58)  27.089 ms  28.994 ms  30.014 ms
5  ae15.cr3-nyc6.ip4.gtt.net (89.149.186.217)  102.034 ms  102.519 ms  108.642 ms
6  a100-gw.ip4.gtt.net (173.205.58.62)  113.228 ms  105.362 ms  105.677 ms
7  52.93.4.71 (52.93.4.71)  105.655 ms 52.93.4.83 (52.93.4.83)  104.673 ms 52.93.4.75 (52.93.4.75)  105.262 ms
8  52.93.4.36 (52.93.4.36)  105.506 ms 52.93.4.34 (52.93.4.34)  105.256 ms 52.93.4.0 (52.93.4.0)  104.802 ms
9  * * *
10  150.222.242.118 (150.222.242.118)  356.458 ms 150.222.242.106 (150.222.242.106)  304.081 ms 150.222.242.132 (150.222.242.132)  294.297 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * 150.222.243.141 (150.222.243.141)  222.225 ms 150.222.243.215 (150.222.243.215)  312.337 ms
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  52.93.28.166 (52.93.28.166)  248.030 ms 52.93.28.180 (52.93.28.180)  316.344 ms 52.93.28.142 (52.93.28.142)  314.675 ms
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

LTE

❯ traceroute github-production-release-asset-2e65be.s3.amazonaws.com
traceroute to github-production-release-asset-2e65be.s3.amazonaws.com (52.217.12.236), 30 hops max, 60 byte packets
1  _gateway (192.168.43.1)  6.477 ms  6.379 ms  6.329 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  80.156.5.113 (80.156.5.113)  30.932 ms  30.887 ms  30.825 ms
10  pd900988a.dip0.t-ipconnect.de (217.0.152.138)  39.300 ms  39.582 ms  39.513 ms
11  m-sa1-i.M.DE.NET.DTAG.DE (217.5.66.113)  35.317 ms  35.244 ms  26.840 ms
12  pd900cc2a.dip0.t-ipconnect.de (217.0.204.42)  29.971 ms  29.899 ms  43.408 ms
13  pd900988a.dip0.t-ipconnect.de (217.0.152.138)  35.327 ms  36.870 ms  35.365 ms
14  80.157.204.58 (80.157.204.58)  34.245 ms  34.443 ms  35.059 ms
15  ae2.cr8-nyc2.ip4.gtt.net (89.149.128.162)  116.828 ms  116.743 ms  122.133 ms
16  a100-gw.ip4.gtt.net (173.205.58.70)  122.863 ms  114.010 ms  114.069 ms
17  52.93.1.81 (52.93.1.81)  124.110 ms 52.93.1.87 (52.93.1.87)  121.934 ms 52.93.1.83 (52.93.1.83)  130.742 ms
18  52.93.1.62 (52.93.1.62)  119.640 ms 52.93.1.52 (52.93.1.52)  123.016 ms 52.93.1.16 (52.93.1.16)  115.813 ms
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  52.93.29.84 (52.93.29.84)  128.656 ms 52.93.29.86 (52.93.29.86)  118.992 ms 52.93.29.78 (52.93.29.78)  118.377 ms
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *