Grüße @martin-ebringen 

Wende dich an den Anbieter das er Geld ausgibt und für eine bessere Anbindung sorgt.

Oder nutze ein VPN der damit klarkommt.

Ansonsten gibt es hier zum Thema Peering noch ein paar interessante Facts.

Denn du kannst nicht verlangen von einem Provider allen Millionen Anbietern die beste Anbindung zu bieten.

Wenn ein Anbieter Probleme mit einem ISP hat, muss sich der Anbieter kümmern.

Ich bin schon wieder raus.

@→мαтαıмακı←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.

Moin!

Mir ist seit dem 7.11 (ab ziemlich genau 14:55) auch aufgefallen, dass Verbindungen zu meinem Hetzner Server in Helsinki nun praktisch nicht mehr nutzbar sind.

Nach einigem Hin und Her mit MTR, iperf und so weiter, bin ich zu dem Ergebnis gekommen, dass es sich wohl, wie hier auch schon erwähnt, um ein Problem mit TCP Paketen handeln muss.

Die Problematik kann komplett umgangen werden, indem ich entweder einen VPN Verwende, um von einem anderen Exit Node (bspw. Schweiz) die Verbindung aufzubauen, oder indem ich mittels Wireguard vom Server aus in mein Heimnetz einen Tunnel erstelle, und meinen Traffic durch diesen leite.

Das führt gar so weit, dass ich mittels NATing via Fritzbox und diversen anderen Routern durch den Wireguard Tunnel externen Telekom Nutzern ermöglichen kann, bspw Minecraft (25565 TCP) auf meinem Server zu spielen.

Hetzner hat das Problem bereits auf dem Schirm und ist angeblich mit der Telekom in Kontakt https://status.hetzner.com/incident/5642a887-dc57-447c-b286-f76053bf9e8d

Das Problem betrifft ALLE Telekom Kunden mit denen ich gesprochen habe und KEINE Kunden anderer ISPs in Deutschland.

Gerne liefere ich auch TCP-Dumps o.ä. bei Bedarf nach.

Also erstmal vielen Dank an die Mühen und die Hinweise generell.

Da auf dem Helsinki-Server auch eine Produktiv-Seite mit mehr als 10.000 Kunden täglich gehosted wurde, konnte ich die Fehleranalyse nicht weiterbetreiben und habe in einer Hauruck-Aktion (18h-Schicht) den Server von Helsinki (95.217.207.230) nach Falkenstein (136.243.61.21) umgezogen. Das stand so oder so auf dem Schirm und jetzt wurde ich indirekt dazu gezwungen.

Die Anbindung an den neuen Server funktioniert wunderbar, so wie das auch grundsätzlich vor dem Do, 10.11.2024 auf dem Helsinki-Server war.

D. h. ich kann jetzt in Ruhe weiter analysieren, was das Problem ist - denn, obwohl auf dem Server keine Last mehr ist, tritt das Problem weiterhin und primär verstärkt zwischen 14.00 auf und 0.00 Uhr auf (bisher am Do, Fr, Sa und heute So).

Für die noch nicht umgezogenen Seiten ist das nicht dramatisch, weil diese nicht von Endkunden genutzt werden (= hier kann also nichts kaputt gehen, egal was ich teste :-)).

@armin23 

Vielen Dank, dass du ebenfalls bestätigen kannst, dass die Verbindung sich ganz anders verhält (je nach Provider). Das es sich evtl. um ein größeres Problem handelt (und auch CDNs) betrifft, kann natürlich sein, aber auf diesem Level kann ich nicht mitsprechen, weil ich eben alles andere als ein Netzwerkprofi bin - was ich vielleicht ändern sollte ;-). Trotzdem hilft es schon sehr, wenn man die Bestätigung bekommt, dass andere das auch nachvollziehen können.

@k.breitscheid 

Vielen Dank ebenfalls für die Bestätigung der hohen Ping-Zeiten und den Hinweis, dass man mit MTR auch TCP-Pakete testen kann. Jetzt muss ich nur noch rausfinden, wie man das auch unter Windows machen kann. Denn dann kann ich nochmal auf Hetzner zugehen - denn Hetzner möchte als Beweis einen MTR-Report (mit mind. 200 Aufrufen). Das ist für mich nicht nur jetzt im akuten Fall wichtig, sondern auch, um zukünftig bei solchen Fällen eine Analyse betreiben zu können (ich wusste bis Do nichts von MTR oder Wireshark ...) <- d. h. daran arbeite ich jetzt, diese KH-Lücke zu schließen.

@steffenba 

Vielen Dank für deine Fehlerbeschreibung - das hätte jetzt 1:1 von mir kommen können.

Mit ICMP-Paketen gibt es keine Probleme und ich verwalte ihn remote über VPN (ebenfalls keine Probleme). 

