web-dev-qa-db-ja.com

MTUの計算について何を誤解していますか？

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

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

ping -D -s <mtu> <ip_address>

traceroute -F <ip_address> <mtu>

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

さて、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ヘッダー（MTUに食い込むはず）に20バイトをカウントしました。

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

tcpethernettcpipgigabit-ethernetmtu
14
morgant

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

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

MTU 9216は、多くのCiscoの機器で標準の9K MTUでもあるため、Netgearはそれと「互換性がある」ことを望んでいたと私は想定しています。

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

11
pfo