Ist dies das berüchtigte Peering der Telekom?

Banned · Donnerstag um 19:29

@CoMo Woher nimmst du jetzt diese Information? Oder mal anderes gefragt: Wurden für die Zeiträume, auf die sich der TE bezieht, hier Vergleiche (Messungen/Erfahrungen) vorgelegt, die eindeutig auf ein Telekom-Problem hindeuten?

Wie du siehst, gibt es aktuell kein generelles Problem bei Telekomanschlüssen oder solchen anderer Anbieter. Wenn der TE aktuell Probleme hat, liegt es somit wohl eher nicht an der Telekom. Wenn er die letzten Tage Probleme hatte, könnte es an den Wartungsarbeiten gelegen haben. Dass Personen mit anderen Anbietern während der Wartungsarbeiten keine Probleme hatten, kann ich hier nirgendwo rauslesen.

Wilhelm14 schrieb:
Soll ich was anderes testen?

Nur, wenn du in der Zeit zurückreisen kannst.

Hier wurden schließlich jetzt zwei Telekom-Anschlüsse ohne Probleme gemessen. Ich habe gerade auch mal testweise mehrere bei CF gehostete Webseiten aufgerufen, ging extrem schnell.

dw4817 · Donnerstag um 19:36

Lawnmower schrieb:
Und das Problem scheint ja eher im Netz ab Colt woanders hin zu sein und nicht bei der Telekom.

Die Telekom-Peering-Probleme bestehen in Lastrichtung (also Server -> Kunde), der Traceroute geht entgegen der Lastrichtung (also Kunde -> Server), daher kann man aus dem Traceroute nicht auf die tatsächliche Stelle des Engpasses schließen.
Man kann aus dem Traceroute nur schließen, dass es irgendwo auf dem Rückweg vom Colt/Lumen-Netz zum Telekom-Netz Paketverluste gibt. Es ist nicht auszuschließen, dass diese an einer verstopften Übergabe zwischen Colt/Lumen und der Telekom liegen. Das gab es in der Vergangenheit schon oft.

Lawnmower · Donnerstag um 19:42

Ja sicher das Monats-Kontingent schon voll, dann wird gedrosselt - ab dem 1.2. läufts dann wieder Vollgas

Wundern würde mich sowas ja nicht...

azereus · Donnerstag um 19:46

das Ziel (Cloudflare) gibt vor wie es erreichbar sein möchte
Cloudflare hat das Peering zur DTAG geändert und meint jetzt über andere Peers (TATA und Lumen in DE und NTT in AT) traffic abführen zu müssen
anstelle des direkten Peerings mit der DTAG das sie eigentlich haben

angefanten hat es lt. lookingglass.telekom.com mit 27.1.

die DTAG muss jetzt schauen das sie den Mehr-Traffic über TATA und Lumen auch verarbeiten kann bzw. TATA+Lumen müssen Kapazitäten schaffen
damit der Mehr-Traffic auch zur DTAG herein kann

CoMo · Donnerstag um 19:50

Banned schrieb:
Wie du siehst, gibt es aktuell kein generelles Problem bei Telekomanschlüssen

dw4817 · Donnerstag um 19:59

azereus schrieb:
das Ziel (Cloudflare) gibt vor wie es erreichbar sein möchte

Das Ziel des Datenflusses ist aber die Telekom, die Daten kommen von Cloudflare. ;-)

azereus schrieb:
die DTAG muss jetzt schauen das sie den Mehr-Traffic über TATA und Lumen auch verarbeiten kann bzw. TATA+Lumen müssen Kapazitäten schaffen damit der Mehr-Traffic auch zur DTAG herein kann

TATA. Colt/Lumen und Co. haben die Kapazitäten, der Engpass sind die Zusammenschaltungen dieser Netze mit der Telekom. Diesen Engpass würden TATA, Colt/Lumen und die anderen Tier-1 sehr gerne beheben, die Telekom blockiert das aber.

Warum?

Nur wenn diese Tier-1-Zusammenschaltungen schlecht genug funktionieren, motiviert das Cloudflare & Co., den zu hohen Preis für direkte Zusammenschaltungen mit der Telekom zu zahlen.

Dr. Chaos · Donnerstag um 20:01

Letztendlich sind wohl Cloudflair und die Telekom nicht unschuldig, so wie das in einem Krieg immer ist machen beide Seiten sich die Hände schmutzig.
Leitragende sind natürlich immer die Zivilisten (Kunden)

