@→мαтαıмακı←Kein Bock mehr 

Das hat doch nichts mit Peering zu tun - 

mich kann’s. Jocht mehr hören 

Danke für das Feedback.

Ich bin der Anbieter der Webseite und Besitzer des Servers (in Helsinki / Finnland). Ich habe auch schon einen neuen Server in Deutschland bestellt + Umzug des Servers nach DE als Worst-Case Szenario - was ich aber nicht in der Kürze der Zeit machen kann und deshalb versuche herauszubekommen, wo der Flaschenhals ist und warum das nur das Telekom-Netz betrifft, aber nicht O2 / Vodafone).

ICMP-Pakete und eine VPN -Verbindung zu dem Server gehen ohne Probleme durch - nur HTTPS und Mail (SSL / Port 995) sind extrem verlangsamt.

Ich glaube nicht, dass es ein Anschlussproblem ist, da mittlerweile 17 Telekom-User das Problem bestätigt haben (+ inkl. auch der Bestätigung, dass es bei O2 / Vodafone funktioniert). 

Hallo martin,

ich kann das Problem von hier aus in Magdeburg ebenfalls bestätigen.

Ich hatte seit etwas einer Woche festgestellt, dass unter anderem die Verbindung zu verschiedenen CDN 's zum Beispiel für Streamingservices  für wenige Minuten super funktioniert und dann der Stream entweder für minuten Stillsteht weil der Datenfluss plötzlich nicht mehr hinterher kommt und astronomisch gering wird bzw. der Stream komplett zum Stillstand kommt und ich ständig neu starten und zum letzten Zeitpunk vorspulen musste um für gerade mal ein paar minuten weiter zu schauen.

Über die Woche hinweg hat sich das Problem nur noch ausgeweitet auf weitere Plattformen. Unter anderem nun auch auf meinen Mietserver zum herumspielen und Basteln bei Hetzner ebenfalls platziert in Helsinki. Diesen hatte ich zwischenzeitlich als VPN Proxy verwendet um die Verbindung zu besagten CDN 's zu verbessern.

Ich habe bis eben versucht das Problem in meinem Netzwerk zu Hause ausfindig zu machen indem ich an verschiedenen Punkten und direkt am Router versucht habe eine Videodatei nach dem Hochladen von meinem Server zu laden, was ab und an mal meine 50Mbit/s aber inzwischen nahezu nur im 5-200kbyte/s herum schleicht weil die Verbindung entsprechend instabil ist bzw sehr häufig gänzlich abreißt.

Das Problem scheint generell weiter verbreitet zu sein, da mich bereits mehrere Kollegen an meinem Arbeitsplatz in den letzten Tagen beklagt haben, dass "das Internet sehr langsam ist", dabei verfügen wir dort über einen vernünftigen firmenorientierten Glasfaseranschluss, im Gegensatz zu meinen 50M DSL Anschluss zu Hause. Welcher auch einfandfreie Messwerte, zumindestens im Netz der Telekom aufweist.

Meine Kollegen auf Arbeit sind viel mehr auf den Plattformen von Großhändlern unterwegs, welche natürlich ebenfalls ihre Dienstleitungen über diverse CDN 's bereit stellen. Wodurch sich dann für Sie das ganze als "langsames Internet", da die Shopseiten und Produktbilder sehr lange zum Aufrufen brauchen.

Ich kann das Problem also an meinem DSL, so wie an unserem Glasfaseranschluss im Betrieb bestätigen.

Ich kann jedoch Netzintern (Telekom DSL Zuhause <> Telekom Glasfaser Firma) ohne jegliche Verbindungseinschränkungen große Dateien hin und her schieben.

Super - Danke für dein Feedback. Mit einer Antwort habe ich jetzt nicht mehr wirklich gerechnet, weil das Problem sehr speziell ist und interessant, dass du zufällig einen Server auch im Hel1  von Hetzner hast.

Ich kann das in Wireshark prima nachweisen, dass die Pakete offensichtlich verloren bzw. etliche Male wiederholt angefordert und gesendet werden - aber nur für TCP-Pakete.

ICMP-Pakete gehen aber prima durch - auch ohne Verlust 1000 und mehr (WinMTR)  - aber diese werden evtl. einfach nur anders geroutet oder sind vielleicht höher priorisiert oder sind einfach kleiner - aber leider bin ich alles, nur kein Netzwerkspezialist, um das beurteilen zu können.

Letztendlich ist da mein Problem, ich kann in Wireshark nicht sehen, an welcher Stelle in der Route das TCP-Paket verloren geht - ich kann ja kein tracert für ein TCP-Pakete machen (oder zumindest weiß ich nicht wie ...).

Das führt zu der Patt-Situation:

• Das Problem passiert offenbar nur bei höherer Netzwerklast - typischerweise zwischen 14/15.00 - 0.00 Uhr (seit Donnerstag / + gestern und heute) 
• Das Problem tritt offensichtlich nur bei Verbindungen aus dem Telekom-Netz auf (ich habe über 40 Nutzer,  die das mittlerweile bestätigt haben)
• Ich kann den Paket-Verlust aus Sicht von Hetzner nicht beweisen, weil er nicht bei ICMP-Paketen auftritt und man dann ja nicht weiß, wo man suchen muss