Hetzner hat das Problem bereits auf dem Schirm und ist angeblich mit der Telekom in Kontakt https://status.hetzner.com/incident/5642a887-dc57-447c-b286-f76053bf9e8d

Diese Info habe ich nicht von Hetzner bekommen - und diese Statusmeldung wird auch auf https://status.hetzner.com nicht angezeigt.

Das Problem betrifft ALLE Telekom Kunden mit denen ich gesprochen habe und KEINE Kunden anderer ISPs in Deutschland.

Ich habe über 40 Kunden, die bestätigt haben, dass sie das Problem auch betrifft. Bei Kunden mit O2, Vodafone und AT A1 gab es keine Probleme.

Hallo zusammen,

aktuell kann ich zu dem Problem zwar keine weiteren Erkenntnisse beitragen, die nicht weiter oben schon thematisiert wurden. Als Telekom-Nutzer und Hetzner-Helsinki-Serverbetreiber bin ich aber auch betroffen.

Und ich möchte mich mal bei den bisherigen Teilnehmern für die Ausführungen und detaillierte Recherche bedanken. Ich habe am Wochenende ebenfalls sehr viel Zeit investiert um rauszufinden, warum mein Server von zuhause aus quasi nicht mehr bedienbar ist und war schon kurz davor, den Server selbst, mein Betriebssystem, den Router oder meine Verkabelung austauschen zu wollen... nur dass sich das Problem eben bei mir ausschließlich bei Verbindungen zu Hetzner Helsinki bemerkbar macht und ich nun die absurde Situation habe, dass ich über getunnelten Remote-Desktop zur Firma flüssiger an dem System arbeiten kann als direkt von zuhause.

Danke für die Auflösung des Gaslighings, das hat mir in jedem Fall viel Nerven und Geld gespart. Und ich hoffe für uns alle, dass das Problem zeitnah behoben wird.

Das Problem besteht offensichtlich immer noch. Mittlerweile konnte ich auch auf einem Windows-11-System das "Windows Subsystem for Linux (WSL)" und mtr installieren können:

1. Powershell als admin öffnen (z. B. "Win + Taste X" - im Menü "Terminal (Administrator)" auswählen
2. WSL installieren mit dem Befehl "wsl --install" (in der Regel wird wohl ein Ubuntu installiert) + Neustarten von Windows
3. Ubuntu starten (einfach nach "Ubuntu" suchen) - oder in einem Powershell den Befehl "wsl" eingeben -> startet scheinbar eine bash console
4. In der bash console die Befehle

sudo apt update

sudo apt install mtr

eingeben.

Dann sollte mtr installiert sein.

Dann in der bash console mtr mit dem betroffenen Server ausprobieren - zunächst ICMP (hier nur 10 cyclen / weitere Hilfe mit "mtr --help")

mtr -c 10 --report 95.217.207.230

 2.|-- fritz.box 0.0% 10 0.9 1.2 0.9 1.8 0.4
3.|-- ********* 0.0% 10 16.0 7.5 5.0 16.0 3.5
4.|-- f-ed12-i.F.DE.NET. DTAG .DE 0.0% 10 12.3 12.7 11.7 13.9 0.6
5.|-- ae8-0.fra20.core-backbone 0.0% 10 11.4 15.3 10.5 52.6 13.1
6.|-- ae1-2081.sth10.core-backb 0.0% 10 31.1 32.6 29.5 51.9 6.8
7.|-- core-backbone.hetzner.com 0.0% 10 30.2 32.1 29.6 42.8 4.2
8.|-- core53.sto.hetzner.com 0.0% 10 30.7 30.8 30.6 31.2 0.2
9.|-- core31.hel1.hetzner.com 0.0% 10 37.3 36.8 35.2 37.6 0.8
10.|-- ex9k2.dc4.hel1.hetzner.co 0.0% 10 37.8 37.7 36.2 38.5 0.7
11.|-- mail.asgard-solutions.de 0.0% 10 36.8 36.7 35.5 37.5 0.7

Dann habe ich es wie oben von @k.breitscheid vorgeschlagen mit TCP probiert 

mtr -c 100 --tcp --report 95.217.207.230

erhalte dann aber das ist nicht unbedingt das erhoffte Ergebnis

 2.|-- fritz.box 0.0% 100 0.9 1.1 0.7 2.2 0.3
3.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
4.|-- f-ed12-i.F.DE.NET. DTAG .DE 0.0% 100 13.4 13.4 12.5 14.6 0.4
f-ed12-i.F.DE.NET. DTAG .DE
5.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
6.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
7.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
11.|-- mail.asgard-solutions.de 4.0% 100 9888. 1127. -2253 9888. 2435.6

Denn, die fritz.box scheint alle Pakete zu verwerfen (= jetzt muss ich erstmal rausfinden, wie man die fritz.box umstellen kann :-)).

