‎Netzwerkprobleme mit TCP Dup ACK und TCP retransmission aber nur für einen bestimmten Server

Telekom hilft Community

Telekom Business Community

Privatkunden

Telekom Shops

Kontakt

Netzwerkprobleme mit TCP Dup ACK und TCP retransmission aber nur für einen bestimmten Server

vor 6 Monaten

Hallo Telekom-Team,

Ich habe seit gestern ein seltsames Problem bei Aufruf einer Webseite aus dem Telekom-Netz. Die Seite lädt manchmal langsam, manchmal nur teilweise und manchmal gar nicht. Andere Webseiten laden 100% ohne Probleme - z. B. Telekom-Seite, Amazon, Google, Spiegel, Bild, etc.

Das Problem passiert phasenweise (erstmalig gestern (07.11.) zwischen 15.00 und 0.00 Uhr, dann wieder stabil bis heute (08.11.) seit ca. 14.00 Uhr) - innerhalb dieser Phase besteht das Problem nicht permanent, aber die meiste Zeit und immer wieder. Es gibt aber auch kurze Phasen, in denen die Verbindung 100% stabil zu der betroffenen Webseite ist.

Wenn man sich das mit Wireshark ansieht, gibt es (in den Problemphasen) vermehrt Fehlermeldungen wie TCP Dup ACK oder TCP Retransmission (siehe Anhang, betroffene Server-IP 95.217.207.230).

In den wenigen stabilen Phasen, tauchen diese Fehler nicht auf.

Wenn ich die Webseite aus dem O2-Netz oder Vodafone-Netz ansteuere, gibt bzw. gab es aber zu keinem Zeitpunkt Probleme.

Um auszuschließen, dass es nur mit meinem Anschluss zu tun hat, habe ich auch mehrere andere Nutzer der Seite gefragt - und da ist es dasselbe Bild. Nutzer, die die Seite aus dem Telekom-Netz aufrufen haben Probleme - Nutzer, die O2 oder Vodafone verwenden, haben das Problem nicht - auch Nutzer aus Österreich (A1-Netz) haben das Problem nicht.

Woran könnte so etwas liegen und an wen bei der Telekom kann man sich in so einem extrem speziellen Fall wenden?

Vielen Dank für die Hilfe!

2024-11-08 19_18_03-.png

958

vor 6 Monaten
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.
http request bad.PNG
http request bad wireshark.PNG
http request fine.PNG
http request fine wireshark.PNG
cloudflare cdn us bad.PNG
cloudflare cdn us fine.PNG
0
vor 6 Monaten
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.
0
vor 6 Monaten
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.
0
vor 6 Monaten
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.
0

vor 6 Monaten

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:

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

vor 6 Monaten
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.
1
Antwort
von
vor 6 Monaten
Danke für dein Feedback - ja, ich kann auch bestätigen, dass
a) das jetzt auch im Robot gesehen hatte
b) offensichtlich nicht alle Ports betroffen waren
c) es zeitlich begrenzt war, angefangen von ca. 14/15 Uhr bis nachts ca. 0.00 Uhr

Uneingeloggter Nutzer
Antwort
von

vor 6 Monaten

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

Antwort

von

vor 6 Monaten

Danke für dein Feedback. Ich hatte die Webseite am Samstag von Helsinki nach Falkenstein umgezogen, weil ich darauf getippt habe, dass die Probleme "verschwinden" (und so war es dann auch).

Mittlerweile scheint die Telekom das Problem aber gelöst zu haben - zumindest laden die Seiten jetzt einwandfrei und ohne Fehler.

Das ist an sich gut, aber leider wüsste ich jetzt auch nicht, an wen ich mich zukünftig bei der Telekom melden könnte (bei so einem spezifischen Problem) - deshalb war ich etwas "lost", als Hetzner sich nicht darum gekümmert hat und mich an die Telekom verwiesen hat. Und ich habe erst durch @steffenba erfahren, dass Hetzner sich mit der Telekom in Verbindung gesetzt hat (ich wurde weder von Hetzner über das Problem informiert, noch darüber, dass es scheinbar jetzt wieder - seit einigen Stunden - läuft).

Klar, unterm Strich, lag es wohl an einem Gerät bei der Telekom - aber, sowas kann natürlich passieren, aber als Kunde (in diesem Fall von beiden Providern) würde ich mir wünschen, dass so was zeitnah von beiden Seiten analysiert und repariert wird - denn mit diesen Infrastruktur-Problemen möchte ich mich ja gar nicht so intensiv beschäftigen - muss ich aber wohl