Retransmissions messen ohne PCAP

Retransmissions messen ohne PCAP bedeutet, TCP-Wiederholungen (und verwandte Signale wie RTOs, DupACKs oder Lost Segments) zuverlässig zu quantifizieren, ohne Pakete mitzuschneiden und zu analysieren. Das ist in der Praxis häufig die bessere Wahl: Paketmitschnitte sind auf Produktionssystemen oft schwer genehmigungsfähig, erzeugen hohe Datenmengen, können sensible Payload enthalten und sind bei verteilten Systemen schwer zu korrelieren. Gleichzeitig sind Retransmissions ein sehr starkes Symptom für echte Transportprobleme: Paketverlust, Queueing, MTU/Fragmentierung, fehlerhafte Offloads, überlastete NICs, Drops im Overlay, asymmetrische Pfade oder schlicht übervolle Buffers. Der Schlüssel ist, Retransmissions über Telemetrie-Schichten zu messen, die ohnehin existieren: Kernel-Zähler, Socket-Statistiken, eBPF/Tracepoints, NIC- und Treiberstatistiken sowie (in Mesh- und Proxy-Setups) L7/L4-Metriken, die indirekt auf Retransmits hinweisen. Dieser Artikel zeigt konkrete Messmethoden, wie Sie Zahlen korrekt interpretieren, welche Kennzahlen sich als SLI eignen und wie Sie aus „Retransmissions steigen“ systematisch zu einer Ursache kommen – ohne PCAP, aber mit belastbarer Evidenz.

Was genau ist eine Retransmission – und warum ist sie so aussagekräftig?

Eine Retransmission ist eine erneute Übertragung von TCP-Daten, wenn der Sender annimmt, dass ein Segment verloren ging oder nicht korrekt angekommen ist. Das passiert typischerweise über zwei Mechanismen: Fast Retransmit (ausgelöst durch mehrere Duplicate ACKs) und Retransmission nach Timeout (RTO), wenn keine Bestätigung innerhalb eines Zeitfensters eintrifft. Retransmissions sind nicht per se „Fehler“ – TCP ist dafür gebaut –, aber sie sind ein zuverlässiger Indikator für ein Transportproblem oder für extreme Latenz/Queueing, das wie Verlust wirkt. Für ein solides Begriffsverständnis und die Mechanik von TCP sind die aktuellen TCP-Spezifikationen eine gute Referenz: RFC 9293 (TCP).

Warum PCAP nicht immer die beste Wahl ist

PCAP liefert Detailtiefe, ist aber operativ teuer. Ohne PCAP zu messen ist oft sinnvoll, wenn:

• Datenschutz/Compliance Payload-Mitschnitte verbietet oder stark einschränkt.
• Performance nicht beeinträchtigt werden darf (Capture kann CPU/IO kosten).
• Skalierung wichtig ist (viele Nodes/Pods; PCAP wird schnell unhandlich).
• Ursache lokalisiert werden soll (zuerst „wo“ und „wie viel“, dann ggf. gezielt PCAP).

Telemetrie-basierte Messung liefert genau das, was Sie für Incident Response meist zuerst brauchen: Verlauf über Zeit, Vergleich zwischen Nodes/Services und klare Trends.

Messstrategie: Auf welcher Ebene wollen Sie Retransmissions sehen?

„Retransmissions“ können Sie auf unterschiedlichen Ebenen erfassen. Jede Ebene beantwortet eine andere Frage:

• Host/Kernel-Ebene: „Hat dieser Node ein generelles Netzwerk-/NIC-/Kernelproblem?“
• Socket-Ebene: „Welche konkrete Verbindung ist betroffen (Ziel, Port, RTT, cwnd, RTO)?“
• Service/Workload-Ebene: „Welche Applikation oder welcher Pod verursacht/erlebt Retransmits?“
• Netzwerkgerät/Interface-Ebene: „Gibt es Drops, Errors oder Overruns auf NIC/Driver/Queue?“
• Proxy/Mesh-Ebene: „Sehen wir Symptome (Resets, Upstream-Timeouts), die zu L4-Problemen passen?“

