Dieses Dokument beschreibt die TCP-Grundlagen, Wireshark Deep Packet Analysis und die praktische Fehlerbehebung zur Optimierung der End-to-End-Leistung.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
Anmerkung: Fragen zur Konfiguration und Interoperabilität von Software oder Hardware von Drittanbietern liegen außerhalb des Cisco Supports. Die Verwendung von Tools von Drittanbietern ist eine gute Möglichkeit, Ihre Konfiguration und Ihren Betrieb mit Cisco Geräten zu demonstrieren.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Das Transmission Control Protocol (TCP) ist ein grundlegendes Transportschichtprotokoll, das auf Schicht 4 des OSI-Modells arbeitet und eine zuverlässige, geordnete und fehlerüberprüfte Bereitstellung eines Bytestroms zwischen Anwendungen ermöglicht, die über ein IP-Netzwerk kommunizieren.
Das Diagramm stellt den TCP/IP-Stack dar, in dem ein TCP-Segment (Layer 4) in ein IP-Paket (Layer 3) und dann in einen Ethernet-Frame (Layer 2) gemäß IEEE 802.3 eingekapselt wird. Dieser Layer-Ansatz stellt eine modulare Kommunikation sicher, bei der jede Layer eigene Steuerinformationen (Header) hinzufügt, um die Bereitstellung, das Routing und die Datenintegrität zu gewährleisten.

Der Ethernet-Header umfasst in der Regel 14 Byte und setzt sich aus folgenden Komponenten zusammen:
Ethernet-Frames enthalten außerdem einen 4 Byte langen Frame Check Sequence (FCS) Trailer zur Fehlererkennung auf Layer 2. IEEE 802.3 definiert Framing, minimale/maximale Frame-Größen und physische Bereitstellungseinschränkungen, die sich direkt auf Protokolle höherer Layer wie TCP auswirken.
Der IPv4-Header hat eine Mindestgröße von 20 Byte und kann mit Optionen auf bis zu 60 Byte erweitert werden. Zu den Schlüsselfeldern gehören:
Die IP-Schicht ist für die logische Adressierung und das Routing über Netzwerke hinweg zuständig, gewährleistet jedoch keine Zuverlässigkeit.
Der TCP-Header reicht je nach Optionen von 20 bis 60 Byte. Zu den Schlüsselfeldern gehören:
TCP fügt der IP-Kommunikation zuverlässige Bereitstellung, korrekte Sequenzierung und Flusskontrolle hinzu.
TCP-Optionen erweitern das Basisprotokoll. Die häufigsten sind:
Sowohl SYN- als auch FIN-Flags verwenden jeweils eine Sequenznummer, auch wenn keine Payload vorhanden ist. TCP arbeitet mit einem byteorientierten Sequenzierungsmodell, bei dem jedes übertragene Byte - und bestimmte Kontrollflags - den Sequenzraum vorverlegt. Dieses Verhalten ist für eine genaue TCP-Analyse bei der Paketerfassung und für die Diagnose von Sequenzierungs- oder Quittierungsinkonsistenzen unerlässlich.
ACK = SEQ + Payload Length + (SYN ? 1: 0) + (FIN ? 1: 0)
Dabei gilt:
ACK-Berechnung:
Dies zeigt ein Szenario an, in dem Daten während des TCP-Handshakes gesendet werden. Sowohl die Nutzlast als auch das SYN-Flag belegen Sequenzräume.
ACK-Berechnung:
Dies zeigt, dass TCP Daten während des Verbindungsabbruchs enthalten kann, und dass sowohl das Nutzdaten- als auch das FIN-Flag die Sequenznummer inkrementieren.
Die maximale Segmentgröße (Maximum Segment Size, MSS) definiert die maximale Nutzlast, die TCP in einem Segment senden kann.
Wenn TCP-Optionen vorhanden sind, wird die MSS entsprechend reduziert. MSS wird während des TCP-Drei-Wege-Handshakes ausgehandelt und verhindert die Fragmentierung auf der IP-Ebene.
Die maximale Segmentgröße (Maximum Segment Size, MSS) wird während des TCP-Drei-Wege-Handshakes mithilfe der MSS-Option in SYN-Paketen ausgetauscht:
Jede Seite sagt:
Dies ist die größte akzeptierte TCP-Nutzlast.
Die MSS wird nicht als einheitlicher vereinbarter Wert ausgehandelt.
Stattdessen:
Daher:
In einem richtig funktionierenden TCP-Stapel: Nein.
Die Fenstergröße legt fest, wie viele Daten der Empfänger ohne Bestätigung akzeptieren kann.
Worum handelt es sich?
Zweck:
Wo kann sie bezogen werden:
Variabilität von Anbieter/Betriebssystem:
Bedingung für Nullfenster:
Variable Windows-Mechanismen
Problembehandlung:
In diesem Abschnitt wird eine praktische Methode beschrieben, mit der festgestellt werden kann, ob sich ein Cisco Nexus-Switch mit NX-OS auf die Weiterleitung des TCP-Datenverkehrs auswirkt oder ob Leistungsprobleme auftreten. Der Ansatz wird anhand eines hypothetischen Szenarios vorgestellt.
Wenn eine TCP-Latenz oder ein Leistungsabfall festgestellt werden, ist es üblich, zunächst zu vermuten, dass das Netzwerk diese Latenz verursacht. Diese Annahme muss jedoch durch datengesteuerte Analysen validiert werden. Die maßgebliche Methode für die TCP-Fehlerbehebung ist die Paketerfassung, die idealerweise durchgeführt wird:
Dadurch wird die Transparenz des TCP-Drei-Wege-Handshakes sichergestellt, bei dem wichtige Parameter wie MSS, Fensterskala und SACK ausgehandelt und später in der Sitzung nicht wiederholt werden. Wenn keine gleichzeitigen Erfassungen möglich sind, kann die Analyse mit einer einzigen Erfassung fortgesetzt werden, die Schlussfolgerungen sind jedoch begrenzt.
Szenariodefinition
Ein Benutzer hat festgestellt, dass der Backup-Prozess für einen Anwendungsdatensatz von ca. 7,5 TB, der zuvor in ca. 9 Stunden abgeschlossen wurde, jetzt fast 21 Stunden dauert. Obwohl TCP-Sitzungen zwischen dem Client und dem Server weiterhin erfolgreich hergestellt werden, deutet die deutliche Verlängerung der Backup-Dauer auf eine mögliche Verschlechterung des Durchsatzes oder der TCP-Gesamtleistung hin. Da der Nexus-Switch das einzige Netzwerkgerät im Pfad ist und zudem Layer-3-Gateway-Funktionen bereitstellt, vermutet der Netzwerkadministrator, dass der Nexus-Switch die Ursache des Problems ist.