Banned · Donnerstag um 20:01

CoMo schrieb:
Kein generelles Problem.

Nein, es ist schon kein generelles Problem mehr, wenn ich als Inhaber eines Telekom-Anschlusses keines habe. Dass es aufgrund des Peerings der Telekom zu Problemen kommen kann, habe ich nie bestritten - ich habe es sogar explizit gesagt.
Die ganze Arbeit mit den Links hättest du dir also sparen können, denn es geht darum, dass der TE sagt, er habe aktuell bzw. in der letzten Zeit Probleme gehabt. Wenn ich und ein anderer Nutzer wohl auch mit der Telekom aktuell keine Probleme haben, dann liegen die Probleme des TE oder auch deine wohl nicht am Peering.

CoMo schrieb:
Und @Banned hat das alles jetzt aufgedeckt. Respekt.

Und du liest irgendwie nicht richtig oder verstehst Sachen massiv falsch - dafür kein Respekt.

Der/die TE kann mir ja gerne mal eine Seite o.Ä. nennen, wo er gerade Probleme hat und ich oder jemand anderes mit Telekom-Anschluss testet das dann gegen. @liz02mo

Alles andere ist hier eben gerade nur Spekulation.

FTTC · Donnerstag um 20:02

Aktuell dauerte es teilweise einige Sekunden, bis die Websiten anfingen zu laden.

Ich habe in meinem Pihole nun von Cloudflare DNS auf quad9 DNS umgestellt. Die Seiten werden nun in Windeseile geöffnet. Geladen nicht, das dauert bei Websites, die über cloudflare gehostet sind, teilweise extrem lang.

Über einen 1und1 Versatel Anschluss läuft es top. Ich überlege, für die letzten 9 Monate, nach denen ich dann hoffentlich Glasfaser bekomme, zu easybell zu wechseln.

azereus · Donnerstag um 20:11

dw4817 schrieb:
Das Ziel des Datenflusses ist aber die Telekom, die Daten kommen von Cloudflare. ;-)

ja und den Rückweg von Cloudflare siehst du aber nicht
DTAG -> Cloudflare
DTAG <- Cloudflare
Der weg kann und wird abweichend sein.
Wenn du von einem Cloudflare-Server -> DTAG prüfen kannst ist das der Weg den die DTAG vorgibt.

Beide Seiten sind an der Situation schuld.
Consumer die die Dienste Nutzen
BigTech die diese Dienste Anbieten
Peerings die Geld kosten
Eine bockige DTAG
Vertragspartner die die Verträge missachten
Gründe gibt es seit Jahren genug

Und wer leidet darunter?
Richtig. Der kleinste in der Kette.

Schlussendlich bleibt einem dann nur eines
abwarten und tee trinken
provider wechseln und hoffen deren peering ist besser

/edit: ich vergas... schlussendlich geht es immer nur um den finanziellen Profit. jeder will die beste leistung und nichts dafür tun/zahlen.
wie schön wäre eine welt in der es ein open peering gibt bei dem beide seiten das problem gleichermassen technisch lösen und sich gegenseitig die rechnung auf 0 ausgeht.
man darf ja noch träumen...

dw4817 · Donnerstag um 20:17

azereus schrieb:
ja und den Rückweg von Cloudflare siehst du aber nicht

Und Du auch nicht, deswegen solltest Du nicht behaupten, dass Cloudflare diesen einseitig geändert hat.

azereus schrieb:
Beide Seiten sind an der Situation schuld.

Die Telekom hat sich für eine restriktive Peering-Policy entschieden, nicht Cloudflare. Hätte sie sich für eine offene Peering-Policy wie Telefonica o2 oder 1&1 Versatel entschieden, bestünde das Problem nicht.

liz02mo · Donnerstag um 20:19

Banned schrieb:
....

Der/die TE kann mir ja gerne mal eine Seite o.Ä. nennen, wo er gerade Probleme hat und ich oder jemand anderes mit Telekom-Anschluss testet das dann gegen. @liz02mo

Alles andere ist hier eben gerade nur Spekulation.

x.com zum Beispiel und 1.1.1.1

gemini.google.com

DNS4EU

gaym0r · Donnerstag um 20:20

azereus schrieb:
das Ziel (Cloudflare) gibt vor wie es erreichbar sein möchte

Jain. Cloudflare gibt zwar per BGP an wie es erreichbar ist, aber es gibt immer mehrere Wege und am Ende entscheidet die Telekom welchen Weg sie gehen will. Stichwort: BGP Policies.

