MTUの計算に関する誤解は何ですか？

さて、いくつかのXserve、Netgear GSM7224、およびDrobo B800iの間のジャンボフレームの問題の解決を終えました。Xserve（Mac OS X 10.6.8 Server）およびDrobo B800iは通常予想されるようにバイト単位のMTU（1500-9000）を受け入れますが、Netgearはさまざまなイーサネットヘッダー/フッター（トレーラー）を含めてそれを望んでいたようです）そして最終的に、Xserves＆DroboはMTU 9000で構成され、NetgearポートはMTU 9216に設定されました。

Netgear上の2つのXserve間のMTUをテストおよび検証するために次のコマンドを使用しました（注：これらはMac OS Xコマンドで、WindowsとLinuxのコマンドは異なります）。

ping -D -s <mtu> <ip_address>

traceroute -F <ip_address> <mtu>

前者の使用法は、manページに「送信するデータバイト数を指定します。デフォルトは56です。これは、8バイトのICMPヘッダーデータと組み合わせると、64 ICMPデータバイトに変換されます。」テストではping -D 1472 <ip_address>、8バイトのICMPヘッダーデータと20バイトのIPヘッダーにより、toがMTU 1500に相当することがわかりました（これとこれを参照）。それはすべて理にかなっています。

では、なぜ9000 MTUに相当するコマンドなのping -D -s 8164 <ip_address>ですか？「sendto：Message too long」エラーが表示される前にこれが制限であることを確認しましたが、9000 MTUが正常にtraceroute -F <ip_address> 9000機能していることも機能してtraceroute -F <ip_address> 9001いないことも確認しました。それでは、なぜ8164ですか？8972（MTU-28バイト、1500 MTUのように）を期待していました。

また、なぜNetgearの9216 MTUですか？MACヘッダーとイーサネットヘッダー（CRCを含む）に42バイト、IPヘッダーに20バイト（MTUに食い込むはず）をカウントしました。

私はこの数学に本当に錆びており、何かが欠けているだけだと知っています。

ジャンボフレームの奇妙で神秘的な世界へようこそ！ジャンボフレームイーサネットギアのMTUが> 1518および<65Kバイトであるのは正常であり、適切なジャンボトラフィックを有効にするには、L2ドメイン全体で最小の共通分母である設定を見つける必要があります。

私の推測では、ping / ICMPの実装は8192バイトのペイロードに対してのみ機能するため、8164 + 28（IPヘッダーの場合は20、ICMPヘッダーの場合は8）は8192バイトになります。

MTU 9216は、多くのシスコ製品の標準的な9K MTUでもあるため、Netgearはそれと「互換性がある」ことを望んでいたと思います。

また、MTUサイズの仕様を真剣に検討する必要があることに注意してください。多くのベンダーは802.1Q（vLAN）またはL2フレームヘッダーさえも含めていません。スイッチベンダーのドキュメントで、MTUサイズについて話しているときに実際に何を指定しているかを確認してください。