TCP-Retransmission-Spike: Netzwerk oder Anwendung?

Ein TCP-Retransmission-Spike ist eines der stärksten Frühwarnsignale für degradierte Servicequalität – und gleichzeitig eine der häufigsten Quellen für Eskalationskonflikte: „Das Netzwerk droppt Pakete“ versus „die Anwendung/der Host ist überlastet“. Retransmissions entstehen immer dann, wenn der Sender ein Segment nicht bestätigt bekommt und es erneut senden muss. Das kann echte Paketverluste bedeuten, aber genauso gut verzögerte ACKs, überfüllte Queues, asymmetrisches Routing über stateful Geräte, MTU/PMTUD-Probleme oder ein Empfänger, der unter Last nicht mehr zeitnah verarbeitet. Operativ ist deshalb nicht die Frage, ob retransmittiert wird – sondern warum und wo in der End-to-End-Kette die Bestätigung ausbleibt. Dieses Playbook zeigt, wie Sie einen TCP-Retransmission-Spike strukturiert triagieren, welche Messpunkte aussagekräftig sind, wie Sie Netzwerk- und Anwendungsursachen sauber trennen und wie Sie Evidence so dokumentieren, dass die richtige Ownership in Minuten klar ist. Der Fokus liegt auf praxistauglichen Checks für NOC und On-Call, ohne sich in Paketmitschnitten zu verlieren – mit optionalen Deep-Dive-Schritten, wenn die erste Diagnose nicht reicht.

Was TCP-Retransmissions technisch bedeuten

TCP ist zuverlässig, weil es Zustellung über Sequenznummern und Bestätigungen (ACKs) absichert. Fehlt eine Bestätigung innerhalb des Retransmission Timeout (RTO), sendet der Sender das Segment erneut. Ein Spike in Retransmissions ist daher ein Symptom für „fehlende oder verspätete Bestätigungen“ – nicht automatisch für „kaputtes Netzwerk“.

• Echter Verlust: Ein Segment oder ein ACK geht unterwegs verloren.
• Starker Jitter/Delay: ACKs kommen zu spät, der Sender hält sie für verloren.
• Receiver-Engpass: Empfänger kann nicht schnell genug lesen/verarbeiten, Window wird klein/0, ACK-Verhalten verschiebt sich.
• Middlebox-Effekte: Firewalls, NAT, Load Balancer oder Proxy verändern Timing oder droppen selektiv.

Für die Grundlagen von TCP-Mechanik, Retransmission und Congestion Control ist RFC 9293 eine zentrale Referenz.

Warum ein Retransmission-Spike so oft falsch eingeordnet wird

In der Praxis sehen unterschiedliche Teams unterschiedliche Teile der Wahrheit. Das Netzwerkteam sieht Interface-Errors oder Queue-Drops (oder eben nicht). Das App-Team sieht erhöhte Latenzen, Timeouts und Retries. Beide interpretieren die Retransmissions aus ihrer Perspektive. Ein operativ gutes Vorgehen bringt beide Sichten zusammen: Sender-, Empfänger- und Pfaddaten müssen konsistent sein.

• Netzwerk sagt „keine Drops“: Viele Drops passieren in Software-Queues, Host-Stacks, Virt-Overlays oder unsichtbaren Buffern.
• App sagt „Timeouts“: Timeouts können auch durch CPU-Scheduling, GC-Pausen oder Connection-Pool-Exhaustion entstehen.
• Monitoring verzerrt: Retransmissions können an einem Hotspot (z. B. einem LB) den Gesamteindruck dominieren.

Retransmission-Arten erkennen: RTO vs. Fast Retransmit

Für die Ursachenanalyse ist entscheidend, ob Retransmissions eher durch RTO (Timeout-basiert) oder durch Fast Retransmit (Duplicate ACKs) ausgelöst werden. Das lässt sich oft schon aus Metriken oder einem kurzen Capture ableiten.

• RTO-Retransmissions: sprechen eher für fehlende ACKs, starke Latenzspitzen, Blackholes oder harte Drops.
• Fast Retransmit: spricht eher für sporadische Verluste bei weiterhin fließendem Verkehr (DupACKs kommen an), häufig durch Congestion/Queue-Drops.
• Spikes bei bestimmten Flows: deutet auf ECMP „bad member“, MTU/PMTUD oder Middlebox-Policy hin.

Vereinfachtes RTO-Backoff (MathML)

$\mathrm{RTO}\to \mathrm{RTO}\times 2^k$

Bei wiederholtem Ausbleiben von ACKs wächst RTO typischerweise exponentiell. Operativ heißt das: Wenn Latenzen plötzlich „explodieren“, kann ein initial kleiner Verlust/Jitter zu massiven Verzögerungen führen, obwohl die Verbindung nicht komplett abreißt.