FTTC · Donnerstag um 20:27

Hier der Ping zu 1.1.1.1. kein Wunder, dass ich in der letzten Zeit Probleme hatte Websites aufzurufen 🧐

Code:

--- 1.1.1.1 ping statistics ---
70 packets transmitted, 46 received, 34.2857% packet loss, time 69416ms
rtt min/avg/max/mdev = 11.018/11.624/14.168/0.694 ms

Wie gesagt, mit der Umstellung auf Quad9 DNS läuft es jetzt wesentlich flüssiger.

Als Website hatte ich als Beispiel www.flugzeugbilder.de . Die Website wird auch über Cloudflare gehostet. Mit einem 1und1 Anschluss läuft es top. Mit meinem Congstar Anschluss laden die Fotos wie damals bei ISDN.

Banned · Donnerstag um 20:34

@liz02mo

PS C:\WINDOWS\System32> tracert 162.159.140.229

Routenverfolgung zu 162.159.140.229 über maximal 30 Hops

1 27 ms 1 ms 2 ms speedport.ip [192.168.2.1]
2 11 ms 18 ms 5 ms p50928214.dip0.t-ipconnect.de [80.146.130.20]
3 10 ms 18 ms 7 ms f-ed13-i.F.DE.NET.DTAG.DE [217.5.67.54]
4 * * * Zeitüberschreitung der Anforderung.
5 313 ms 314 ms 157 ms if-bundle-66-2.qcore2.fnm-frankfurt.as6453.net [195.219.220.129]
6 190 ms 159 ms 160 ms if-bundle-11-2.qcore2.f2c-frankfurt.as6453.net [195.219.87.51]
7 11 ms 8 ms * 162.158.84.251
8 25 ms 9 ms 8 ms 162.159.140.229

Ablaufverfolgung beendet.
PS C:\WINDOWS\System32> ping -n 20 162.159.140.229

Ping wird ausgeführt für 162.159.140.229 mit 32 Bytes Daten:
Antwort von 162.159.140.229: Bytes=32 Zeit=26ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=10ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=7ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=10ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=7ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=9ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=8ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=9ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=8ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=8ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=10ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=7ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=10ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=9ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=10ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=9ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=8ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=7ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=10ms TTL=56
Antwort von 162.159.140.229: Bytes=32 Zeit=9ms TTL=56

Ping-Statistik für 162.159.140.229:
Pakete: Gesendet = 20, Empfangen = 20, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 7ms, Maximum = 26ms, Mittelwert = 9ms

PS C:\WINDOWS\System32> tracert 1.1.1.1

Routenverfolgung zu one.one.one.one [1.1.1.1]
über maximal 30 Hops:

1 3 ms 20 ms 3 ms speedport.ip [192.168.2.1]
2 4 ms 8 ms 4 ms p50928214.dip0.t-ipconnect.de [80.146.130.20]
3 13 ms 10 ms 9 ms f-ed13-i.F.DE.NET.DTAG.DE [217.5.118.230]
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6 278 ms 261 ms 353 ms if-bundle-11-2.qcore2.f2c-frankfurt.as6453.net [195.219.87.51]
7 * 36 ms 9 ms 162.158.84.27
8 42 ms 9 ms 11 ms one.one.one.one [1.1.1.1]

Ablaufverfolgung beendet.
PS C:\WINDOWS\System32> ping -n 20 1.1.1.1

Ping wird ausgeführt für 1.1.1.1 mit 32 Bytes Daten:
Antwort von 1.1.1.1: Bytes=32 Zeit=35ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=9ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=9ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=9ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=11ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=9ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=9ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=10ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=12ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=11ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=13ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=12ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=13ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=12ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=11ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=9ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=9ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=11ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=10ms TTL=56
Antwort von 1.1.1.1: Bytes=32 Zeit=12ms TTL=56

Ping-Statistik für 1.1.1.1:
Pakete: Gesendet = 20, Empfangen = 20, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 9ms, Maximum = 35ms, Mittelwert = 11ms

Routenverfolgung zu gemini.google.com [2a00:1450:4001:81d::200e]
über maximal 30 Hops:

1 2 ms 6 ms 2 ms p200301013706cb07e6fb5dfffeb1b937.dip0.t-ipconnect.de [2003:101:3706:cb07:e6fb:5dff:feb1:b937]
2 27 ms 4 ms 7 ms 2003:0:8308:e000::1
3 * * * Zeitüberschreitung der Anforderung.
4 8 ms 8 ms 8 ms 2003:0:1304:8002::2
5 56 ms 36 ms 38 ms 2001:4860:0:1::88af
6 27 ms 8 ms 7 ms 2001:4860:0:1::9f
7 30 ms 5 ms 5 ms tzfraa-aa-in-x0e.1e100.net [2a00:1450:4001:81d::200e]

Ablaufverfolgung beendet.

C:\Users\XXXX>ping -n 10 gemini.google.com

Ping wird ausgeführt für gemini.google.com [2a00:1450:4001:81d::200e] mit 32 Bytes Daten:
Antwort von 2a00:1450:4001:81d::200e: Zeit=6ms
Antwort von 2a00:1450:4001:81d::200e: Zeit=27ms
Antwort von 2a00:1450:4001:81d::200e: Zeit=7ms
Antwort von 2a00:1450:4001:81d::200e: Zeit=6ms
Antwort von 2a00:1450:4001:81d::200e: Zeit=5ms
Antwort von 2a00:1450:4001:81d::200e: Zeit=7ms
Antwort von 2a00:1450:4001:81d::200e: Zeit=27ms
Antwort von 2a00:1450:4001:81d::200e: Zeit=42ms
Antwort von 2a00:1450:4001:81d::200e: Zeit=15ms
Antwort von 2a00:1450:4001:81d::200e: Zeit=6ms

Ping-Statistik für 2a00:1450:4001:81d::200e:
Pakete: Gesendet = 10, Empfangen = 10, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 5ms, Maximum = 42ms, Mittelwert = 14ms

Routenverfolgung zu unfiltered.joindns4.eu [86.54.11.100]
über maximal 30 Hops:

1 5 ms 3 ms 1 ms speedport.ip [192.168.2.1]
2 12 ms 33 ms 8 ms p50928214.dip0.t-ipconnect.de [80.146.130.20]
3 12 ms 9 ms 28 ms f-ed11-i.F.DE.NET.DTAG.DE [217.0.200.218]
4 30 ms 10 ms 9 ms 80.156.162.158
5 37 ms 9 ms 9 ms coreb-fra.cdn77.com [169.150.195.68]
6 20 ms 10 ms 21 ms vl251.fra-drt30-dist-2.cdn77.com [79.127.195.84]
7 27 ms 12 ms 11 ms unfiltered.joindns4.eu [86.54.11.100]

Ablaufverfolgung beendet.

C:\Users\XXXX>ping -n 10 86.54.11.100

Ping wird ausgeführt für 86.54.11.100 mit 32 Bytes Daten:
Antwort von 86.54.11.100: Bytes=32 Zeit=34ms TTL=58
Antwort von 86.54.11.100: Bytes=32 Zeit=12ms TTL=58
Antwort von 86.54.11.100: Bytes=32 Zeit=11ms TTL=58
Antwort von 86.54.11.100: Bytes=32 Zeit=16ms TTL=58
Antwort von 86.54.11.100: Bytes=32 Zeit=10ms TTL=58
Antwort von 86.54.11.100: Bytes=32 Zeit=11ms TTL=58
Antwort von 86.54.11.100: Bytes=32 Zeit=8ms TTL=58
Antwort von 86.54.11.100: Bytes=32 Zeit=10ms TTL=58
Antwort von 86.54.11.100: Bytes=32 Zeit=11ms TTL=58
Antwort von 86.54.11.100: Bytes=32 Zeit=12ms TTL=58

Ping-Statistik für 86.54.11.100:
Pakete: Gesendet = 10, Empfangen = 10, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 8ms, Maximum = 34ms, Mittelwert = 13ms

Web-Schecki · Donnerstag um 21:36

azereus schrieb:
anstelle des direkten Peerings mit der DTAG das sie eigentlich haben

Hast du eine Quelle dazu? Auch zur Kapazität?

azereus schrieb:
provider wechseln und hoffen deren peering ist besser

Man muss nicht hoffen. Public-Peering-Kapazitäten und die Peering-Policy sind öffentlich einsehbar und immer ein guter Indikator, ob ein Netz gut erreichbar sein möchte oder nicht.
Natürlich geht es auch ohne, aber dann muss man eben wirklich hoffen...

azereus schrieb:
jeder will die beste leistung und nichts dafür tun/zahlen.

