6
Cisco Campus Netz mit Win10 Clients: TCP Autotuning?
Hallo
Top - Down sich mit dem Thema auseinander setzend:
Ausgangslage:
Cisco Campus Architektur. Switche sind primär 29xx.
Verschiedene Gebäude bis zu 140km verteilt
Anbindung grösstenteils über 1 GBit, aber auch noch 100MBit Leitungen
Clients setzen Citrix (SAP) als auch die üblichen Browser und Office / Outlook Lösungen ein.
Die Switche an den 100 Mbit Standorten weisen mehr Drops auf. Die Klagen der Benutzer auch.
Einer der langjährigen Netzexperten meinte nun, man könne das Problem anstatt über Leitungsausbau auch damit lösen, dass man "TCP receive window autotuning level" ausschaltet. Er argumentiert, dass ein Netz keine Datern buffern kann und das der Datenmenge der Win 10 Clients auf Grund dieser seit Vista / Server 2008 eingeführten Funktion zu den Drops führe.
Logisch könnte man das testen, in dem man einfach einen Test an 2 Standorten über eine Woche fährt und die Anzahl Drops vergleicht. Die Switche werden alle Jahre gebootet und Counter clearing wird nicht durchgeführt.
Praktisch halte ich nicht viel von diesem Ansatz. Weil im Internet keine Beispiele der letzten 5 Jahre zu finden sind. Und in der Cisco Community finde ich lediglich einen Post von 2012. Ich tendiere in Richtung, akademische Exzentrik bzw. theoretisieren eines Experten.
Was sagen die Cisco Experten dazu?
Beste Grüsse
Top - Down sich mit dem Thema auseinander setzend:
Ausgangslage:
Cisco Campus Architektur. Switche sind primär 29xx.
Verschiedene Gebäude bis zu 140km verteilt
Anbindung grösstenteils über 1 GBit, aber auch noch 100MBit Leitungen
Clients setzen Citrix (SAP) als auch die üblichen Browser und Office / Outlook Lösungen ein.
Die Switche an den 100 Mbit Standorten weisen mehr Drops auf. Die Klagen der Benutzer auch.
Einer der langjährigen Netzexperten meinte nun, man könne das Problem anstatt über Leitungsausbau auch damit lösen, dass man "TCP receive window autotuning level" ausschaltet. Er argumentiert, dass ein Netz keine Datern buffern kann und das der Datenmenge der Win 10 Clients auf Grund dieser seit Vista / Server 2008 eingeführten Funktion zu den Drops führe.
Logisch könnte man das testen, in dem man einfach einen Test an 2 Standorten über eine Woche fährt und die Anzahl Drops vergleicht. Die Switche werden alle Jahre gebootet und Counter clearing wird nicht durchgeführt.
Praktisch halte ich nicht viel von diesem Ansatz. Weil im Internet keine Beispiele der letzten 5 Jahre zu finden sind. Und in der Cisco Community finde ich lediglich einen Post von 2012. Ich tendiere in Richtung, akademische Exzentrik bzw. theoretisieren eines Experten.
Was sagen die Cisco Experten dazu?
Beste Grüsse
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: 1905358516
Url: https://administrator.de/forum/cisco-campus-netz-mit-win10-clients-tcp-autotuning-1905358516.html
Ausgedruckt am: 12.04.2025 um 19:04 Uhr
6 Kommentare
Neuester Kommentar
Von den geschilderten Anpassungen halte ich nichts. Das ist etwas, was du in sehr isolierten Umgebungen (z.B. lokales Storage-Netz) machen kannst, aber nicht auf Verbindungen mit Congestion.
Das produziert eher mehr Probleme als es löst.
Das Autotuning (oder auch "Sliding Window") hilft dir und dem Netzwerk, bei Last nicht komplett zusammenzubrechen.
Grundsätzlich kann man jedoch über eine (am Router stattfindende) künstliche Verkleinerung des TCP-Transmit-Window tatsächlich die Netzwerk-Congestion besser steuern, gerade wenn viele verschiedene Clients involviert sind.
Reduziert man das Receive-Window, werden die einzelnen Verbindungen schlechtestenfalls langsamer, es entstehen aber auch weniger Peaks, die kurzzeitig die 100M auslasten.
Das produziert eher mehr Probleme als es löst.
Das Autotuning (oder auch "Sliding Window") hilft dir und dem Netzwerk, bei Last nicht komplett zusammenzubrechen.
Grundsätzlich kann man jedoch über eine (am Router stattfindende) künstliche Verkleinerung des TCP-Transmit-Window tatsächlich die Netzwerk-Congestion besser steuern, gerade wenn viele verschiedene Clients involviert sind.
Reduziert man das Receive-Window, werden die einzelnen Verbindungen schlechtestenfalls langsamer, es entstehen aber auch weniger Peaks, die kurzzeitig die 100M auslasten.
2
Guten Morgen LordGurke
Danke für die Einschätzung.
Was ist die Parade zu der Aussage "Ein Netz kann keine Daten buffern, daher muss der TCP- Client beim senden kontrolliert werden"?
Meiner Ansicht nach, spielt dieser Sachverhalt bei Ethernet / TCP keine Rolle. Anders als Token Ring, wird solange gesendet bis alles am Ziel ist. Das Netz wird natürlich immer langsamer, wenn das TCP Ziel lange auf die einzelnen Pakete warten muss.
Den TCP Datenverkehr am Router zu konfigurieren leuchtet mir ein. Den TCP IP Stack eines Client, egal welches OS, für den TCP Verkehr und die Leistung einer Leitung eher weniger. Last but not least, wurde dieses Feature von MS 2006 eingeführt.
D.h. die Netzwerk Firmen wie Cisco hatten mehr als genug Zeit darauf zu reagieren, falls MS hier ein "Manhatten Project" erfunden hätte. Ferner würde es im weltweiten Netz Artikel dazu geben. Artikel nach 2012 sind so gut wie nicht existent. Folgerung: nicht relevant.
Vielen Dank
Beste Grüsse
Peter
Danke für die Einschätzung.
Was ist die Parade zu der Aussage "Ein Netz kann keine Daten buffern, daher muss der TCP- Client beim senden kontrolliert werden"?
Meiner Ansicht nach, spielt dieser Sachverhalt bei Ethernet / TCP keine Rolle. Anders als Token Ring, wird solange gesendet bis alles am Ziel ist. Das Netz wird natürlich immer langsamer, wenn das TCP Ziel lange auf die einzelnen Pakete warten muss.
Den TCP Datenverkehr am Router zu konfigurieren leuchtet mir ein. Den TCP IP Stack eines Client, egal welches OS, für den TCP Verkehr und die Leistung einer Leitung eher weniger. Last but not least, wurde dieses Feature von MS 2006 eingeführt.
D.h. die Netzwerk Firmen wie Cisco hatten mehr als genug Zeit darauf zu reagieren, falls MS hier ein "Manhatten Project" erfunden hätte. Ferner würde es im weltweiten Netz Artikel dazu geben. Artikel nach 2012 sind so gut wie nicht existent. Folgerung: nicht relevant.
Vielen Dank
Beste Grüsse
Peter
Der Vollständigkeit halber:
Ich habe hier mal ein ausführlicheres Traktat zum Thema "Rolle des TCP-Window bei Congestion" geschrieben.
Mit dem Kram habe ich mich auch nur deshalb so intensiv beschäftigt, weil ich einem RZ-Kunden von uns erklären musste, wo der Packetloss auf seiner Firewall herkommt, wenn alle seine Leute darüber surfen.
Der hatte nämlich TCP-Tuning auf den Clients gemacht, weil er bemerkt hatte, dass es immer ein paar Sekunden dauert, bis die volle Download-Geschwindigkeit erreicht wurde. Hatte dann halt auch Nachteile.
Ich habe hier mal ein ausführlicheres Traktat zum Thema "Rolle des TCP-Window bei Congestion" geschrieben.
Mit dem Kram habe ich mich auch nur deshalb so intensiv beschäftigt, weil ich einem RZ-Kunden von uns erklären musste, wo der Packetloss auf seiner Firewall herkommt, wenn alle seine Leute darüber surfen.
Der hatte nämlich TCP-Tuning auf den Clients gemacht, weil er bemerkt hatte, dass es immer ein paar Sekunden dauert, bis die volle Download-Geschwindigkeit erreicht wurde. Hatte dann halt auch Nachteile.
2
Hallo LordGurke
Sehr spannender Post. Vielen Dank!
Viele Grüsse
Peter
Sehr spannender Post. Vielen Dank!
Viele Grüsse
Peter
Grundsätzlich kann man jedoch über eine (am Router stattfindende) künstliche Verkleinerung des TCP-Transmit-Window tatsächlich die Netzwerk-Congestion besser steuern,
Was genau am Router willst Du wie in diesem Kontext konfigurieren? Ich habe seit heute Morgen darüber nachgedacht und kam zu keinem Schluss.
Beste Grüsse
Peter
Manche Router können bei TCP die maximale Window-Size begrenzen.
Wenn man die künstlich klein hält, kann man damit verhindern, dass eine einzelne Verbindung durch kurzzeitige Bursts mehr Daten anfordert, als durch die Leitungen passen.
Wenn man die künstlich klein hält, kann man damit verhindern, dass eine einzelne Verbindung durch kurzzeitige Bursts mehr Daten anfordert, als durch die Leitungen passen.
2