Linux: ping -c 10 -I 10.93.19.8 -s 1472 -M do 10.91.2.35
Windows: ping -n 10 -l 1472 -f 10.91.2.35
Warum 1472 Byte?
Schlussfolgerungen
Verwendung dieses Handbuchs zur Fehlerbehebung
Praktische Relevanz für TCP
Um die TCP-Leistung auf einem Cisco Nexus 9000-Switch effektiv zu überprüfen, muss ermittelt werden, welche Schnittstellen den Datenverkehr zwischen Quelle und Ziel empfangen und weiterleiten.
In einfachen Topologien kann dies direkt aus den physischen Verbindungen abgeleitet werden. Wenn der Client beispielsweise mit Ethernet1/1 und der Server mit Ethernet1/2 verbunden ist, ist der Datenverkehrspfad unkompliziert. In realen Umgebungen mit mehreren aktiven Schnittstellen, Port-Channels oder vPC-Konfigurationen ist diese Identifizierung jedoch nicht immer trivial.
In diesen Fällen wird empfohlen, das Embedded Logic Analyzer Module (ELAM) zu verwenden, das Transparenz auf ASIC-Ebene (Data-Plane Hardware) bietet.
Mit ELAM können Sie ein Paket erfassen, während es von der Weiterleitungspipeline verarbeitet wird, und wichtige Informationen wie die folgenden offenlegen:
Diese Methode ist wesentlich genauer als die Verwendung von Tools auf Kontrollebene, da sie den tatsächlichen Weiterleitungspfad der Hardware widerspiegelt.
Es ist wichtig zu beachten, dass ELAM jeweils nur ein Paket erfasst, sodass die Filterkriterien genau definiert werden müssen, um dem gewünschten Datenverkehr (z. B. Quell-IP, Ziel-IP, TCP-Port) gerecht zu werden. Wenn die Filter zu breit gefasst sind, besteht das Risiko, dass nicht zusammenhängender Datenverkehr wie ICMP oder UDP anstatt des beabsichtigten TCP-Datenflusses erfasst wird.
Außerdem muss dieser Vorgang für beide Verkehrsrichtungen wiederholt werden:
In Umgebungen, die vPC oder ECMP verwenden, kann die Datenverkehrslast auf mehrere Pfade verteilt werden. So kann der vor- und zurückfließende Datenverkehr über verschiedene Switches oder Schnittstellen geleitet werden. In diesen Szenarien muss ELAM auf jedem relevanten Nexus-Switch ausgeführt werden, um vollständige Transparenz zu gewährleisten.
Durch die genaue Identifizierung von Eingangs- und Ausgangsschnittstellen wird der Umfang der Fehlerbehebung erheblich reduziert, sodass eine gezielte Validierung der Schnittstellenzähler, QoS-Richtlinien, MTU-Einstellungen und potenziellen Überlastungspunkten entlang des genauen Weiterleitungspfads möglich ist.
In diesem Beispiel wird der Datenverkehr mit der Quell-IP 10.93.19.8, der Ziel-IP 10.91.2.35 und dem TCP-Zielport 445 gefiltert.
ELAM-Einrichtung
switch# debug platform internal tah elam
switch(TAH-elam)# trigger init
Slot 1: param values: start asic 0, start slice 0, lu-a2d 1, in-select 6, out-select 0
switch(TAH-elam-insel6)# set outer ipv4 src_ip 10.93.19.8
switch(TAH-elam-insel6)# set outer ipv4 dst_ip 10.91.2.35
switch(TAH-elam-insel6)# set outer l4 l4-type 0
switch(TAH-elam-insel6)# set outer l4 dst-port 445
switch(TAH-elam-insel6)# start
Nachdem Sie den Datenverkehr generiert haben, rufen Sie das Ergebnis ab:
switch(TAH-elam-insel6)# report
Umgekehrte Datenverkehrserfassung (erforderlich für volle Transparenz)
Um den Rückgabepfad zu validieren, wiederholen Sie die Konfiguration, indem Sie die Quell- und Ziel-IP-Adresse austauschen:
switch# debug platform internal tah elam
switch(TAH-elam)# trigger init
Slot 1: param values: start asic 0, start slice 0, lu-a2d 1, in-select 6, out-select 0
switch(TAH-elam-insel6)# set outer ipv4 dst_ip 10.93.19.8
switch(TAH-elam-insel6)# set outer ipv4 src_ip 10.91.2.35
switch(TAH-elam-insel6)# set outer l4 l4-type 0
switch(TAH-elam-insel6)# set outer l4 dst-port 445
switch(TAH-elam-insel6)# start
Betriebshinweise
Cisco Nexus 9000 Cloud Scale ASIC ELAM-Leitfaden
Die Validierung auf Schnittstellenebene stellt sicher, dass der Nexus-Switch keine Einschränkungen oder Anomalien mit Auswirkungen auf den TCP-Datenverkehr einführt. Im Mittelpunkt steht die Bestätigung, dass Konfiguration, Betriebsstatus und Hardware-Zähler mit dem erwarteten Verhalten für eine leistungsstarke Weiterleitung auf Datenebene übereinstimmen.
Validierung der Konfiguration
switch# show running-config interface ethernet1/1-2 | include access-group
switch#show running-config interface ethernet1/1-2 | include service-policyswitch#show policy-map interface ethernet1/1-2
switch# show policy-map
switch# show class-map
switch# show class-map type network-qos
switch# show policy-map type network-qos
switch#show policy-map system type network-qos
switch# show queuing interface ethernet1/1-2
switch# show policy-map type queuing
switch#show running-config interface ethernet1/1-2
switch#show interface ethernet1/1-2 switchport
switch#show spanning-tree interface ethernet1/1-2
switch# show ip interface ethernet1/1-2
Überprüfung des Betriebsstatus
switch#show interface ethernet1/1-2 | include MTU
switch#show interface ethernet1/1-2 | include speed|duplex
switch#show interface ethernet1/1-2 | include rate|flap
Überprüfung des Fehlerzählers
switch#clear counters interface all
switch#show interface counters errors non-zero | include Port|Eth1/1|Eth1/2
Validierung nach dem Test
switch#show interface counters errors non-zero | include Port|Eth1/1|Eth1/2
Die Sicherstellung von Routing- und ARP-Stabilität ist von entscheidender Bedeutung, um sicherzustellen, dass der Nexus-Switch konsistent auf Layer 3 erreichbar ist und keine intermittierenden Probleme bei der Auflösung verursacht, die die TCP-Leistung beeinträchtigen könnten. Instabilität bei Routing-Einträgen oder eine ARP-Auflösung können zu Paketverlusten, erhöhter Latenz oder Blackholing von Datenverkehr führen.
Validierungskriterien
switch# show ip route 10.93.19.8
switch# show ip route 10.91.2.35
switch# show ip arp detail | include 10.93.19.8
switch# show ip arp detail | include 10.91.2.35
Bei Cisco Nexus Switches der Serie 9000 erfolgt die Weiterleitung über die Hardware (ASIC), und die CPU ist nicht am normalen Betrieb der Datenebene beteiligt. Daher ist die Beobachtung von Host-zu-Host-TCP-Datenverkehr auf der Steuerungsebene ungewöhnlich und weist darauf hin, dass Pakete aufgrund von Ausnahmen oder Fehlkonfigurationen blockiert werden. Sobald der Datenverkehr von der CPU verarbeitet werden muss, unterliegt er dem Control Plane Policing, und es wird erwartet, dass Datenverluste auftreten können, wenn der Datenverkehr die zulässige Kontrollebenenrate überschreitet.
Validierungsmethode
switch# ethanalyzer local interface inband display-filter "ip.addr==10.93.19.8 and ip.addr==10.91.2.35" limit-capture 0
Erwartetes Verhalten
Unerwartetes Verhalten
Die Paketweiterleitungslatenz in Nexus 9000-Switches hängt von der Paketgröße, dem Weiterleitungsmodus und den aktivierten Funktionen ab. Die Spezifikationen von Cisco beziehen sich bei der Cut-Through-Weiterleitung für 64-Byte-Pakete in der Regel auf die Latenz.
+----------------------+----------------------+-------------------------+-------------------------------+
| Switch Model | ASIC / Architecture | Ports (example config) | Typical Forwarding Latency |
| | | | (64B packet) |
+----------------------+----------------------+-------------------------+-------------------------------+
| Nexus 93180YC-EX | Cloud Scale (EX) | 48x25G + 6x100G | ~1.0 – 1.2 microseconds |
| Nexus 93180YC-FX | Cloud Scale (FX) | 48x25G + 6x100G | ~0.9 – 1.0 microseconds |
| Nexus 93180YC-FX2 | Cloud Scale (FX2) | 48x25G + 6x100G | ~0.8 – 0.9 microseconds |
| Nexus 9364C | Cloud Scale | 64x100G | ~1.0 microsecond |
| Nexus 9336C-FX2 | Cloud Scale (FX2) | 36x100G | ~0.8 microseconds |
| Nexus 93240YC-FX2 | Cloud Scale (FX2) | 48x25G + 12x100G | ~0.8 – 0.9 microseconds |
| Nexus 92300YC | Broadcom Trident II | 48x10/25G + 6x40/100G | ~2 – 3 microseconds |
| Nexus 92160YC-X | Broadcom Tomahawk | 48x25G + 6x100G | ~2 microseconds |
+----------------------+----------------------+-------------------------+-------------------------------+
Zusätzliche Funktionen können zu inkrementeller Latenz führen:
Allerdings:
Das einzig realistische Szenario, in dem die Latenz merklich zunimmt, sind Überlastungen:
Selbst in diesen Fällen:
Dies ermöglicht die Spiegelung des Datenverkehrs auf Datenebene in die Steuerungsebene zur Paketerfassung und den Export in eine .pcapng-Datei, sodass detaillierte Analysen in Wireshark durchgeführt werden können.
Konfiguration
monitor session 1
source interface ethernet1/1 both
source interface ethernet1/2 both
destination interface sup-eth0
no shut
Erfassungsausführung
switch# ethanalyzer local interface inband mirror capture-filter "tcp port 445" limit-capture 0 write bootflash:tcp_capture.pcapng
Technische Aspekte
| Methode | Vorteil | Einschränkung |
|---|---|---|
| SPAN |
Präzise, keine Kapselung |
Erfordert physische Verbindung. |
| ERSPAN |
Remote-Erfassungsfunktion |
Anfällig für Netzwerküberlastungen. |
Um die Zuverlässigkeit der SPAN-zu-CPU-Daten sicherzustellen, muss überprüft werden, ob die Kontrollebene aufgrund der Ratenbegrenzung gespiegelte Pakete verwirft.
Validierungsbefehl
switch(config)# show hardware rate-limiter | i Allowed|span
Allowed, Dropped & Total: aggregated bytes since last clear counters
R-L Class Config Allowed Dropped Total
span 50 0 0 0 <<<
span-egress disabled 0 0 0
Validierungsmethode
Dolmetschen
Wenn Verwerfungen festgestellt werden, muss die Fangmethode auf SPAN oder ERSPAN geändert werden.
ICMP-Tests bieten eine Baseline-Validierung der Integrität der Datenebene vor der Durchführung komplexer TCP-Analysen. Da ICMP Stateless und einfacher ist, ermöglicht es die schnelle Erkennung von Paketverlusten, Duplizierungen oder Pfadinkonsistenzen.
Erwartetes Verhalten bei der SPAN-Erfassung
Dies bestätigt die korrekte Weiterleitung und das Fehlen von Paketverlusten auf Datenebene.
Ungewöhnliches Verhalten
Wenn ICMP-Datenverkehr konsistent und verlustfrei weitergeleitet wird, besteht eine hohe Wahrscheinlichkeit, dass der TCP-Datenverkehr auch auf Layer 2/3 korrekt weitergeleitet wird.
Wenn der Datenverkehr über SPAN zur CPU (oder SPAN/ERSPAN) erfasst wird, kann jedes Paket zweimal beobachtet werden: einmal am Eingang und einmal am Ausgang. Diese Duplizierung kann verwendet werden, um die vom Nexus-Switch verursachte Weiterleitungslatenz zu schätzen, indem die Zeitdifferenz zwischen beiden Instanzen desselben Pakets berechnet wird.
In der Praxis kann diese Latenz mithilfe des zuvor erfassten ICMP-Verkehrs gemessen werden, indem das Zeitdelta zwischen duplizierten Echo Request- und Echo Reply-Paketen verglichen wird. Dies bietet eine einfache und effektive Grundlage für die Switch-Weiterleitungsleistung. Wenn eine tiefere Analyse erforderlich ist, kann dieselbe Methode auf den TCP-Datenverkehr angewendet werden, indem der Datenfluss erfasst und die Zeitdifferenz zwischen duplizierten TCP-Paketen gemessen wird.
Methodik
Wireshark-Konfiguration
View > Time Display Format > Seconds Since Previous Displayed Packet
Right-click on "Time Delta from Previous Displayed Packet" → Apply as Column
ip.addr==10.93.19.8 and ip.addr==10.91.2.35 and tcp
Right-click packet → Follow → TCP Stream
Dolmetschen
Dieser Abschnitt enthält eine detaillierte Methodik für die Analyse einer TCP-Paketerfassung in Wireshark, einschließlich der Profilkonfiguration, anhand des oben beschriebenen hypothetischen Falls. Die gezeigten Bilder stammen direkt aus Wireshark. Zur Erinnerung:
Ein Benutzer hat festgestellt, dass der Backup-Prozess für einen Anwendungsdatensatz von ca. 6,5 TB, der zuvor in ca. 9 Stunden abgeschlossen wurde, jetzt fast 21 Stunden dauert. Das einzig zugängliche Netzwerkgerät ist ein mit dem Quellserver (10.93.19.8) verbundener Cisco Nexus 9300-Switch. Die auf der Switch-Schnittstelle konfigurierte MTU beträgt 9.000 Byte (Jumbo Frames), während die MTU auf dem Server unbekannt ist. Eine Paketerfassung vom Quellserver ist verfügbar, und alle vorherigen Nexus-Validierungsschritte wurden bereits abgeschlossen, ohne dass Anomalien erkannt wurden.
Wichtigste Beobachtungen und Einschränkungen
In Wireshark können Sie benutzerdefinierte Profile erstellen, die auf den jeweiligen Analysetyp, den Sie ausführen möchten, zugeschnitten sind.
Spaltenbeschreibung
Das Erfassen des TCP-Drei-Wege-Handshakes ist erforderlich, da es wichtige Parameter wie MSS, Window Scale und SACK enthält, die das Sitzungsverhalten festlegen.
Ohne diese Informationen ist jede TCP-Analyse unvollständig und kann zu falschen Schlussfolgerungen in Bezug auf die Leistung oder die Ursache führen.

