Wireshark fürs NOC: TCP-Handshake und Retransmissions lesen

Wireshark fürs NOC ist dann am wertvollsten, wenn Sie in kurzer Zeit zwei Dinge zuverlässig lesen können: den TCP-Handshake (kommt die Verbindung überhaupt sauber zustande?) und Retransmissions (werden Daten wirklich sauber übertragen oder kaschiert TCP gerade Netzprobleme durch Wiederholungen?). Genau diese beiden Themen decken einen großen Teil typischer Incidents ab: „Service ist langsam“, „nur ein Teil der Verbindungen bricht“, „Timeouts treten sporadisch auf“, „Uploads hängen“, „API-Calls sind unzuverlässig“ oder „nach einem Change ist es plötzlich instabil“. Wireshark macht diese Symptome sichtbar, weil es Paketfolgen und TCP-Mechanik detailliert aufschlüsselt – inklusive Sequenznummern, ACK-Logik, Window-Größen, SACK, Retransmissions, Dup ACKs, Fast Retransmit und RTO. Gleichzeitig ist Wireshark nur so gut wie der Capture: Falscher Capture-Punkt, SPAN/ERSPAN-Drops oder Offloading können die Interpretation verfälschen. Dieser Artikel zeigt Ihnen deshalb einen NOC-tauglichen Workflow: wie Sie einen TCP-Handshake schnell verifizieren, wie Sie Retransmissions in Wireshark sicher erkennen, wie Sie die häufigsten Ursachen unterscheiden (Loss, Congestion, MTU, Asymmetrie, Firewall-State, Server-Overload) und welche Anzeigen und Filter in 80% der Fälle reichen, ohne dass Sie sich in Details verlieren.

Vorbereitung: Voraussetzungen für einen verwertbaren Wireshark-Trace

Bevor Sie im Trace „TCP-Probleme“ diagnostizieren, stellen Sie sicher, dass die Datengrundlage stimmt. Viele Fehlinterpretationen entstehen, weil Captures unvollständig oder am falschen Ort sind.

• Capture-Punkt bewusst wählen: Idealerweise so nah wie möglich am betroffenen Client oder Server. Captures „irgendwo im Core“ können Asymmetrie oder ECMP verdecken.
• Beidseitige Sicht bevorzugen: Handshake- und Retransmission-Interpretation ist am zuverlässigsten, wenn Sie beide Richtungen sehen (Requests und Responses).
• SPAN/ERSPAN beachten: Oversubscription kann genau die Pakete droppen, die Sie sehen wollen. Ein „sauberer“ Trace ohne Retransmissions beweist dann nichts.
• Offloading im Blick: GRO/LRO/TSO können dazu führen, dass Wireshark große „zusammengefasste“ Segmente zeigt. Für präzise TCP-Analyse sind Captures ohne solche Effekte ideal.

Für Tool- und Feature-Übersicht ist die offizielle Seite Wireshark eine gute Referenz.

Wireshark-Workflow fürs NOC: In 3 Minuten zum ersten Befund

Im NOC zählt Geschwindigkeit. Der folgende Ablauf ist ein praxiserprobtes Minimal-Playbook, bevor Sie tief in Sequenznummern einsteigen.

• 1) Auf eine Verbindung fokussieren: Nutzen Sie „Follow TCP Stream“, um einen konkreten Flow zu isolieren.
• 2) Handshake prüfen: SYN → SYN/ACK → ACK vorhanden?
• 3) Retransmissions/Dup ACKs checken: Gibt es Wiederholungen oder Hinweise auf Loss/Congestion?
• 4) Zeitverhalten betrachten: RTT-Anmutung, Pausen, RTOs, Burst-Muster.
• 5) Ursache eingrenzen: Loss, Stau, MTU, Firewall/State, Server-Overload oder Asymmetrie?

Dieser Ablauf reduziert das Risiko, sich in Nebenbefunden zu verlieren.

TCP-Handshake verstehen: Was „gesund“ aussieht

