Wenn das Gigabit-Netzwerk schleicht: Performance-Engpässe mit Wireshark präzise analysieren

„Das Netzwerk ist langsam.“ Jeder Admin kennt diesen Satz. Er ist die IT-Variante von „Ich habe Bauchschmerzen“ – unspezifisch, frustrierend und oft schwer zu diagnostizieren. Das Kuriose dabei: Schaut man ins Monitoring, leuchten alle Ports grün. Die Auslastung der 1-Gbit/s- oder 10-Gbit/s-Strecke liegt bei schmalen 5 %. Trotzdem dauert das Öffnen einer Excel-Datei vom Fileserver gefühlte Ewigkeiten, und die Datenbankabfragen der Warenwirtschaft kriechen im Schneckentempo über die Leitung.

In meiner täglichen Praxis als IT-Netzwerkanalytiker erlebe ich oft, dass an dieser Stelle blind Hardware getauscht wird. Es werden neue Switche gekauft oder Glasfaserstrecken nachgerüstet, nur um festzustellen, dass das Problem hartnäckig bleibt. Der Grund ist simpel: Bandbreite ist nicht gleich Durchsatz. Ein breites Rohr nützt nichts, wenn das Wasser darin ständig gegen die Fließrichtung gedrückt wird oder das Ventil am Ende nur tröpfchenweise öffnet. Wir müssen also tiefer graben – dorthin, wo die Pakete fließen.

Typisches Szenario: Die Schatten-Latenz im Gigabit-Netz

Stellen Sie sich ein mittelständisches Unternehmen vor. Die Infrastruktur ist modern, Cat.7-Verkabelung, performante Core-Switche, SSD-Storage im SAN. Ein Nutzer meldet, dass eine spezialisierte Client-Server-Anwendung seit dem letzten Wochenende extrem langsam reagiert. Der klassische Ping-Test zeigt unauffällige 1 ms. Ein Dateitransfer per SMB erreicht fast die volle Gigabit-Rate.

Warum also hakt die Anwendung? Hier stoßen wir auf das Phänomen der Response Time auf Applikationsebene, die durch mikroskopische Störungen im TCP-Stack beeinflusst wird. Oft liegt es nicht an der Menge der Daten, sondern an der Art und Weise, wie sie quittiert werden. Wir haben es hier nicht mit einem totalen Ausfall zu tun, sondern mit einem Performance Problem, das durch Effekte wie den TCP Algorithmus, kleine Puffer oder schlichte Konfigurationsfehler verursacht wird.

Technischer Hintergrund: Warum Bandbreite nicht alles ist

Um zu verstehen, warum ein Netzwerk trotz hoher Kapazität langsam sein kann, müssen wir uns das Überlastverhalten von TCP (Transmission Control Protocol) ansehen. TCP ist ein verbindungsorientiertes Protokoll, das auf Zuverlässigkeit getrimmt ist. Es ist quasi ein ständiger Dialog zwischen Sender und Empfänger.

Ein entscheidender Faktor ist die RTT (Round Trip Time). Sie beschreibt die Zeit, die ein Paket zum Ziel und die Bestätigung (ACK) wieder zurück benötigt. In einem LAN sollte die RTT minimal sein. Steigt sie jedoch – etwa durch überlastete Router-Hops oder fehlerhafte Media-Converter – sinkt der Durchsatz dramatisch, selbst wenn die Leitung theoretisch „frei“ ist.

Dazu kommt das Windowing-Konzept. Der Empfänger teilt dem Sender über das „Receive Window“ mit, wie viele Daten er puffern kann, ohne eine Bestätigung zu schicken. Wenn der Empfänger mit der Verarbeitung nicht hinterherkommt, signalisiert er ein TCP Zero Window. In diesem Moment stoppt der Sender die Übertragung komplett. Das ist der digitale Herzinfarkt für jede Performance.

