ジャンボフレームが実際に機能しているかどうかのテスト
ジャンボフレームが実際に機能しているかどうかをテストするコマンドはありますか？つまり、途中でパケットが分割されたかどうかを報告するある種の「ping」。
UbuntuでESXiホストを使用しているVMこれは、iSCSIを介してDell MD3000iをマウントします。ジャンボフレームがスイッチで有効になっておらず、管理アクセスを簡単に取得できないと思います。ディスクアレイをESXiホストに直接接続するオプションがありますが、ジャンボフレームが最初に問題であることを確認する方法が必要です。
ジャンボフレームを有効にすると、通常はMTUを9000に設定することで、より大きな最大転送単位（MTU）が許可されます。
これが機能していることを確認するには、-lフラグを指定して windowsのping を使用してパケットサイズを設定し、-fフラグを使用してパケットにフラグメント化しないフラグを設定します。
ping my.test.Host -f -l 8972
パケットが断片化すると、次のようになります。
Packet needs to be fragmented by DF set
通常目にするものの代わりに。
Linuxの場合、 pingコマンド は異なるフラグを使用します。 -sはパケットサイズを設定し、-M do Do Not Fragmentを設定します。したがって、上記のコマンドは次のようになります。
ping my.test.Host -M do -s 8972
パケットサイズを調整することにより、リンクのMTUが何であるかを理解できます。これは、パス、スイッチ、コンピューター、ターゲット、またはその間のその他の任意のデバイスで許可されている最小のMTUを表します。
これだけではMTUの最小値はわかりません-パス内のさまざまなデバイスに対してテストを実行することで問題を解決できる可能性がありますが、MTUを制限する透過的なルーターが常に存在する可能性がありますが、表示されませんtracerouteの場合。
注ICMPヘッダーには28バイトのオーバーヘッドがあるため、MTUは上記の方法で設定した数値よりも28バイト大きくなります。したがって、MTUが9000かどうかを確認するには、実際にpingパケットサイズを9000-28 = 8972に設定する必要があります。
Updateホストとターゲットの間のパス全体のMTUを具体的に把握できるいくつかのリソースを見つけました。
- Windowsの場合 mturoute
- * nix tracepathまたはtraceroute --mtuの場合
これが機能するかどうかはわかりませんが、試してみることができます。
MDSMクライアントがインストールされているコンピューターで、ジャンボフレームがサポートされ、有効になっていることを確認してから、MDSMクライアントのサポートタブに移動して、[サポート情報の収集]リンクを選択し、ファイルをダウンロードするMDSMクライアントの場所を選択します。 MDSMクライアントでパケットキャプチャを開始し、開始ボタンをクリックして、サポート情報（Zipファイル）の収集とダウンロードを開始します。収集/ダウンロードが完了したら、キャプチャを見て、MD3000iからMDSMクライアントまでのイーサネットフレームの大きさを確認します。スイッチ、MD300i、およびMDSMクライアントがすべてジャンボフレーム用に構成されている場合は、キャプチャのイーサネットフレームサイズにそれが表示されます。
ESXiでは、使用するインターフェイスを指定する必要があります。指定しない場合、pingはmgmtインターフェイス経由でルーティングされ、さらに-dでDF（フラグメント化しないでください）を設定します）：
vmkping -I vmkX -s 8972 -d x.x.x.x