Symptommuster: Wie Retransmission-Spikes in Observability aussehen

Retransmissions sind selten allein. Meist korrelieren sie mit weiteren Signalen. Diese Korrelationen sind der schnellste Weg zur Ursache.

• Retransmissions + Queue Drops: häufig Congestion auf einem Link/Interface oder in einem Virt-Path.
• Retransmissions + steigende RTT: Bufferbloat, Überlast, Scheduling-Engpass, oder Pfadänderung.
• Retransmissions + keine RTT-Änderung: eher sporadischer Verlust, ECMP-Teilpfad, physische Errors.
• Retransmissions + Window Shrink/Zero Window: Receiver ist überfordert oder Application Read ist zu langsam.
• Retransmissions nur bei großen Transfers: MTU/PMTUD, Fragmentation/Blackhole oder MSS/Clamping-Probleme.

Der 10-Minuten-Decision-Tree: Netzwerk oder Anwendung?

Der Schlüssel ist eine strukturierte Reihenfolge. Sie brauchen zuerst: Scope, Richtung, und die Frage „Wer sieht den Verlust – Sender, Empfänger oder das Netz?“

• 1) Scope bestimmen: Betrifft es alle Services, nur einen Cluster, nur eine AZ, nur einen Standort, nur einen LB?
• 2) Richtung bestimmen: Retransmissions auf Client→Server, Server→Client oder beidseitig?
• 3) RTT und Jitter prüfen: Steigt die RTT parallel? Gibt es Periodik (z. B. alle 60 Sekunden)?
• 4) Loss-/Drop-Indikatoren prüfen: Interface drops, queue drops, discards, CRC, overruns, ECN/RED.
• 5) Host-Indikatoren prüfen: CPU, softirq, NIC ring drops, tcp retrans, backlog drops, socket errors.
• 6) Middleboxes prüfen: NAT/Firewall/LB: conntrack, SNAT pool, state drops, asymmetry, policy changes.
• 7) ECMP/Path-Spezifik prüfen: Nur manche Flows? Dann ECMP-Mitglieder, Hashing, „bad member“ isolieren.

Netzwerk-Ursachen: Die häufigsten Trigger für Retransmission-Spikes

Wenn das Netzwerk der Treiber ist, finden Sie oft Indikatoren in Countern, Telemetrie oder in klaren Korrelationen zu Last und Pfad. Wichtig: Nicht jeder Loss ist als „drop“ auf einem Interface sichtbar. Trotzdem gibt es Muster, die sehr typisch sind.

• Congestion/Queue Drops: Mikrobursts, Oversubscription, egress queue overflow, policer drops.
• Physische Degradation: CRC/Interface errors, optische Leistung am Limit, fehlerhafte Kabel/SFP.
• ECMP „Bad Member“: ein Teilpfad droppt; nur manche Flows betroffen; Retransmissions steigen selektiv.
• MTU/MSS-Probleme: Path MTU Discovery blockiert, falsches MSS-Clamping, Fragmentation/Blackhole.
• Asymmetrisches Routing: Rückverkehr über andere stateful Instanz, SYN/ACK/ACK Timing bricht, Retransmissions steigen.
• Policing/Rate-Limits: Carrier oder interner policer droppt bursty Traffic; Retransmissions steigen, RTT kann stabil bleiben.

MTU/PMTUD als Retransmission-Treiber

PMTUD-Probleme führen häufig nicht zu „Link down“, sondern zu selektiven Verlusten bestimmter Paketgrößen. Typisch sind Retransmissions bei TLS-Handshakes oder bei Antworten, die größer als MSS/MTU sind. Für IPv6 ist RFC 8201 relevant, für allgemeine TCP-Interaktion mit PMTUD ist auch das Host-Verhalten aus RFC 1122 nützlich.

Anwendungs- und Host-Ursachen: Wenn Retransmissions „von innen“ kommen

Viele Retransmission-Spikes sind Folge eines überlasteten Empfängers oder eines Hosts, der Pakete zwar empfängt, aber nicht schnell genug verarbeitet. Das ist besonders häufig bei virtualisierten Umgebungen, Containern, oder bei CPU-Spikes durch GC/Encryption.

• Receiver Window wird klein/0: Anwendung liest zu langsam; Kernel signalisiert Backpressure.
• CPU-/Scheduling-Engpässe: ACKs kommen zu spät; Sender interpretiert das als Verlust (RTO).
• NIC/Ring Buffer Drops: Treiber/IRQ/softirq überlastet; Drops passieren auf dem Host, nicht auf dem Switch.
• Load Balancer überlastet: Frontend nimmt an, Backend ist langsam; Retransmissions häufen sich in einer Richtung.
• Connection Pool/Thread Pool Exhaustion: App nimmt Verbindungen an, kann aber nicht bedienen; Latenz steigt, Retransmits folgen.

