1&1 / Telekom Peering vergleich

Das steht aber nur, dass mehrere hundertausend Anschlüsse untersucht werden können. Da steht nicht, dass sie untersucht wurden, und da steht auch nicht, was "untersucht" in dem Kontext überhaupt bedeutet. Das könnte z.B. bedeuten, wenn ein Messpunkt in einer Stadt ist, werden alle Anschlüsse dieses Providers in dieser Stadt als "untersucht" gekennzeichnet. Es könnte auch bedeuten, von einem Messpunkt wurde ein Ping an einen Anschluss gesendet, und der gilt dann als "untersucht", da ja auch explizit darauf hingewiesen wird, dass der Test Aussagen über die Zuverlässigkeit zulässt, aber nicht über die Geschwindigkeit.

Hunderte Millionen Messwerte schaffe ich in 24 Wochen auch problemlos von 80 Stationen. Das ist nicht mal ein Messwert pro Sekunde.

Und für alles Weitere dürft ihr gerne auch mal ein bisschen bei umlaut nachlesen.

In Ermangelung an besseren Alternativen halte ich übrigens Connect/umlaut weiterhin für das deutlich bessere Ergebnis als die immer wiedergekäuten Anekdoten und "Untersuchungen", die zum Besten gegeben werden.

Und spannender wird das Thema für mich nicht mehr, daher tatsächlich eod.

Jeder, der im Internet ein eigenes AS betreibt oder dessen Arbeitgeber hinter einem (größeren) AS steht, weiß um die Problematik der Erreichbarkeit von Single-Homed Anschlüssen der DTAG. Unter vorgehaltener Hand wird das ja sogar von den Network Engineers der Telekom zugegeben, auf RIPE Board Meetings oder anderen Zusammenkünften (DENOG, CCC, GPNs usw.). Die Faktenlage dazu ist in der Fachwelt eigentlich auch mehr als eindeutig. Preisaufschläge von mehr als dem 4-fachen über dem Durchschnitt für Transit von AS3320 sind anders auch gar nicht zu rechtfertigen.

Ein hoffentlich letztes Wort zum Connect-Test. Ich habe kein beef mit Connect oder Umlaut, und sehe den Test für Connects Marketing-Ziel einen "besten Massenmarkt-ISP" zu nach quasi-objektiven Kriterien wählen durchaus geeignet an (ist allerdings eine Frage deren Antwort mich persönlich nicht sonderlich interessiert).

