Sie haben nicht angegeben, über welche Netzwerktechnologien Sie gesprochen haben, also gehe ich von Ethernet und IP [v4] aus.
Ethernet hat den Bereich akzeptabler Nutzdatenlängen immer auf 46 bis 1500 Byte festgelegt und erfordert, dass alle Geräte (Hosts und Switches) im LAN Frames mit 1500 Byte Nutzdaten empfangen können. Aus diesem Grund bietet Ethernet weder einen Fragmentierungsmechanismus noch einen Mechanismus zum Kommunizieren oder Aushandeln von MTUs (oder, was noch wichtiger ist, M R Us - Maximum Receive Units) zwischen Geräten. Tatsächlich erscheint der Begriff "MTU" oder "Maximum Transmission Unit" an keiner Stelle in der IEEE 802.3-Spezifikation.
Fügen wir also IP in das Bild ein. IP hat ein MTU-Konzept, und bei den meisten modernen IP-Stacks können Sie MTUs pro Schnittstelle (und mehr) einstellen. Aber Ihre gestellte Frage klappt im Zusammenhang mit IP auch nicht ganz, denn IP hat eine minimale MTU von 576. Lassen Sie mich Ihre Frage wiederholen, da "M1 eine MTU von 600 hat und M2 eine MTU von 1200 hat ". Aber welche MTU sollen wir sagen, die "Switch" hat? Wenn es sich bei Switch lediglich um einen Layer-2-Ethernet-Switch handelt, gibt es kein Konzept einer einstellbaren MTU. Damit Ihre Frage im IP-Kontext klappen kann, müssen wir diesen Switch in einen Router umwandeln. Nennen wir es "Router" und sagen, es hat zwei Ethernet-Schnittstellen, eine an M1 und eine an M2. Sagen wir auch, dass es auf beiden Schnittstellen MTUs von 1200 gesetzt hat.
- Wenn M1 einen Frame mit einer Nutzlast von 600 Byte an M2 sendet, wäre dies kein Problem.
- Wenn M2 einen Frame mit einer 1200-Byte-Nutzlast an M1 sendet, wäre dies immer noch kein Problem. Warum nicht? Weil die Einstellung der M1 von M1 nicht notwendigerweise ihre MRU geändert hat, und meiner Erfahrung nach sind MTUs und MRUs voneinander getrennt, und Implementierungen geben Ihnen keine Möglichkeit, Ihre MRU zu ändern. Die MRU von M1 an dieser Schnittstelle wäre also 1500, da es sich um Ethernet handelt.
- Der Router weiß nicht, dass er die Frames von M2 fragmentieren muss, da er der Ansicht ist, dass alle Hosts im Ethernet-LAN, in denen M1 eingeschaltet ist, Frames mit 1200-Byte-Payloads empfangen können, da er für eine 1200-Byte-MTU konfiguriert wurde Schnittstelle. Glücklicherweise würde dies wahrscheinlich noch gut funktionieren, wie ich in (2) besprochen habe.
Okay, versuchen Sie immer noch, den wahren Geist Ihrer Frage zu finden und zu beantworten. Nehmen wir an, die Verbindung zwischen M1 und Router ist eigentlich PPP anstelle von Ethernet. Das PPP-Protokoll ermöglicht Hosts die Kommunikation / Verhandlung ihrer MRUs. Nehmen wir an, dass M1 dem Router mitgeteilt hat, dass M1 eine MRU-Beschränkung von 600 Byte hat, sodass der Router seine MTU für diese Verbindung auf 600 Byte gesetzt hat.
Wenn M2 in diesem Fall ein 1200-Byte-IP-Datagramm an M1 sendet (ohne das Bit "Don't Fragment" im IP-Header festzulegen), empfängt der Router das Datenpaket einwandfrei und erkennt, dass es zum Senden fragmentiert werden muss es zu M1. Fragt der Router ihn also in zwei 600-Byte-Fragmente auf? Nun, nein, aus ein paar Gründen ist es nicht so einfach.
Ein Grund ist, dass jedes Fragment einen eigenen IP-Header haben muss, der die Größe jedes Fragments nach dem ersten um 20 Byte erhöht. Der andere Grund ist, dass das Fragmentierungs-Offset-Feld von IP in 8-Byte-Chunks statt in einzelnen Bytes zählt.
Nehmen wir an, das 1200-Byte-Datagramm bestand aus 1172 Byte Anwendungsdaten in einem UDP-Datagramm (8 Byte UDP-Header, 20 Byte IP-Header). Nach der Fragmentierung würde das erste Fragment einen 20-Byte-IP-Header, den 8-Byte-UDP-Header und die ersten 568 Bytes der Anwendungsdaten für insgesamt 586 Bytes enthalten. Der zweite Frame würde einen weiteren 20-Byte-IP-Header, keinen UDP-Header und die nächsten 576 Bytes der Anwendungsdaten für insgesamt 586 Bytes enthalten. So bleiben 28 Byte Anwendungsdaten für das endgültige Fragment übrig, das mit seinem hinzugefügten IP-Header 48 Byte betragen würde.
Das Update basiert auf Kavins Update, dass er über Jumbo-Frames sprach:
Jumbo-Frames sind etwas, das einige Hersteller von Gigabit-Ethernet-Produkten eigenständig um die Zeit herum erstellt haben, als GigE erstellt wurde. Dies wurde (glaube ich) später von der IEEE abgelehnt oder ignoriert und scheint unwahrscheinlich jemals Teil des 802.3-Ethernet-Standards werden. Sogar IEEE 802.3-2008, das nicht nur 1000BASE-T, sondern auch 10 G BASE-T enthält, enthält nichts über 9000-Byte-Frame-Nutzdaten.
Die Anbieter von Jumbo-Frames hatten keine Art von Autonegotiation oder Kommunikationsmechanismus für die Unterstützung von Jumbo-Frames und erstellten auch keine Fragmentierungsmethode auf Ethernet-Ebene, um den (sehr häufigen) Fall zu behandeln, den Sie illustriert haben. Wenn Sie Ihr Ethernet-LAN in diesem nicht standardmäßigen Modus betreiben möchten, müssen Sie sicherstellen, dass alle Hosts und Switches in Ihrem LAN Jumbo-Frames unterstützen.
Wenn die NIC von M1 nicht in der Lage ist, Jumbo-Frames zu empfangen, wird ein Jumbo-Frame als "Ethernet-Jabber" betrachtet - ein defektes Gerät, das "Jabbering on und on" hält; Sendet Bits weit über das Ende eines maximal zulässigen 1500 (wirklich 1518) Bytes hinaus. Beachten Sie, dass diese Bedeutung von Jabber ein Begriff für eine Art Ethernet-Fehlfunktion ist und nicht mit dem gleichnamigen Internet-Chat-System "Jabber" zu verwechseln ist. Sie müssen entscheiden, ob Sie die Verwendung von Jumbo-Frames in diesem Netzwerk beenden oder M1 aktualisieren möchten, um eine NIC zu haben, die Jumbo-Frames unterstützt.
Wenn M1 NIC ist geeignet zum Empfang von Jumbo - Frames, ich vermute, dass für diese Schnittstelle bis zu 1500 seine IPv4 - MTU - Einstellung wird sichergestellt, es nicht überträgt keine Jumbo - Größe IP - Datagramme in einem Jumbo - Ethernet - Frame, aber es wird wahrscheinlich in der Lage sein, Große IP-Datagramme in einzelnen Jumbo-Ethernet-Frames empfangen - kein Problem, da MTU wiederum keine MRU ist und das Festlegen einer IP-Layer-MTU keinen Einfluss darauf hat, welche Frame-Puffer der NIC zulässt. Wenn Sie nun eine NIC / Treibereinstellung ändern, um der NIC zu sagen, dass nur 1500-Byte-Puffer anstelle von 9000-Byte-Puffern verwendet werden sollen, ist dies eine Änderung der Ethernet-Schicht und würde Ihre NIC wahrscheinlich so tun, als wäre sie nicht 9000-Byte-Puffer unterstützen.