Der klassische TCP-Handshake besteht aus drei Segmenten: SYN, SYN/ACK, ACK. In Wireshark erkennen Sie sie direkt in der Info-Spalte (Flags) und im TCP-Header.

Das 3-Wege-Handshake-Schema

• SYN: Client initiiert Verbindung und schlägt Initial Sequence Number (ISN) vor.
• SYN/ACK: Server bestätigt und liefert seine eigene ISN.
• ACK: Client bestätigt die Server-ISN – die Verbindung ist etabliert.

Handshake als Zustandsübergang

Wenn Sie es formal betrachten möchten: Der Übergang von „keine Verbindung“ zu „established“ passiert erst nach dem dritten Segment. Das ist wichtig, weil viele Incidents genau in den ersten zwei Segmenten stecken (SYN geht raus, Antwort fehlt).

Handshake-Probleme lesen: Die vier häufigsten Muster im NOC

In der Praxis reichen vier Muster, um 80% der „Verbindung kommt nicht hoch“-Tickets einzuordnen.

SYN ohne SYN/ACK: Timeout-Klassiker

• Was Sie sehen: Mehrere SYNs vom Client, keine Antwort.
• Typische Ursachen: Pfadproblem, Firewall droppt, falsche Ziel-IP/Port, Server down, Return Path asymmetrisch.
• NOC-Check: Sehen Sie die SYNs am Server? Wenn nein: Netzwerk/Pfad. Wenn ja, aber keine Antwort: Server/Host-Firewall/Listen-Socket.

SYN → RST: „Connection refused“ oder Middlebox-RST

• Was Sie sehen: Der Server (oder ein Gerät dazwischen) sendet RST.
• Typische Ursachen: Port geschlossen, Service nicht gestartet, L4-Proxy lehnt ab, Policy erzwingt Reset.
• NOC-Check: Quell-IP des RST prüfen. Kommt es wirklich vom Server oder von einer Firewall/Load Balancer?

SYN/SYN-ACK vorhanden, aber kein abschließendes ACK

• Was Sie sehen: Server antwortet, Client bestätigt nicht.
• Typische Ursachen: Rückwegproblem zum Client, Client-Firewall/Stack, asymmetrisches Routing, MSS/MTU-Themen, Anti-DDoS-Mechanismen.
• NOC-Check: Capture am Client vs. am Server vergleichen. Wenn der Client das SYN/ACK nie sieht, ist es ein Pfad-/Policy-Thema.

Handshake ok, aber sofortige Probleme beim ersten Datenpaket

• Was Sie sehen: Verbindung steht, dann Retransmissions oder Window-Probleme direkt nach den ersten Payload-Segmenten.
• Typische Ursachen: MTU/PMTUD, Policing, Loss auf Teilpfad, Server überlastet, TLS/Applikationslayer hängt.

Wireshark-Anzeigen, die Sie für TCP immer aktiv nutzen sollten

Wireshark bietet viele Statistiken, aber im NOC reichen wenige Funktionen, die schnell Orientierung geben.

• Follow TCP Stream: Isoliert eine Sitzung, reduziert Lärm.
• Conversation/Endpoints: Zeigt Top-Talker und hilft, die relevante Verbindung zu finden.
• TCP Stream Graphs: Besonders „Time-Sequence (Stevens)“ und „Round Trip Time“ (je nach Version) helfen, Retransmissions/Pauses visuell zu erkennen.
• Expert Information: Meldet viele TCP-Events (Retransmission, Dup ACK, Out-of-Order) – nützlich, aber nicht blind vertrauen.

Retransmissions sicher erkennen: Was Wireshark markiert – und was das bedeutet

Retransmissions sind Wiederholungen von TCP-Segmenten, weil der Sender annimmt, dass Daten verloren gingen oder nicht bestätigt wurden. Wireshark kennzeichnet häufig:

• [TCP Retransmission]: Segment wird erneut gesendet, meist nach einem Timeout (RTO) oder nach fehlenden ACKs.
• [TCP Fast Retransmission]: Retransmission aufgrund mehrerer Duplicate ACKs (schneller als Timeout).
• [TCP Dup ACK]: Empfänger bestätigt wiederholt denselben ACK-Wert, weil ein Segment fehlt oder Out-of-Order ankam.
• [TCP Out-Of-Order]: Segmente kommen nicht in erwarteter Reihenfolge an (kann echter Reorder sein oder Capture-Artefakt).

