我對計算 MTU 有什麼誤解？
好的，我剛剛解決了幾個 Xserve、Netgear GSM7224 和 Drobo B800i 之間的巨型幀問題。事實證明，Xserves（Mac OS X 10.6.8 伺服器）和 Drobo B800i 像通常預期的那樣接受以字節為單位的 MTU（1500-9000），但 Netgear 似乎希望它包括各種乙太網頁眉/頁腳（拖車） ) 我最終將 Xserves & Drobo 配置為 MTU 9000，並將 Netgear 埠設置為 9216。
我使用以下命令在 Netgear 上測試和驗證兩個 Xserve 之間的 MTU（注意：這些是 Mac OS X 命令，Windows 和 Linux 不同）：
ping -D -s <mtu> <ip_address> traceroute -F <ip_address> <mtu>前者的用法在
man頁面中註明為“指定要發送的數據字節數。預設為 56，與 8 字節的 ICMP 標頭數據組合時轉換為 64 個 ICMP 數據字節。” 在測試中，我發現 toping -D 1472 <ip_address>相當於 MTU 1500，因為 8 字節的 ICMP 標頭數據加上 20 字節的 IP 標頭（參見this和this）。這一切都說得通。現在，為什麼 9000 MTU 的等效命令是
ping -D -s 8164 <ip_address>？在我收到“sendto：消息太長”錯誤之前，我已經驗證這是限制，而且 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（20 用於 IP 標頭，8 用於 ICMP 標頭）為您提供 8192 字節。
MTU 9216 也是許多 Cisco 設備上的標準 9K MTU，所以我的假設是 Netgear 想要與之“兼容”。
另請注意，應認真對待 MTU 大小規範，許多供應商不包括 802.1Q (vLAN) 甚至 L2 幀頭。請查看您的交換機供應商的文件，他們在談論 MTU 大小時真正指定了什麼。