Default für MTU / Max Frame Size - hab ich nen Denkfehler?

[firefox_i]

Hallo zusammen,
bei meinen Switchen (GS-2326) ist bei allen Ports für Maximum Frame Size der Defaultwert von 9600 drin.

Da ich in der nächsten Zeit an den Switchen einiges verändern werden/Muss hab ich mich auch mal in das Thema Jumbo Frames eingearbeitet und finde es etwas seltsam, dass da diese großen Werte drin sind.

Meine naive Vorstellung wäre jetzt:
- 'Ich stelle an Ports eher Standardmäßig 1518 ein (Standard ETH Frame MTU).
- an den Ports an denen Clients hängen, die mehr können, stell ich höhere Werte ein. zB an den Ports an denen der Server und die NAS hängen
- auf diesen Clients aktiviere ich dann Jumbo Frames

Ich hätte dann gehofft, dass der Switch zwischen NAS und Server mit Jumbos arbeitet.
Datenströme an andere Clients werden dann ggf. vom Switch auf die kleineren MTUs fragmentiert.

Hab ich da nen Denkfehler oder passt das so?

Hat jemand ne Idee, warum diese Defaults so in den Switch-OS drin sind?
Ist ja potentiell schon risikobehaftet.

Oder hab ich da nen Mega-Denkfehler?

Danke
S.

[rotwang]

Ich hätte dann gehofft, dass der Switch zwischen NAS und Server mit Jumbos arbeitet.
Datenströme an andere Clients werden dann ggf. vom Switch auf die kleineren MTUs fragmentiert.

Wenn Dein Switch wirklich nur als Switch auf Layer 2 arbeitet, dann kann er das gar nicht, weil Ethernet (802.3) selber überhaupt keinen Fragmentierungs-Mechanismus kennt. Außerdem sind Jumbo-Frames nicht Teil des 802.3-Standards und ein Switch weiß überhaupt nicht, ob die Endgeräte sie unterstützen oder nicht. Vielleicht mit der Ausnahme, dass Geräte mit 10/100 Mbps-Links sie sehr sicher nicht unterstützen, weil das Feature erst mit GBit-Ethernet aufgekommen ist.

Ich kenne diesen Switch nicht im Detail, aber ich würde davon ausgehen, dass diese Einstellung lediglich bewirkt, dass größere Pakete verworfen und nicht weitergeleitet werden.

[firefox_i]

Ich kenne diesen Switch nicht im Detail, aber ich würde davon ausgehen, dass diese Einstellung lediglich bewirkt, dass größere Pakete verworfen und nicht weitergeleitet werden.

Hey, dann würden die Defaultwerte auch wieder Sinn ergeben.

Ich frag mich halt:
Wie kann ich dann jemals in einem LAN auf bestimmten Strecken Jumbo Frames einsetzen?
Irgendein Endgerät - und sei es nur irgendein Labeldrucker oder sonstwas - gibt es immer, das keine Jumbos kann.

Oder rettet einen da PMTU des OS, das eben für jede Verbindung die MTU ermittelt?

[lna]

die Porteinstellung sagt nur was der port zulässt (und wie viel buffer dafür eingeplant wird).
dein normales Endgerät hat ab Werk eine MTU von 1500 eingestellt.
das wird niemals größere Frames verschicken.

Große frames werden nur von geräten geschickt die das in eigen netzwerkkarte eingetragen haben und es werden die frames nur dann so groß gemacht, wenn auch die Datenmenge vorliegt.
Wenn du den Port zum client klein stellst, hat keiner die chance festzustellen, dass Fragmentierung benötigt wird.

Um ganz sicher zu gehen kannst du eine L3-Trennung zwischen Client und Server einführen. Der Router bekommt dann auf der hohen MTU Seite auch eine hohe mtu eingrtragen auf der kleinen-mtu seite eine kleine mtu und verschickt dann selbst "fragmentation needed" bzw. fragmentiert im Auftrag wenn Fragmentierung auf dem Frame erlaubt ist.