In der Praxis starten viele Teams auf Host-Ebene (schnell, standardisiert), gehen dann auf Socket- oder Workload-Ebene (gezielter), und korrelieren abschließend mit NIC- und Infrastrukturmetrik.

Kernel-Zähler: Retransmissions ohne PCAP auf Linux-Nodes

Die robusteste Basis sind Kernel-Statistiken, weil TCP die Retransmissions selbst auslöst und zählt. Auf Linux finden Sie relevante Counters in /proc und über Standardtools.

/proc/net/snmp und /proc/net/netstat

Viele TCP-Zähler stehen in /proc/net/snmp und /proc/net/netstat. Typische Felder sind (je nach Kernel): Segmente gesendet/empfangen, Retransmissions, RTO-Ereignisse, ListenOverflows usw. Diese Dateien sind maschinenlesbar und eignen sich gut für Exporter.

• Vorteil: sehr geringe Overhead-Kosten, systemweit verfügbar.
• Nachteil: aggregiert (nicht pro Pod/Service), Interpretation braucht Kontext.

Grundlagen zu procfs und Netzstatistiken sind in der Linux-Dokumentation beschrieben: Linux Kernel Dokumentation: procfs.

netstat -s und ss -s

netstat -s (aus net-tools) und ss -s (iproute2) können TCP-Statistiken zusammenfassen, inklusive Retransmits. Für Produktionsumgebungen ist ss oft bevorzugt, weil iproute2 aktiv gepflegt wird: ss(8) Manpage.

Node Exporter und Prometheus-Metriken

Wenn Sie Prometheus einsetzen, ist der übliche Weg, Kernel-Counters über den Node Exporter zu sammeln. Dort finden Sie u. a. TCP-Segmente, Retransmissions und verwandte Zähler als Zeitreihen. Dokumentation und Collector-Übersicht: Prometheus Node Exporter.

Eine sinnvolle Kennzahl: Retransmission Rate statt nur „Anzahl“

Absolute Retransmission-Zahlen sind schwer vergleichbar, weil sie stark von Traffic-Volumen abhängen. Praktischer ist eine Rate, die Retransmissions ins Verhältnis zu ausgehenden Segmenten setzt. Dadurch können Sie Nodes/Services vergleichen und Schwellen sinnvoller definieren.

$\mathrm{RetransmissionRate}=\frac{\mathrm{retransmitted\_segments}}{\mathrm{outgoing\_segments}}\times 100$

Als Daumenregel (sehr abhängig von Workload und RTT): Eine dauerhaft erhöhte Rate ist verdächtig, insbesondere wenn sie mit p95/p99-Latenz, Timeouts oder sinkendem Durchsatz korreliert. Einzelne Peaks können normal sein (Traffic-Bursts, kurze Congestion-Phasen), wiederkehrende Muster sind relevanter.

Socket-Ebene: Retransmissions pro Verbindung sichtbar machen

Wenn Sie wissen wollen, welche Verbindung Retransmissions verursacht, reicht System-Aggregation nicht mehr. Dann brauchen Sie Socket-Telemetrie.

ss -i: RTT, RTO, cwnd und Retransmits im Kontext

ss -i zeigt pro Socket zusätzliche TCP-Infos wie RTT, RTO, Congestion Window (cwnd), SACK-Status und (je nach Ausgabe) Retransmission-bezogene Felder. Das ist besonders hilfreich, um zu unterscheiden:

• Loss/Congestion: cwnd schwankt, RTT steigt, Retransmits steigen.
• RTO-Probleme: hohe RTOs, Timeouts, stark schwankende RTT.
• Path-MTU/Blackhole: große Writes hängen, kleine funktionieren (oft indirekt sichtbar über Zeitouts/Backoff).

Referenz: ss(8) und für TCP-Optionen/Diagnosewerte die iproute2-Dokumentation: iproute2 Überblick.

TCP_INFO über Applikationsmetriken

Viele Sprachen und Proxys können TCP_INFO (Socket-Option) auslesen und damit Metriken wie RTT, Retransmits, unacked, snd_cwnd erfassen. Das ist eine elegante Methode, wenn Sie pro Service messen wollen, ohne Kernel-weite Aggregation. Wichtig ist dabei die Kardinalität: Messen Sie nicht pro Connection-ID, sondern aggregieren Sie pro Zielservice oder pro Pool.

