Reproduzierbare TCP-Resets (ca. 25 %) zu AWS CloudFront HAM50 – Routing/Peering-Problem

[cr1ebwyn]

Hallo zusammen,

ich habe ein reproduzierbares Problem mit abgebrochenen TCP-Verbindungen zu einem bestimmten Zielnetz. Anschluss und Signalwerte sind unauffällig – es trifft gezielt Verbindungen zu AWS CloudFront über den Standort Hamburg (HAM50).

Angaben zum Anschluss:
- Vertrag: GigaZuhause 1000 Kabel
- Router: FRITZ!Box 6690 Cable (eigenes Gerät), DOCSIS-Software 7.3.5.3.521
- PLZ: 27624
- Anschlussart: Kabel, Dual-Stack (kein DS-Lite)
- PC per LAN direkt an der FRITZ!Box

Symptom:
Ca. 23–27 % aller HTTPS-Verbindungen zu edge.forgecdn.net (AWS CloudFront) werden mit einem TCP-Reset abgebrochen. Betroffen sind alle vier Ziel-IPs aus 99.86.240.0/24. Anwendungen ohne automatische Wiederholung (z. B. die CurseForge-App, PUBG) brechen dadurch komplett ab, Browser kaschieren es durch Retrys.

Signalwerte (damit die Leitung als Ursache ausscheidet):
- Downstream DOCSIS 3.1: 5,8 dBmV, MER 44 dB, 0 nicht korrigierbare Fehler
- Downstream DOCSIS 3.0: Pegel -3,8 bis +7,6 dBmV, MSE -34,9 bis -40,9 dB
- Nicht korrigierbare Fehler: 0 auf allen Kanälen außer Kanal 14 (5 Stück)
- Upstream: 32,0 dBmV (DOCSIS 3.1) bzw. 38–39 dBmV (DOCSIS 3.0)
- 33 Empfangs- und 5 Sendekanäle aktiv

Messungen (mehrfach reproduziert, verschiedene Zeitpunkte):

1) Ausfallrate, 30 Verbindungen in Folge:
7 von 30 Verbindungen mit "Recv failure: Connection was reset". Zweite Messreihe: 16 von 60. Die Abbrüche erfolgen nach ca. 47 ms, erfolgreiche Verbindungen brauchen ca. 160 ms – der Reset kommt also schneller als eine reguläre Antwort, was gegen Überlastung oder Paketverlust spricht.

2) pathping zu 99.86.240.85: 0 % Paketverlust auf allen erreichbaren Hops:
1 fritz.box [192.168.178.1] 0 %
2 95.91.167.252 (kabel-deutschland.de) 0 %
3 83.169.158.117 (kabel-deutschland.de) 0 %
4 83.169.135.20 (kabel-deutschland.de) 0 %
5 145.254.3.122 0 %
6 145.254.2.217 0 %
(ab Hop 7 antwortet AWS nicht auf ICMP)

3) Kontrolltest zu einem Nicht-AWS-Ziel (www.cloudflare.com), 30 Verbindungen: 30 von 30 erfolgreich, 0 Fehler.

4) Gegentest über einen anderen CloudFront-Standort: Nach Umstellung des DNS-Resolvers werde ich nach Amsterdam (AMS56, 3.173.161.0/24) geleitet – dort 30 von 30 Verbindungen fehlerfrei. Über VPN ebenfalls fehlerfrei.

Einschätzung:
Signalwerte sind einwandfrei, ICMP läuft verlustfrei durch, andere Ziele funktionieren fehlerfrei, und derselbe Dienst ist über einen anderen CloudFront-Standort problemlos erreichbar. Ich vermute daher ein defektes oder überlastetes Gerät am Peering-Übergang Richtung AWS/HAM50 – vermutlich hinter Hop 145.254.2.217.

Könntet ihr das bitte an den 2nd-Level-Support bzw. das Netzwerkteam weitergeben? Weitere Messreihen kann ich jederzeit liefern.

Viele Grüße

[andreasabaad]

Hier im reinen Kunden helfen Kunden Forum kann niemand irgendetwas weiterleiten! Schließe zum Gegentesten mal das Leihgerät an. Wenn der Fehler dann immernoch besteht, melde das dem technischen Support!

[Sigi-DD]

Hallo cr1ebwyn,

welche Modulation haben die 5 Kanäle im Upload?

Viele Grüße Siegmar

[cr1ebwyn]

Hallo Siegmar,

danke fürs Draufschauen. Hier die Upstream-Kanäle im Detail:

DOCSIS 3.1 (1 Kanal):

- Kanal 43: 256QAM, 29,775–64,775 MHz, 32,0 dBmV, 640 aktive Subcarrier, FFT 2K

DOCSIS 3.0 (4 Kanäle, alle ATDMA):

- Kanal 9: 64QAM, 51,000 MHz, 39,0 dBmV

- Kanal 10: 64QAM, 44,600 MHz, 39,0 dBmV

- Kanal 11: 64QAM, 37,200 MHz, 38,0 dBmV

- Kanal 12: 64QAM, 30,800 MHz, 38,0 dBmV

Also 64QAM auf allen vier 3.0-Kanälen, keine Degradierung auf 32QAM oder QPSK. Die Sendepegel liegen bei 38–39 dBmV bzw. 32 dBmV auf dem OFDMA-Kanal, also im unteren Normbereich.

Auch im Downstream sind die Werte unauffällig: DOCSIS 3.1 mit 4096QAM, 5,8 dBmV und MER 44 dB, null nicht korrigierbare Fehler; die 3.0-Kanäle zwischen -3,8 und +7,6 dBmV mit MSE -34,9 bis -40,9 dB. Nicht korrigierbare Fehler nur auf Kanal 14 (5 Stück) – bei der kurzen Verbindungsdauer nach einem Neustart wohl vernachlässigbar.

Zur Einordnung: Der Fehler tritt sehr selektiv auf. Verbindungen zu anderen Zielen laufen fehlerfrei (30 von 30 zu einem Nicht-AWS-Ziel), und derselbe Dienst über einen anderen CloudFront-Standort (Amsterdam) ebenfalls 30 von 30. Betroffen sind ausschließlich Verbindungen über HAM50 bzw. 99.86.240.0/24, dort dann rund jede vierte. Ein reines Signal- oder Leitungsproblem würde ich daher eher ausschließen – aber falls dir an den Werten doch etwas auffällt, sag gern Bescheid.

Viele Grüße

[cr1ebwyn]

Moin, 

Habe leider kein Leihgerät.

LG

[Sigi-DD]

Hallo cr1ebwyn,

ich kann auch da im Upload nichts auffälliges finden. Wenn Du nicht schon einen Dual Stack Anschluss hättest, dann würde ich auf Probleme mit dem AFTR Gateway tippen, da es immer IPv4 Adressen sind mit den Du Probleme hast. Könnte es Probleme mit einem DNS Server bei Dir geben? Durchsuche doch mal die Reports "Internetverbindung" und "System" nach Meldungen zu der Zeit, wenn es mal wieder Probleme gibt. Da könnte es immer vorher einen Ausfall eines DNS Servers geben. Bei der Fritz-Box gibt es die Möglichkeit dann automatisch auf einen öffentlichen DNS Server umzustellen.

Viele Grüße Siegmar

[ArthurGabri]

Das klingt nach einem Problem, das sich nur durch eine genaue Analyse des Routings eingrenzen lässt. Wenn die TCP-Resets reproduzierbar sind, sind die gesammelten Tests und Logs auf jeden Fall hilfreich, um den Fehler weiter einzugrenzen.