Aber der Test ist Grütze wenn es darum geht das "vorsätzliche Unterpeering" der Telekom messen zu wollen. (Die Anzahl der getesteten End-AS ist ziemlich überschaubar (habe mit https://radar.qrator.net getestet ob eine Verbindung zu AS3320 DTAG existiert, ich bin nicht sicher wie präzise die Einteilung Peeringpartner oder Transitkunde hier ist, aber in beiden Fällen gibt es eine direkte Kopplung):

1. Akamai (AS20940, peert mit DTAG)
2. Amazon Cloudfront (AS16509, peert mit DTAG)
3. ETSI Kepler page (Hosting unklar)
4. https://about.instagram.com/about-us/careers (AS32934, indirekt per Transit)
5. https://en.m.wikipedia.org/wiki/Wikipedia:Featured_pictures (AS14907, Transitkunde der DTAG)
6. https://policies.google.com/privacy (AS15169, peert mit DTAG)

Der Test ist auch Grütze wenn es darum geht die Vertragstreue von ISPs zu untersuchen (der Test den die Zafaco fuer die Bundesnetzagentur aufgesetzt hat ist da klar überlegen).

Hier meine Gedanken zum Crowdsourcing-Teil des Connect Tests (Spoiler Alert: fuer Connects Ziel ausreichend, ansonsten wenig aussagekräftig)

Daher werde ich fuer meinen Teil das Thema beenden, auch wenn ich akzeptiere, dass meine Bewertung des Tests hier nicht allgemein geteilt wird.

Zitat von pufferueberlauf

Der Test ist auch Gruetzte wenn es darum geht die Vertragstreue von ISPs zu untersuchen (der Test den die Zafaco fuer die Bundesnetzagentur aufgesetzt hat ist da klar ueberlegen).

Zafaco hat hier das „Glück“, Core-Backbone als einer ihrer Transit-Partner ausgewählt zu haben, die ihrerseits (teuren) Transit der DTAG beziehen. Das kann wieder ganz anders aussehen, wenn man zum Beispiel von einem DG Anschluss auf einen Anschluss der DTAG zugreifen möchte.

Oder wenn ich unsere Interconnection zur Telekom deaktivieren würde. Wir hätten dafür locker die Bandbreite, über unsere regulären Transitprovider (3356,1299,174) Kunden der DTAG zu erreichen. Wenn die Telekom denn zu ihren T1 Partnern genügend Bandbreite zur Verfügung stellen würde. Gäbe es kein vorsätzliches Unterpeering zwischen der Telekom und anderen T1, hätte auch Cogent vor Jahren nicht versucht, dagegen vorzugehen. Oder Level3.

Ich denke das Thema wird weiter an Fahrt aufnehmen, wenn mehr große Dienste sich weigern werden, für ihre Verbindung zu Endkunden der DTAG Premiumpreise bezahlen zu müssen. Meta hat es ja in letzter Zeit vor gemacht, Google/Alphabet war in der Vergangenheit auch erfolgreich.

Ich stimme Dir zu, mir ging es eher darum wie der Rest des Tests implementiert ist, z.B. dass mann sich bei den Messservern mit der vertraglichen Rate anmeldet und eine Messung nur gestartet wird wenn die Server ausreichend Kapazitaet fuer den Test haben.

Was das Unterpeering angeht, in der Hinsicht ist auch der breitbandmessung.de Test Gruetze...

Wobei Meta IMHO zu dreist war* und mit einem solchen Urteil haette rechnen muessen, das war ein Eigentor. Google ist IMHO relativ sicher, da die Telekom selber die Google Cloud nutzt... (und ich vermute Goggle zahlt da auch nicht extra fuer).

*) Die bisherigen bezahlten Transitlinks unilateral weiter zu nutzen ohne dafuer zu zahlen mit der Begruendung nur noch Traffic mit Endspunktem im Telekom-AS zu senden war IMHO etwas zu ueberheblich.

Ich fand dieses Dokument der BEREC ganz erhellend:

| BEREC

Wo in Teil 6 Generic structure of IP-IC issues eine Liste von Problemfaellen kommt:

Zitat

These cases are in particular:

• Init7 vs. Swisscom83; [da ist die Deutsche Telekom indirekt auch dran beteiligt]

• Deutsche Forschungsnetz vs. Deutsche Telekom;

• Hetzner vs. Deutsche Telekom;

• [CONFIDENTIAL] vs. Deutsche Telekom;

• as well as the cases mentioned in Annex I. [das enthaelt unter anderem den Disput der Telekom mit Meta]

Alles anzeigen

Da wuerde ich zu gerne wissen wer sich hinter CONFIDENTIAL versteckt. Egal, klar ist, die Telekom ist damit europaweit auffaellig...

Zitat

• Init7 vs. Swisscom83; [da ist die Deutsche Telekom indirekt auch dran beteiligt]

Dazu gibt es nun ein Urteil

https://www.init7.net/de/news/241223-mm-init7-comcom-verfugt-swisscom-muss-zero-settlement-peering-mit-init7-betreiben-de.pdf

Puh, das Urteil ist aber auch mal ein echter Wälzer. 90 DIN-A4 Seiten eng bedruckt. Das wichtigste wurde ja in der Init7 Pressemitteilung wiedergegeben, aber im dort verlinkten Urteil sind sogar noch einige sehr spezifische technische Details zu lesen:

Zitat von Verfügung der Eidgenössischen Kommunikationskommission ComCom

1. Die Gesuchsgegnerin [Swisscom] wird verpflichtet, der Gesuchstellerin [Init7] auf transparente und nichtdiskriminierende Weise zu einem Preis von CHF 0.00 (pro Mbps P95/monatlich) nach folgenden Zugang zu gewähren:

• Datenaustausch (Peering) zwischen dem InternetBackbone AS3303 der Gesuchsgegnerin mit dem Internet Backbone AS 13030 der Gesuchstellerin, sowohl für IPv4 wie auch für IPv6.
• Datenaustausch (Peering) zwischen dem mobilen Netzwerk der Gesuchsgegnerin mit dem Internet Backbone AS13030 der Gesuchstellerin.
• Anzahl Leitungen: 2 (Genf und Zürich).
• Geschwindigkeit: Pro Leitung 10 Gigabit pro Sekunde.
• Ohne jeglichen Ratelimiter.
• Die Gesuchsgegnerin muss alle Prefixe wie zu anderen Peering Partnern propagieren, insbesondere auch alle More-Specific Prefixe, die für die Privatkundenbasis in Benutzung sind.
• Überschreitet der ausgetauschte Traffic 50 % der Nennkapazität basierend auf der 95-percentile Messung (Monatsabrechnung), wird die Gesuchsgegnerin verpflichtet, kooperativ mit der Gesuchstellerin zusätzliche Kapazität an den branchenüblichen Interkonnektionspunkten zu erstellen. Die notwendigen Verkabelungskosten werden dabei für jeden zusätzlichen Link abwechslungsweise von der Gesuchstellerin und der Gesuchsgegnerin getragen.

2. Die Verfahrenskosten in der Höhe von CHF 170'340.00 werden der Gesuchsgegnerin zur Bezahlungauferlegt.

3. Diese Verfügung wird den Parteien schriftlich gegen Rückschein eröffnet.

https://www.init7.net/de/vf-2024-12-19-001-entscheid-comcom-verf-init7-swisscom-interconnect-pering.pdf

Die Verbraucherzentrale Bundesverband (VZBV) wirft der Deutschen Telekom ein Ausbremsen des Internets durch kostenpflichtiges Zusammenschalten wie Peering vor. Das geht aus einer Kampagnenseite hervor, die zusammen mit Aktivisten für digitale Bürgerrechte und der Stanford-Professorin Barbara von Schewig veröffentlicht wurde. Die Telekom schaffe "künstliche Engpässe an den Zugängen zum Telekom-Netz", lautet der Vorwurf.

Und hier der Bericht bei Golem mit einer Stellungnahme der Telekom: https://www.golem.de/news/peering-v…192195.amp.html

Zitat

Telekom-Sprecherin Nicole Schmidt wies die Vorwürfe zurück. Sie sagte Golem.de: "Die erhobenen Vorwürfe sind falsch und zeugen von rechtlichem und technischem Unverständnis. Die Telekom verletzt weder die Netzneutralität, noch verschlechtert sie den Netzzugang für ihre Kundinnen und Kunden. Stattdessen gewinnen wir sämtliche Netztests und sind jüngst wieder – zum 17. Mal in Folge – als Anbieter des besten Internets ausgezeichnet worden."

Da wird also wie erwartet unter anderem der Sieg im Connect-Test herangezogen und ziemlich über-.interpretiert... weil wie in #44 gezeigt ist gerade eine einziger HTML-Test gegen ein AS das nicht mit der Telekom gut/teuer verbunden ist. Grütze ist das Wort was sich mir da aufdrängt, Marketinggrütze....

Zitat von HubeBube

Und hier der Bericht bei Golem mit einer Stellungnahme der Telekom: https://www.golem.de/news/peering-v…192195.amp.html

Finde ich nett aufbereitet. Insbesondere das Video, auch für technisch wenig versierte Durchschnittsnutzer verständlich. Wäre zu hoffen, dass hier eine entsprechende Resonanz generiert wird.

Mir scheint das Thema allerdings deutlich weniger griffig als der frühere Versuch der Telekom, die Breitband-Flatrate abzuschaffen (Stichwort „Drosselkom“).

Die Telekom hat seit dem PR-technisch massiv dazu gelernt... fair-share klingt doch nett und positiv, und wer steht nicht auf der Seite des Underdogs (Telekom) gegen die Riesen des Silicon Valleys wie Meta?

Das ganze wird konsequent nicht verleugnet, aber auch nicht klar als das verbalisiert was es ist, vorsaetzliches Unterpeering. Und wie erwartet fuehrt dass dazu, dass all die Telekomversteher in den anderen Foren weiter davon schwadronieren, dass es keine harten Beweise gaebe...

Bloede Geschaeftspolitik, aber gute PR....

Zitat von kingpin42

Zafaco hat hier das „Glück“, Core-Backbone als einer ihrer Transit-Partner ausgewählt zu haben, die ihrerseits (teuren) Transit der DTAG beziehen. Das kann wieder ganz anders aussehen, wenn man zum Beispiel von einem DG Anschluss auf einen Anschluss der DTAG zugreifen möchte.

Danke dass das mal öffentlich erwähnt wird! Es ist ein Unding, dass das so ist. Aber wo kämen wir hin, wenn der Test noch die Realität widerspiegelt?

In dem Zusammenhang ebenfalls spannend zu beobachten: seitdem Netzbremse.de am Start ist, scheinen (zumindest einige) Peering deutlich besser zu laufen. Über Cogent gingen gestern um 21 Uhr (Lastrichtung Cogent -> DTAG) noch >1GBit durch. Das gab es in der History, die wir das monitoren, vorher noch _nie_. >1G ging höchsten Mal um 4 Uhr morgens.
Ganz spannendes Timing..

Zitat von Hesphion

Danke dass das mal öffentlich erwähnt wird! Es ist ein Unding, dass das so ist. Aber wo kämen wir hin, wenn der Test noch die Realität widerspiegelt?

In dem Zusammenhang ebenfalls spannend zu beobachten: seitdem Netzbremse.de am Start ist, scheinen (zumindest einige) Peering deutlich besser zu laufen. Über Cogent gingen gestern um 21 Uhr (Lastrichtung Cogent -> DTAG) noch >1GBit durch. Das gab es in der History, die wir das monitoren, vorher noch _nie_. >1G ging höchsten Mal um 4 Uhr morgens.
Ganz spannendes Timing..

Hmm... über den Test aufmein-datendurchsatz.de komme ich hier gerade ca. 2 Uhr nachts nur auf 3-6 Mbit/s, stark schwankend, lässt sich besser beobachten, wenn man die Testdatei direkt versucht herunterzuladen, die Seite bricht nach nur wenigen Sekunden ab., Hatte am späten Nachmittag vor ein paar Tagen < 1Mbit/s (habe kein glasfaser, sondern vdsl100)

Komischerweise liefert der Test in den ersten Sekunde weit höhere Darenraten, da erreiche ich kurzzeitig am Verbindungsstart 20 bis 70mbits (erster spike im task manager) um dann stark abzuflachen.

Gibt es irgendeinen anderen Geschwindigkeitstest, oder Seite die über cogent hostet mit ner großen Datei zum Download?

Geht's dir denn um die Vertrauenswürdigkeit des Tests? Bei mir lädt die Datei sowohl über Telekom Festnetz, als auch über Mobilfunk mit knapp 450 kbit/s.

Ich hab hier noch drei andere Internetzugänge (o2 LTE, 1&1 VDSL 250 und knapp 20 Mbit/s VPN-Verbidung ins NetCologne-Netz) zum Test, dort wird jeweils die volle Geschwindigkeit erreicht.

Das Thema Unterpeering der Telekom ist ja so ein Dauerbrenner... (und auch bei anderen ISPs gibt es sicherlich gelegentlich laenger dauernde Engpaesse, aber halt nicht so systematisch und nicht so vorsaetzlich wie bei der Telekom).

Dabei scheinen sich die betroffenen Endpunkte ueber die Zeit zu aendern (z.B. Hetzner war eine zeitlang nur gut erreichbar wenn mann bei Hetzner eine extra Telekom-Abgabe entrichtet hat, aber inzwischen ist Hetzner eingeknickt und generell gut aus dem Telekomnetz erreichbar).

Die Symptome des "vorsaetzlichen Unterpeerings" sind immer aehnlich und beinhalten meist einen oder mehrere aus folgender Liste:

1. Niedriger Durchsatz: meist auf die Spitzenzeiten* beschraenkt (kann aber gelegentlich auch ausserhalb der Spitzenzeiten beobachtet werden).
   Das laesst sich relativ leicht durch Durchsatztests zu ausgewaehlten Zielen messen.
2. Erhoehte Latenz und Jitter: (meist zur Spitzenzeit) die Latenz ist erhoeht entweder im Vergleich zu den Nebenzeiten fuer den selben Endpunkt, oder im Vergleich zu Zielen am gleichen Standort die ueber andere Uebergaben laufen.
   Das laesst sich durch traceroutes, oder besser mtr oder trippy messen.
3. Erhoehter Paketverlust: ueberlastete Uebergaben droppen oft mehr Pakete was dann wegen der Retransmits und TCPs/QUICs Rateadaptation Algorithmen dazu fuehrt dass alles langsamer wird (siehe 1)).
   Messbar wie 2)