Nun ist das Problem übrigens auch auf der Hauptseite des Hetzner Robot angeschrieben.

Weiterhin scheint es nun etwas begrenzter aufzutreten.

Während via 25565/tcp nun der Traffic scheinbar recht ordentlich durchläuft, macht 443/tcp konkret Probleme.

Auch 25565/tcp zickt wieder.

Lasse ich via 444/tcp auf Server und Client ein iperf laufen, so braucht er zwar etwas um loszulegen, und macht lt. Wireshark auch einige retransmissions, aber es geht.

Lasse ich via 443/tcp auf Server und Client ein iperf laufen, so legt er im Endeffekt gar nicht los, in Wireshark tauchen diverse retransmissions auf und irgendwann wird die Verbindung mittels RST ACK quittiert.

Port 80: geht

Port 443: geht nicht

Port 444: geht

Ich hatte heute morgen zwischen 8 und 10 Uhr auch den Eindruck, dass der Seitenaufbau recht fix war, daher kann es also sogar sein, dass das Problem zeitlich begrenzt auftritt. Ich teste das morgen früh noch ein Mal.

Mit MTR-Statistiken kann ich dienen, zwar nicht von zuhause auf ein Hetzner-System, aber andersrum.

Von Helsinki gruselige Latenzen und Packet Loss, die aber erst ab #9 einsetzen (was ein Telekom-System ist):

~ # mtr -c 100 --tcp --report 87.188.149.57
Start: 2024-11-11T20:29:18+0100
HOST: eris5b                    Loss%  Snt   Last    Avg  Best   Wrst   StDev
 1.|-- 5.eris-olymp.de           0.0%  100    0.3    0.2   0.1    0.4     0.1
 2.|-- static.65.130.108.65.clie 0.0%  100    0.5    1.1   0.4   32.7     3.8
 3.|-- core32.hel1.hetzner.com   0.0%  100    0.5    0.5   0.3    0.8     0.1
       core31.hel1.hetzner.com
 4.|-- core52.sto.hetzner.com    0.0%  100    6.9    6.9   6.8    7.3     0.1
       core53.sto.hetzner.com
       core53.sto.hetzner.com
       core52.sto.hetzner.com
 5.|-- core3.sto.hetzner.com     0.0%  100    7.0   14.7   6.9   61.0    11.1
       core3.sto.hetzner.com
 6.|-- ae7-0.sth10.core-backbone 0.0%  100    7.0    6.9   6.8    7.2     0.1
 7.|-- ae13-2081.fra10.core-back 0.0%  100   24.7   24.4  24.3   24.7     0.1
 8.|-- ae22.cr6-fra2.ip4.gtt.net 0.0%  100   39.1   26.2  22.5   68.1     7.6
 9.|-- 80.150.168.84             6.0%  100  1185.  773.3  26.4  7293.  1311.3
10.|-- p57ba85b5.dip0.t-ipconnec 1.0%  100  1198.  1194.  33.2  7491.  1848.7
11.|-- p57bc9539.dip0.t-ipconnec 2.0%  100  185.6  1179.  36.6  7549.  1914.6

Von Falkenstein hingegen alles gut:

mtr -c 100 --tcp --report 87.188.149.57
Start: 2024-11-11T20:29:14+0100
HOST: rts42d                        Loss%  Snt  Last   Avg  Best  Wrst  StDev
1.|-- rts42.systems.wegewerk.ne      0.0%  100   0.2   0.2   0.2   0.3    0.0
2.|-- 100.85.244.129                 0.0%  100   0.4   0.7   0.3   8.9    1.0
3.|-- core23.fsn1.hetzner.com        0.0%  100   7.5   2.7   0.4  16.6    3.6
      core21.fsn1.hetzner.com
      core22.fsn1.hetzner.com
      core24.fsn1.hetzner.com
4.|-- juniper4.dc2.nbg1.hetzner      0.0%  100  16.8   4.1   2.8  27.0    4.0
      juniper5.dc2.nbg1.hetzner.com
      juniper4.dc2.nbg1.hetzner.com
      juniper5.dc2.nbg1.hetzner.com
      juniper4.dc2.nbg1.hetzner.com
      juniper5.dc2.nbg1.hetzner.com
      juniper5.dc2.nbg1.hetzner.com
      juniper4.dc2.nbg1.hetzner.com
5.|-- 62.157.248.137                 0.0%  100   9.1   6.6   2.9  32.3    5.8
      fr-ea1.fr.de.net.dtag.de
6.|-- p57ba85b5.dip0.t-ipconnec      0.0%  100  12.7  13.3  12.6  40.8    3.2
7.|-- p57bc9539.dip0.t-ipconnec      0.0%  100  16.8  16.7  16.4  17.2    0.2