Ist dies das berüchtigte Peering der Telekom?

[liz02mo]

Hi zusammen,

ich habe seit vorgestern laut Unifi Dashboard bis zu 10% Packet Loss (5 Minuten Intervall) und es laden bei mir auch einige Seiten nicht richtig. Dann habe ich gerade mittels mtr ein traceroute zu 1.1.1.1 laufen lassen und folgendes Ergebnis:

Ich habe FTTH 600/300 über die Telekom (Glasfaser Nordwest) und der Ping ist an sich in Ordnung, nur der Packet Loss ist halt hoch.

Gerdae nochmal geschaut, bei x.com ist es genauso hoch, bei youtube.com bei 0%.

VG
liz02mo

 

[Lawnmower]

Ping Pakete haben normalerweise keine hohe Prio soweit ich weiss, deswegen weiss ich nicht ob man das wirklich so hart so beurteilen kann.
Und das Problem scheint ja eher im Netz ab Colt woanders hin zu sein und nicht bei der Telekom.

Das Seiten nicht richtig laden, würde ich jetzt eher woanders einordnen und nicht bei Paket Verlusten.

 

[wupi]

In den letzten Tagen hatte ich bei einigen Diensten Probleme. Heute hatte ich auch bei Cloudflare Probleme. Geizhalz sieht auch ganz gut aus.

 

[conf_t]

Genau ab hop4 hat die Telekom nix mehr damit zu tun u d Hop 6 ist ja erst das Problem.
Ob Colt das Problem sind kann man so nicht sagen, aber vermutlich

 

[liz02mo]

Dann dürfte es ja an sich mehrere Provider betreffen, oder?

 

[conf_t]

Warum? Ein Provider in der Kette reicht. Es können Nutzer mehrerer Provider betroffen sein, genau wissen tut man das so nicht und ungewöhnlich istsowas auch nicht. Isthalt Internet, alles kann, nichts muss. Habe ich schon häufiger gehabt, im Schnitt 1x pro Jahr, dass ich Meinem Arbeitgeber erklären musste, dass Cloud über Internet halt scheisse ist, genau aus solchen Gründen. Dumm wenn halt Logistiklieferketten daran hängen….

 

[Kristatos]

Habe da auch Probleme mit aktuell, betrifft alle Seiten die Cloudflare nutzen, gestern Abend ging fast garnichts, die Bilder von den Seiten wurden nicht nachgeladen oder dauerten ewig. Aktuell ist es bei mir (noch) normal um 17.40 Uhr.

 

[Helge01]

Bei mir betrifft es auch seit ein paar Tagen Webseiten die Cloudflare nutzen, denke die haben wieder mal ein Problem.

Peering wäre meist lange Paketlaufzeiten, Paketverluste eher nicht.

 

[BFF]

Das wird vermutlich garnicht mehr Telekom sein, wenn Lumen nicht zu denen gehoert. 🤷‍♂️
Alerdings findet man extrem viele Hinweise/Post das irgendwas nicht wirklich klappt wenn ueber Lumen nach Cloudflare in FFM geroutet wird. @liz02mo

 

[Web-Schecki]

Das grundsätzliche Problem ist, dass man als Telekom-Kunde überhaupt den Umweg über einen Carrier wie Lumen gehen muss, um Cloudflare zu erreichen. Cloudflare ist ein CDN. Die existieren aus genau einem einzigen Grund: Umwege über Carrier einsparen, indem man direkt mit dem Eyeball-AS peert. Funktioniert in der Regel erstaunlich gut, mit der Telekom jedoch nicht.
Also nein, das Problem existiert in dieser Form vermutlich nicht bei anderen deutschen Providern. Auch wenn sicherlich innerhalb des Telekom-Netzes alles funktioniert und in diesem Fall auch der PNI zu Lumen nicht voll zu sein scheint. Womöglich ist es der PNI zwischen Lumen und Cloudflare. Dort Kapazität nachzukaufen müsste wohl vornehmlich Cloudflare bezahlen, und die sehen das nicht ein.

 