Analyse mit Wireshark: Schritt für Schritt zum Bottleneck

Wenn wir den „Ghost in the Machine“ finden wollen, ist Wireshark das Werkzeug der Wahl. Aber Vorsicht: Einfach nur mitschneiden („Trace“) und auf bunte Zeilen hoffen, führt selten zum Ziel. Wir brauchen einen Plan.

1. Den richtigen Capture-Punkt wählen

Analysieren Sie immer so nah wie möglich an der Quelle und am Ziel. Idealerweise schneiden Sie zeitgleich am Client und am Server mit. Nur so lässt sich feststellen, ob ein Paket auf dem Weg verloren gegangen ist oder ob der Server schlichtweg zu lange zum Antworten braucht.

2. Experten-Infos nutzen

Wireshark bietet unter dem Menüpunkt Analyze -> Expert Information einen schnellen Überblick. Achten Sie auf rote und gelbe Markierungen.

• TCP Retransmission: Ein Paket kam nicht an oder das ACK blieb aus. Der Sender schickt es erneut. Das kostet Zeit.

• Previous Segment not captured: Ein Hinweis auf Packetverluste vor dem Capture-Punkt.

• TCP Dup ACK: Ein Zeichen, dass Pakete in der falschen Reihenfolge ankamen oder eines fehlt.

3. Das IO-Graph für die Visualisierung

Gehen Sie auf Statistics -> I/O Graphs. Stellen Sie die Y-Achse auf „Bits/s“ und eine zweite Kurve auf „TCP Errors“. Wenn die Fehlerkurve genau dann ausschlägt, wenn der Durchsatz einbricht, haben Sie den Beweis für ein Layer-2- oder Layer-3-Problem.

4. TCP Stream-Analyse

Wählen Sie ein Paket der langsamen Verbindung aus: Rechtsklick -> Follow -> TCP Stream. Hier sehen Sie den nackten Dialog. Interessanter ist jedoch: Statistics -> TCP Stream Graphs -> Time Sequence (Stevens). Ein Treppenmuster, das flach verläuft, deutet auf Pausen im Protokollfluss hin – oft verursacht durch Applikations-Latenzen oder Wartezeiten des Betriebssystems.

Häufige Ursachen: Wo es wirklich klemmt

In meinen Projekten kristallisieren sich meist drei Hauptverdächtige heraus:

1. Der „Silent Killer“: Packetverluste und Retransmissions
In einer idealen Welt gehen im LAN keine Pakete verloren. In der Realität führen defekte Patchkabel, schlecht aufgelegte Dosen oder elektromagnetische Störungen zu CRC-Fehlern. Ein einziger Prozentpunkt an Packetverlusten kann den TCP-Durchsatz um 80 % reduzieren, da der TCP Algorithmus (z.B. CUBIC oder BBR) sofort die Übertragungsrate drosselt, um eine (vermutete) Netzüberlastung zu vermeiden. Eine TCP Retransmission ist teuer, da der Timeout oft deutlich über der normalen RTT liegt.

2. Das Puffer-Dilemma: TCP Zero Window
Wenn ein Server unter Volllast steht (CPU-Limit oder langsamer Storage), leert er seinen TCP-Empfangspuffer nicht schnell genug. Er sendet ein TCP Zero Window. Der Client muss warten. In Wireshark sieht man das oft als „ZeroWindowProbe“ – der Client klopft vorsichtig an, ob wieder Platz ist. Das ist ein klassisches Bottleneck auf Systemebene, nicht auf der Leitung.

3. MSS-Mismatch und Fragmentierung
Wenn die Maximum Segment Size (MSS) falsch ausgehandelt wird (oft bei VPN-Tunneln oder VLAN-Kaskaden), müssen Pakete fragmentiert werden. Das führt zu massivem Overhead und Fehlern, die in Wireshark als „Fragmentation Needed“ (ICMP Type 3, Code 4) auftauchen sollten, aber oft von Firewalls blockiert werden (Black Hole Router Problem).