Alle anderen Anbieter bekommen es ja hin, sich mit Cloudflare zu einigen. Die Telekom selbst hat hingegen nicht nur mit Cloudflare so ihre Probleme, sondern mit vielen anderen Diensten auch, wo erst nach zähen Verhandlungen eine Übereinkunft getroffen werden konnte. Die Statements der Telekom sind bekannt, man gibt offen zu, dass man sich das eigene Netz gerne von CDNs und von Endkunden bezahlen lassen will.
Es gibt darüber hinaus zahlreiche Medienberichte, dass die Telekom marktunübliche Preise verlangt.

Ich weiß echt nicht, wie man mit all diesen Informationen zum Schluss kommen kann, dass Cloudflare etwas dafür kann. Aber es ist auch vollkommen egal, denn mit Cloudflare habe ich als Internetnutzer keinen Vertrag. Mit meinem ISP schon. Und aus dieser Perspektive ist die Sache ziemlich eindeutig: Bei der Telekom zahlt man regelmäßig höhere Preise für seinen Anschluss und bekommt eine schlechte Anbindung an das Internet als bei allen anderen Providern (Vodafone mal ausgenommen). Warum sollte man dort also Kunde sein?

FTTC · Donnerstag um 21:39

@Banned
Scheint so, als ob du über Frankfurt geroutet wirst.

Bei mir läuft es über Düsseldorf, wenn ich das richtig interpretiere.

Code:

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  Router (x.x.x.x)  0.457 ms  0.272 ms  0.262 ms
 2  x.x.x.x.t-ipconnect.de (x.x.x.x)  8.652 ms  8.402 ms  8.422 ms
 3  d-ed5-i.D.DE.NET.DTAG.DE (217.5.110.90)  8.296 ms d-ed5-i.D.DE.NET.DTAG.DE (217.0.193.42)  8.382 ms  8.365 ms
 4  ae5.edge6.dus1.sp.lumen.tech (4.68.71.113)  9.265 ms  13.766 ms  10.538 ms
 5  ae2.3216.ear4.frf1.neo.colt.net (171.75.10.127)  12.279 ms ae2.3221.edge8.frf1.neo.colt.net (171.75.10.151)  13.505 ms ae2.3216.ear4.frf1.neo.colt.net (171.75.10.127)  12.281 ms
 6  195.122.183.210 (195.122.183.210)  17.896 ms  14.456 ms 212.162.9.130 (212.162.9.130)  10.526 ms
 7  162.158.84.39 (162.158.84.39)  13.611 ms 162.158.84.219 (162.158.84.219)  20.823 ms 162.158.84.221 (162.158.84.221)  12.150 ms
 8  one.one.one.one (1.1.1.1)  11.605 ms  11.208 ms  11.098 ms

Ich konnte lange Zeit die Probleme auch nicht nachvollziehen. Jetzt nervt es nur noch.

Dafür zahle ich nur 28€ für aktuell 130/40 Mbits.

dw4817 · Donnerstag um 21:42

FTTC schrieb:
@Banned
Scheint so, als ob du über Frankfurt geroutet wirst.

Bei mir läuft es über Düsseldorf, wenn ich das richtig interpretiere.

Du siehst mit Traceroute nur den Hinweg, der Engpass ist aber auf dem Rückweg. Da zwischen den großen Netzen bei mehreren Übergaben "hot potatoe routing" zum Einsatz kommt, ist der Rückweg i.d.R. nicht mit dem Hinweg identisch.

CoMo · Donnerstag um 23:57

FTTC schrieb:
Scheint so, als ob du über Frankfurt geroutet wirst.

Bei mir läuft es über Düsseldorf, wenn ich das richtig interpretiere.

Ihr wisst doch nicht mal, ob ihr überhaupt denselben Server traced. 1.1.1.1 ist Anycast. Die IP ist über die ganze Welt verteilt.

gaym0r · Freitag um 00:11

dw4817 schrieb:
Du siehst mit Traceroute nur den Hinweg, der Engpass ist aber auf dem Rückweg.

Wie kommst du darauf?

Ist dies das berüchtigte Peering der Telekom?

Fleet Admiral

Cadet 4th Year

Maître de cuisine Pro

Rear Admiral

Commodore

Cadet 4th Year

Lieutenant

Fleet Admiral

Cadet 4th Year

Rear Admiral

Cadet 4th Year

Lt. Junior Grade

Commodore

Cadet 4th Year

Fleet Admiral

Lt. Commander

Cadet 4th Year

Cadet 4th Year

Commodore

Commodore

Ähnliche Themen