Deshalb fühlt sich Hetzner hier nicht in der Verantwortung, das weiter zu untersuchen (der Server ist ja da und die Anbindung ist "perfekt") und hat mich an die Telekom verwiesen.  Aber ich kann jetzt natürlich nicht Tage und Wochen damit zubringen, jemanden bei der Telekom zu finden, der das Problem versteht und die geeignete Untersuchung initiieren kann - ich gehe zumindest nicht davon aus, dass ein Call-Center-Arbeiter überhaupt versteht, dass es ein generelles Problem (und nicht ein spezifisches mit einem Anschluss ist).

Deshalb die Hoffnung hier im Forum einen Tipp zu bekommen, an wen man sich bei der Telekom wenden könnte, der so ein Art Störung (innerhalb der Telekom) bearbeiten kann.

ICMP Pakte sind im Netz Abfall mit niedriger Priorität 

das alles passt auch nicht zu einem

  Peering Problem - einfach mal Hetzner anschreiben 

Das Problem besteht wie ich bereits sagte zu mehreren CDN 's, aus dem Telekom Netz heraus.

Mich betrifft es hier teils bei verschiedenen Streaminganbietern sowie bei den CDN von Großhändlern mit denen wir verkehren, die haben sicher nicht alle Ihren Hostingbetreiber bei Hetzner.

Ich habe lediglich versucht den Fehler zu Diagnostizieren mit hilfe meines dort befindlichen Servers. Die Probleme bestehen entsprechend nicht nur zu den Netzen von Helsinki/Hetzner.

Hier, ein Beispiel welches noch viel schrecklicher läuft.

Diese Verbindung ist zu einem CDN hinter Cloudflare US. (172 . 67 . 139 . 197)

Verbindung geht von langsam aber nutzbar durch die vielen retransmissions über unbrauchbar langsam bis zum kompletten Verbindungsabbruch.

Und weder Hetzner noch Helsinki sind hier im Spiel.

@martin-ebringen

UDP Verbindungen haben das gleiche Problem, jedoch wird hier niemals ein retransmission durchgeführt, dadurch kannst du es auch nicht in wireshark beobachten, UDP ignoriert paketverlust weg und Daten gehen schlicht verloren. Von daher wirst du dort den Fehler nur beobachten können, wenn du Quelle und Ziel unter Kontrolle hast und den IN und OUTPUT vergleichst.

Ich vermute eher das hier irgendein Netzwerkknoten am Versagen ist, mit welchem die Telekom verbandelt ist, zum Beispiel eines Vertragspartner nach außen.

mtr geht auch per TCP.

mtr -c 100 --tcp --report 95.217.207.230
HOST: xxxxx Loss% Snt Last Avg Best Wrst StDev
...
9.|-- core32.hel1.hetzner.com 0.0% 100 32.1 33.1 30.7 60.3 4.8
ex9k2.dc4.hel1.hetzner.com 
10.|-- ex9k2.dc4.hel1.hetzner.co 0.0% 100 40.7 76.7 30.4 3273. 325.1
mail.asgard-solutions.de 
11.|-- mail.asgard-solutions.de 3.3% 91 3172. 1196. 33.8 9304. 2534.0

Sehr hohe Pingzeiten bis zu 9304 ms, vielleicht hat das etwas mit dem Problem zu tun.

Von anderen Adressen aus bekomme ich keine Verzögerungen, nur aus dem Netz der Telekom. Ich glaube nicht, dass es an Hetzner alleine liegt, vllt. am Zusammenspiel zwischen Hetzner und der Telekom.

Die Fehlerbeschreibung passt doch so ziemlich 1:1 dazu, bestimmte Netze, Fehler auschließlich aus dem besagten ISP und gleiches Fehlerbild.

Ich habe das Problem um identische Szenarien ergänzt, wodurch auch andere CDN 's betroffen sind mit ebenfalls dem gleichen Fehlerbild. Ebenfalls auschließlich über Telekom-Netz.

Im Anhang noch einmal weitere Beispiele, die mit "http request" betitelten Dateien sind eine HTTP Übertragung von seinem Server. Und die mit "bad" betitelten sind die besagten Übertragungsfehler welche @martin-ebringen im Netz des Providers hat und ich hier bestätigen kann.

Die mit "fine" betitelten, habe ich über unsere redundante Richtfunkanbindung gemacht, welche hier ebenfalls in Magdeburg ausgeht.

Wie unschwer den übertragungszeiten im Browser, bestätigt durch die retransmissions in wireshark zu erkennen ist, läuft hier doch schon gewaltig etwas verkehrt.

Und nachfolgend im Anhang erneut einmal das genau gleiche von Martin beschriebene Problem, angewendet auf einen von mir verwendeten CDN hinter Cloudflare, wie auch unsere Businesspartner verwenden, wodurch sich das gleiche Problem nachweislich eben nicht nur auf die Verbindung zum Rechenzentrum von Hetzner beschränkt.

"cloudflare CDN us bad" ist hier die Aufzeichnung aus dem Telekom-Netz (DSL wie Glasfaser) und die "cloudflare CDN us fine" ist erneut über unsere Redundante Richtfunkanbindung über einen anderen Provider.

Ich habe bis auf weiteres meine Heimanbindung sowie unser Firmennetz auf unseren Ausweichprovider umgeschalten, ich hoffe für dich (Martin) das sich das Problem noch größer für mehr bemerkbar machen wird und somit auch in naher Zukunft angegangen wird.