Telekom und Cloudflare: Was ich an meinem Anschluss gesehen habe

Deutsche Telekom und Cloudflare haben am 29. September 2026 angekündigt, ihre Netze direkt miteinander zu verbinden. Die offiziellen Mitteilungen nennen bessere Ende-zu-Ende-Netzqualität und höhere Resilienz als Ziele. Für mich war das Anlass, am eigenen Telekom-Anschluss nachzuschauen, welche Wege zu verschiedenen Cloudflare-Zielen tatsächlich sichtbar werden.

Das Ergebnis ist ein schönes Beispiel dafür, warum man aus einem einzelnen Traceroute nie eine pauschale Aussage ableiten sollte: Einige Ziele wirkten am Morgen des 1. Oktober bereits sehr direkt angebunden, ein anderes Cloudflare-Präfix lief weiterhin über zusätzliche Netze.

Die offizielle Einordnung

Cloudflare und Deutsche Telekom bestätigen jeweils, dass ihre Netzwerke direkt miteinander verbunden werden. Das stützt die Einordnung meiner Messung, ersetzt aber keine Netzbetreiber-Diagnose: Ein Traceroute kann weder eine konkrete BGP-Session noch den physischen Übergabepunkt beweisen.

• Offizielle Mitteilung von Cloudflare
• Offizielle Mitteilung der Deutschen Telekom

Messung vom 1. Oktober 2026, 07:12 Uhr CEST

Ich habe mit drei Probes pro Hop und maximal 15 Hops zu discord.com, cloudflare.com, 1.1.1.1 und drei konkreten Cloudflare-IP-Adressen gemessen. Die nachfolgende Tabelle fasst jeweils die Laufzeit bis zum Ziel zusammen. Es handelt sich um eine Momentaufnahme von einem einzelnen Telekom-Festnetzanschluss.

Ein direkter wirkender Pfad zu 1.1.1.1 und 104.16.x

Bei 1.1.1.1, cloudflare.com und 104.16.124.96 war ab 80.157.131.165 unmittelbar ein Cloudflare-Hop aus dem Bereich 198.41.240.9 beziehungsweise 198.41.240.13 sichtbar. Zwischen diesem Telekom-Hop und Cloudflare erschien kein weiteres fremdes Netz.

Telekom
  ↓
80.157.131.165
  ↓
198.41.240.9 / 198.41.240.13 (Cloudflare)
  ↓
1.1.1.1 oder 104.16.x

Das passt zu einer sehr nahen Übergabe und ist mit der angekündigten direkten Interconnection vereinbar. Mehr lässt sich aus dem Traceroute allein jedoch nicht sicher ableiten.

Ein anderer Pfad zu 162.159.135.232

Zum Cloudflare-Ziel 162.159.135.232, das bei meiner Messung auch für discord.com ausgewählt wurde, sah der Pfad anders aus. Nach Telekom waren unter anderem 4.68.71.113, 171.75.10.x und anschließend 212.162.9.130 beziehungsweise 195.122.183.210 zu sehen. Erst danach folgten Cloudflare-Hops aus 162.158.84.x.

Telekom
  ↓
4.68.71.113
  ↓
171.75.10.x
  ↓
212.162.9.130 / 195.122.183.210
  ↓
162.158.84.x (Cloudflare)
  ↓
162.159.135.232

Warum beides gleichzeitig stimmen kann

Cloudflare betreibt ein globales Anycast-Netz. BGP-Entscheidungen, Zielpräfixe, Standort, Redundanz, Kapazitäten und Routing-Policies können dazu führen, dass unterschiedliche Cloudflare-Adressen zur gleichen Zeit unterschiedliche Übergabepunkte verwenden. Die zweite Route widerlegt die direkte Interconnection also nicht.

Außerdem ist ein Traceroute nur ein Snapshot: Er bildet antwortende Hops für genau diese Probe ab, nicht den vollständigen Hin- und Rückweg. Router können ICMP-Antworten anders priorisieren als normalen Datenverkehr oder sie ganz unterdrücken.

Fazit

Mein aktueller Messstand zeigt drei sehr direkte wirkende Wege zu 1.1.1.1 und zwei 104.16.x-Zielen mit rund 9 ms Laufzeit. Das Discord-Ziel 162.159.135.232 nahm dagegen einen längeren, aber weiterhin schnellen Weg mit rund 13 ms. Gerade dieser Vergleich macht den Beitrag interessant: Direkte Interconnection bedeutet nicht, dass jedes Cloudflare-Präfix augenblicklich dieselbe Route nutzt.

Messstand: 1. Oktober 2026, 07:12 Uhr CEST. Alle Werte stammen aus einem einzelnen Anschluss und sind keine allgemeine Aussage für alle Telekom-Anschlüsse oder Regionen.