[firefox_i]

Um ganz sicher zu gehen kannst du eine L3-Trennung zwischen Client und Server einführen.

Da Client + Server im selben Subnetz sind läuft das ja erstmal nicht über den Server.

Wie gesagt:
Dir Frage ist doch, ob Windows Rerchner (WIN10/11, Server 2019/22) über den PMTUD Mechanismus die maximal mögliche MTU ermittelt oder nicht.

Irgendwie drängt sich mir der Verdacht auf, dass das ganze Jumbo-Frame Thema nur bei direkten Point-2-Point Verbindungen sinnvoll ist.
Ich bin auch unsicher, ob eine MTU von zB 9000 überhaupt was bringen würde, oder ob die Effekte eher marginal sind.
Größere Datenmengen fallen bei mir nur dann an, wenn Backups gefahren werden.
Dann werden GB-große Daten von den Clients zum Server und von dort dann auf als SecondStorage auf eine NAS transferriert.

S.

[lna]

da passiert nichts dynamisch, bei Windows wird das hart eingetragen.

große MTU macht bei Server-Storage Traffic sinn (z.B. FCOE oder ISCSI) und wird dort ebenfalls hart auf den Netzwerkkarten der beteiligten Geräte eingetragen.

Router können häufig PMTU Discovery auf der WAN Schnittstelle.

[GrandDixence]

Ordentliche Netzwerkkarten verfügen über Hardwareschaltkreise zur Beschleunigung der Verarbeitung von empfangenen und zu versendenden Datenpaketen. Diese Hardwareschaltkreise entlasten auch die CPU (Offload). Zum Beispiel:
https://learn.microsoft.com/en-us/windo ... ip-offload

Werden Jumbo Frames eingesetzt, können häufig diese Offload-Hardwareschaltkreise auf der Netzwerkkarte und den Netzwerkkomponenten nicht mehr verwendet werden und die Performance bricht ein.

Gemäss diesem Artikel:
https://blog.osnexus.com/2024/01/31/the ... bo-frames/
liegt beim Einsatz von Jumbo Frames im Serverbereich eine Performanceverbesserung von 20% drin. Aber man handelt sich sehr wahrscheinlich heftig zeitfressende Probleme ein!

Im Datencenter-Bereich gibt es aber noch weitere (hochproblematische) Optimierung wie DCTCP (DataCenter TCP), welche vermutlich auch Performancegewinne im zweistelligen Bereich bringen würden, inklusive zeitintensiver Probleme...
https://docs.kernel.org/networking/dctcp.html

https://learn.microsoft.com/en-us/previ ... 8(v=ws.11)

[firefox_i]

da passiert nichts dynamisch, bei Windows wird das hart eingetragen.

Ich denke Du hast mich misverstanden.
Es geht nicht um den Eintrag der MTU in den Eigenschaften des LAN Adapters, sondern um die automatische Ermittllung der tatsächlich erreichbaren MTU im Netz.
Da bauen - zumindest bei mir - sowohl die Server (WIN2019 und WIN2022) und die Clients (Win10/11Pro) Listen auf, in denen pro Verbindung (also IP-basiert) die MTU eingetragen wird die maximal möglich ist.

liegt beim Einsatz von Jumbo Frames im Serverbereich eine Performanceverbesserung von 20% drin.

Hmm 20% kommt mir etwas viel vor.
Ich weiß nicht wo mein Denkfehler ist, aber wenn ich einen Jumboframe mit 9k und 4 normale mit 1500byte Betrachte, viertelt sich der Protokolloverhead und geht von etwas über 2% auf etwas über nem halben Prozent zurück.
Wo da 20% stecken sollen ist für mich nicht nachvollziehbar.

Aber ungeachtet dessen:
Ich werde - rein interessehalber - mal in nem Testsystem schauen, was die Änderung von MTU1500 auf 9000 wirklich an realer Durchsatzsteigerung bringt.