4. Manchmal sieht mann auch ungewoehnlich lange Netzwerkpfade die geographisch unsinning erscheinen, wie Routing ueber die USA fuer Traffic zwischen Endpunkten innerhalb Deutschlands.
   Dafuer sind traceroutes, oder besser mtr oder trippy nuetzlich, idealerweise nicht nur vom eigenen Computer zum Server, sondern auch in Gegenrichtung (z.B. von einem Looking Glass Server am selben Ort).

Es sei angemerkt, dass all diese Symptome auch im normalen Betrieb auftreten koennen, wenn sich die Last aendert braucht auch der beste und aufmerksamste ISP etwas Zeit um seine Netzstruktur anzupassen, auffaellig wird es wenn solche Probleme vorhersagbar und zuverlaessig auftreten.

Hier mal eine (unvollstaendige) Liste von Netzen/Endpunkten die in der Vergangenheit Probleme gemacht haben (zusammen mit dem wget Befehl um das schnell selber messen zu koennen). Da ich selber kein Teleklomkunde bin kann ich nicht testen/ueberpruefen ob diese Endpunkte immer noch betroffen sind oder nicht:

1. FDCservers: looking glass server in Frankfurt: lg-fra.fdcservers.net, da ist momentan bei O2 cogent in der Lastrichtung involviert.
   Durchsatz (wget reportiert die mittleren Durchsatz in der letzten Zeile):
   wget -c -O /dev/null https://lg-fra.fdcservers.net/1GBtest.zip --report-speed=bits
   Latenz/Jitter (Hinweg):
   mtr -ezb4w -c 100 lg-fra.fdcservers.net
   Latenz/Jitter (Rueckweg):
   https://www.fdcservers.net/looking-glass dort Location Frankfurt und statt Ping MTR auswaehlen, dann "Start here" klicken, wenn die Hop DNS Namen nicht lesbar sind, Trace statt MTR auswaehlen.