Lösung und Best Practices

Wie lösen wir diese Probleme nachhaltig?

1. Physische Schicht prüfen: Nutzen Sie professionelle Zertifizierungsgeräte für die Verkabelung. Ein „Link ist da“ reicht nicht aus. Schauen Sie in die Interface-Statistiken der Switche (show interfaces counters errors bei Cisco).

2. Flow Control & Quality of Service: Deaktivieren Sie im LAN oft kontraproduktive Features wie IEEE 802.3x Flow Control auf den Access-Ports, wenn diese zu Head-of-Line Blocking führen. Priorisieren Sie kritischen Traffic per QoS.

3. TCP Stack Optimierung: Bei modernen Windows-Servern ist „Receive Window Auto-Tuning“ meist hilfreich, kann aber in Verbindung mit alten Firewalls Probleme machen. Prüfen Sie, ob LSO (Large Send Offload) auf den NICs Probleme verursacht – manchmal ist die Hardware-Beschleunigung der Netzwerkkarte fehlerhaft implementiert.

4. MTU-Check: Stellen Sie sicher, dass die MTU (Maximum Transmission Unit) durchgängig 1500 Byte beträgt (oder 9000 bei Jumbo Frames, aber dann konsequent überall im VLAN).

Fazit: Gewissheit statt Raten

Ein langsames Netzwerk ist kein Schicksal, sondern eine meist logisch erklärbare Folge technischer Parameter. Die reine Netzwerkanalyse mit Wireshark erlaubt es uns, von der Ebene der Vermutungen auf die Ebene der Beweise zu wechseln.

Wenn Sie das nächste Mal vor einem Performance-Rätsel stehen, denken Sie daran: Die Bandbreite ist nur die Autobahn. Ob der Verkehr fließt, entscheiden die Ampelschaltungen (TCP-Stacks), der Zustand des Belags (Layer 1/2) und die Geschwindigkeit der Be- und Entladestationen (Applikation/Storage).

Sollten Sie bei einer tiefgreifenden Analyse nicht weiterkommen oder Unterstützung bei der Optimierung Ihrer Infrastruktur benötigen, ist es oft effizienter, einen Experten hinzuzuziehen, bevor wertvolle Arbeitszeit in erfolglosen Troubleshooting-Zyklen versinkt.

FAQ – Häufig gestellte Fragen

1. Warum sehe ich in Wireshark so viele „TCP Spurious Retransmissions“?

Dies passiert oft, wenn Pakete tatsächlich ankommen, aber die Bestätigung (ACK) so lange braucht (hohe Latenz), dass der Sender ungeduldig wird und das Paket erneut schickt. Es ist ein Indiz für asymmetrisches Routing oder überlastete Rückwege.

2. Reicht ein normaler Office-PC für einen Wireshark-Capture bei 1 Gbit/s?

Es kommt darauf an. Für eine erste Einschätzung kann dies bereits ausreichen. Für professionelle Analysen empfehle ich dedizierte Network TAPs oder spezielle Capture-Karten, um das Messergebnis nicht zu verfälschen.

3. Was ist eine „gute“ RTT im lokalen Netzwerk?

In einem gesunden Gigabit-LAN sollte die RTT zwischen zwei Workstations unter 1 ms liegen. Werte über 5-10 ms innerhalb eines Standorts ohne VPN-Strecke deuten fast immer auf eine Fehlkonfiguration oder eine massive Überlastung der aktiven Komponenten hin.

4. Kann eine Firewall die Performance bremsen, ohne dass die CPU-Last hoch ist?

Ja, absolut. Wenn die State-Table der Firewall voll ist oder Deep Packet Inspection (DPI) für bestimmte Protokolle ineffizient arbeitet, steigt die Response Time massiv an, während die CPU-Auslastung der Firewall-Hardware oft unauffällig bleibt.