Fehlrouting AS3320 → Cloudflare (AS13335): 50–65 % Paketverlust zu 104.26.0.0/15 und 172.67.0.0/16, während 104.21.0.0/16 sauber läuft
vor 25 Tagen
Kurzfassung
Von meinem Telekom-Anschluss (öffentliche IP 91.42.255.xx AS3320) — und nach unseren
Rückmeldungen von vielen Telekom-Anschlüssen in der Region Lahn-Dill-Kreis (LDK) — tritt seit
19.08.2026 massiver Paketverlust (50–65 %) zu bestimmten Cloudflare-IP-Bereichen auf.
Betroffen sind unsere produktiven Webseiten (u. a. portal.revierwelt.de), die dadurch
zeitweise nicht erreichbar sind. Nutzer in anderen Regionen / bei anderen Providern (anderes
Routing) sind nicht betroffen — das Problem ist an das Telekom-Routing in dieser Region gebunden.
Die Analyse zeigt eindeutig: **Das Telekom-Netz teilt den Weg zu Cloudflare abhängig vom
Ziel-Prefix bereits im eigenen Netz auf** (ab dem Telekom-Hop 217.239.x). Ein Cloudflare-
Bereich wird sauber über Telia/Arelion (AS1299) geroutet, der andere über einen überlasteten
Transit-Pfad mit hohem Paketverlust. Beide Ziele liegen im selben Cloudflare-Netz (AS13335).
Bitte: Routing/ Peering von AS3320 zu den Cloudflare-Prefixen 104.26.0.0/15 und
172.67.0.0/16 prüfen und auf einen nicht überlasteten Pfad (wie er für 104.21.0.0/16 bereits
genutzt wird) korrigieren.
Messdaten (Quelle: 91.42.255.xx / AS3320, 19.08.2026)
Paketverlust (ICMP, 30 Pakete je Ziel):
| Ziel-IP | Cloudflare-Prefix | Verlust |
|---|---|---|
| 104.26.2.79 | 104.26.0.0/15 | 57 % (17/30) |
| 104.26.3.79 | 104.26.0.0/15 | 57 % (17/30) |
| 172.67.75.96 | 172.67.0.0/16 | 63 % (19/30) |
| 104.21.47.175 (Vergleich) | 104.21.0.0/16 | 0 % (0/30) |
Alle vier Ziele gehören zu Cloudflare (AS13335), gemessen vom selben Anschluss zur selben Zeit.
Traceroute — betroffen (104.26.2.79): Weg zweigt bei der Telekom ab und läuft über einen
überlasteten Transit; Verlust ab dem Cloudflare-Eingang.
3 62.155.246.130 (Telekom)
4 217.239.51.134 (Telekom) <-- hier zweigt der Weg ab
5 46.33.81.53
6 141.136.108.226
7 154.14.163.19 (Transit Richtung Cloudflare, erhöhte/schwankende Latenz)
8 141.101.67.142 (Cloudflare) <-- Paketverlust beginnt an diesem Übergang (40 %)
10 104.26.2.79 (Cloudflare) <-- kumuliert 65 % Verlust am ZielTraceroute — sauber (104.21.47.175): anderer Telekom-Ausgang, über Telia (AS1299), 0 % Verlust.
3 62.155.246.130 (Telekom)
4 217.239.58.37 (Telekom) <-- andere Telekom-Route als oben
5 62.115.50.18 (Telia/Arelion, AS1299)
6 62.115.151.125 (Telia/Arelion, AS1299)
7 141.101.71.97 (Cloudflare) <-- sauberer Eingang, 0 % Verlust
8 104.21.47.175 (Cloudflare)pathping (Verlust-Statistik über Zeit) bestätigt: am Link 154.14.163.19 → 141.101.67.142
beginnt der Verlust (40 %) und steigt zum Ziel auf 65 %. Der Vergleichs-Pfad zu 104.21.x ist über
alle Hops verlustfrei. (Vollständige pathping-/Traceroute-Protokolle liegen bei.)
Was Cloudflare dazu sagt
Cloudflare (Ticket 02288346) hat sein eigenes Netz geprüft und als gesund bestätigt. Der Verlust
beginne vor dem ersten Cloudflare-eigenen Router, an der Transit-Strecke Richtung Cloudflare —
also im Verantwortungsbereich der Telekom bzw. ihres Transit-Partners. Cloudflare bittet ausdrücklich
darum, dies mit der Telekom zu klären.
Konkrete Bitte an die Telekom
- Warum routet AS3320 die Cloudflare-Prefixe 104.26.0.0/15 und 172.67.0.0/16 über den
verlustbehafteten Pfad (217.239.51.x → 46.33.81.53 → 141.136.108.226 → 154.14.163.19),
während 104.21.0.0/16 sauber über Telia (AS1299) läuft?
- Bitte den überlasteten Übergang zu Cloudflare (AS13335) für diese Prefixe entlasten bzw. den
Verkehr auf den funktionierenden Pfad (Telia) umlegen.
- Rückmeldung, sobald das Routing angepasst wurde — ich verifiziere den Verlust dann erneut.
Messprotokolle-Paketverlust-revierwelt-2026-08-19.pdf
186
0
13
Das könnte Ihnen auch weiterhelfen
61
0
14
in
5
0
0
in
7
1
0
vor 4 Stunden
in
106
0
12
in
14
0
1
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 25 Tagen
verlustbehafteten Pfad (
217.239.51.x → 46.33.81.53 → 141.136.108.226 → 154.14.163.19),während 104.21.0.0/16 sauber über Telia (AS1299) läuft?
Kurzfassung
Von meinem Telekom-Anschluss (öffentliche IP 91.42.255.xx AS3320) — und nach unseren
Rückmeldungen von vielen Telekom-Anschlüssen in der Region Lahn-Dill-Kreis (LDK) — tritt seit
19.08.2026 massiver Paketverlust (50–65 %) zu bestimmten Cloudflare-IP-Bereichen auf.
Betroffen sind unsere produktiven Webseiten (u. a. portal.revierwelt.de), die dadurch
zeitweise nicht erreichbar sind. Nutzer in anderen Regionen / bei anderen Providern (anderes
Routing) sind nicht betroffen — das Problem ist an das Telekom-Routing in dieser Region gebunden.
Die Analyse zeigt eindeutig: **Das Telekom-Netz teilt den Weg zu Cloudflare abhängig vom
Ziel-Prefix bereits im eigenen Netz auf** (ab dem Telekom-Hop
217.239.x). Ein Cloudflare-Bereich wird sauber über Telia/Arelion (AS1299) geroutet, der andere über einen überlasteten
Transit-Pfad mit hohem Paketverlust. Beide Ziele liegen im selben Cloudflare-Netz (AS13335).
Bitte: Routing/ Peering von AS3320 zu den Cloudflare-Prefixen 104.26.0.0/15 und
172.67.0.0/16 prüfen und auf einen nicht überlasteten Pfad (wie er für 104.21.0.0/16 bereits
genutzt wird) korrigieren.
Messdaten (Quelle: 91.42.255.xx / AS3320, 19.08.2026)
Paketverlust (ICMP, 30 Pakete je Ziel):
Alle vier Ziele gehören zu Cloudflare (AS13335), gemessen vom selben Anschluss zur selben Zeit.
Traceroute — betroffen (104.26.2.79): Weg zweigt bei der Telekom ab und läuft über einen
überlasteten Transit; Verlust ab dem Cloudflare-Eingang.
Traceroute — sauber (104.21.47.175): anderer Telekom-Ausgang, über Telia (AS1299), 0 % Verlust.
pathping (Verlust-Statistik über Zeit) bestätigt: am Link
154.14.163.19 → 141.101.67.142beginnt der Verlust (40 %) und steigt zum Ziel auf 65 %. Der Vergleichs-Pfad zu 104.21.x ist über
alle Hops verlustfrei. (Vollständige pathping-/Traceroute-Protokolle liegen bei.)
Was Cloudflare dazu sagt
Cloudflare (Ticket 02288346) hat sein eigenes Netz geprüft und als gesund bestätigt. Der Verlust
beginne vor dem ersten Cloudflare-eigenen Router, an der Transit-Strecke Richtung Cloudflare —
also im Verantwortungsbereich der Telekom bzw. ihres Transit-Partners. Cloudflare bittet ausdrücklich
darum, dies mit der Telekom zu klären.
Konkrete Bitte an die Telekom
verlustbehafteten Pfad (
217.239.51.x → 46.33.81.53 → 141.136.108.226 → 154.14.163.19),während 104.21.0.0/16 sauber über Telia (AS1299) läuft?
Verkehr auf den funktionierenden Pfad (Telia) umlegen.
Weil die Routen so von Cloudflare propagiert werden? Ja!
Und das wird "betriebswirtschaftlich" gerne mal "optimiert". Wenn ihre Kunden aber genug bezahlen, dann lösen sich die Probleme schnell in Nichts auf.
Was Cloudflare dazu sagt
Cloudflare (Ticket 02288346) hat sein eigenes Netz geprüft und als gesund bestätigt. Der Verlust
beginne vor dem ersten Cloudflare-eigenen Router, an der Transit-Strecke Richtung Cloudflare —
also im Verantwortungsbereich der Telekom bzw. ihres Transit-Partners. Cloudflare bittet ausdrücklich
darum, dies mit der Telekom zu klären.
Kurzfassung
Von meinem Telekom-Anschluss (öffentliche IP 91.42.255.xx AS3320) — und nach unseren
Rückmeldungen von vielen Telekom-Anschlüssen in der Region Lahn-Dill-Kreis (LDK) — tritt seit
19.08.2026 massiver Paketverlust (50–65 %) zu bestimmten Cloudflare-IP-Bereichen auf.
Betroffen sind unsere produktiven Webseiten (u. a. portal.revierwelt.de), die dadurch
zeitweise nicht erreichbar sind. Nutzer in anderen Regionen / bei anderen Providern (anderes
Routing) sind nicht betroffen — das Problem ist an das Telekom-Routing in dieser Region gebunden.
Die Analyse zeigt eindeutig: **Das Telekom-Netz teilt den Weg zu Cloudflare abhängig vom
Ziel-Prefix bereits im eigenen Netz auf** (ab dem Telekom-Hop
217.239.x). Ein Cloudflare-Bereich wird sauber über Telia/Arelion (AS1299) geroutet, der andere über einen überlasteten
Transit-Pfad mit hohem Paketverlust. Beide Ziele liegen im selben Cloudflare-Netz (AS13335).
Bitte: Routing/ Peering von AS3320 zu den Cloudflare-Prefixen 104.26.0.0/15 und
172.67.0.0/16 prüfen und auf einen nicht überlasteten Pfad (wie er für 104.21.0.0/16 bereits
genutzt wird) korrigieren.
Messdaten (Quelle: 91.42.255.xx / AS3320, 19.08.2026)
Paketverlust (ICMP, 30 Pakete je Ziel):
Alle vier Ziele gehören zu Cloudflare (AS13335), gemessen vom selben Anschluss zur selben Zeit.
Traceroute — betroffen (104.26.2.79): Weg zweigt bei der Telekom ab und läuft über einen
überlasteten Transit; Verlust ab dem Cloudflare-Eingang.
Traceroute — sauber (104.21.47.175): anderer Telekom-Ausgang, über Telia (AS1299), 0 % Verlust.
pathping (Verlust-Statistik über Zeit) bestätigt: am Link
154.14.163.19 → 141.101.67.142beginnt der Verlust (40 %) und steigt zum Ziel auf 65 %. Der Vergleichs-Pfad zu 104.21.x ist über
alle Hops verlustfrei. (Vollständige pathping-/Traceroute-Protokolle liegen bei.)
Was Cloudflare dazu sagt
Cloudflare (Ticket 02288346) hat sein eigenes Netz geprüft und als gesund bestätigt. Der Verlust
beginne vor dem ersten Cloudflare-eigenen Router, an der Transit-Strecke Richtung Cloudflare —
also im Verantwortungsbereich der Telekom bzw. ihres Transit-Partners. Cloudflare bittet ausdrücklich
darum, dies mit der Telekom zu klären.
Konkrete Bitte an die Telekom
verlustbehafteten Pfad (
217.239.51.x → 46.33.81.53 → 141.136.108.226 → 154.14.163.19),während 104.21.0.0/16 sauber über Telia (AS1299) läuft?
Verkehr auf den funktionierenden Pfad (Telia) umlegen.
Was sollen sie auch anderes sagen, sie sind ja"nie" die Schuldigen.
0
3
von
vor 25 Tagen
Was sollen sie auch anderes sagen, sie sind ja"nie" die Schuldigen.
verlustbehafteten Pfad (
217.239.51.x → 46.33.81.53 → 141.136.108.226 → 154.14.163.19),während 104.21.0.0/16 sauber über Telia (AS1299) läuft?
Kurzfassung
Von meinem Telekom-Anschluss (öffentliche IP 91.42.255.xx AS3320) — und nach unseren
Rückmeldungen von vielen Telekom-Anschlüssen in der Region Lahn-Dill-Kreis (LDK) — tritt seit
19.08.2026 massiver Paketverlust (50–65 %) zu bestimmten Cloudflare-IP-Bereichen auf.
Betroffen sind unsere produktiven Webseiten (u. a. portal.revierwelt.de), die dadurch
zeitweise nicht erreichbar sind. Nutzer in anderen Regionen / bei anderen Providern (anderes
Routing) sind nicht betroffen — das Problem ist an das Telekom-Routing in dieser Region gebunden.
Die Analyse zeigt eindeutig: **Das Telekom-Netz teilt den Weg zu Cloudflare abhängig vom
Ziel-Prefix bereits im eigenen Netz auf** (ab dem Telekom-Hop
217.239.x). Ein Cloudflare-Bereich wird sauber über Telia/Arelion (AS1299) geroutet, der andere über einen überlasteten
Transit-Pfad mit hohem Paketverlust. Beide Ziele liegen im selben Cloudflare-Netz (AS13335).
Bitte: Routing/ Peering von AS3320 zu den Cloudflare-Prefixen 104.26.0.0/15 und
172.67.0.0/16 prüfen und auf einen nicht überlasteten Pfad (wie er für 104.21.0.0/16 bereits
genutzt wird) korrigieren.
Messdaten (Quelle: 91.42.255.xx / AS3320, 19.08.2026)
Paketverlust (ICMP, 30 Pakete je Ziel):
Alle vier Ziele gehören zu Cloudflare (AS13335), gemessen vom selben Anschluss zur selben Zeit.
Traceroute — betroffen (104.26.2.79): Weg zweigt bei der Telekom ab und läuft über einen
überlasteten Transit; Verlust ab dem Cloudflare-Eingang.
Traceroute — sauber (104.21.47.175): anderer Telekom-Ausgang, über Telia (AS1299), 0 % Verlust.
pathping (Verlust-Statistik über Zeit) bestätigt: am Link
154.14.163.19 → 141.101.67.142beginnt der Verlust (40 %) und steigt zum Ziel auf 65 %. Der Vergleichs-Pfad zu 104.21.x ist über
alle Hops verlustfrei. (Vollständige pathping-/Traceroute-Protokolle liegen bei.)
Was Cloudflare dazu sagt
Cloudflare (Ticket 02288346) hat sein eigenes Netz geprüft und als gesund bestätigt. Der Verlust
beginne vor dem ersten Cloudflare-eigenen Router, an der Transit-Strecke Richtung Cloudflare —
also im Verantwortungsbereich der Telekom bzw. ihres Transit-Partners. Cloudflare bittet ausdrücklich
darum, dies mit der Telekom zu klären.
Konkrete Bitte an die Telekom
verlustbehafteten Pfad (
217.239.51.x → 46.33.81.53 → 141.136.108.226 → 154.14.163.19),während 104.21.0.0/16 sauber über Telia (AS1299) läuft?
Verkehr auf den funktionierenden Pfad (Telia) umlegen.
Weil die Routen so von Cloudflare propagiert werden? Ja!
Und das wird "betriebswirtschaftlich" gerne mal "optimiert". Wenn ihre Kunden aber genug bezahlen, dann lösen sich die Probleme schnell in Nichts auf.
Was Cloudflare dazu sagt
Cloudflare (Ticket 02288346) hat sein eigenes Netz geprüft und als gesund bestätigt. Der Verlust
beginne vor dem ersten Cloudflare-eigenen Router, an der Transit-Strecke Richtung Cloudflare —
also im Verantwortungsbereich der Telekom bzw. ihres Transit-Partners. Cloudflare bittet ausdrücklich
darum, dies mit der Telekom zu klären.
Kurzfassung
Von meinem Telekom-Anschluss (öffentliche IP 91.42.255.xx AS3320) — und nach unseren
Rückmeldungen von vielen Telekom-Anschlüssen in der Region Lahn-Dill-Kreis (LDK) — tritt seit
19.08.2026 massiver Paketverlust (50–65 %) zu bestimmten Cloudflare-IP-Bereichen auf.
Betroffen sind unsere produktiven Webseiten (u. a. portal.revierwelt.de), die dadurch
zeitweise nicht erreichbar sind. Nutzer in anderen Regionen / bei anderen Providern (anderes
Routing) sind nicht betroffen — das Problem ist an das Telekom-Routing in dieser Region gebunden.
Die Analyse zeigt eindeutig: **Das Telekom-Netz teilt den Weg zu Cloudflare abhängig vom
Ziel-Prefix bereits im eigenen Netz auf** (ab dem Telekom-Hop
217.239.x). Ein Cloudflare-Bereich wird sauber über Telia/Arelion (AS1299) geroutet, der andere über einen überlasteten
Transit-Pfad mit hohem Paketverlust. Beide Ziele liegen im selben Cloudflare-Netz (AS13335).
Bitte: Routing/ Peering von AS3320 zu den Cloudflare-Prefixen 104.26.0.0/15 und
172.67.0.0/16 prüfen und auf einen nicht überlasteten Pfad (wie er für 104.21.0.0/16 bereits
genutzt wird) korrigieren.
Messdaten (Quelle: 91.42.255.xx / AS3320, 19.08.2026)
Paketverlust (ICMP, 30 Pakete je Ziel):
Alle vier Ziele gehören zu Cloudflare (AS13335), gemessen vom selben Anschluss zur selben Zeit.
Traceroute — betroffen (104.26.2.79): Weg zweigt bei der Telekom ab und läuft über einen
überlasteten Transit; Verlust ab dem Cloudflare-Eingang.
Traceroute — sauber (104.21.47.175): anderer Telekom-Ausgang, über Telia (AS1299), 0 % Verlust.
pathping (Verlust-Statistik über Zeit) bestätigt: am Link
154.14.163.19 → 141.101.67.142beginnt der Verlust (40 %) und steigt zum Ziel auf 65 %. Der Vergleichs-Pfad zu 104.21.x ist über
alle Hops verlustfrei. (Vollständige pathping-/Traceroute-Protokolle liegen bei.)
Was Cloudflare dazu sagt
Cloudflare (Ticket 02288346) hat sein eigenes Netz geprüft und als gesund bestätigt. Der Verlust
beginne vor dem ersten Cloudflare-eigenen Router, an der Transit-Strecke Richtung Cloudflare —
also im Verantwortungsbereich der Telekom bzw. ihres Transit-Partners. Cloudflare bittet ausdrücklich
darum, dies mit der Telekom zu klären.
Konkrete Bitte an die Telekom
verlustbehafteten Pfad (
217.239.51.x → 46.33.81.53 → 141.136.108.226 → 154.14.163.19),während 104.21.0.0/16 sauber über Telia (AS1299) läuft?
Verkehr auf den funktionierenden Pfad (Telia) umlegen.
Was sollen sie auch anderes sagen, sie sind ja"nie" die Schuldigen.
Das dürfte aus verständlichen Gründen tatsächlich so sein. Allerdings folgt daraus nicht, dass die Telekom keinen Mist baut. Vielmehr agiert die Telekom exakt genau so.
0
von
vor 25 Tagen
Danke euch beiden für die Einordnung — der Peering -/kommerzielle Hintergrund ist mir bewusst und durchaus plausibel.
Ein Punkt zur Technik, weil er für die Lösung entscheidend ist: Cloudflare kündigt alle drei Prefixe (104.21.0.0/16, 104.26.0.0/15, 172.67.0.0/16) aus demselben AS13335 an. Welchen der gelernten Wege AS3320 dann tatsächlich nutzt, entscheidet die Best-Path-Auswahl der Telekom — nicht Cloudflare allein. Der Beleg: Zur exakt gleichen Zeit, vom selben Anschluss, läuft 104.21.0.0/16 über Telia (AS1299) mit 0 % Verlust ins selbe Cloudflare-Netz. Ein sauberer Weg zu AS13335 existiert also und wird genutzt — nur nicht für 104.26.0.0/15 und 172.67.0.0/16, die über einen überlasteten Transit gehen.
Mir geht es nicht um Schuldzuweisung, sondern um den konkreten Effekt: In der Region Hessen/Lahn-Dill-Kreis sind produktive Seiten für Telekom-Kunden zeitweise nicht erreichbar, während andere Netze sauber durchkommen. Wo auch immer die Ursache kommerziell verankert ist - die Stellschraube (den überlasteten Übergang entlasten oder die betroffenen Prefixe auf den funktionierenden Pfad legen) liegt in der Routing-Auswahl der Telekom.
Könnte bitte jemand aus dem Team das mit den beigefügten Messdaten an die Netztechnik / das NOC bzw. Peering -Team weitergeben? Ich verifiziere jede Änderung sofort per erneuter Messung und melde das Ergebnis hier zurück.
@mboettcher: genau so sehe ich es auch - an der Stellschraube können ggf. beide Seiten drehen, aber der akute Impact für die Kunden vor Ort ist real und messbar.
von
vor 25 Tagen
Die Tatsache, dass 104.21.0.0/16 sauber über Telia (AS1299) läuft, während 104.26.0.0/15 und 172.67.0.0/16 auf überlasteten Pfaden landen, deutet stark auf das BGP-Traffic-Engineering von Cloudflare hin.
Cloudflare steuert seine Anycast-Prefixe hochgradig granular über AS-Path Prepending und selective BGP Announcements.
Heißt:
Cloudflare macht Telia für bestimmte Blöcke künstlich unattraktiv, so dass die Telekom in ihrer Routing-Tabelle gar keine andere Wahl hat, als auf den nächstbesten (ggf. überlasteten) Transit auszuweichen.
Paketverluste im Downstream entstehen fast immer auf dem Rückweg (Cloudflare -> Endkunde) – und diesen Weg bestimmt nur Cloudflare in den eigenen Routern. Cloudflare entscheidet hier bewusst, über welche Transit-Schnittstellen welcher IP-Block geschoben wird, um die eigene Edge-Last zu balancieren.
Uneingeloggter Nutzer
von
vor 25 Tagen
bzw. ihres Transit-Partners
Kurzfassung
Von meinem Telekom-Anschluss (öffentliche IP 91.42.255.xx AS3320) — und nach unseren
Rückmeldungen von vielen Telekom-Anschlüssen in der Region Lahn-Dill-Kreis (LDK) — tritt seit
19.08.2026 massiver Paketverlust (50–65 %) zu bestimmten Cloudflare-IP-Bereichen auf.
Betroffen sind unsere produktiven Webseiten (u. a. portal.revierwelt.de), die dadurch
zeitweise nicht erreichbar sind. Nutzer in anderen Regionen / bei anderen Providern (anderes
Routing) sind nicht betroffen — das Problem ist an das Telekom-Routing in dieser Region gebunden.
Die Analyse zeigt eindeutig: **Das Telekom-Netz teilt den Weg zu Cloudflare abhängig vom
Ziel-Prefix bereits im eigenen Netz auf** (ab dem Telekom-Hop
217.239.x). Ein Cloudflare-Bereich wird sauber über Telia/Arelion (AS1299) geroutet, der andere über einen überlasteten
Transit-Pfad mit hohem Paketverlust. Beide Ziele liegen im selben Cloudflare-Netz (AS13335).
Bitte: Routing/ Peering von AS3320 zu den Cloudflare-Prefixen 104.26.0.0/15 und
172.67.0.0/16 prüfen und auf einen nicht überlasteten Pfad (wie er für 104.21.0.0/16 bereits
genutzt wird) korrigieren.
Messdaten (Quelle: 91.42.255.xx / AS3320, 19.08.2026)
Paketverlust (ICMP, 30 Pakete je Ziel):
Alle vier Ziele gehören zu Cloudflare (AS13335), gemessen vom selben Anschluss zur selben Zeit.
Traceroute — betroffen (104.26.2.79): Weg zweigt bei der Telekom ab und läuft über einen
überlasteten Transit; Verlust ab dem Cloudflare-Eingang.
Traceroute — sauber (104.21.47.175): anderer Telekom-Ausgang, über Telia (AS1299), 0 % Verlust.
pathping (Verlust-Statistik über Zeit) bestätigt: am Link
154.14.163.19 → 141.101.67.142beginnt der Verlust (40 %) und steigt zum Ziel auf 65 %. Der Vergleichs-Pfad zu 104.21.x ist über
alle Hops verlustfrei. (Vollständige pathping-/Traceroute-Protokolle liegen bei.)
Was Cloudflare dazu sagt
Cloudflare (Ticket 02288346) hat sein eigenes Netz geprüft und als gesund bestätigt. Der Verlust
beginne vor dem ersten Cloudflare-eigenen Router, an der Transit-Strecke Richtung Cloudflare —
also im Verantwortungsbereich der Telekom bzw. ihres Transit-Partners. Cloudflare bittet ausdrücklich
darum, dies mit der Telekom zu klären.
Konkrete Bitte an die Telekom
verlustbehafteten Pfad (
217.239.51.x → 46.33.81.53 → 141.136.108.226 → 154.14.163.19),während 104.21.0.0/16 sauber über Telia (AS1299) läuft?
Verkehr auf den funktionierenden Pfad (Telia) umlegen.
Ha xD Der Witz kam tief.
Cloudflare hat den sich ausgesucht!
Cloudflare bestimmt das Peering !
0
0
vor 24 Tagen
Zusammenfassung nach mehreren Tagen Analyse und einem Ticket-Austausch mit Cloudflare: Der Entscheidungspunkt für dieses Fehlrouting liegt nachweislich im Telekom-Netz. Cloudflare hat schriftlich bestätigt, dass es auf ihrer Seite nichts zu ändern gibt. Wir gehen daher davon aus, dass das Problem ohne eine Anpassung bei der Telekom nicht behoben wird.
Nachfolgend alle Fakten gebündelt.
1. Das Symptom
Von Telekom-Anschlüssen im Raum Hessen / Lahn-Dill-Kreis tritt zeitweise 50–65 % Paketverlust zu bestimmten Cloudflare-IP-Bereichen auf. Betroffene Seiten (u. a. portal.revierwelt.de) sind dann praktisch nicht erreichbar. Nutzer in anderen Regionen oder bei anderen Providern sind nicht betroffen. WARP/ VPN behebt es sofort (0 % Verlust), weil der Verkehr dann an der Telekom-Route vorbeigeht.
2. Messdaten (vom selben Anschluss, zur selben Zeit)
Paketverlust (ICMP, 30 Pakete je Ziel):
Alle vier Ziele gehören zum selben Cloudflare-Netz (AS13335).
Traceroute — betroffen (104.26.2.79): der Weg zweigt bei der Telekom ab und läuft über einen überlasteten Transit (Cogent):
Traceroute — sauber (104.21.47.175): anderer Telekom-Ausgang, über Telia/Arelion (AS1299), 0 % Verlust:
pathping bestätigt: am Link
154.14.163.19 → 141.101.67.142
beginnt der Verlust (40 %) und steigt zum Ziel auf 65 %. Der Vergleichspfad zu 104.21.x ist über alle Hops verlustfrei.
Der entscheidende Punkt: Der Weg der betroffenen Prefixe teilt sich schon innerhalb des Telekom-Netzes (Hop 217.239.x) vom sauberen Weg ab — bevor ein Cloudflare-Router erreicht wird. Die Best-Path-Auswahl an dieser Stelle trifft AS3320.
3. Das Zeitverhalten (neu)
4. Was Cloudflare offiziell sagt (Support-Ticket 02288346)
Cloudflare hat das eigene Netz geprüft und schriftlich Stellung genommen. Kernaussagen im Original:
„this is not a transit capacity or technical failure on Cloudflare's edge. It's a BGP routing decision. Deutsche Telekom's network independently decides, per destination prefix, which of its own upstream connections to use to reach a given block of Cloudflare IP addresses."
„Cloudflare announces our address space the same way regardless of which specific block a zone is assigned; we don't control, and can't override, which of its own upstream links Deutsche Telekom chooses to carry traffic to a given prefix."
„Deutsche Telekom has adopted a position distinct from almost all other major global ISPs. They have elected to monetise the termination of traffic into their network by demanding network usage fees from content providers. When content networks refuse to pay these arbitrary fees … DTAG refuses to utilise the direct local capacity available. Because DTAG refuses to open the direct local ports in Germany without payment, they force your traffic to detour via third party transit providers."
„there isn't a configuration change, IP reassignment, or peering adjustment on Cloudflare's side that would fix this, because the decision point is inside Deutsche Telekom's network, not ours."
Cloudflare kündigt seinen Adressraum gegenüber AS3320 also einheitlich an — es gibt keine block-spezifische Bevorzugung. Welchen der gelernten Wege AS3320 nutzt, entscheidet die Telekom.
5. Einordnung der Forum-Kommentare (@buenni, @CyberSW)
Der Einwand „das steuert Cloudflare über sein BGP-Traffic-Engineering" ist berechtigt und wurde deshalb bei Cloudflare direkt adressiert — die Antwort steht oben: einheitliche Announcements, die Wegewahl liegt bei AS3320, und die Divergenz ist in unseren Messungen im Telekom-Netz verortet. Unabhängig davon, wie man die kommerzielle Verantwortung bewertet: die technische Stellschraube (welcher Transit für welchen Prefix genutzt wird) liegt in der Routing-Auswahl der Telekom.
6. Das ist kein Einzelfall — es ist dokumentiert und Gegenstand eines Verfahrens
Genau dieses Muster ist Teil einer laufenden Netzneutralitäts-Beschwerde bei der Bundesnetzagentur, eingereicht am 28.04.2025 von VZBV, Gesellschaft für Freiheitsrechte (GFF), epicenter.works und Stanford-Professorin Barbara van Schewick. Die begleitende Initiative netzbremse.de nennt als Beispiel-Impact wörtlich „Cloudflare-hosted services experiencing 50%+ packet loss during peak hours" und „performance restored immediately when using VPN " — das deckt sich 1:1 mit unseren Messungen.
Quellen: netzbremse.de · vzbv.de (Pressemitteilung „Keine Zweiklassengesellschaft im Internet", 28.04.2025) · wotschofsky.com/blog/telekom-cloudflare-routing
7. Schlussfolgerung
Daraus folgt: Ohne eine Anpassung im Telekom-Routing/- Peering wird dieses Problem nicht behoben.
8. Konkrete Bitte
Bitte diese Meldung samt Messdaten an die Netztechnik / das NOC bzw. das Peering -Team weitergeben und prüfen, warum AS3320 die Cloudflare-Prefixe 104.26.0.0/15 und 172.67.0.0/16 für diese Region zeitweise über einen überlasteten Transit (Cogent) schickt, während 104.21.0.0/16 durchgehend sauber über Telia (AS1299) läuft — und die betroffenen Prefixe auf den funktionierenden Pfad zu legen bzw. den Übergang zu entlasten.
Ich verifiziere jede Änderung sofort per erneuter Messung und melde das Ergebnis hier zurück; ein lückenloses 24/7-Zeitprofil (wann es kippt, wann es zurückschnappt) reiche ich nach.
6
von
vor 23 Tagen
Abschließende Zusammenfassung — und Schluss meinerseits in diesem Thread.
Nach eigener Analyse, einem Cloudflare-Ticket und etwas Recherche ist der Stand für mich eindeutig:
Für mich ist damit klar: Ohne eine Anpassung im Telekom-Routing/- Peering wird das nicht besser. Ich habe die Messdaten samt Einordnung an die Netztechnik weitergegeben und schließe den Thread meinerseits ab — unabhängig von weiteren Einzelmeinungen hier.
Quellen:
PS: Ja, ich nutze KI als Werkzeug, um meine Texte zu formulieren und Belege zusammenzufassen. Die Messungen, die technische Analyse und die Bewertung kommen von mir — KI ist hier das Schreibwerkzeug, kein Ersatz für Fachwissen
0
von
vor 23 Tagen
PS: Ja, ich nutze KI als Werkzeug, um meine Texte zu formulieren und Belege zusammenzufassen. Die Messungen, die technische Analyse und die Bewertung kommen von mir — KI ist hier das Schreibwerkzeug, kein Ersatz für Fachwissen
Abschließende Zusammenfassung — und Schluss meinerseits in diesem Thread.
Nach eigener Analyse, einem Cloudflare-Ticket und etwas Recherche ist der Stand für mich eindeutig:
Für mich ist damit klar: Ohne eine Anpassung im Telekom-Routing/- Peering wird das nicht besser. Ich habe die Messdaten samt Einordnung an die Netztechnik weitergegeben und schließe den Thread meinerseits ab — unabhängig von weiteren Einzelmeinungen hier.
Quellen:
PS: Ja, ich nutze KI als Werkzeug, um meine Texte zu formulieren und Belege zusammenzufassen. Die Messungen, die technische Analyse und die Bewertung kommen von mir — KI ist hier das Schreibwerkzeug, kein Ersatz für Fachwissen
Da sind wir uns einig.
und schließe den Thread meinerseits ab — unabhängig von weiteren Einzelmeinungen hier.
Abschließende Zusammenfassung — und Schluss meinerseits in diesem Thread.
Nach eigener Analyse, einem Cloudflare-Ticket und etwas Recherche ist der Stand für mich eindeutig:
Für mich ist damit klar: Ohne eine Anpassung im Telekom-Routing/- Peering wird das nicht besser. Ich habe die Messdaten samt Einordnung an die Netztechnik weitergegeben und schließe den Thread meinerseits ab — unabhängig von weiteren Einzelmeinungen hier.
Quellen:
PS: Ja, ich nutze KI als Werkzeug, um meine Texte zu formulieren und Belege zusammenzufassen. Die Messungen, die technische Analyse und die Bewertung kommen von mir — KI ist hier das Schreibwerkzeug, kein Ersatz für Fachwissen
Das Problem ist, wenn Du Antworten von Experten als Einzelmeinungen abtust.
Analyse und Antwort mit KI-Support:
AS13335 AS13335 AS13335), muss der BGP-Algorithmus der Telekom den scheinbar kürzeren Pfad über Cogent wählen. Der Telekom-Router führt nur aus, was Cloudflare per BGP vorgibt.
0
von
vor 23 Tagen
Hey @xAlexVx,
wir können bei Cloudflare nichts machen.
Solltest du doch möchten, das unsere Fachabteilung das prüft, müssen wir vorher telefonieren.
Liebe Grüße
Behar
0
Uneingeloggter Nutzer
von
vor 3 Stunden
Heute seit ca. 15 Uhr wieder mal extreme Probleme...
0
0
Uneingeloggter Nutzer
von