Aus der Paketerfassung:
Der anfängliche RTT (iRTT) wird wie folgt berechnet:
Dieser Wert wird abgeleitet von:
Der Großteil der Latenz (~94 %) liegt im Weiterleitungspfad (Client → Server → Client), während die Reaktionszeit von der Quelle minimal ist, was darauf hindeutet, dass der Client keine CPU- oder Anwendungsverzögerung aufweist.
Port 445 entspricht dem Microsoft Server Message Block (SMB), der häufig für die Dateifreigabe, Netzwerklaufwerke und Windows-Authentifizierungsdienste verwendet wird. Da dieses Protokoll sowohl auf Latenz als auch auf Durchsatz empfindlich ist, ist es stark von der TCP-Effizienz und der Netzwerkstabilität abhängig.
Das TCP-Fenster gibt an, wie viele Daten gesendet werden können, bevor auf die Bestätigung gewartet wird. In diesem Fall ist die Quelle etwas restriktiver als das Ziel. Diese Werte sind in modernen Umgebungen relativ gering und können den Durchsatz insbesondere bei zunehmender RTT begrenzen.
Der maximale theoretische Durchsatz kann wie folgt geschätzt werden:
Durchsatz = TCP-Fenstergröße / RTT
Ersetzen der beobachteten Werte:
Durchsatz ≈ 64.240 / 0,000798 ≈ 80,5 MB/s (~644 Mbit/s)
Dieser Wert stellt den oberen Grenzwert für den Durchsatz dar. Dabei wird Folgendes vorausgesetzt:
Bei einem aktuellen Durchsatz von 644 Mbit/s dauert die Übertragung einer Datei mit 6,5 TB ungefähr 23,5 Stunden, was mit der beobachteten Verschlechterung übereinstimmt. Um ein Übertragungsfenster von 9 Stunden zu erreichen, muss der Durchsatz auf ca. 1,68 Gbit/s erhöht werden. Dies erfordert entweder ein größeres TCP-Fenster (~2,7x Erhöhung) oder eine deutlich niedrigere RTT (~291 µs).
Unter den aktuellen Bedingungen (64 KB Fenster und ~798 µs RTT) ist es nicht möglich, das 9-Stunden-Ziel zu erreichen, da der TCP-Durchsatz durch das Bandbreiten-Verzögerungsprodukt eingeschränkt ist. Ohne die Fenstergröße zu erhöhen oder die Latenz zu reduzieren, kann das Protokoll keine höhere verfügbare Bandbreite nutzen, wodurch das Ziel unerreichbar wird.
| Szenario | Durchsatz | Geschätzte Übertragungszeit (6,5 TB) | Erforderliches TCP-Fenster | Erforderliche RTT |
|---|---|---|---|---|
| Aktueller Status |
644 Mbit/s (~80,5 MB/s) |
~23,5 Stunden |
64 KB |
798 µs |
| Ziel (9 Stunden) |
~1683 Mbit/s (~210 MB/s) |
9 Stunden |
~172 KB |
~291 µs |
Dies funktionierte bereits, was darauf hinweist, dass eine Änderung im Netzwerk, in der Anwendung, in der Quelle oder im Ziel aufgetreten ist. Es ist wichtig, darauf hinzuweisen, dass allein auf der Grundlage dieser ersten Analyse bereits eine wesentliche Schlussfolgerung gezogen werden kann: Unter den aktuellen TCP-Fenstergrößen und RTT-Bedingungen ist das Erreichen des 9-Stunden-Ziels nicht möglich.
In den Tabellen wird verglichen, wie sich der Durchsatz bei einer Vergrößerung oder Verkleinerung des RTT- und TCP-Fensters ändert.
RTT-Auswirkung auf den Durchsatz (feste Fenstergröße = 64.240 Byte)
| RTT | Durchsatz (MB/s) | Durchsatz (Mbit/s) |
|---|---|---|
| 200 µs (0,0002 s) |
~321 MB/s |
~ 2.568 Mbit/s |
| 798 µs (0,000798 s) |
~80,5 MB/s |
~644 Mbit/s |
| 2 ms (0,002 s) |
~32,1 MB/s |
~257 Mbit/s |
| 10 ms (0,01 s) |
~6,4 MB/s |
~51 Mbit/s |
Auswirkungen auf die TCP-Fenstergröße (Fixed RTT = 798 µs)
| TCP-Fenstergröße | Durchsatz (MB/s) | Durchsatz (Mbit/s) |
|---|---|---|
| 16 KB (16 384 B) |
~20,5 MB/s |
~ 164 Mbit/s |
| 64 KB (64 240 B) |
~80,5 MB/s |
~644 Mbit/s |
| 256 KB (262 144 B) |
~328 MB/s |
~ 2.624 Mbit/s |
| 1 MB (1.048.576 B) |
~1.314 MB/s |
~10,5 Gbit/s |
Technische Interpretation
Dies zeigt, dass sowohl die RTT- als auch die TCP-Fenstergröße wichtige Faktoren für die TCP-Leistung sind und bei der Behebung von Durchsatzproblemen zusammen analysiert werden müssen.
Ein 20-Byte-IP-Header gibt an, dass keine IP-Optionen vorhanden sind. Der 32-Byte-TCP-Header bestätigt, dass TCP-Optionen verwendet werden, und fügt 12 Byte über den Basis-Header hinzu. Zu diesen Optionen gehören in der Regel MSS, Fensterskalierung und SACK Permitted.
Die selektive Bestätigung (SACK) ist auf beiden Endpunkten aktiviert. Dies ist auf dem Bild nicht sichtbar. Mit SACK kann der Empfänger nicht zusammenhängende Datenblöcke bestätigen und dem Absender genau mitteilen, welche Segmente erfolgreich empfangen wurden.
Wenn beispielsweise die Segmente 1000-2000 und 3000-4000 empfangen werden, aber 2000-3000 fehlt, kann der Empfänger dies explizit angeben. Ohne SACK würde der Absender alle Daten nach der Lücke erneut übermitteln; mit SACK wird nur der fehlende Teil erneut übertragen. Dadurch wird die Leistung in Umgebungen mit Paketverlusten erheblich verbessert.
Paket 1 (SYN)-Analyse
Wireshark normalisiert aus Gründen der Lesbarkeit die Sequenznummer auf Null, obwohl es sich in der Praxis um einen großen Zufallswert handelt. Während des Verbindungsaufbaus wird erwartet, dass keine Nutzlast vorhanden ist. Der MSS-Wert von 1.460 Byte gibt eine MTU von 1.500 Byte an (20 Byte IP-Header + 20 Byte TCP-Header). Ein TTL von 128 kann ein Windows-basierter Host sein. Wenn dieser Wert bei der Erfassung angezeigt wird, bedeutet dies, dass die Erfassung wahrscheinlich über Layer 2 an oder in unmittelbarer Nähe der Quelle durchgeführt wurde.
Paket-2-Analyse (SYN-ACK)
Der ACK-Wert ist 1, da das SYN-Flag eine Sequenznummer belegt, auch wenn keine Nutzlast vorhanden ist. Daher ist ACK = SEQ + 1.
Der beobachtete TTL-Wert von 59 deutet auf einen anfänglichen TTL-Wert von 64 hin, d. h., das Paket durchlief etwa 5 Routing-Hops (64 − 59 = 5). Jeder geroutete Hop dekrementiert den TTL um eins.
Fragmentierungsrisiken und Auswirkungen auf Netzwerke
Das Vorhandensein von ca. fünf Routing-Hops birgt potenzielle Leistungsrisiken, insbesondere im Zusammenhang mit MTU-Diskrepanzen und der Fragmentierung.
Wenn eine zwischengeschaltete Verbindung eine geringere MTU als die ursprüngliche Paketgröße hat, kann es zu einer Fragmentierung kommen. Dies hat mehrere Konsequenzen:
Angesichts dieser Faktoren ist es wichtig, eine konsistente MTU über den Pfad sicherzustellen oder ggf. eine MSS-Klemmung zu implementieren.
Wenn ACK RTT größer als iRTT ist, weist dies darauf hin, dass die Latenz im Vergleich zur Baseline, die während des TCP-Handshakes festgelegt wurde, erhöht wurde.
Das bedeutet, dass das Netzwerk oder die Endgeräte zusätzliche Verzögerungen während der Sitzung verursachen, was in der Regel auf Folgendes zurückzuführen ist:
Wenn diese Bedingung während der TCP-Sitzung beibehalten wird, führt dies zu:
In Wireshark können Sie mithilfe der Funktion "I/O Graphs" (E/A-Diagramme) anzeigen, wie oft die Bedingung ACK RTT > iRTT auftritt: Statistiken → E/A-Diagramme, Anwenden des Anzeigefilters (tcp.analysis.ack_rtt > tcp.analysis.initial_rtt), Auswählen des Impulsstils, Festlegen der Y-Achse auf Pakete und Verwenden eines Intervalls von 50 Mikrosekunden.
Im Diagramm stellen die violetten Impulse die Anzahl der Pakete dar, die diese Bedingung innerhalb eines Intervalls von jeweils 50 Mikrosekunden erfüllen. Wie beobachtet, besteht dieser Zustand während der gesamten Paketerfassung fort, was darauf hinweist, dass die Latenz während der Sitzung durchweg höher ist als die ursprüngliche Baseline. Dieses Verhalten deutet stark auf eine nachhaltige Leistungsminderung statt auf einen vorübergehenden Zustand hin und verstärkt die Notwendigkeit, potenzielle Quellen wie Überlastung, Pufferung oder Verzögerungen bei der Endpunktverarbeitung über den End-to-End-Pfad zu untersuchen.

