Ist dies das berüchtigte Peering der Telekom?

[eifelman85]

E.ON

Routenverfolgung zu metalfactory.ch [194.191.24.25]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.2.1]
  2    20 ms    19 ms    19 ms  192.168.203.24
  3    25 ms    19 ms    19 ms  172.28.127.9
  4    19 ms    19 ms    19 ms  192.168.125.11
  5    25 ms    27 ms    22 ms  253-145-088-212.ip-addr.vsenet.de [212.88.145.253]
  6    20 ms    20 ms    20 ms  et-2-0-5.0.vs-core-r1.6838.ip.vsenet.de [217.24.235.181]
  7    22 ms    20 ms    20 ms  et-2-0-2.0.vs-core-r2.6838.ip.vsenet.de [217.24.235.178]
  8    22 ms    23 ms    26 ms  et-2-1-2.0.vs-core-r2.6898.ip-addr.vsenet.de [217.24.235.157]
  9    36 ms    35 ms    29 ms  frals3000.de.as1836.net [80.81.195.163]
 10    31 ms    30 ms    31 ms  146.228.2.114
 11    31 ms    31 ms    31 ms  146.228.2.101
 12    32 ms    33 ms    32 ms  146.228.67.99
 13    31 ms    31 ms    31 ms  194.191.25.66
 14    31 ms    31 ms    31 ms  web15.servicehoster.ch [194.191.24.25]

 

[Engaged]

---------------------------------------
Route nach metalfactory.ch verfolgen
(194.191.24.25)
Max. Hops 30
---------------------------------------

hop 1:
192.168.178.1
192.168.178.1
19 ms

hop 2:
p3e9bf103.dip0.t-ipconnect.de
62.155.241.3
* ms

hop 3:
hh-ea13-i.hh.de.net.dtag.de
80.156.161.156
* ms

hop 4:
80.156.160.237
80.156.160.237
* ms

hop 5:
Keine Antwort

hop 6:
ffm-bb2-link.ip.twelve99.net
ffm-bb2-link.ip.twelve99.net
* ms

hop 7:
zch-b1-link.ip.twelve99.net
zch-b1-link.ip.twelve99.net
* ms

hop 8:
greendatacenter-ic-393844.ip.twelve99-cust.net
2001:2035:0:1968::2
* ms

hop 9:
146.228.2.49
146.228.2.49
130 ms

hop 10:
146.228.2.114
146.228.2.114
99 ms

hop 11:
146.228.2.101
146.228.2.101
* ms

hop 12:
146.228.67.99
146.228.67.99
126 ms

hop 13:
194.191.25.66
194.191.25.66
114 ms

hop 14:
web15.servicehoster.ch
194.191.24.25
99 ms

---------------------------------------
Traceroute-Statistiken von metalfactory.ch
Sprünge 14, Gesamtzeit 21081 ms
---------------------------------------

Traceroute by Ping Master - Network Tools & IP Utilities
https://play.google.com/store/apps/details?id=com.appplanex.pingmasternetworktools.pro

 

[millen]

Versatel (1und1):

$ traceroute -I metalfactory.ch
traceroute to metalfactory.ch (194.191.24.25), 30 hops max, 38 byte packets
 1  ddn0020aihk001.versatel.de (94.134.199.136)  5.236 ms  4.820 ms  4.809 ms
 2  ddn1001dihd001.versatel.de (62.214.42.187)  8.879 ms  6.957 ms  10.651 ms
 3  fra020isp005.versatel.de (80.81.193.80)  19.068 ms  19.154 ms  19.203 ms
 4  frals3000.de.as1836.net (80.81.195.163)  24.078 ms  24.129 ms  30.543 ms
 5  146.228.2.114 (146.228.2.114)  24.538 ms  24.797 ms  24.599 ms
 6  146.228.2.101 (146.228.2.101)  25.769 ms  25.495 ms  25.270 ms
 7  146.228.67.99 (146.228.67.99)  25.872 ms  27.008 ms  32.662 ms
 8  194.191.25.66 (194.191.25.66)  25.484 ms  26.010 ms  25.421 ms
 9  web15.servicehoster.ch (194.191.24.25)  24.398 ms  24.198 ms  24.183 ms

