Telekom Peering
Welche Cloudflare-Adressbereiche ein Anschluss der Deutschen Telekom erreicht, alle fünf Minuten gemessen, mit Kontrollzielen außerhalb von Cloudflare und dem Übergabepunkt je Bereich.
Kein Ziel überschreitet die Schwellen für Paketverlust oder Verbindungsaufbau.
Beide Linien laufen über denselben Anschluss. Läuft die blaue am Boden, während die rote ausschlägt, liegt es nicht am Anschluss.
| Tag | Zeitraum | Dauer | Spitze | Betroffene Bereiche |
|---|---|---|---|---|
| 14.09.26 | 21:40–21:50 | 14 Min | 20% | 3 |
| 13.09.26 | 18:50–23:20 | 274 Min | 90% | 6 |
| Bereich | Erreicht über | Übergabe | Verlust | Aufbau | Status | |
|---|---|---|---|---|---|---|
| 172.64.80.0/20 | Telekom (AS3320) | Amsterdam, NL | 0% | 38ms | ok | |
| 188.114.96.0/20CORE, Handle, The Free Dictionary +4 | Telekom (AS3320) | Amsterdam, NL | 0% | 37ms | ok | |
| 104.25.16.0/20freenode | Telekom (AS3320) | Amsterdam, NL | 0% | 34ms | ok | |
| 172.67.64.0/20DOI, PLOS, ScienceDaily | Telekom (AS3320) | Amsterdam, NL | 0% | 32ms | ok | |
| 188.114.99.0/24 | Telekom (AS3320) | Amsterdam, NL | 0% | 32ms | ok |
Die Telekom trägt diesen Verkehr nach Netherlands, bevor sie ihn abgibt
Der letzte Router vor dem Transit-Anbieter gehört noch zu AS3320, also zum Netz der Telekom selbst. Der Umweg beginnt damit innerhalb ihres Netzes, nicht außerhalb.
Das ist der entscheidende Punkt, denn solche Beschwerden werden üblicherweise mit dem Hinweis beantwortet, die Störung liege außerhalb des Telekom-Netzes. Telekom und Cloudflare sind beide an den Knoten in Frankfurt & Berlin vertreten, und die dort übergebenen Bereiche kamen auf höchstens 20 % Verlust, gegenüber 20 % auf dem Weg über Netherlands.
11 weitere Cloudflare-Bereiche, alle unauffällig
| Bereich | Erreicht über | Übergabe | Verlust | Aufbau | Status | |
|---|---|---|---|---|---|---|
| 103.31.4.0/24 | Lumen (AS3356) | Berlin, DE | 0% | 102ms | ok | |
| 104.26.0.0/20DOI, PLOS, ScienceDaily | Telekom (AS3320) | Frankfurt, DE | 0% | 34ms | ok | |
| 198.41.208.0/23 | Lumen (AS3356) | Berlin, DE | 0% | 18ms | ok | |
| 173.245.58.0/24 | Lumen (AS3356) | Berlin, DE | 0% | 18ms | ok | |
| 141.101.90.0/24EPO, Espacenet, Brevo +2 | Lumen (AS3356) | Berlin, DE | 0% | 17ms | ok | |
| 190.93.244.0/22 | Lumen (AS3356) | Berlin, DE | 0% | 17ms | ok | |
| 104.16.240.0/20Read the Docs, Algolia, GoCardless +3 | Lumen (AS3356) | Berlin, DE | 0% | 17ms | ok | |
| 104.16.0.0/13ResearchGate, Creative Commons, W3C +34 | Lumen (AS3356) | Berlin, DE | 0% | 17ms | ok | |
| 1.1.1.0/24Cloudflare DNS | Lumen (AS3356) | Berlin, DE | 0% | 16ms | ok | |
| 162.159.128.0/19Vimeo, Medium, PayPal +8 | Lumen (AS3356) | Berlin, DE | 0% | 16ms | ok | |
| 108.162.195.0/24 | Lumen (AS3356) | Berlin, DE | 0% | 16ms | ok |
| Bereich | Betreiber | Übergabe | Verlust | Aufbau | Status | |
|---|---|---|---|---|---|---|
| 212.27.32.0/19 | Free (AS12322) | 0% | 27ms | ok | ||
| 198.27.92.0/24 | OVH (AS16276) | 0% | 26ms | ok | ||
| 152.53.184.0/22 | netcup (AS197540) | 0% | 23ms | ok | ||
| 140.82.121.0/24 | GitHub (AS36459) | 0% | 21ms | ok | ||
| 213.133.96.0/19 | Hetzner (AS24940) | 0% | 21ms | ok | ||
| 8.8.8.0/24 | Google (AS15169) | 0% | 16ms | ok |
Kennzahlen je Ziel
| Bereich | Ø Verlust | Max Verlust | Ø Aufbau | Max Aufbau | Auffällige Läufe |
|---|---|---|---|---|---|
| 103.31.4.0/24 | 0% | 20% | 107ms | 164ms | 1 / 288 |
| 172.64.80.0/20 | 0% | 20% | 50ms | 538ms | 2 / 288 |
| 188.114.96.0/20 | 2% | 20% | 43ms | 119ms | 1 / 288 |
| 104.25.16.0/20 | 0% | 20% | 43ms | 73ms | 1 / 288 |
| 104.26.0.0/20 | 0% | 20% | 43ms | 242ms | 1 / 288 |
| 172.67.64.0/20 | 0% | 20% | 42ms | 71ms | 1 / 288 |
| 188.114.99.0/24 | 2% | 20% | 43ms | 317ms | 9 / 288 |
| 212.27.32.0/19 | 0% | 20% | 41ms | 74ms | 1 / 288 |
| 198.27.92.0/24 | 0% | 20% | 39ms | 73ms | 1 / 288 |
| 152.53.184.0/22 | 0% | 20% | 36ms | 70ms | 1 / 288 |
| 140.82.121.0/24 | 0% | 20% | 35ms | 66ms | 1 / 288 |
| 213.133.96.0/19 | 0% | 15% | 35ms | 70ms | 1 / 288 |
| 198.41.208.0/23 | 0% | 20% | 36ms | 356ms | 2 / 288 |
| 173.245.58.0/24 | 0% | 20% | 36ms | 352ms | 1 / 288 |
| 141.101.90.0/24 | 0% | 20% | 35ms | 343ms | 1 / 288 |
| 190.93.244.0/22 | 0% | 20% | 35ms | 146ms | 1 / 288 |
| 104.16.240.0/20 | 0% | 20% | 35ms | 552ms | 2 / 288 |
| 104.16.0.0/13 | 0% | 20% | 35ms | 345ms | 1 / 288 |
| 1.1.1.0/24 | 0% | 20% | 34ms | 354ms | 1 / 288 |
| 162.159.128.0/19 | 0% | 20% | 35ms | 733ms | 2 / 288 |
| 108.162.195.0/24 | 0% | 20% | 34ms | 163ms | 1 / 288 |
| 8.8.8.0/24 | 0% | 20% | 28ms | 59ms | 1 / 288 |
Warum es diese Seite gibt
Zwischen der Telekom und Cloudflare bestehen seit Jahren wiederkehrende Engpässe. Die Telekom unterhält praktisch kein direktes Peering mit Cloudflare und erreicht einen Teil der Adressbereiche über Transit-Anbieter wie GTT und Lumen. Sind diese Strecken zur Hauptzeit ausgelastet, verlieren Telekom-Anschlüsse Pakete zu einzelnen Cloudflare-Bereichen, während der Rest des Netzes völlig unauffällig bleibt.
Für Betroffene sieht das nach einer Störung des jeweiligen Dienstes aus, und es trifft immer nur einen Teil der Nutzer. Wer bei einem anderen Anbieter ist oder zufällig in einem anderen Adressbereich landet, merkt nichts. Diese Seite zeigt, welcher Bereich gerade betroffen ist und welcher nicht.
Wofür die Seite gilt
Gemessen wird von einem einzelnen Anschluss der Deutschen Telekom in Deutschland. Für Anschlüsse anderer Anbieter sagt die Seite nichts aus. Cloudflare verteilt Kunden über mehrere Adressbereiche, deshalb kann ein Dienst betroffen sein und ein anderer auf derselben Leitung einwandfrei laufen.