[Banned]

Cloudflare hat in der jüngeren Vergangenheit mehrfach Wartungsarbeiten durchgeführt.

 

[Dr. Chaos]

Ich habe keine Probleme, Vodafone mit direkt Peering zu Cloudflair, liegt also wohl an einem der Provider zwischen Telekom und Cloudflair.

2     9 ms     8 ms     8 ms  178.26.xx.xxx
  3     9 ms    12 ms     8 ms  88.134.216.129
  4    16 ms    17 ms    16 ms  83.169.156.38
  5    17 ms    18 ms    15 ms  145.254.3.170
  6    14 ms    12 ms    12 ms  145.254.2.209
  7    20 ms    18 ms   227 ms  162.158.84.80
  8    16 ms    17 ms    13 ms  162.158.84.79
  9    16 ms    16 ms    15 ms  162.158.84.247
 10    17 ms    15 ms    12 ms  one.one.one.one [1.1.1.1]


 2     9 ms    11 ms    19 ms  178.26.xx.xxx
  3    12 ms     9 ms    11 ms  88.134.216.129
  4    15 ms    16 ms    16 ms  83.169.156.38
  5    17 ms    13 ms    17 ms  145.254.3.170
  6    16 ms    17 ms    16 ms  145.254.2.195
  7    12 ms    32 ms    29 ms  162.158.84.8
  8    17 ms    15 ms    21 ms  162.158.84.79
  9    21 ms    26 ms    20 ms  162.158.84.35
 10    14 ms    17 ms    10 ms  103.21.244.0

 

[CoMo]

Ja, sieht hier ähnlich aus. Massiver Packet Loss zu Cloudflare vom Telekom Anschluss aus. Kein Problem von einem O² Anschluss ein paar Kilometer entfernt.

 Host                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. OPNSense.home.arpa                               0.0%   245    0.3   0.2   0.1   0.6   0.1
 2. 62.156.244.46                                    0.0%   245    8.8   7.8   4.9  66.8   7.1
 3. 80.146.232.24                                    0.0%   245    6.1   6.3   5.8   7.5   0.2
 4. f-ed13-i.F.DE.NET.DTAG.DE                        0.0%   245   14.3  14.9  13.5  60.0   4.2
 5. 80.156.160.223                                  75.0%   245  290.8 276.5 222.0 318.5  23.1
 6. if-bundle-66-2.qcore2.fnm-frankfurt.as6453.net  72.1%   245  281.3 271.0 205.6 319.4  26.1
 7. if-bundle-11-2.qcore2.f2c-frankfurt.as6453.net   0.4%   244  297.8 272.5 185.2 336.0  23.4
 8. 162.158.84.235                                  24.7%   244   55.0  21.4  14.3 104.2  11.5
 9. one.one.one.one                                 30.3%   244   15.5  15.6  14.8  21.8   0.6

 Host                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.178.1                                         0.0%   169    0.5   0.5   0.4   3.9   0.4
 2. loopback1.0001.acln.05.ber.de.net.telefonica.de       0.0%   168    5.7   6.1   5.5   8.9   0.5
 3. bundle-ether37.0001.cord.05.ber.de.net.telefonica.de  0.0%   168    6.1   6.0   5.1  10.7   0.5
 4. ae7-0.0001.corx.05.ber.de.net.telefonica.de           0.0%   168    5.9   6.3   5.5  51.9   3.6
 5. bundle-ether2.0002.cord.01.ber.de.net.telefonica.de   0.0%   168    6.6   6.7   5.9  13.4   0.8
 6. bundle-ether2.0010.corp.07.ber.de.net.telefonica.de   0.0%   168    6.9   6.7   6.0  28.5   1.7
 7. 162.158.112.6                                         0.0%   168    6.2  11.7   5.3  74.0   9.1
 8. one.one.one.one                                       0.0%   168    5.2   5.8   5.1  18.1   1.0