eBPF/Tracepoints: Retransmissions präzise messen, ohne Payload zu erfassen

eBPF ist in vielen Produktionsumgebungen der Sweet Spot: sehr detailliert, aber ohne PCAP-Payload. Sie können Retransmissions an Kernel-Events (Tracepoints/Kprobes) binden und pro Prozess, cgroup, Pod oder Zieladresse aggregieren.

bcc/bpftrace: Schnelle Werkzeuge für TCP-Retransmits

Tool-Sammlungen wie BCC enthalten fertige Scripts (z. B. zur Erfassung von TCP Retransmits), die über eBPF Kernel-Events auswerten. Das ermöglicht Aussagen wie „welcher Prozess/Pod verursacht Retransmits“ oder „welches Ziel ist auffällig“. Einstieg in BCC: iovisor/bcc. Für bpftrace als deklaratives Tool ist die offizielle Doku hilfreich: bpftrace.

• Vorteil: Hohe Genauigkeit, Pod-/cgroup-Zuordnung möglich, kein Payload.
• Nachteil: Operative Reife nötig (Kernel-Kompatibilität, Rechte, Governance).

Was Sie mit eBPF zusätzlich gewinnen

Neben Retransmissions können Sie weitere Signale erfassen, die ohne PCAP schwer greifbar sind:

• RTO-Events (Timeout-basierte Retransmits sind meist gravierender als Fast Retransmit).
• Congestion-Phasen (cwnd reductions, pacing-Änderungen).
• Pod-/Namespace-Zuordnung über cgroups (besonders in Kubernetes nützlich).

NIC- und Treiberstatistiken: Drops und Errors, die Retransmits auslösen

Retransmissions sind oft die Folge von Drops unterhalb von TCP: NIC-Ring voll, RX/TX-Queue-Overruns, Treiberfehler, CRC-Errors oder Drops durch qdisc/Traffic Shaping. Daher ist es wichtig, Interface-Statistiken parallel zu betrachten.

ethtool -S und klassische Interface-Counter

Mit ethtool -S erhalten Sie treiberspezifische Zähler, die in ip -s link nicht sichtbar sind (z. B. RX_missed_errors, tx_queue_* drops, ring buffer issues). Referenz: ethtool(8) Manpage.

• Hinweis: Ein Anstieg von RX/TX Drops oder Errors korreliert häufig direkt mit steigenden Retransmissions.
• Praktikabel: Wenn Retransmissions steigen, prüfen Sie zuerst: Drops/Errors, CPU saturation, IRQ-Last, softnet backlog.

softnet_stat und CPU/IRQ-Sättigung

Auf Linux können Drops auch durch Überlast in der Netzwerkverarbeitung entstehen (softirq, backlog). In solchen Fällen sehen Sie oft steigende Retransmits und Indikatoren für RX-Verarbeitung, die nicht hinterherkommt. Hier lohnt die Korrelation mit CPU, IRQ-Verteilung, NIC-Queues und ggf. RSS/RPS-Konfiguration.

Kubernetes: Retransmissions pro Node und näher an Pods bringen

In Kubernetes ist der erste Schritt meist Node-Ebene: Node Exporter + Dashboard nach Node/Zone. Das beantwortet schnell: „Ist es ein einzelner Node oder das ganze Cluster?“ Der zweite Schritt ist Pod-Nähe, ohne PCAP.

• cgroup-basierte eBPF-Aggregation: Retransmits pro Pod/Namespace sichtbar machen.
• Socket-Metriken aus Sidecars: Wenn ein Mesh im Einsatz ist, kann Proxy-Telemetrie indirekte Symptome liefern (Upstream connect failures, timeouts, resets) und helfen, betroffene Services zu identifizieren.
• Workload-Korrelation: Retransmissions steigen nur bei bestimmten Deployments → Verdacht auf MTU, Policy, spezifische Pfade, bestimmte Ziel-Services.

