Ihr wisst, dass speed.cloudflare.com kein zuverlaessiger Reflektor fuer ICMP/Pings ist?
Der Endhop (bei mir 2606:4700:7::da) zeigt 16% Packetloss mit Trippy, aber Kapazitaetstests zu https://speed.cloudflare.com laufen ohne Probleme mit der erwarteten Kapazitaet.
Was die Telia/AS1299 Hops auf dem Weg machen hat leider wenig diagnostischen Wert, weil Infrastrukltur-Zwischenhops i.d.R. keine zuverlaessigen Reflektoren fuer Endkunden Probes sind...
Deshalb schrieb ich "Wenn es ein Problem gibt". Wobei es bei den Hops davor ja losgeht, auch mit der auffälligen Erhöhung der Laufzeit.
Das Problem dürfte wohl eher der Cloudflare Upstream Richtung DG sein.
Wenn ich mir mal eine Random v6 addresse von DG schnappe und ein trace von Cloudflare mache:
2400:cb00:71:1000::1
2400:cb00:71:2::2
2001:1900:5:2:2:0:11c:56d
lo-0-v6.ear4.Frankfurt1.Level3.net
ae27.cs1.fra9.de.eth.zayo.com
ae1.mcs1.fra9.de.zip.zayo.com
2a00:16f8:11::2c2
2a00:6020:0:1d::1
pki.int63-fra.dg-w.de
PL sehen ich zwischen der Übergabe Zayo zu DG
Also nicht Cloudflares schuld sondern mal wieder Überlastung bei DG
In der Ausgabe sieht man leider gar nichts. Steht der Cloudflare Rechner in der Nähe des Speedtest Servers? Und im anderen Trace kommt zayo nicht vor.
Naja, asymmetrisches Routing ist wohl nicht ganz unueblich, d.h. nur weil der Hinweg ueber Telia laeuft heisst, nicht, dass der Rueckweg auch zwingend Telia involviert...
Das kann ja sein. Ändert aber nichts daran, das in den anderen Traces die Probleme quasi innerhalb des Telia Netzes auftreten, und das beim Test Cloudflare -> DG die Cloudflare IPs aus komplett anderen Subnetzen kommen, als der Problem-Server. Das Routing dahin ist aus dem DG Netz heraus auch ein komplett anderes.
DG hat mitgeteilt, dass die Störung behoben ist. Cloudfare Speed Test vom 5 Mbit/s auf 91 Mbit/s und 0 Packet Loss.
Ganz im Gegenteil. Gerade zu Coudflare flutscht es richtig über meine 400er DG Leitung.
frank_m Verständnis Frage. Wie kommt Du auf 622 Mbts bei einer 400er Leitung?
DG hat mitgeteilt, dass die Störung behoben ist. Cloudfare Speed Test vom 5 Mbit/s auf 91 Mbit/s und 0 Packet Loss.
Zumindest der Paketverlust ist schon mal weg. Ist das eine symmetrische 100-Mbps-Leitung?
Es ist eine 400/200er Leitung.
Wie kommt Du auf 622 Mbts bei einer 400er Leitung?
Das Phänomen ist den Traffic Shapern bei der DG geschuldet. Der physikalische Link ist 1 GBit/s schnell. Da fangen die Daten an, mit voller Geschwindigkeit zu fließen, und dann greift der Traffic Shaper ein und regelt die Geschwindigkeit auf die vertragliche Geschwindigkeit runter. Wenn du hinschaust: Diese Geschwindigkeit erreiche ich bei 10 MB Datenmenge. Die sind so schnell weg, da kommt der Traffic Shaper gar nicht richtig zum Regeln. Bei größeren Paketen klappt das (leider ;)) nicht mehr, da hat der Traffic Shaper dann Zeit, alles richtig einzustellen.
Es ist eine 400/200er Leitung.
Da würde ich jetzt nicht unbedingt von "gelöst" sprechen.
Wobei natürlich das Wichtigste ist, dass es nicht mehr zu Packet Loss kommt.
Sieht jetzt besser aus und die 400/200 werden zu speed.cloudflare.com mittlerweile auch erreicht. Auf dem Weg dahin gibt es noch bei twelve99 (ehemals Telia) 30% Paket Loss.
Packet Loss unterwegs ist im besten Fall ein Indikator.
Wenn das Paket ankommt, ist es komplett irrelevant, was die Hops dazwischen sagen oder eben nicht.
Das Phänomen ist den Traffic Shapern bei der DG geschuldet. Der physikalische Link ist 1 GBit/s schnell. Da fangen die Daten an, mit voller Geschwindigkeit zu fließen, und dann greift der Traffic Shaper ein und regelt die Geschwindigkeit auf die vertragliche Geschwindigkeit runter. Wenn du hinschaust: Diese Geschwindigkeit erreiche ich bei 10 MB Datenmenge. Die sind so schnell weg, da kommt der Traffic Shaper gar nicht richtig zum Regeln. Bei größeren Paketen klappt das (leider ;)) nicht mehr, da hat der Traffic Shaper dann Zeit, alles richtig einzustellen.
Den Zahn muss ich dir leider ziehen: Die Burstsize ist in deinem Fall nur größer eingestellt, würde man das ab dem ersten Byte direkt begrenzen wollen, könnte man das auch ohne Probleme tun.
Auf dem Weg dahin gibt es noch bei twelve99 (ehemals Telia) 30% Paket Loss.
Wie bereits geschrieben, hat das gar keine Aussagekraft, weil ICMP TTL Exceeded von der Controlplane des Routers gesendet werden müssen. Zum Schutz der Controlplane werden aber sehr oft Ratelimiter für bestimmte Paketarten eingesetzt, sodass man hier nur ein künstliches Ratelimit im entsprechenden Hop aufzeigen könnte.
Gestern ein Ticket erstellt und heute Morgen einen Anruf von Deutsche Glasfaser erhalten. Eine freundliche Dame erklärte mir, dass sie meinen Anschluss neu starten würde und ich für ca. 20 Minuten kein Internet hätte. Ich habe noch versucht klarzustellen, dass das Problem nicht am Anschluss liegt, was im Ticket auch schon ausführlich beschrieben war.
Leider ließ sich die Dame nicht davon abbringen, den Neustart durchzuführen. Das Ende vom Lied: Das Problem besteht weiterhin, und mein Ticket wurde einfach geschlossen.
Danke, Deutsche Glasfaser! 
Ich kann die Probleme mit der Verbindung zu Cloudflare auch bestätigen.
Vielleicht bessert es sich morgen.
Es ist aber jedenfalls beruhigend dass man nicht alleine betroffen ist.
Gestern Nachmittag sah es bei mir ordentlich aus.
Jetzt sind es nur noch 8 MBit/s im Download.
Ich kann die Probleme mit der Verbindung zu Cloudflare auch bestätigen.
Vielleicht bessert es sich morgen.
Es ist aber jedenfalls beruhigend dass man nicht alleine betroffen ist.
Ich glaube nicht, dass sich die Situation einfach von selbst verbessern wird. Da ich regelmäßig Traffic in Richtung Cloudflare habe und schnell merke, wenn es zu Störungen kommt, kann ich sagen, dass sich dieses Problem bereits über Wochen angekündigt hat. Es war jedoch nie so gravierend, dass es wirklich gestört hätte. In der aktuellen Situation ist es jedoch nicht mehr nutzbar.
Daher möchte ich alle bitten, ebenfalls ein Support-Ticket zu eröffnen und das Problem ausführlich zu schildern.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
