Ist dies das berüchtigte Peering der Telekom?

[Helge01]

Vermutlich sind das mehrere Probleme, Peering bei der Telekom und Cloudflare hat zusätzlich auch noch eine Störung.

 

[Web-Schecki]

Aber wenn einige keine Probleme haben und andere schon, würde das doch zumindest gegen die Peering-Theorie sprechen, oder?

Aber müsste es, wenn es am Peering läge, denn nicht bei allen Telekom-Kunden gleichermaßen auftreten?

Nein, nicht unbedingt. Es kann auch mehrere Übergabepunkte geben, besonders zu Cloudflare ist das auch sinnvoll. Im Telekom-Looking-Glass sieht man das auch.
1.1.1.1 wird derzeit von Hamburg, Düsseldorf und München aus über Lumen zu Cloudflare geroutet, von Berlin und Frankfurt aus hingegen über Tata.
104.16.132.229 ist auch eine Cloudflare-IP und wird von München und Berlin ausgehend stattdessen über GTT geroutet, aber zumindest Telekom-intern auf unterschiedlichem Wege.
172.67.160.69 ist eine Cloudflare-IP aus dem Free-Tier, und die geht einheitlich über Arelion, egal, von wo.

 

[FTTC]

Aktuell bin ich in einem Nachbarort an einem Telekom Anschluss. Dieser wird tatsächlich über Frankfurt geroutet, mein Anschluss wird über Düsseldorf geroutet.
Hier gibt es keine Probleme. Weder Packetloss noch Probleme bei der Geschwindigkeit.
Das würde ja deine Infos unterstützen @Web-Schecki

Per VPN nach Hause sieht's dann wieder schlecht aus.

 

[Banned]

Hmm, interessant. Bei mir ist es ja auch Frankfurt (was geographisch auch ziemlich Sinn macht in meinem Fall).

104.16.132.229 ist auch eine Cloudflare-IP und wird von München und Berlin ausgehend stattdessen über GTT geroutet, aber zumindest Telekom-intern auf unterschiedlichem Wege.

Hier sieht es bei mir auch komplett unterirdisch aus:

Ping-Statistik für 104.16.132.229:
Pakete: Gesendet = 40, Empfangen = 18, Verloren = 22
(55% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 7ms, Maximum = 10ms, Mittelwert = 7ms

172.67.160.69 ist eine Cloudflare-IP aus dem Free-Tier, und die geht einheitlich über Arelion, egal, von wo.

Hier hingegen gut:

Ping-Statistik für 172.67.160.69:
Pakete: Gesendet = 40, Empfangen = 40, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 20ms, Maximum = 24ms, Mittelwert = 21ms

Hatte bei nem vorherigen Test mit zwanzig Paketen mal ein verlorenes - also nichts Weltbewegendes.

Bei 1.1.1.1 weiterhin alles super:

Ping-Statistik für 1.1.1.1:
Pakete: Gesendet = 40, Empfangen = 40, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 8ms, Maximum = 15ms, Mittelwert = 9ms

 

[froeschi62]

@Banned So, es geht langsam los..:-)
https://flugzeugbilder.de/

 

[liz02mo]

@froeschi62 Ich habe jetzt keinen traceroute gemacht, aber ich kann sie im Browser nicht laden . Ah jetzt, seeehr langsam

 

[Krik]

Die Seite lädt bei mir auch nicht. Schade, der Name klingt spannend.

 

[Helge01]

So, es geht langsam los

Das scheint aber an Cloudflare zu liegen, 141.101.71.125 ist eine Cloudflare Adresse.

traceroute to www.flugzeugbilder.de (188.114.97.3), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.254)  0.235 ms  0.213 ms  0.211 ms
 2  p3e9bf783.dip0.t-ipconnect.de (62.155.247.131)  5.560 ms  5.556 ms  5.663 ms
 3  lon-sb2-i.LON.GB.NET.DTAG.DE (217.239.58.45)  26.020 ms  26.016 ms *
 4  ldn-b2-link.ip.twelve99.net (62.115.50.18)  30.667 ms * *
 5  * cloudflare-ic-339870.ip.twelve99-cust.net (62.115.151.125)  26.730 ms  26.726 ms
 6  141.101.71.125 (141.101.71.125)  88.014 ms * *
 7  188.114.97.3 (188.114.97.3)  32.206 ms * *

 

[CoMo]

Ich habe jetzt tatsächlich mal den Workaround aus dem Telekom Forum umgesetzt, mir mit wgcf Acocunt und Config erstellt und mit Firewall-Regeln und Outbound NAT auf dem Router ein Policy-Based-Routing für Cloudflare-Ziele eingerichtet. Scheint soweit zu funktionieren. Mal beobachten wie es läuft.

Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2003:xxxx:xxxx:1a00::1    0.0%   161    0.3   0.3   0.1   0.6   0.1
 2. one.one.one.one           0.0%   160    6.2   6.7   5.7  13.0   0.7

 

[Krik]

Ok, die Seite ging jetzt bei mir auf, lädt sich aber bei jedem weiteren Klick nahezu tot.

 

[Banned]

@froeschi62

Da ist alles gut bei mir:

Ping-Statistik für 2a06:98c1:3120::3:
Pakete: Gesendet = 40, Empfangen = 40, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 21ms, Maximum = 28ms, Mittelwert = 22ms

Also scheinbar sind manche Übergabepunkte problematisch, und je nachdem, welche Webseite(n) man nutzt und wo man sich geographisch befindet, kann man die Arschkarte gezogen haben.

 