2. Clouvider: (https://as62240.net Looking Glass und Speedtest)
   Durchsatz (wget reportiert die mittleren Durchsatz in der letzten Zeile):
   wget -c -O /dev/null --report-speed=bits https://fra.speedtest.clouvider.net/1g.bin
   Latenz/Jitter (Hinweg):
   mtr -ezb4w -c 100 demolandia.net
   Latenz/Jitter (Rueckweg):
   https://as62240.net/tools da eigene Adresse eingeben Frankfurt als Location waehlen und auf Traceroute klicken (ist momentan von AS6805 nicht nutzbar, keine Ahnung ob es von anderswo geht)
3. Demolandia.net (Cloudflare): (Seite mit Demos fuer TV and Sound)
   Durchsatz:
   muss per Browser geladen werden, einfach eine grosse Datei suchen und runterladen.
   Latenz/Jitter (Hinweg):
   mtr -ezb4w -c 100 demolandia.net
   Latenz/Jitter (Rueckweg):
   curl -s "https://faizazhar.com/projects/traceroute?targets=1.1.1.1&colos=fra03&packet_type=icmp"
   nicht sonderlich elegant, und wer weiss wie lange das funktionieren wird, die eigene WAN Adreesse laesst sich so feststellen:
   curl -4 icanhazip.com
   in der URL die 1.1.1.1 durch die eigene IP Adresse ersetzen.
4. https://mein-datendurchsatz.de
   Interessante und moeglicherweise relevante Testseite, die allerdings nicht mehr lange funktionieren wird, laut Kopfzeile der Seite:
   Hinweis: Diese Seite geht zum 15.3.2025 dauerhaft außer Betrieb!
   Hier wird eine Download von IONOS (in Berlin?) mit einem Download von BlueVPS ueber Cogent verglichen.

*) Spitzenzeiten: Die Lastkurve am DE-CIX in Frankfurt vermittelt da ein gutes Bild:

Es geht da um die Zeit von ca. 16:00 bis 22:00, da ist das deutsche Netz am aktivsten.

Zitat von DLMttH

Geht's dir denn um die Vertrauenswürdigkeit des Tests? Bei mir lädt die Datei sowohl über Telekom Festnetz, als auch über Mobilfunk mit knapp 450 kbit/s.

Ich hab hier noch drei andere Internetzugänge (o2 LTE, 1&1 VDSL 250 und knapp 20 Mbit/s VPN-Verbidung ins NetCologne-Netz) zum Test, dort wird jeweils die volle Geschwindigkeit erreicht.

Mir geht es um Vertrauenswürdigkeit aber auch eben die baldige Abschaltung von mein-datendurchsatz, wie ein anderer hier auch nocheinmal erwähnte. Ich hab auch mal mit meinem VPS bei der Schildkröte heruntergeladen, dort flutschen die 100Mbit/s auch durch. Rein theoretisch könnte ja der eine Server schauen, ob die Anfrage von einer IP des AS 3320 kommt und dann absichtlich ausbremsen.

pufferueberlauf :

Bei fdcservers erreiche ich über telekom über ipv4 ca. 550kbit/s, über ipv6 ca. 800kbit/s und clouvider lädt 10-20Mbit/s schwankend (egal ob ipv4 oder 6).