Wichtig: CNI/Overlay kann Drops verursachen, die auf Host-Interface-Counters nicht immer klar sichtbar sind. Daher ist es wertvoll, eBPF an den richtigen Hooks zu platzieren oder CNI-spezifische Metriken zu nutzen, wenn verfügbar.

Interpretationsfallen: Wann Retransmissions „falsch“ wirken können

Ohne PCAP müssen Sie Retransmissions sauber interpretieren. Typische Fallstricke:

• Offloads (TSO/GSO/GRO): Segmente werden im Stack aggregiert oder später segmentiert; Counters bleiben korrekt, wirken aber manchmal „sprunghaft“.
• Asymmetrische Pfade: Retransmits messen Sie am Sender; Ursache kann auf dem Rückweg (ACK-Loss) liegen.
• Load Balancer und NAT: Verbindungen können umgebrochen oder neu aufgebaut werden; das erzeugt Timeouts/Resets, die wie Loss-Symptome aussehen.
• Kleine vs. große Payloads: MTU-Probleme zeigen sich oft als „small works, large fails“; Retransmits steigen dann vor allem bei großen Writes.
• Retry-Storms: Applikations-Retries erhöhen Traffic und damit auch Retransmits; Ursache und Verstärker müssen getrennt betrachtet werden.

Praktisches Vorgehen: Runbook zur Messung ohne PCAP

Ein strukturierter Ablauf hilft, ohne PCAP schnell zu belastbaren Aussagen zu kommen.

• Schritt 1: Scope klären – Betrifft es wenige Nodes, eine Zone, einen Service oder alles?
• Schritt 2: Kernel-Counter prüfen – Retransmissions und outgoing segments als Zeitreihe; daraus eine Retransmission Rate ableiten.
• Schritt 3: Korrelation herstellen – p95/p99 Latenz, Timeouts, Throughput-Drops, CPU/IRQ, NIC-Drops/Errors.
• Schritt 4: Socket-Drilldown – Betroffene Ziele/Ports/RTT/RTO über ss -i identifizieren.
• Schritt 5: Pod-/Service-Zuordnung – eBPF/cgroup oder Proxy-Telemetrie nutzen, um den Verursacher zu isolieren.
• Schritt 6: Hypothese testen – z. B. MTU prüfen, Queueing/Traffic Shaping analysieren, Offloads vergleichen, Upstream-Pfad prüfen.

Der Vorteil dieses Vorgehens: Sie können sehr oft bereits auf Schritt 3 oder 4 eine klare Richtung erkennen, ohne jemals Payload anzufassen.

Dashboards und Alerts: Welche Signale wirklich „incident-tauglich“ sind

Für eine kontinuierliche Überwachung sind wenige, gut gewählte Panels besser als viele Detailcharts:

• Retransmission Rate (Node) – nach Node/Zone/Cluster, mit p95/p99 App-Latenz korreliert.
• Absolute Retransmits/s – um Impact zu sehen, unabhängig vom Traffic-Verhältnis.
• NIC Drops/Errors – RX/TX drops, errors, overruns, missed (wenn verfügbar).
• CPU/IRQ/softnet – Sättigungssignale, die Drops und Retransmits erklären.
• Service-Symptome – Timeouts, Resets, Upstream connect failures (insbesondere bei Proxys).

Alerting sollte vorsichtig sein: Retransmits können kurzzeitig steigen. Actionable Alerts basieren oft auf „Retransmission Rate über Baseline“ plus gleichzeitiger Verschlechterung von Latenz oder Fehlerquote.

Outbound-Quellen für vertiefende Informationen

• RFC 9293: Transmission Control Protocol (TCP)
• RFC 6298: Computing TCP’s Retransmission Timer (RTO)
• ss(8) Manpage: Socket-Statistiken und TCP-Infos
• ethtool(8) Manpage: NIC- und Treiberstatistiken
• Prometheus Node Exporter: Kernel-/Netzwerk-Counter als Metriken
• BCC (eBPF Tools): TCP-Retransmit-Analysen ohne Payload
• bpftrace: eBPF-basierte Tracing-Queries
• Linux Kernel Dokumentation: procfs und Systemstatistiken

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.