[CoMo]

Test zu der erwähnten Seite www.flugzeugbilder.de:

Direkt vom Telekom-Anschluss aus:

Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                               Packets               Pings
 Host                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2003:xxxx:xxxx:1a00::1                    0.0%    62    0.3   0.3   0.2   0.4   0.1
 2. 2003:0:1001:6418::1                       0.0%    62    5.4   7.0   4.9  20.3   3.5
 3. 2003:0:1001:6410::1                      44.3%    62    6.5   6.5   6.2   6.9   0.2
 4. dtag-ic-323085.ip.twelve99-cust.net      32.8%    62   27.9  27.9  27.1  28.4   0.3
 5. ldn-b2-link.ip.twelve99.net               0.0%    62   25.4  25.1  24.8  25.6   0.2
 6. cloudflare-ic-339870.ip.twelve99-cust.ne 44.3%    62   36.5  31.3  27.9  60.0   6.7
 7. 2400:cb00:991:3::                        16.1%    62   28.3  31.7  27.9 108.3  11.6
 8. 2606:4700:3037::ac43:ccfb                11.3%    62   27.1  27.6  26.7  28.5   0.5

Vom selben Anschluss aus durch den Cloudflare WARP Tunnel:

Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2003:xxxx:xxxx:1a00::1    0.0%   116    0.3   0.3   0.2   0.6   0.1
 2. 2606:4700:3037::6815:2ce  0.0%   116    6.9   6.7   6.0   9.0   0.5

 

[liz02mo]

Ich habe jetzt tatsächlich mal den Workaround aus dem Telekom Forum umgesetzt, mir mit wgcf Acocunt und Config erstellt und mit Firewall-Regeln und Outbound NAT auf dem Router ein Policy-Based-Routing für Cloudflare-Ziele eingerichtet. Scheint soweit zu funktionieren.

Magst du den Beitrag verlinken?

 

[CoMo]

Gefunden habe ich die Idee hier https://telekomhilft.telekom.de/con...597b08879d?commentId=69750e06f8cc8d29601231ef

Das auf der OPNSense zum Laufen zu bringen mit IPv4 und IPv6 hat mich aber jetzt bestimmt 3 Stunden gekostet.

 

[froeschi62]

Bei der Fritzbox geht über Wireguard(Netzkopplung) nur IPv4 und kein Tunnelsplitting. Man müsste dann IPv6 abschalten, sonst ginge es vorbei.

 

[CoMo]

Ne, sowas geht natürlich nur mit einem richtigen Router und es soll ja auch nur der Traffic zu CF durch diesen Tunnel geschickt werden.

Ich habe mir dafür die CF IP's als Alias eingerichtet und verwende den in den Regeln. Wird alle 12 Stunden abgerufen. Nur falls Cloudflare da mal was ändert.

https://www.cloudflare.com/ips-v4/
https://www.cloudflare.com/ips-v6/

 

[froeschi62]

Hier ein arroganter Auftritt eines Telekom Teamleiters, techn. Kundendienst (ganz wichtig!) im Telekom Hilfe Forum:
https://telekomhilft.telekom.de/con...786937e549fb&replyId=697cf1c7b74a8e54adfb440b

 

[Web-Schecki]

Das scheint aber an Cloudflare zu liegen

Eine Traceroute ist einfach nicht aussagekräftig genug, um problematische Router zu identifizieren.

Das Problem ist, dass über Arelion geroutet wird und die DTAG dorthin scheinbar in London übergibt. Das ist ein Umweg, der technisch unbegründet ist: Bei allen anderen deutschen ISPs wird direkt an Cloudflare übergeben und die Anfrage wird extrem schnell beantwortet. Es ginge also technisch besser. Und Cloudflare existiert genau zu diesem Zweck: Anfragen direkt vor Ort zu beantworten.

Natürlich könnte ein Router von Cloudflare in London kaputt oder überlastet sein, klar. Über mehrere Monate? Sodass nur Telekom-Kunden betroffen sind? Und als zuvor über Newark, NJ geroutet wurde? Was war da der Grund?

 

[Alexander2]

Das scheint aber an Cloudflare zu liegen, 141.101.71.125 ist eine Cloudflare Adresse.

hab die Seite mal gerade aufgerufen. hätte schneller sein können, aber nach 2-3 Sekunden, was ja auch recht lang ist war sie auf mal komplett da.
Edit:
nen Link zu den Bildern auf der seite von klick zu komplett da ~ 3 Sekunden gezählt. funktioniert gut, könnte besser sein

(EWE da bin ich wohl höchstens von der Cloudflare langsamkeit betroffen, ansich gehts gut)
Edit:
um nur eine Perspektive einzubringen eines Providers wo es das Telekom problem eigentlich meines wissens nach nicht gibt (war ja auch mal Telekom Kunde)

 

[user3402]

Neben den üblichen Clouflare-Peering-Problemen habe ich als Telekom-Kunde seit Monaten Probleme mit https://satisfactory-calculator.com/en/interactive-map, obwohl die Seite laut tracert nicht über Cloudflare sondern Hetzner geroutet wird. Mit VPN wird die Map aber sofort geladen, wie bei allen Seiten hinter Cloudflare.

Liegt hier auch ein Peering-Problem vor oder woran liegt das?

Heute geht es sogar noch eingermaßen, gestern war es wie so oft schlimm (Map wurde nicht zu Ende geladen, und Bilder bauten sich schleppend von oben nach unten auf).