Zero-Window und Application Backpressure als klares Signal

Wenn Sie in Metriken oder Captures sehen, dass das Receiver Window schrumpft oder Zero-Window-Events auftreten, ist das ein starkes Argument für eine Host-/App-Ursache. Das Netz kann dennoch Mitursache sein (z. B. zusätzliche RTT), aber die Ownership liegt dann selten primär beim Transportnetz.

Dual-Stack und DNS: Wenn IPv6-Probleme als Retransmission-Spike erscheinen

Dual-Stack-Umgebungen erzeugen Edge-Cases: Ein Teil der Clients nutzt IPv6 und trifft auf instabile Pfade, während IPv4 stabil ist. Retransmission-Spikes können dann „nur“ im IPv6-Subset sichtbar sein, wirken aber groß, weil wichtige Services betroffen sind. Happy Eyeballs führt zu Retries und Parallel-Connects, die das Signal verstärken. Eine Referenz ist RFC 8305.

• Indikator: Retransmissions steigen nur auf IPv6-Interfaces/Flows, IPv4 bleibt stabil.
• Ursache: ND/RA-Instabilität, PMTUD-Blackhole, IPv6-Firewall-Policy, asymmetrisches IPv6-Routing.
• Bestätigung: getrennte SLI/SLOs für IPv4 vs. IPv6, getrennte Flow-Metriken.

Bestätigung ohne Packet Capture: Metriken, die wirklich helfen

Ein Packet Capture ist ideal, aber nicht immer sofort möglich. In vielen Fällen reichen gute Metriken, wenn Sie sie richtig kombinieren. Wichtig ist, nicht nur „Retransmissions“ zu betrachten, sondern Kontextsignale.

• RTT/RTTVAR: steigt RTT parallel zum Spike?
• Packet Loss/Discards: Interface discards, queue drops, policer drops, WRED/ECN.
• Host tcp_retrans / segments retransmitted: Host-seitig erhöht?
• Socket Errors: listen drops, backlog overflows, accept queue issues.
• Flow-Symmetrie: sind nur bestimmte Pfade/Next Hops betroffen?

Wenn Sie doch capturen: Welche drei Dinge Sie zuerst prüfen

Falls Sie die Möglichkeit haben, kurz zu capturen (am Sender, am Empfänger oder auf einer Middlebox), sind diese Punkte besonders aussagekräftig:

• DupACKs vs. RTO: Gibt es viele Duplicate ACKs (Fast Retransmit) oder Retransmissions nach Timeout?
• ACK-Delay: kommen ACKs verspätet, aber regelmäßig? Das spricht eher für Receiver/Queueing.
• Richtung: Retransmissions hauptsächlich in eine Richtung? Dann Pfad/Policy/Interface in dieser Richtung fokussieren.

Dokumentation für Ownership: So schreiben Sie das Ticket, damit es nicht ping-pongt

Damit ein Retransmission-Incident nicht zwischen Teams hängen bleibt, müssen Sie Evidence in einheitlicher Form liefern. Das Ziel ist: „Netzwerk- oder Host-/App-Ursache?“ nicht als Meinung, sondern als belegte Hypothese.

• Scope: betroffene Services, Standorte, AZs, Subnetze, nur ein Cluster oder global?
• Richtung: Client→Server, Server→Client, oder beidseitig.
• Korrelationen: RTT/Queue-Drops/Host-CPU/Conntrack/NAT/ECMP – was steigt zeitgleich?
• Top Talkers/Flows: welche Quellen/Ziele dominieren den Spike?
• Change-Korrelation: Releases, Netzwerk-Changes, Policy-Änderungen, neue Traffic-Patterns.
• Mitigation: welche Maßnahme wurde getestet (z. B. ECMP-Mitglied entfernt, Pool erweitert, Rate-Limit), und welcher Effekt trat ein?

Outbound-Links für Standards und vertiefende Referenzen

• RFC 9293 (Transmission Control Protocol) für Retransmission, ACK-Verhalten und TCP-Grundmechanik.
• RFC 5681 (TCP Congestion Control) für Congestion Avoidance, Fast Retransmit/Recovery und typische Muster bei Verlust.
• RFC 1122 (Requirements for Internet Hosts) für Host-Stack-Verhalten, ICMP/PMTUD-Interaktion und Robustheit.
• RFC 8201 (Path MTU Discovery for IPv6) für MTU-Blackholes und retransmission-getriebene Latenzspitzen.
• RFC 8305 (Happy Eyeballs v2) für Dual-Stack-Effekte, die Retries und Retransmissions beeinflussen können.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.