D'accord, je viens de terminer la résolution d'un problème de trames jumbo entre quelques Xserves, un Netgear GSM7224 et un Drobo B800i. Il s'est avéré que les Xserves (Mac OS X 10.6.8 Server) et le Drobo B800i acceptent le MTU en octets comme normalement prévu (1500-9000), mais le Netgear semble l'avoir voulu, y compris les divers en-têtes / pieds de page Ethernet (remorques) ) et je me suis finalement retrouvé avec les Xserves et Drobo configurés avec une MTU de 9000 et les ports Netgear définis sur une MTU de 9216.
J'ai utilisé les commandes suivantes pour tester et vérifier le MTU entre les deux Xserves sur Netgear (Remarque: ce sont les commandes Mac OS X, celles de Windows et Linux diffèrent):
ping -D -s <mtu> <ip_address>
traceroute -F <ip_address> <mtu>
L'utilisation du premier est notée dans la man
page comme: "Spécifiez le nombre d'octets de données à envoyer. La valeur par défaut est 56, ce qui se traduit par 64 octets de données ICMP lorsqu'il est combiné avec les 8 octets de données d'en-tête ICMP." Lors des tests, j'ai trouvé que ping -D 1472 <ip_address>
c'était l'équivalent de MTU 1500 en raison des 8 octets de données d'en-tête ICMP plus de 20 octets d'en-têtes IP (voir ceci et cela ). Tout cela a du sens.
Maintenant, pourquoi la commande équivalente pour un 9000 MTU ping -D -s 8164 <ip_address>
? J'ai vérifié que c'est la limite avant de commencer à obtenir des erreurs "sendto: Message too long", mais aussi que 9000 MTU fonctionne correctement traceroute -F <ip_address> 9000
et traceroute -F <ip_address> 9001
ne fonctionne pas. Alors, pourquoi 8164? Je m'attendais à 8972 (MTU - 28 octets, tout comme pour 1500 MTU).
Aussi, pourquoi 9216 MTU pour Netgear? J'ai compté 42 octets pour les en-têtes MAC et Ethernet (y compris CRC), plus 20 pour les en-têtes IP (qui devraient manger dans le MTU).
Je suis vraiment rouillé sur ce calcul et je sais qu'il me manque juste quelque chose.