Und so wie ich es abschätze, scheint es dann unterm letzten Strich höchstwahrscheinlich auf 1500 rauszulaufen, wegen der ganzen potentiellen Themen, die man sich einhandeln kann.

Ich werde auch mal schauen, was passiert, wenn ein MTU1500 Client mit dem MTU9000 Server kommunizieren will.....rein aus Interesse.
Ob da über die PMTUD eben die 1500 ausgehandelt werden...ich bin gespannt.

S.

[Hagen2000]

Hmm 20% kommt mir etwas viel vor.
Ich weiß nicht wo mein Denkfehler ist, aber wenn ich einen Jumboframe mit 9k und 4 normale mit 1500byte Betrachte, viertelt sich der Protokolloverhead und geht von etwas über 2% auf etwas über nem halben Prozent zurück.
Wo da 20% stecken sollen ist für mich nicht nachvollziehbar.

Sehe ich auch so - aber 9k sind 6 * 1500
Werde mit Interesse deine Ergebnisse verfolgen.

[rotwang]

Hmm 20% kommt mir etwas viel vor.
Ich weiß nicht wo mein Denkfehler ist, aber wenn ich einen Jumboframe mit 9k und 4 normale mit 1500byte Betrachte, viertelt sich der Protokolloverhead und geht von etwas über 2% auf etwas über nem halben Prozent zurück.
Wo da 20% stecken sollen ist für mich nicht nachvollziehbar.

Der Ausgangspunkt für die Einführung von Jumbo-Frames war, dass viele Netzwerkkomponenten einen Bearbeitungsaufwand pro Paket haben, der unabhängig von der Paketgröße ist - egal ob das Paket 64, 1500 oder 9000 Byte lang ist. Mit grossen Paketen kann ein Router mehr Durchsatz schaufeln. Um den gesparten Overhead durch weniger MAC- und IP-Header ging's da wohl weniger. Wenn das die ganze Wahrheit wäre, dann könnte ein Router mit Jumbo-Frames also sechsmal soviel Daten schaufeln. Auf einem Server oder Client hat hat man auch Komponenten, die mit der Payload etwas machen und nicht nur mit den Headern, da relativiert sich das natürlich und die Wahrheit liegt irgendwo dazwischen.

Über die Jahre sind die Computer und Router schneller geworden und irgendwann konnten dann alle z.B. einen GBit-Durchsatz auch mit 'normalen' 1500-Byte-Frames handeln und man konnte sich die Interop-Probleme der Jumbo-Frames wieder sparen. Mit jeder neuen Generation von Netzen (1,10,40,100...GBit) kommt das Thema natürlich neuerlich auf.

[firefox_i]

Naja, also wenn der CPU seitige Unterschied zwischen 6 mal Header bauen zu 1 mal Header bauen 20% ist, dann ist die CPU schon recht gemächlich unterwegs.
CRC Berechnung ist linear zur Datenstromlänge.

Was ich mir vorstellen kann:
In einem Netzwerk mit mehreren Switchen müssen die Daten über die UP/DOWN links.
Wenn jetzt "viel los ist", dann sind diese UDL recht stark belegt und die einzelnen Pakete werden nicht sofort versendet.
Und wenn man dann eben wenige große Pakete hat, dann gehen die eben in einem durch, wohingegen die 6 1500MTU Pakete durch andere Pakete unterbrochen werden.

Wie gesagt: ich muss es mir mal im realen Leben anschauen

[GrandDixence]

Wie gesagt: ich muss es mir mal im realen Leben anschauen

Beim Testen mit TCP-Netzwerkverbindungen den MSS-Mechanismus und das allenfalls vorhandene "MSS Clamping" beachten.
https://de.wikipedia.org/wiki/Maximum_Segment_Size

fragen-zur-lancom-systems-routern-und-g ... ml#p112809