Beide traceroutes führen von mir aus über gtt/as3257, auffällig ist im trace das der ping zum ziel und zu den meisten Hops bei 17-25ms liegt, dazwischen aber ein Gerät von gtt knapp 100ms ausspuckt.
Der trace von fdcservers.net in Richtung Telekom führt immer noch über cogent.

Das LG https://as62240.net/tools lädt bei mir schon selbst absolut schnarchlangsam und spuckt nach noch längerem Warten (aber Seite vollständig geladen) keine Messergebnisse aus (Textfeld bleibt leer).

bei cloudflare / demolandia erreiche ich volle Geschwindigkeit, da gibt es nur 100ms ping weils über nyc/us läuft. Den Rückweg hab ich nicht zum laufen bekommen.

Alles innerhalb der einer Viertelstunde gemessen.

Bei diesen Ergebnissen scheint das Problem klar: die Verbindung Telekom - Cogent bremst weiterhin alles aus.

Ueber einen O2 VDSL2 Link (L3-BSA ueber Telekom Vorleistung)

user@123-1234567 ~ % wget -c -O /dev/null https://lg-fra.fdcservers.net/1GBtest.zip --report-speed=bits
--2025-01-19 15:31:19--  https://lg-fra.fdcservers.net/1GBtest.zip
Resolving lg-fra.fdcservers.net (lg-fra.fdcservers.net)... 2001:49f0:d085::4, 50.7.50.9
Connecting to lg-fra.fdcservers.net (lg-fra.fdcservers.net)|2001:49f0:d085::4|:443... failed: No route to host.
Connecting to lg-fra.fdcservers.net (lg-fra.fdcservers.net)|50.7.50.9|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1,0G) [application/zip]
Saving to: ‘/dev/null’

/dev/null                                                 100%[=====================================================================================================================================>]   1,00G  87,9Mb/s    in 97s     

2025-01-19 15:33:15 (88,9 Mb/s) - ‘/dev/null’ saved [1073741824/1073741824]

Hier der Vorwaertsweg:

user@123-1234567 ~ % sudo mtr -ezb4w -c 100 lg-fra.fdcservers.net
Start: 2025-01-19T15:34:01+0100
HOST: 123-1234567.local                                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    192.168.42.1                                                         0.0%   100    0.7   0.8   0.5   1.8   0.2
  2. AS6805   loopback1.0004.acln.06.ham.de.net.telefonica.de (62.52.201.201)      0.0%   100   11.3  18.0   9.9 101.4  15.0
  3. AS6805   bundle-ether11.0001.dbrx.06.ham.de.net.telefonica.de (62.53.7.108)   0.0%   100   12.1  11.3  10.1  22.6   1.4
  4. AS6805   ae6-0.0001.corx.06.ham.de.net.telefonica.de (62.53.14.250)           0.0%   100   17.8  18.3  16.5  33.2   2.3
       [MPLS: Lbl 16830 TC 0 S u TTL 1]
  5. AS6805   ae6-0.0002.corx.02.fra.de.net.telefonica.de (62.53.0.49)             0.0%   100   18.0  18.9  16.9  35.2   3.0
       [MPLS: Lbl 16830 TC 0 S u TTL 1]
  6. AS6805   bundle-ether3.0002.cord.02.fra.de.net.telefonica.de (62.53.14.183)   0.0%   100   18.6  18.6  16.9  30.6   1.5
       [MPLS: Lbl 16830 TC 0 S u TTL 1]
  7. AS6805   bundle-ether2.0001.corp.02.fra.de.net.telefonica.de (62.53.8.189)    0.0%   100   18.5  18.6  17.5  40.2   2.2
  8. AS12956  176.52.252.28                                                        5.0%   100   17.5  17.9  16.8  21.7   0.7
  9. AS12956  94.142.107.201                                                       0.0%   100   17.4  18.4  16.9  43.3   2.6
 10. AS6453   if-ae-25-2.tcore2.fr0-frankfurt.as6453.net (80.231.65.20)            0.0%   100   17.6  18.8  17.5  34.7   2.3
       [MPLS: Lbl 79218 TC 0 S u TTL 1]
 11. AS6453   if-be-60-2.ecore1.f2c-frankfurt.as6453.net (80.231.27.2)             0.0%   100   28.7  19.3  17.9  42.7   2.9
       [MPLS: Lbl 24019 TC 0 S u TTL 1]
 12. AS30058  50.7.50.9                                                            0.0%   100   18.6  18.1  16.9  24.9   0.8

