マシンとスイッチのMTU設定について
2台のマシンと1台のスイッチがあるとします。
M1--スイッチ--M2。
設定は次のとおりです。
- M1のMTUは100に設定されています
- スイッチのMTUは1000に設定されています
- M2のMTUは1000に設定されています。
質問：
M1が100バイトのパケットをM2に送信しようとしても、問題はないはずですよね？
M2が1000バイトのパケットをM1に送信しようとすると、問題はありますか？
M2は1000バイトのパケットをSwitchに送信できますが、SwitchがパケットをM1に送信しようとすると、パケットを10個の小さなパケットにフラグメント化する必要があります。そうですか？
更新：
より現実的には、M1、スイッチ、およびM2はすべて10Gネットワークで実行されており、IPv4を使用しています。
設定は次のとおりです。
M1のMTUは1500に設定されています
スイッチのMTUは9000に設定されています
M2のMTUは9000に設定されています
質問に答えるのに役立ちますか？
話しているネットワークテクノロジーを指定しなかったので、イーサネットとIP [v4]を想定します。
イーサネットは、許容可能なペイロード長の範囲を常に46〜1500バイトと定義しており、LAN上のすべてのデバイス（ホストとスイッチ）が1500バイトのペイロードを持つフレームを受信できるようにする必要があります。このため、イーサネットはフラグメンテーションメカニズムを提供せず、MTU（または、さらに重要なことに、M）を通信またはネゴシエートするためのメカニズムも提供しません。RUs-デバイス間の最大ReceiveUnits）。実際、「MTU」または「最大伝送ユニット」という用語は、IEEE802.3仕様のどこにも表示されていません。
それでは、IPを図に追加しましょう。 IPにはMTUの概念があり、最新のIPスタックのほとんどでは、インターフェイスごと（およびそれ以上）にMTUを設定できます。ただし、IPの最小MTUは576であるため、前述の質問はIPのコンテキストでもうまく機能しません。したがって、「M1のMTUは600、M2のMTUは1200」と言い換えることができます。 "。しかし、「スイッチ」にはどのMTUがあると言えますか？スイッチが単なるレイヤ2イーサネットスイッチである場合、設定可能なMTUの概念はありません。したがって、IPのコンテキストで質問を解決するには、そのスイッチをルーターに変える必要があります。それで、それを「ルーター」と呼び、2つのイーサネットインターフェースがあり、1つはM1に接続され、もう1つはM2に接続されているとしましょう。また、両方のインターフェイスに1200のMTUが設定されているとします。
- M1が600バイトのペイロードを持つフレームをM2に送信する場合、問題はありません。
- M2が1200バイトのペイロードを持つフレームをM1に送信する場合でも、問題はありません。何故なの？ M1のMTUを設定しても、必ずしもMRUが変更されるわけではなく、私の経験では、MTUとMRUは別々であり、実装ではMRUを変更する方法が提供されないためです。したがって、そのインターフェイスでのM1のMRUは、イーサネットであるため1500になります。
- ルーターは、M2からフレームをフラグメント化する必要があることを認識しません。これは、M1がオンになっているイーサネットLAN上のすべてのホストが、1200バイトのMTU用に構成されているため、1200バイトのペイロードを持つフレームを受信できると考えているためです。インターフェース。幸いなことに、（2）で説明したように、これでもおそらく問題なく機能します。
さて、まだあなたの質問の真の精神を見つけて答えようとしているとしましょう。M1とルーターの間のリンクが実際にはイーサネットではなくPPPです。PPPプロトコルにより、ホストはMRUと通信/ネゴシエートできます。M1がルーターにM1には600バイトのMRU制限があることを伝えたため、ルーターはそのリンクのMTUを600バイトに設定したとします。
この場合、M2が1200バイトのIPデータグラムをM1に送信すると（IPヘッダーの「Do n'tFragment」ビットを設定せずに）、ルーターはそれを正常に受信し、送信するにはフラグメント化する必要があることを認識します。 M1に。では、ルーターはそれを2つの600バイトフラグメントにフラグメント化しますか？いいえ、いくつかの理由でそれほど単純ではありません。
1つの理由は、すべてのフラグメントに独自のIPヘッダーが必要であるため、最初のフラグメントの後に各フラグメントのサイズが20バイト追加されます。もう1つの理由は、IPのフラグメンテーションオフセットフィールドが、個々のバイトではなく8バイトのチャンクでカウントされることです。
したがって、1200バイトのデータグラムがUDPデータグラム内の具体的に1172バイトのアプリケーションデータであったとしましょう（8バイトのUDPヘッダー、20バイトのIPヘッダー）。フラグメント化後、最初のフラグメントには、20バイトのIPヘッダー、8バイトのUDPヘッダー、およびアプリケーションデータの最初の568バイト、合計586バイトが含まれます。 2番目のフレームには、別の20バイトのIPヘッダーが含まれ、UDPヘッダーは含まれず、アプリケーションデータの次の576バイト、合計586バイトが含まれます。これにより、最終フラグメント用に28バイトのアプリケーションデータが残ります。これは、IPヘッダーが追加されると48バイトになります。
ジャンボフレームについて話していたKavinの更新に基づく更新：
ジャンボフレームは、GigEが作成された頃に一部のギガビットイーサネット製品ベンダーが独自に作成したものであり、その後IEEEによって拒否または無視され、802.3イーサネット標準の一部になる可能性は低いようです。 。 1000BASE-Tだけでなく10を含むIEEE802.3-2008でさえGBASE-Tには、9000バイトのフレームペイロードに関する情報は含まれていません。
ジャンボフレームを考案したベンダーは、ジャンボフレームをサポートするための自動ネゴシエーションや通信メカニズムを提供していませんでした。また、説明した（非常に一般的な）ケースを処理するためのイーサネット層の断片化方法も作成していません。この非標準モードでイーサネットLANを実行する場合は、LAN上のすべてのホストとスイッチがジャンボフレームをサポートしていることを確認する必要があります。
M1のNICがジャンボフレームを受信できない場合、ジャンボフレームは「イーサネットジャバー」と見なされます。 「ジャバリングを繰り返し続ける」;最大許容1500（実際には1518）バイトフレームの終わりをはるかに超えてビットを送信し続けるジャバーのこの意味は一種のイーサネット誤動作の用語であり、混同しないでください。同様の名前の「Jabber」インターネットチャットシステム。このネットワークでのジャンボフレームの使用を停止するか、M1をアップグレードしてNIC that]にするかを決定する必要があります。ジャンボフレームをサポートします。
M1のNICisがジャンボフレームを受信できる場合、そのインターフェイスのIPv4 MTUを1500に設定すると、確実に受信できないと思われます。 送信単一のジャンボイーサネットフレームでジャンボサイズのIPデータグラムを送信しますが、大規模なIPデータグラムを受信できる可能性があります。単一のジャンボイーサネットフレームは問題ありません。これもMTUはMRUではなく、IP層MTUを設定しても、NICが許可するフレームバッファのサイズには影響しません。調整している場合は、 NICに9000バイトのバッファではなく1500バイトのバッファのみを使用するように指示するNIC /ドライバ設定。これはイーサネット層の変更であり、おそらくNIC 9000バイトのバッファをサポートしていないかのように動作します。
正直なところ、MTUを100に設定しても、どのような形式のIP接続も確立できるとは思いません。 ipv4には最低576 ...そしておそらくそれ以上が必要だと思います。それはCRAAAZYSMALLです...通常、過去20年間に構築された10/100スイッチは1492または1500 MTUを備えています...そして、9000までのより優れた機器を備えたより要求の厳しいネットワークで。
「pmtu」またはパスMTUと呼ばれるテクノロジーがあります。これにより、一方の端が他方に確実に送信できるパケットの最大サイズを検出し、パケットのサイズを最小のMTUのサイズに縮小します。
これよりも大きいパケットは、IPヘッダーに「DF」またはDo not Fragmentフラグが設定されていない限り、フラグメント化されます。設定されている場合、パケットは途中で失われます。
あなたが説明しているようなピアツーピア接続では、PMTUを非常にうまく使用する必要があります。これは、多数のネットワークを介してルーティングしていて、ユーザーと宛先の間のルーターの1つがPMTUを適切にサポートしておらず、使用する正しいMTUサイズを報告しない場合にのみ問題になります。