Wichtig: Diese Labels sind Interpretationen auf Basis der beobachteten Pakete. Wenn Ihr Capture unvollständig ist (SPAN-Drops) oder Offloading aktiv ist, kann Wireshark Ereignisse falsch klassifizieren. Deshalb sollte ein NOC Retransmissions immer mit dem Gesamtbild abgleichen: Latenz, Loss, Interface-Drops, Queue-Drops, Flow-Daten.

Ursachenanalyse: Retransmission ist ein Symptom, nicht die Ursache

Im Betrieb gibt es einige Hauptursachen, die im Trace unterschiedliche Muster erzeugen. Die Kunst ist, das Muster zu erkennen und die richtige nächste Messung zu wählen.

Echter Packet Loss im Datenpfad

• Trace-Muster: Dup ACKs, Fast Retransmits, gelegentlich RTOs; oft korreliert mit Latenzspikes.
• Begleitindikatoren: Interface-Drops/Errors, Queue Drops, erhöhte Jitter/Latenz.
• NOC-Next Step: Loss-Quelle eingrenzen (Hop-by-hop vs. End-to-End), Interface-Counter prüfen, ggf. Pfadsegmentierung.

Congestion/Queueing: „Netz ist voll“ oder Microbursts

• Trace-Muster: RTT steigt an, ACKs kommen verzögert, Window kann schwanken; Retransmissions treten häufig in Bursts auf.
• Begleitindikatoren: Hohe Utilization, Queue Drops, Buffer-Occupation (falls Telemetry vorhanden).
• NOC-Next Step: QoS, Shaping, Kapazitätsengpass, Hotspots, Traffic-Klasse (DSCP) prüfen.

MTU/PMTUD-Probleme: „Kleine Pakete gehen, große hängen“

• Trace-Muster: Handshake ok, kleine Payload ok, dann Stalls; Retransmissions wiederholen immer dieselben großen Segmente.
• Begleitindikatoren: ICMP „Fragmentation Needed“ fehlt oder wird gefiltert; MSS-Mismatch.
• NOC-Next Step: ICMP-Filter prüfen, Pfad-MTU testen, MSS-Clamping an Edge in Betracht ziehen.

Asymmetrisches Routing + stateful Firewall

• Trace-Muster: Eine Richtung sichtbar, Return-Traffic fehlt oder wird resettiert; Handshake kann auf einer Seite ok wirken, auf der anderen nicht.
• Begleitindikatoren: Sporadisches Verhalten, abhängig von ECMP-Hash/Session-Pinning.
• NOC-Next Step: Captures an beiden Seiten, Firewall-Session-Logs, Routing/ECMP prüfen.

Server-Overload oder Application Stall

• Trace-Muster: Netzwerk liefert, aber Server antwortet spät; Zero Window oder sehr kleine Window-Updates möglich; keine klassischen Drops nötig.
• Begleitindikatoren: Hohe Server-CPU, Queueing in App/DB, lange TLS/HTTP Antwortzeiten.
• NOC-Next Step: Servermetriken, Applikationslogs, Load Balancer-Statistiken korrelieren.

Die wichtigsten Wireshark-Filter fürs NOC: Handshake und Retransmissions

Wireshark hat Display-Filter, die sich von tcpdump/BPF unterscheiden. Für NOC-Zwecke sind wenige Filter besonders hilfreich, um Handshake-Probleme und Retransmissions schnell zu isolieren.

Handshake-Fokus

• Nur SYN: tcp.flags.syn == 1 and tcp.flags.ack == 0
• Nur SYN/ACK: tcp.flags.syn == 1 and tcp.flags.ack == 1
• Nur RST: tcp.flags.reset == 1
• Nur FIN: tcp.flags.fin == 1

Retransmissions und ACK-Anomalien