Es ist auch wichtig festzustellen, wie lange die iRTT überschritten wird, nicht nur wie oft. Obwohl Wireshark keine direkte Subtraktion zwischen Feldern zulässt, kann mithilfe von E/A-Diagrammen ein visueller Vergleich erzielt werden:
In dieser Visualisierung stellt der lila Graph die Bedingung ACK RTT > iRTT dar, die während der gesamten TCP-Sitzung konsistent vorhanden ist. Die Daten zeigen eine anhaltende Latenzinflation, bei der mehrere Spitzen 11 Millisekunden erreichen und ein maximaler Spitzenwert von über 100 Millisekunden beträgt, was dem 11- bis 100-fachen des iRTT-Basiswerts entspricht.
Dieses Verhalten bestätigt, dass die Latenzerhöhung nicht vorübergehend, sondern dauerhaft ist, was auf ein systemisches Problem hinweist, das die Sitzung im Laufe der Zeit beeinträchtigt. Diese anhaltende Abweichung deutet stark auf Faktoren wie Netzwerküberlastung, Pufferung (Bufferbloat) oder Verzögerungen bei der Endpunktverarbeitung hin.

In diesem Abschnitt wird die TCP-Zuverlässigkeit bewertet, indem die Übertragungswiederholung analysiert wird. Auf diese Weise kann geprüft werden, ob der Paketverlust zu einer Leistungsverschlechterung beiträgt.
Das Diagramm zeigt die Verteilung der TCP-Neuübertragungen über die Zeit. Insgesamt wurden 42 Neuübertragungen beobachtet, was nur 0,00125 % des gesamten Datenverkehrs ausmacht.
Dieses Ausmaß an wiederholten Übertragungen ist vernachlässigbar und zeigt deutlich an, dass der Paketverlust in diesem Szenario keinen Beitrag leistet.
Wireshark-Konfiguration (TCP-Neuübertragungen)
Statistics → I/O Graphs
tcp.analysis.retransmission and !tcp.analysis.spurious_retransmission
Das Diagramm zeigt die Anzahl der TCP-Neuübertragungen in Intervallen von 1 Sekunde, die von der Quelle 10.93.19.8 generiert wurden.
In Wireshark gibt eine TCP Spurious Retransmission an, dass ein Host ein Segment erneut übertragen hat, das noch nicht verloren gegangen ist. Das ursprüngliche Paket erreichte den Empfänger erfolgreich, aber der Sender nahm aufgrund ungenauer Zeitschätzung fälschlicherweise einen Verlust an. Dieses Verhalten weist nicht auf einen echten Paketverlust hin, sondern auf eine ineffiziente Weiterleitungslogik beim Sender.
In dieser Aufzeichnung:
Dies bestätigt, dass das Übertragungsverhalten vollständig vom Quell-TCP-Stack und nicht vom Netzwerk gesteuert wird.
Insgesamt wurden 1.112 unberechtigte Neuübertragungen beobachtet, was 0,0332 % des gesamten erfassten Datenverkehrs entspricht.
Wireshark-Konfiguration (TCP Spurious Retransmissions)
Statistics → I/O Graphs
tcp.analysis.spurious_retransmission and ip.src==10.93.19.8
Technische Interpretation
Diese Analyse bestätigt außerdem, dass das Problem nicht mit der Zuverlässigkeit des Netzwerks, sondern mit dem TCP-Verhalten, der Latenz oder der Leistung der Endgeräte zusammenhängt.

