ジャンボフレームが実際に機能しているかどうかのテスト

ジャンボフレームが実際に機能しているかどうかをテストするコマンドはありますか？すなわち、パケットが途中で分割されたかどうかを報告するある種の「ping」。

iSCSI経由でDell MD3000iをマウントするUbuntu VMを備えたESXiホストを使用しています。スイッチでジャンボフレームが有効になっていないため、管理者が簡単にアクセスできません。ディスクアレイをESXiホストに直接接続するオプションがありますが、ジャンボフレームが最初に問題であることを確認する方法が必要です。

ジャンボフレームを有効にすると、通常、MTUを9000に設定することで、最大伝送単位（MTU）を大きくすることができます。

これが機能したことを確認するために、ウィンドウでpingを使用して-lフラグを指定してパケットサイズを設定し、-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。

注意 MTUは、あなたが上記の方法で確立数値より28バイト大きいので、ICMPヘッダの28バイトのオーバーヘッドがあります。したがって、MTU 9000を確認するには、実際にpingパケットサイズを9000-28 = 8972に設定する必要があります。

更新ホストとターゲット間のパス全体でMTUを明確に把握するリソースを見つけました。

• Windows mturouteの場合
• * nix tracepathまたはtraceroute --mtuの場合

そして、経路のMTUを見つけることに関するいくつかの議論。

これがうまくいくかどうかはわかりませんが、試してみてください：

MDSMクライアントがインストールされているコンピューターで、ジャンボフレームがサポートされ、有効になっていることを確認してから、MDSMクライアントのサポートタブに移動し、[サポート情報の収集]リンクを選択し、ファイルをダウンロードするMDSMクライアントの場所を選択し、 MDSMクライアントでパケットキャプチャを開始し、開始ボタンをクリックしてサポート情報（zipファイル）の収集とダウンロードを開始します。収集/ダウンロードが完了したら、キャプチャを見て、MD3000iからMDSMクライアントまでのイーサネットフレームの大きさを確認します。スイッチ、MD300i、およびMDSMクライアントがすべてジャンボフレーム用に構成されている場合、キャプチャのイーサネットフレームサイズでそれを確認する必要があります。

ESXiでは、使用するインターフェイスを指定する必要があります。指定しない場合、pingはmgmtインターフェイス経由でルーティングされ、さらに-dでDFを設定します（断片化しないでください）。

vmkping -I vmkX -s 8972 -d xxxx

http://kb.vmware.com/kb/1003728

また、SSH経由でESXiコンソールから確認することもできます。セキュリティ->ファイアウォール->リモートTech.support（SSH）をオンにし、sshログイン後に「vmkping -s 8000」などを実行します（オプションを正確に思い出さないでください）