Ursache ist, dass die Telekom sich privates Peering teuer bezahlen lassen will und Cloudflare sich weigert.

 

[azereus]

CF macht präfix leaking und schickt traffic der eigentlich direkt peeren sollte über andere peers
im asiatischen raum ist INDGO-West von Singapur nach Australien seit ner woche offen
Amazon verschiebt Server von und in Asien herum um die Lsat zu verteilen
...
sucht euch was aus

 

[Bodennebel]

Bei mir (Telekom-Glasfaser) sieht alles ok aus:

PowerShell 7.5.4
PS C:\Users\MYUSERNAME> tracert 1.1.1.1

Routenverfolgung zu one.one.one.one [1.1.1.1]
über maximal 30 Hops:

  1     2 ms     1 ms     2 ms  Speedport.ip [192.168.2.1]
  2     5 ms     5 ms     4 ms  p3e9bf1e4.dip0.t-ipconnect.de [62.155.241.228]
  3     8 ms     7 ms     7 ms  d-ed5-i.D.DE.NET.DTAG.DE [62.153.187.154]
  4     8 ms    10 ms     8 ms  ae5.edge6.dus1.sp.lumen.tech [4.68.71.113]
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6    13 ms    13 ms    13 ms  195.122.183.210
  7    17 ms    17 ms    17 ms  162.158.84.241
  8    14 ms    14 ms    15 ms  one.one.one.one [1.1.1.1]

Ablaufverfolgung beendet.

PS C:\Users\MYUSERNAME> ping -n 20 1.1.1.1

Ping wird ausgeführt für 1.1.1.1 mit 32 Bytes Daten:
Antwort von 1.1.1.1: Bytes=32 Zeit=13ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=13ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=13ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=13ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=13ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=15ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=15ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=13ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=21ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=15ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=15ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=55
Antwort von 1.1.1.1: Bytes=32 Zeit=22ms TTL=55

Ping-Statistik für 1.1.1.1:
    Pakete: Gesendet = 20, Empfangen = 20, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 13ms, Maximum = 22ms, Mittelwert = 14ms

 

[Banned]

Bei mir - ebenfalls Telekom-Glasfaser - sieht es ähnlich aus:

Wie gesagt: Wartungsarbeiten. War bei mir zwei Abende so krass, dass ich auf mehrere von CF gehostete Webseiten überhaupt wirklichen Zugriff mehr erhalten habe.

Ändert natürlich nichts daran, dass die Telekom wegen Peering trotzdem gewisse "Einschränkungen" hat generell.

 

[CoMo]

Wie gesagt: Wartungsarbeiten.

Wenn du da Insider-Infos hast, dann gebe die doch mal an die Verbraucherzentrale weiter. Das wäre im laufenden Verfahren sicher hilfreich. https://www.vzbv.de/pressemitteilun...-im-internet-buendnis-reicht-beschwerde-gegen

 

[Banned]

Wenn du da Insider-Infos hast

Wieso Insider-Infos? Die Statusmeldungen konnte/kann man bei Cloudflare einsehen. Die Wartungsarbeiten bei Cloudflare haben nichts mit der Telekom zu tun.

 

[CoMo]

Wozu soll dann der Hinweis auf irgendwelche Wartungsarbeiten gut sein, wenn das Problem offensichtlich nur Telekom-Anschlüsse betrifft?

 

[Wilhelm14]

Soll ich was anderes testen?
Hier ein Anschluss, Deutsche Glasfaser, Provider auch Deutsche Glasfaser, Dorf, Niedersachsen, WLAN.
Sieht auf den ersten Blick gut aus.
PS: In der Fritzbox ist 1.1.1.1 als DNS eingetragen, ich merke aktuell nichts schlimmes beim Surfen.
Youtube lädt in letzer Zeit teils lange, wenn das nächste Video ansteht. Das scheint aber mit ublock zusammenzuhängen, was Youtube ein Dorn im Auge ist.