Das Diagramm zeigt den effektiven Durchsatz, berechnet auf Basis der TCP-Nutzlast (tatsächlich übertragene Daten) in Megabit pro Sekunde. Der beobachtete Durchsatz schwankt primär zwischen 600 Mbit/s und 800 Mbit/s, was darauf hinweist, dass das Netzwerk während der aktiven Datenübertragung nicht das höhere Bandbreitenpotenzial erreicht.
Wireshark-Konfiguration (effektiver Durchsatz)
Statistics → TCP Streams Graphs → Throughout

Technische Interpretation
Das Diagramm zeigt ein kritisches Verhalten in der TCP-Sitzung, indem die Empfängerkapazität mit den tatsächlich übertragenen Daten (Bytes im Flug) verglichen wird.

Die beobachteten Flugdaten erreichen Spitzenwerte von ca. 1 MB, mit zusätzlichen Spitzenwerten von ca. 8 KB und 5 KB, sind aber primär zwischen 1 KB und 250 KB konzentriert.
Dies deutet darauf hin, dass der Empfänger zwar in der Lage ist, größere Datenmengen zu verarbeiten, jedoch das verfügbare Fenster nicht konsequent ausnutzt.
Wireshark-Konfiguration (Daten im Flug vs. Fenster)
Statistics → TCP Streams Graphs → Throughout
Technische Interpretation
Durch die Analyse der TCP-Nutzlastgröße im Vergleich zur MSS im Zeitverlauf kann festgestellt werden, ob der Sender jedes TCP-Segment effizient nutzt. Diese Analyse wird aus der Perspektive der Quell-IP-Adresse (10.93.19.8) durchgeführt.
In Wireshark werden die Diagramme wie folgt konfiguriert:
Aus der Analyse:

Diese Analyse zeigt, dass die Identifizierung der Ursache von TCP-Leistungsproblemen einen ganzheitlichen End-to-End-Ansatz erfordert, anstatt davon auszugehen, dass das Netzwerk die Hauptursache für die Beeinträchtigung ist.
Der Cisco Nexus 9300-Switch wurde umfassend validiert. Dies umfasste Schnittstellenzähler, QoS-Richtlinien, Routing- und ARP-Stabilität, CPU-Punktverifizierung, SPAN-basierte Paketerfassung und die Validierung der Weiterleitung auf ASIC-Ebene mithilfe von ELAM. Alle Ergebnisse bestätigten konsistent, dass der Switch innerhalb der erwarteten Parameter funktionierte:
Zusätzlich ergab die TCP-Analyse Folgendes:
Die Leistungseinbußen werden durch den Quellserver verursacht, der mit einer MTU von 1500 in einer Jumbo-fähigen Umgebung arbeitet, wodurch eine effiziente Nutzung der verfügbaren Netzwerkkapazität verhindert wird.
Erhöhung der MTU auf dem Quellserver von 1500 auf 9000 Byte entsprechend der Ziel- und Netzwerkinfrastruktur Die Vorteile:
Eine wichtige Erkenntnis aus dieser Analyse ist, dass frühzeitige Schlussfolgerungen bei der Behebung von Problemen mit der Netzwerkleistung vermieden werden müssen. Obwohl es üblich ist, Probleme zunächst dem Netzwerk zuzuweisen, zeigt dieser Fall deutlich, dass das Netzwerk auf dem gesamten Datenebenenpfad ordnungsgemäß funktionierte. Nur durch eine umfassende TCP-Analyse sowohl aus Quell- als auch aus Zielperspektive - einschließlich Handshake-Parametern, RTT-Verhalten, Fensterauslastung, Neuübertragungen und Nutzlasteffizienz - konnte der tatsächliche Engpass genau identifiziert werden.
Indem Sie sich die Zeit nehmen, das TCP-Verhalten detailliert zu analysieren, verhindern Sie Fehldiagnosen, reduzieren unnötige Netzwerkänderungen und stellen sicher, dass die Beseitigung auf die tatsächliche Ursache ausgerichtet ist.
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
07-May-2026
|
Aktualisierter Titel pro Autorenanfrage. |
1.0 |
06-May-2026
|
Erstveröffentlichung |