Und der Rueckweg:

traceroute to 95.116.19.235 (95.116.19.235), 30 hops max, 60 byte packets
 1  _gateway (50.7.50.1)  0.729 ms * *
 2  * * *
 3  be7948.ccr42.fra05.atlas.cogentco.com (154.54.72.126)  1.102 ms be5484.ccr41.fra05.atlas.cogentco.com (130.117.1.1)  0.971 ms be7948.ccr42.fra05.atlas.cogentco.com (154.54.72.126)  1.263 ms
 4  be3763.agr31.fra05.atlas.cogentco.com (154.54.76.210)  1.324 ms be5970.agr31.fra05.atlas.cogentco.com (154.54.59.53)  1.376 ms be3763.agr31.fra05.atlas.cogentco.com (154.54.76.210)  1.254 ms
 5  telefonica.fra03.atlas.cogentco.com (130.117.14.118)  1.239 ms  0.814 ms  0.785 ms
 6  176.52.252.35 (176.52.252.35)  1.762 ms  1.947 ms 5.53.1.65 (5.53.1.65)  0.881 ms
 7  bundle-ether9.0001.cord.01.off.de.net.telefonica.de (62.53.12.52)  8.620 ms bundle-ether33.0002.cord.02.fra.de.net.telefonica.de (62.53.9.52)  8.340 ms bundle-ether6.0001.cord.01.off.de.net.telefonica.de (62.53.28.170)  8.515 ms
 8  ae100-0.0002.corx.02.fra.de.net.telefonica.de (62.53.14.162)  8.045 ms bundle-ether1.0002.corx.01.off.de.net.telefonica.de (62.53.2.150)  9.856 ms bundle-ether4.0002.corx.01.off.de.net.telefonica.de (62.53.28.150)  8.984 ms
 9  ae10-0.0001.corx.06.ham.de.net.telefonica.de (62.53.0.48)  8.202 ms  7.863 ms  8.281 ms
10  bundle-ether1.0002.dbrx.06.ham.de.net.telefonica.de (62.53.15.1)  8.676 ms  9.028 ms  9.012 ms
11  eth-trunk2.0004.acln.06.ham.de.net.telefonica.de (62.53.7.111)  9.052 ms  8.980 ms eth-trunk1.0004.acln.06.ham.de.net.telefonica.de (62.53.7.109)  9.394 ms
12  dynamic-095-116-019-235.95.116.pool.telefonica.de (95.116.19.235)  16.713 ms  18.602 ms  18.577 ms

Auch ueber Cogent... nur halt von Cogent direkt zu Telefonica...

Jetzt moechte ich anmerken, dass Cogent nicht ganz unproblematisch ist als Transitprovider der Unterschied zwischen DTAG und O2 ist jedoch wie Tag und Nacht...

Clouvider in Frankfurt ist gerade auch von O2 aus grottig...

Zitat von pufferueberlauf

Jetzt moechte ich anmerken, dass Cogent nicht ganz unproblematisch ist als Transitprovider

Wie kommst du da drauf ? Wir haben Cogent seit 20 Jahren im Transitmix und gerade in den letzten Jahren positiv überrascht, sowohl von der Qualität der Routen als auch dem Support.