Das ist zwar DSL, würde ich zumindest meinen aufgrund der 1. HOP Latenz, aber wo kommen da die extra 15ms her zwischen dem von die genutzten Anschluss und meinem? Also ich mein 20ms von einem Anschluss in Dresden nach FFM ist schon krass, zumal das versatel intern läuft.

Start: 2026-10-12T13:08:38+0200
HOST: gmk-01                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    _gateway (10.1.0.1)                  0.0%    10    0.5   0.5   0.3   0.5   0.1
  2. AS8881   fra0102aihk001.versatel.de (94.134.1 0.0%    10    3.0   3.0   2.4   6.3   1.2
  3. AS8881   62.72.71.113                         0.0%    10    2.2   3.6   2.2   7.2   1.8
  4. AS???    fra020isp005.versatel.de (80.81.193. 0.0%    10    2.4   2.4   2.2   2.5   0.1
  5. AS???    frals3000.de.as1836.net (80.81.195.1 0.0%    10    8.7   8.8   8.6   9.1   0.2
  6. AS1836   146.228.2.114                        0.0%    10    9.3   9.7   9.2  10.8   0.5
  7. AS1836   146.228.2.101                        0.0%    10    9.6  10.8   9.2  22.9   4.3
  8. AS1836   146.228.67.99                        0.0%    10   11.6  13.8  10.4  17.7   2.5
  9. AS1836   194.191.25.66                        0.0%    10    9.6   9.5   9.4   9.6   0.1
 10. AS1836   web15.servicehoster.ch (194.191.24.2 0.0%    10    9.4   9.3   9.2   9.4   0.1

 

[Bodennebel]

Telekom Glasfaser:

PS C:\Users\...> tracert metalfactory.ch

Routenverfolgung zu metalfactory.ch [194.191.24.25]
über maximal 30 Hops:

  1     2 ms     3 ms     2 ms  Speedport.ip [192.168.2.1]
  2     3 ms     3 ms     3 ms  p3e9bf1e4.dip0.t-ipconnect.de [62.155.241.228]
  3     6 ms     5 ms     6 ms  d-ed5-i.D.DE.NET.DTAG.DE [217.5.110.94]
  4     5 ms     6 ms     5 ms  ae5.edge6.dus1.sp.lumen.tech [4.68.71.113]
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6    31 ms    30 ms    30 ms  green.ch-ag.ear1.zurich3.level3.net [213.242.82.42]
  7    30 ms    31 ms    31 ms  146.228.2.97
  8    37 ms    38 ms    39 ms  146.228.67.99
  9    31 ms    33 ms    31 ms  194.191.25.66
 10    32 ms    31 ms    31 ms  web15.servicehoster.ch [194.191.24.25]

Ablaufverfolgung beendet.

PS C:\Users\...> tracert die-glocke.de

Routenverfolgung zu die-glocke.de [83.223.64.122]
über maximal 30 Hops:

  1     1 ms     2 ms     1 ms  Speedport.ip [192.168.2.1]
  2     3 ms     3 ms     3 ms  p3e9bf1e4.dip0.t-ipconnect.de [62.155.241.228]
  3     6 ms     7 ms     6 ms  d-ed5-i.D.DE.NET.DTAG.DE [62.159.98.194]
  4     6 ms     6 ms     6 ms  ae5.edge6.dus1.sp.lumen.tech [4.68.71.113]
  5    24 ms    28 ms    24 ms  ae2.3602.edge3.ber1.neo.colt.net [171.75.9.134]
  6    17 ms    18 ms    17 ms  carrier-51.edge3.berlin1.level3.net [62.67.20.130]
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8    16 ms    16 ms    15 ms  rosza.im-serverschrank.de [83.223.70.12]
  9    17 ms    16 ms    17 ms  die-glocke.de [83.223.64.122]

Ablaufverfolgung beendet.

Wie bei @Col. Jessep : Homepage von die-glocke.de geht super schnell, das Laden der Artikel oder des Impressums dauern mehrere Sekunden (für meinen Geschmack zu lange).

 

[NDiCB]

aber wo kommen da die extra 15ms her zwischen dem von die genutzten Anschluss und meinem?

Weiß ich leider nicht. Der Traffic läuft m.W.n. bei Versatel mitunter erst einmal über Berlin (anstatt über L). Nicht nur von DD sondern u.a. auch von Chemnitz aus.

BTW:
die-glocke.de läuft bei mir gerade auch über einen 1und1-Anschluss nicht gerade gut.

 

[turbowiesel]

Habe eben gestestet. Die Seite läuft generell sehr zügig. Egal was man dort aufruft.

 

[NDiCB]

Jetzt ja. Vor 4 bzw. 3 Stunden sah das jedoch noch anders aus…

 

[froeschi62]

Sogar heute, den 13.10.26 um 09:34 Uhr ist über die Telekom bei Aufruf dieser Seite direkt Stillstand.

 

[T!tr0]

@froeschi62 Kann ich aktuell nicht bestätigen. Auf der Arbeit mit Telekom Anschluss kein Problem. Klar, der Artikelaufruf dauert 1-2 Sekunden aber sonst nichts auffälliges.

 

[conf_t]

@T!tr0 Ich lese ja noch immer meist still mit, aber ich kann weder für gestern Abend ( 20 Uhr +/-) oder heute Morgen für keine der Seiten was auffälliges berichten. In unter 2 Sekunden aufgerufen und Latenz unter 20 ms jeweils. Auch Telekom FTTH, und ich gehe da ja wie wir mittlerweile festgestellt haben an einem benachbarten POP (MAIJ00) von @froeschi62 rein und habe meistens ( nicht immer) keine Probleme während @froeschi62 hingegen schwache Performance erlebt.

 

[froeschi62]

Zumindest Stand 12:03 Uhr wird die Anfangsseite wieder sofort geladen und das Laden der Artikel innerhalb der Seite dauert etwa 5 bis 6 Sekunden.

Ergänzung (Dienstag um 12:27)

Da meine Telekom FTTH Leitung physisch an diesen Pop gebunden ist, werde ich ihn wohl nur über einen Providerwechsel (L2-BSA) los.

 

[conf_t]

Ja, bei mir dauert der Artikelaufruf auch, das liegt aber nicht an der latenz (=Auslastung des Peerings), sondern daran, dass der Server erst mal in den Keller geht in der Datenbank rumwühlt, die wohl eher eine Datenmülltonne zu sein scheint, und dann Sekunden später anfängt auszuliefern:

Paket 8 ist mein Request, Paket 9 die Empfangsbestätigung des selbigen (TCP ACK) und dann kommen erst 3,5 Skeunden später die Daten. Ob schlechtes Anwendungsdesign, zuwenig Datenbank Ressourcen, fortn oer backend Problem, keine Ahnung. Da danach aber alle Pakete schnell ausgeliefert werden, widerlegen sie jeden Auslastungsverdacht. Aber es zeigt, es wird zu oft hier im Thread nach "böse Telekom" gerufen, wenn es mit etwas mühe nachweisbar ist, dass es auch mal (natürlich nicht immer) an etwas anderem liegt.

Bei performanten Netzwerk- und Internetverbindungen werden schlecht designte Webdienste oder fehlende Ressourcen in Webdiensten schneller sichtbar.

 

[froeschi62]

Nun ja, über Lumen, GutCon.net und sinma ist jetzt auch nicht gerade die Traumroute

 

[conf_t]

Das ist aber jetzt ein Strohmann in dem Fall das Routing anzusprechen. Flaschenhals (aus der Erfahrung der Analyse von tausenden PCAPS) höchstwahrsceinlich bei metalfactory.ch das Backend. Eine optimalere Route würde vielleicht 5 oder 6 ms Einsparen. Aber was nutzt es ob das Paket mit Daten nach nun 3500 oder 3506 ms bei einem ankommt? Wenn das Backend 3500 ms benötigt. Selbst ohne Latenz würde es sich vielleicht von 3500 auf 3480 ms verbessern. Wow!

Vielleicht erkennt man daran, über welche Größenordnungen im großen und ganze teilweise hier diskutiert wird...... 🤦‍♂️. Deshalb, ofmals sind es eben doch Einzelfälle, die man sich einzeln anschauen muss und wie hier, ist zumindest bei metalfactory.ch die Telekom unschuldig, auch wenn die Route schöner sein könnte.

 

[froeschi62]

Wie so oft findet man immer legitime Gegenargumente aber man sollte dabei auch sachlich bleiben. Niemend schreibt von einer bösen Telekom. Die Beschwerde zum Thema Cloudflare war gerechtfertigt, wozu dieser Thread hier überhaupt erst entstanden ist. Damit wurde über die Zusammenschaltung nun eine große Peering Lücke geschlassen aber deshalb ist nicht automatisch alles damit gelöst.

 

[conf_t]

Die Beschwerde zum Thema Cloudflare war gerechtfertigt, wozu dieser Thread hier überhaupt erst entstanden ist

Dem widerspreche ich nicht. Und ich habe meine Aussagen daher immer auf Teilmengen des Threads bezüglich meiner Fackeln&Mistgabel-Mob-Kritik eingeschränkt.

Es lohnt sich halt einfach genau hinzuschauen was los ist. Traceroute kann ein Hinweis für Probleme sein, aber genauso gut nichts sinnvolles liefern, es kann ein Anhaltspunkt sein. Besser man schaut in den Problemfällen direkt auf die Leitung, sprich in die Pakete, die sprechen für sich. Und in dem von mir geposteten Fall gibt es Nix zu argumentieren, das ist ziemlich Basic.

 

[NDiCB]

Ich hatte ja gestern gegen 17 Uhr auch enorme Probleme mit der Webseite die-glocke.de, egal über welchen ISP. Zwei oder drei Stunden später dagegen keine Probleme mehr, auch nicht über ein Telekom-Anschluss. Also ich denke was diese Webseite betrifft ist tatsächlich (zumindest zeitweise) irgendetwas anderes im Argen.

 

[Web-Schecki]

Und auch beim Thema Cloudflare konnte man beobachten, dass die alles in Bewegung gesetzt haben, um das Problem einzudämmen. Es gab ja zig verschiedene Transitrouten, und die Premiumdienste haben meistens auch an Telekom-Anschlüssen gut funktioniert. Der Transit über Newark für Cloudflare-Free wurde auch irgendwann durch einen Übergabepunkt in London ersetzt, der - wenn er nicht gerade vollgelaufen ist - auch ein annehmbares Erlebnis an Telekomanschlüssen ermöglicht hat.

Es ist eben das Perfide daran, dass die Geschäftspolitik der Telekom allen anderen schadet und alle versuchen, die dadurch entstehenden Probleme mit aller Macht und unter hohen Kosten einzudämmen. Aber natürlich ist Transit - auch über verschiedene Provider - nicht grundsätzlich ein technisches Problem, das einen Internetanschluss unbenutzbar macht.

 

[markchess]

Die Anbieter sind auch selber Schuld.
Einfach überall einen Banner einblenden mit:
"Ihr ISP "Dt. Telekom" hat schlechtes Peering. Wechseln Sie zu einem anderen damit unsere Dienste wieder einwandfrei funktionieren" oder so ähnlich.

 

[conf_t]

@markchess Praktisch: Der Anbieter spart sich die Fehlersuche und blendet stattdessen einen Telekom-Banner ein. Selbst dann, wenn die eigene Anwendung trödelt oder Nutzer anderer Provider dasselbe Problem melden.

Genau diese reflexartige Schuldzuweisung kritisiere ich. Hier wurden gerade zuletzt providerübergreifende Probleme beschrieben und für einen konkreten Abruf eine mehrsekündige Wartezeit nach bereits bestätigtem Empfang der Anfrage gezeigt. Und die nächste Empfehlung lautet wieder: Telekomkunde? Anbieter wechseln!

Bekannte Peeringprobleme sind ein guter Grund, das Peering zu prüfen. Sie sind kein Freifahrtschein, jede langsame Webseite damit zu erklären. Erst die Ursache feststellen, dann den passenden Banner schreiben.