Lange TCP Retransmission Sequenzen - welche Ursachen kann es geben?
Guten Morgen,
auf der Suche nach einer Lösung für unser SharePoint Problem (SharePoint Ausfälle nur über unser Netzwerk) wurde mir von einem hilfsbereiten User Wireshark empfohlen. Nun bin ich dabei mich in dieses sehr umfangreiche Programm einzuarbeiten.
Schnell wurde deutlich, dass Port 443 häufig TCP Retransmission Fehler hat - im angefügten Beispiel ist Google betroffen.
Meine Frage: Ist das ein normales Vorkommen? Falls nein, wo sollte ich bei der weiteren Ursachen Suche ansetzen?
auf der Suche nach einer Lösung für unser SharePoint Problem (SharePoint Ausfälle nur über unser Netzwerk) wurde mir von einem hilfsbereiten User Wireshark empfohlen. Nun bin ich dabei mich in dieses sehr umfangreiche Programm einzuarbeiten.
Schnell wurde deutlich, dass Port 443 häufig TCP Retransmission Fehler hat - im angefügten Beispiel ist Google betroffen.
Meine Frage: Ist das ein normales Vorkommen? Falls nein, wo sollte ich bei der weiteren Ursachen Suche ansetzen?
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 520313
Url: https://administrator.de/forum/lange-tcp-retransmission-sequenzen-welche-ursachen-kann-es-geben-520313.html
Ausgedruckt am: 24.04.2025 um 04:04 Uhr
10 Kommentare
Neuester Kommentar
Ist das ein normales Vorkommen?
Nein, natürlich nicht !Es ist vielmehr ein sicheres Indiz dafür das es bei dieser massiven Häufigkeit, wie im Screenshot zu sehen, irgendwo massive Probleme im Netzwerk oder Netzwerk Design gibt.
Rettransmissions treten auf wenn ein Empfänger keine ACK Pakete an den Sender sendet oder diese nicht rechtzeitig eintreffen. Sowas deutet immer auf Performance Probleme im Datenpfad zwischen Sender und Empfänger hin.
Diese können sehr vielfältig sein:
- Defekte Kabel und Transceiver
- Defekte NICs
- Defekte oder Bug behaftete Treiber
- Falsches oder fehlerhaftes Netzwerk Design
- Asymetrisches Routing bei geroutetem Traffic
- Defekte Switches oder Switchports
- Spanning Tree Problematiken durch falsch oder fehlerhaft designtes Spanning Tree
Da du keinerlei Angabe zum Netz und Netzdesign machst kann man hier nur im freien Fall raten und die Kristallkugel bemühen.
Klasse, danke dir! Das ist eine klare Aussage mit der ich was anfangen kann!
Unser Netzwerk ist etwa so aufgebaut:
User - cisco Switch - zyxel Switch - Medienkonverter - Patch Panel - Medienkonverter - Firewall - Hytron.
Dieser Aufbau steht seit ein paar Jahren, das SharePoint Problem tritt seit Mai auf. Diese Woche wurde der alte cisco Switch durch einen neuen ersetzt und ein Firewall Austausch steht auch noch an.
Unser Netzwerk ist etwa so aufgebaut:
User - cisco Switch - zyxel Switch - Medienkonverter - Patch Panel - Medienkonverter - Firewall - Hytron.
Dieser Aufbau steht seit ein paar Jahren, das SharePoint Problem tritt seit Mai auf. Diese Woche wurde der alte cisco Switch durch einen neuen ersetzt und ein Firewall Austausch steht auch noch an.
cisco Switch - zyxel Switch
Da liegt vermutlich das Problem ?!Ist das ein Cisco Switch aus der SG SoHo Serie oder ein Catalyst ??
Die Catalysten arbeiten mit PVSTP+ einem Cisco proprietären Spanning Tree der nicht mit dem Zyxel kompatibel ist der sehr wahrscheinlich nur einfaches und billiges Single Span kann ?!
Da hast du dann ein Problem, denn durch die STP Inkompatibilitäten kommten es dann zu unkontrollierten Link Toogles. Du hast dir vermutlich noch nie das STP Log angesehen obs da Topo Changes gibt, oder ??
Wenn es ein SoHo SG ist dann nicht, denn der macht auch nur Single Span. Dennoch sollten dann auch hier beide RSTP machen und einer sollte als Root Switch (Priority) definiert sein !
Ist das ein Cisco Switch aus der SG SoHo Serie oder ein Catalyst ??
Es ist ein Cisco Catalyst Switch, bis vor paar Tagen war es aber ein Summit X20e-48t. An dem SharePoint Problem hat sich nichts verändert, wir haben nur einen allgemein bessere Upload seit dem Wechsel.
Unabhängig davon ist das natürlich ein guter Einwand mit dem Zyxel Switch.
Es ist ein Cisco Catalyst Switch,
Tödlich was STP anbetrifft !!!Dann hat sich sicher keinerlei Gedanken über das Cisco PVSTP+ gemacht !! Fahrlässig und zeugt eher von wenig Netzwerk KnowHow beu euch.
Cisco kann kein Single Span und dann kommt es eben zu unkalkulierbaren STP Verhalten im Netz. Du kannst sicher sein das das der Grund ist.
Du hast nur eine Chance da Cisco kein Single Span kann und der Zyxel logischerweise das Cisco PVSTP+ nicht supportet musst du auf den kleinsten gemeinsamen Nenner MSTP geben und bei Switch Familien generell auf MSTP umstellen.
Wie das geht kannst du hier nachlesen:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)
Die Konfig der HPs dort kannst du 1:1 auf deine Zyxels übertragen.
Sorry, aber diese STP Problematik kennt man doch aber als Netzwerker wenn man Cisco Catalysten mit Billigswitches einsetzt !!
Das ist sicherlich alles richtig, aber die cisco switche haben wir ja erst seit ein paar Tagen, das SharePoint Problem besteht seit Mai. Wenn ich dich richtig verstehe, wird es das Problem nicht mit dem "einfachen" Summit Switchen gegeben haben, oder?
Dann muss es ja zumindest eine weitere Ursache geben.
Ich bin im übrigen kein Netzwerker - wir haben hier keinen lokalen. Daher versuche ich gerade Schritt für Schritt in das Thema rein zukommen.
Dann muss es ja zumindest eine weitere Ursache geben.
Ich bin im übrigen kein Netzwerker - wir haben hier keinen lokalen. Daher versuche ich gerade Schritt für Schritt in das Thema rein zukommen.
die cisco switche haben wir ja erst seit ein paar Tagen,
Aber der Installateur, Dienstleister hätte das wissen müssen wenn er Cisco PVSTP+ Switches in eine Umgebung mit billigen SoHo Switches hängt und das entsprechend anpassen müssen. Da hat der einen schlechten Job gemacht !!wird es das Problem nicht mit dem "einfachen" Summit Switchen gegeben haben, oder?
Ich kenne Extreme Switches nicht so genau. Es gibt aber eine Reihe von Herstellern die Ciscos proprietäre PVSTP+ BPDU Pakete automatisch erkennen und sich dann auch automatisch auf PVSTP+ an diesem Port umstellen. Grundsätzlich müssen sie dann auch das Cisco PVSTP+ Protokoll supporten.Ruckus ICX Switches machen sowas zum Beispiel. Da kann man also einfach den Cisco zustecken und gut iss.
Billige Soho Switches wie NetGear, Zyxel, D-Link und Co und z.B. auch HPs können das aber nicht. Die supporten in der Regel nicht mal PVST also ein Per VLAN Spanning Tree Verfahren sondern nur das billige und einfache Single Span Verfahren was dazu nicht kompatibel ist und wo dann solche Problematiken vorbestimmt sind.
Du musst also per Handbuch oder Datenblatt klären ob die Extremisten auch Cisco PVSTP+ fähig sind wie z.B. die Ruckus ICX Switches.
wir haben hier keinen lokalen
Aber irgendein Dienstleister (oder eher Bastler) wird die Catalysten dann wohl installiert haben, oder ? 
Ich habe es gerade einmal in Erfahrung bringen können: Der Root Switch ist der Zyxel Switch und das Protokoll ist RSTP.
Der Root Switch ist der Zyxel Switch und das Protokoll ist RSTP.
Wie gruselig !!Klar, denn die Cisco Switches kann der Zyxel durch die Inkompatibilität ja gar nicht sehen.
Ist vermutlich auch nicht gewollt das ein billiger SoHo Switch Root ist wenn man (vermutlich) im Core 10mal so teure Premium Switches hat....?!
Da liegt wohl einiges im Argen in diesem Netz ?!!
Der von uns angestellte Dienstleister (die Firma hat einen eigentlich guten Ruf in ganz Deutschland) ist sich unserer Struktur hier bewusst und empfand es anscheinend als nicht notwendig, den Zyxel auch auszutauschen, bzw. wurde uns dazu nichts gesagt...
