Peering zu AWS unwürdig für einen deutschen ISP

[#1]

So langsam frag ich mich ob die Telekom auch den letzten Internetkunden vergraulen will? Meine Leidensfähigkeit bei Unitymedia war zwar nicht groß genug, aber dass mit der Telekom jetzt komplette Dienstanbieter, in diesem Fall AWS (was so bestimmt 50% meines Internetkonsums abdeckt) mit miesem Peering zu ISDN-Geschindigkeit (und deutlich schlechter) degradiert ist echt eine Unmöglichkeit sondergleichen. 

Erst das miese Peering zu Youtube, jetzt ist wohl AWS dran? Was soll dieser Dreck? Sobald ich das VPN zum Kollegen mit Vodafone oder in die Firma öffne bekomme ich dem VDSL-Anschluss entsprechende Bandbreiten. Das ist eindeutig ein Telekomproblem, scheinbar ein gewolltes auf dem Rücken der Kunden. Wir sind wieder im Zeitalter der Drosselkom(com?) angelangt.

[#2 · Accepted solution]

Hallo @MrShumway,

herzlich willkommen in der Telekom hilft Community.

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.

Grüße
Alexander M.

[#3]

@Phischi 

weit über 99% der Kunden der Telekom bekommen von deinem Problem nicht mal etwas mit. Aber die die ein Problem haben schreiben nur in Foren. Und Peering erzeugt immer lange Diskussionen, die sich dann aber oft im Kreis drehen und nicht zielführend sind.

[#4]

Zur AWS ist das Peering gut.
Das Forum hier liegt auch in der AWS.

Das Problem ist nur wo in der AWS.
GitHub müsste in den USA an der Westküste gehostet sein und nur da. Dorthin gibt es eben kein direktes peering.

[#5]

---

@fdi  schrieb:

@Phischi 

weit über 99% der Kunden der Telekom bekommen von deinem Problem nicht mal etwas mit. [...]

---

Hat du da eine Erhebung zur Hand, oder behauptest du das einfach mal so?

[#6]

@Phischi  Das ist bekannt vorallem wenn es über die USA läuft,wurde auch von der Telekom bestätigt,nur wird sich so schnell nichts ändern

[#7]

@lejupp 

es ist keine Behauptung, sondern eine einfache Einschätzung. Ähnlich zu Problemen mit Windows. Nur von denen die keine Probleme haben hört man auch nie etwas. Und es tritt schnell eine Verallgemeinerung bei so etwas auf und die sachliche Ebene wird genau so schnell verlassen.

[#8]

Das ist jetzt die letzte Woche so massiv schlimmer geworden. Und ob jetzt egal wie viele Nutzer nur froh sind wenn Ihre Browserspiel läuft ist mir auch relativ egal, aber wenn ich Bandbreiten abseits der 100KByte/Sek nur im Telekomnetz habe, dann frag ich mich schon was das soll. Aber ich sehe schon, das ist hier kein Hilfeforum, das ist hier eine Telekomlobhudelei? Fanboys unter sich?

[#9]

@Phischi 

Bitte beachten Sie unsere Netiquette.

Im Übrigen glaube ich fast, es liegt an ihrem Heimnetzwerk.

Weil wenn das selbe Problem auch beim Kabel-Internet war, was ist denn dann gleich zur Telekom?

Was haben Sie denn so alles im Netzwerk aktiv?

[#10]

@Phischi 

schicke mal den Link zu dieser Datei.

eine andere Datei mit 30MB konnte ich in 2-3 Sekunden wiederholt herunterladen.

trotz gleichem Peering und Privatkundenanschluss

[#11]

Ich bin wohl nicht der einzige: https://twitter.com/adlerweb/status/1341376692858875906

https://www.youtube.com/watch?v=Eq-DTdT6AcA

@Gelöschter Nutzer: ich habe nicht geschrieben dass das Kabel-Internet genauso bescheiden läuft. Im Gegenteil. Alle anderen Anbieter am Ort (Mobil wie Coaxkabel) bekommen volle Bandbreite. Ich habe nur gesagt, sobald ich ein VPN in ein Nicht-Telekomnetz aufmache bekomme ich ordentliche Bandbreiten. Und nein, "der Router" oder "Das Heimnetz" ist es nicht. Und nein, es ist auch KEIN Bandbreitenproblem.
Es ist schade (beschämend) dass die Telekom dies aussitzt und weiter auf Doublepay setzt.

[#12]

 

@Stefan: einfach mal ein youtube-dl oder ffmpeg von Github laden:
https://github-production-release-asset-2e65be.s3.amazonaws.com/1039520/13aa6900-4411-11eb-98f4-ebd3...

[#13]

@Phischi 

Vom Telekomanschluss direkt über Browser geladen, konnte so schnell kein Screenshot machen, so schnell war der Download fertig von Github. Die Adresse war deiner ähnlich.

Komisch, bei mir klappte es.

[#14]

Auch ich habe deinen Link hier getestet, waren 8 MB in knapp 2 Sekunden. Muss meine Route zum Ziel wohl gut und unproblematisch sein.

W:\Temp>tracert github-production-release-asset-2e65be.s3.amazonaws.com

Routenverfolgung zu s3-1-w.amazonaws.com [52.216.20.235]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms pfSense.localnet [192.168.1.1]
2 6 ms 6 ms 5 ms p3e9bf44a.dip0.t-ipconnect.de [62.155.244.74]
3 2611 ms 7 ms 7 ms d-ed5-i.D.DE.NET.DTAG.DE [62.154.43.138]
4 13 ms 13 ms 13 ms 80.157.204.58
5 83 ms 83 ms 114 ms ae2.cr8-nyc2.ip4.gtt.net [89.149.128.162]
6 93 ms 102 ms 95 ms a100-gw.ip4.gtt.net [173.205.58.70]
7 100 ms 98 ms 101 ms 52.93.1.95
8 91 ms 91 ms 91 ms 52.93.1.30
9 * * * Zeitüberschreitung der Anforderung.
10 * * * Zeitüberschreitung der Anforderung.
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 97 ms 97 ms 97 ms 52.93.28.90
15 * * * Zeitüberschreitung der Anforderung.
16 * * * Zeitüberschreitung der Anforderung.
17 * * * Zeitüberschreitung der Anforderung.
18 * * * Zeitüberschreitung der Anforderung.
19 * * * Zeitüberschreitung der Anforderung.
20 * * * Zeitüberschreitung der Anforderung.
21 99 ms 98 ms 98 ms s3-1-w.amazonaws.com [52.216.20.235]

Ablaufverfolgung beendet.

[#15]

@Phischi 

---

@Phischi  schrieb:

Das ist jetzt die letzte Woche so massiv schlimmer geworden. Und ob jetzt egal wie viele Nutzer nur froh sind wenn Ihre Browserspiel läuft ist mir auch relativ egal, aber wenn ich Bandbreiten abseits der 100KByte/Sek nur im Telekomnetz habe, dann frag ich mich schon was das soll. Aber ich sehe schon, das ist hier kein Hilfeforum, das ist hier eine Telekomlobhudelei? Fanboys unter sich?

---

Einfach mal ganz geschmeidig bleiben. Ich spiele auf Ostküsten, Westküsten Servern und Servern in Paris und Irland. Sorry, habe keines deiner genannten Probleme. HAbe ebenfalls eine 100er Leitung...also, keine Lag, keine Ping Einbussen.....alles gut

[#16]

@Phischi 

habe beide geladen, allerdings war dein Link expired.

habe sie daher selbst gesucht und von Github geladen.

1,2 Sekunden die eine und 1,8 Sekunden die andere Datei

[#17]

hier nach mal der WGET

Dies mal waren es 2,5 Sekunden

C:\tools>wget https://github.com/FFmpeg/FFmpeg/archive/master.zip

--2020-12-24 21:28:42-- https://github.com/FFmpeg/FFmpeg/archive/master.zip

Resolving github.com (github.com)... 140.82.121.3

Connecting to github.com (github.com)|140.82.121.3|:443... connected.

HTTP request sent, awaiting response... 302 Found

Location: https://codeload.github.com/FFmpeg/FFmpeg/zip/master [following]

--2020-12-24 21:28:43-- https://codeload.github.com/FFmpeg/FFmpeg/zip/master

Resolving codeload.github.com (codeload.github.com)... 140.82.121.10

Connecting to codeload.github.com (codeload.github.com)|140.82.121.10|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [application/zip]

Saving to: 'master.zip' master.zip [ <=> ] 17.08M 6.81MB/s in 2.5s

2020-12-24 21:28:45 (6.81 MB/s) - 'master.zip' saved [17913985] 

[#18]

man müsste halt mal rausfinden, warum ihr die Datei von einem Server in USA bekommt, anstatt über den CDN in eurer Nähe

[#19]

Stefan: ich traue der Telekom zu den VDSL-Pöbel auf ein anderes Peering oder eine andere Route zu schicken als dem Volk das tatsächlich FTTH  oder gar Business-Fiber hat. Gigabit wird ja wohl nicht über Kupferdoppelader laufen.

[#20]

@Phischi 

Da es ja bei allen anderen zu funktionieren scheint, (ich habe übrigens  nicht über Glasfaser getestet) stelle ich mal Fragen an Sie:

Um helfen zu können, benötigen wir noch einige Informationen:

1. Welchen Router verwenden Sie?
2. Welche Firmware-Version hat der Router?
3. Verwenden Sie Switches, Repeater oder PowerLAN

[#21]

@Phischi 

Die Behauptung ist natürlich völlig haltlos ohne Beweis, und führt auch nicht weiter, aber bei meinem Schwager funktioniert es ja auch und der hat VDSL 250 hier am gleichen Ort.

Für konstruktive Tests bin ich offen 

was für eine Ip bekommst du denn wenn du    github.com    auflöst

Schön wäre auch die IP und eine Route die ein Nutzer eines Kabelnetzes bekommt, wenn es da so schnell läuft.

[#22]

---

@Phischi  schrieb:

Stefan: ich traue der Telekom zu den VDSL-Pöbel auf ein anderes Peering oder eine andere Route zu schicken als dem Volk das tatsächlich FTTH  oder gar Business-Fiber hat. Gigabit wird ja wohl nicht über Kupferdoppelader laufen.

---

Hier, an einem Magenta Zuhause L Anschluss im Großraum Köln-Bonn, kommt der Download mit etwa 8 Mbyte/s.

Github schein ein DNS-basiertes Loadbalancing zu verwenden, github.com wird hier wahlweise zu 140.82.121.2, 140.82.121.3 oder 140.82.121.4 aufgelöst. Und zwar sowohl bei Verwendung der Telekom DNS-Server, wie auch über 8.8.8.8 und 1.1.1.1. Troztdem wäre es interessant zu erfahren welchen DNS-Server @Phischi verwendet. Wer weiß, vielleicht wird man von anderen DNS-Server ggfs. doch auf eine ungünstige Route geschickt.

[#23]

mein eigener DNS bei Hetzner, löst auch zu diesen Adressen auf @lejupp 

[#24]

Ebenso löst der DNS Resolver auf der pfSense (Query gegen Root- und Authorized-Server) zu diesen IPs auf.

[#25]

Der öffentliche "Comodo Secure DNS" löst github.com zu 140.82.114.4 auf. Der Download ist aber trotzdem schnell.

[#26]

Hallo zusammen, ich freue mich sehr, dass Google mir diesen Thread ausgespuckt hat. So ist meine Befürchtung, es sein ein Problem, dass nur mich betrifft, verflogen.

Konkret geht es mir genauso wie allen anderen, die sich zu dem Thema oder im Forum äußern: Der Downstream vom S3-Buckets der AWS, die ich über meine VDSL-Leitung erhalten, ist absurd langsam (rund 7kb/s). Die Gegenprobe via LTE im T-Mobile- und Vodafone-Netz zeigt auch, das es kein "AWS"-Problem an sich ist, denn dort erhalte ich einen sehr guten Downstream (10-20mb/s).

Das Verhalte beobachte ich seit mindestens Dezember.

Vom DNS erhalte ich folgende IPs: 52.216.94.91, 52.216.204.83, 52.217.69.116, 52.216.130.91…

Bitte geht dieses Thema an; wir sind in der Mittel des Januars und das Verhalten problematische Verhalten tritt weiterhin auf.