crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
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?
Gelöst! Gehe zu Lösung.
29.01.2021 14:15
@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
@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.
19.01.2021 20:39 Zuletzt bearbeitet: 24.01.2021 14:52 von Stefan
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...
13.01.2021 10:35 Zuletzt bearbeitet: 18.01.2021 11:37 durch den Autor
der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen
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
12.01.2021 12:25
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
12.01.2021 13:17 Zuletzt bearbeitet: 12.01.2021 13:17 durch den Autor
@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!
12.01.2021 13:17
@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 👍
12.01.2021 17:40 Zuletzt bearbeitet: 12.01.2021 17:42 durch den Autor
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?
12.01.2021 18:01 Zuletzt bearbeitet: 12.01.2021 18:20 durch den Autor
@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
12.01.2021 18:04
@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
?
12.01.2021 18:19 Zuletzt bearbeitet: 12.01.2021 18:21 durch den Autor
12.01.2021 18:30
@Stefan schrieb:
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.
12.01.2021 19:08
@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
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.
12.01.2021 21:25
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 * *
12.01.2021 22:12
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
12.01.2021 22:18
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
12.01.2021 23:22
@Stefan schrieb: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.
12.01.2021 23:36
@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
13.01.2021 02:02
@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."
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:
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:
Nachhaltig getan hat sich bisher nicht viel.
13.01.2021 08:20
Ich habe schon den Eindruck, dass sich etwas tut: bei mir wird es nämlich von Tag zu Tag schlimmer...
13.01.2021 08:58
Ich schließe mich mal an. Muss im HomeOffice öfter mit Github und Co arbeiten. Geht im Moment gar nicht. Traurig
13.01.2021 09:12
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
13.01.2021 09:26 Zuletzt bearbeitet: 13.01.2021 09:27 durch den Autor
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.
13.01.2021 09:34
@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):
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.
13.01.2021 09:48
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.
13.01.2021 09:52
@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.
13.01.2021 10:35
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
13.01.2021 10:35 Zuletzt bearbeitet: 18.01.2021 11:37 durch den Autor
der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen
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
13.01.2021 11:14
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 * * *
❯ 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 * * *
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.