• Wireshark-Analyseflags: tcp.analysis.retransmission
• Fast Retransmit: tcp.analysis.fast_retransmission
• Duplicate ACK: tcp.analysis.duplicate_ack
• Out-of-Order: tcp.analysis.out_of_order

Diese Filter sind besonders effektiv in Kombination mit ip.addr == A and ip.addr == B sowie tcp.port == 443 (oder dem relevanten Port), damit Sie wirklich nur den betroffenen Flow sehen.

Retransmissions quantitativ einschätzen: Wann ist es „viel“?

Im NOC ist es hilfreich, Retransmissions nicht nur qualitativ („ich sehe welche“), sondern grob quantitativ zu bewerten. Ein einfaches Maß ist der Retransmission-Anteil bezogen auf gesendete Segmente. Sei N_r die Anzahl Retransmissions und N die Anzahl gesendeter Segmente in einem betrachteten Zeitraum. Dann ist der Anteil p:

$p=\frac{N_r}{N}$

Als Faustregel gilt: Bereits niedrige Prozentwerte können bei latenzsensitiven oder transaktionskritischen Pfaden spürbar sein, während Bulk-Transfers kurzfristige Retransmissions eher „wegstecken“. Deshalb sollte die Bewertung immer zusammen mit RTT/Jitter und dem Anwendungstyp erfolgen.

Typische Fehlinterpretationen im NOC und wie Sie sie vermeiden

• „Wireshark sagt Retransmission, also ist das Netz schuld“: Retransmissions können auch durch Server-Stalls, Receiver-Window-Probleme oder Capture-Artefakte entstehen. Lösung: Korrelation mit RTT, Window, Servermetriken.
• Out-of-Order = Loss: Out-of-Order kann echtes Reordering (ECMP) oder Capture-Lücken bedeuten. Lösung: Zweitcapture oder Vergleich mit Interface-/SPAN-Drops.
• Handshake im Trace ok, also ist alles ok: Viele Probleme beginnen erst bei Payload (TLS, MTU, Policy). Lösung: Nach Handshake direkt die ersten Datenpakete prüfen.
• Nur eine Richtung captured: Dann sind ACK- und Retransmission-Interpretationen unsicher. Lösung: Capture-Punkt wechseln oder bidirektional spiegeln.

Praxis-Playbook: Handshake und Retransmissions in 10 Minuten sauber belegen

Wenn Sie einen Incident dokumentieren oder eskalieren müssen (Netzwerkteam, Security, Provider), ist „Beweis“ entscheidend. Das folgende Vorgehen ist in vielen Organisationen Standard.

• 1) Problemzeitfenster festhalten: absolute Zeiten, betroffene Clients/Server, Ports, erwartete Symptome.
• 2) Einen repräsentativen Flow auswählen: nicht „alles“, sondern genau eine Session, die fehlschlägt.
• 3) Handshake-Status belegen: SYN/SYN-ACK/ACK oder das Fehlen eines Elements.
• 4) Retransmission-Muster belegen: Dup ACKs, Fast Retransmits, RTOs – inklusive Zeitabständen.
• 5) Korrelation ergänzen: parallel Loss/Latenz/Queue-Drops/Interface-Errors oder Servermetriken notieren.
• 6) Aussage formulieren: „Wir sehen X, was typischerweise auf Y hinweist, und schlagen Z als nächsten Check vor.“

Mit dieser Struktur wird ein Wireshark-Trace vom „Debugging-Tool“ zur belastbaren Incident-Evidence.

Outbound-Quellen für vertiefendes Verständnis

Für die praktische Nutzung und Dokumentation von Wireshark ist die offizielle Seite Wireshark die primäre Quelle, insbesondere für Funktionen wie Stream Graphs und Display-Filter. Für eine fundierte, aktuelle TCP-Spezifikation (Handshake, Zustände, Retransmission-Mechanik als Basisprotokoll) ist RFC 9293 (TCP) die maßgebliche Referenz. Für eine allgemeine, verständliche Einordnung von TCP-Konzepten im Betrieb kann zusätzlich TCP als Übersicht hilfreich sein.

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.