De acuerdo, acabo de terminar de resolver un problema de tramas gigantes entre algunos Xserves, un Netgear GSM7224 y un Drobo B800i. Resultó que los Xserves (Mac OS X 10.6.8 Server) y el Drobo B800i aceptan la MTU en bytes como se esperaba normalmente (1500-9000), pero Netgear parece haberlo querido incluyendo los diversos encabezados / pies de página de Ethernet (trailers ) y finalmente terminé con los Xserves y Drobo configurados con una MTU de 9000 y los puertos Netgear configurados con una MTU de 9216.
He utilizado los siguientes comandos para probar y verificar la MTU entre los dos servidores X a través de Netgear (Nota: estos son los comandos de Mac OS X, los de Windows y Linux son diferentes):
ping -D -s <mtu> <ip_address>
traceroute -F <ip_address> <mtu>
El uso del primero se indica en la man
página como "Especifique el número de bytes de datos que se enviarán. El valor predeterminado es 56, que se traduce en 64 bytes de datos ICMP cuando se combina con los 8 bytes de datos de encabezado ICMP". En las pruebas, descubrí que ping -D 1472 <ip_address>
era el equivalente de MTU 1500 debido a los 8 bytes de datos del encabezado ICMP más los encabezados IP de 20 bytes (vea esto y esto ). Todo eso tiene sentido.
Ahora, ¿por qué es el comando equivalente para un 9000 MTU ping -D -s 8164 <ip_address>
? Verifiqué que este es el límite antes de comenzar a recibir errores de "sendto: Mensaje demasiado largo", pero también que 9000 MTU funciona correctamente como traceroute -F <ip_address> 9000
funciona y traceroute -F <ip_address> 9001
no funciona. Entonces, ¿por qué 8164? Hubiera esperado 8972 (MTU - 28 bytes, al igual que para 1500 MTU).
Además, ¿por qué 9216 MTU para Netgear? Conté 42 bytes para los encabezados MAC y ethernet (inc. CRC), más 20 para los encabezados IP (que deberían comer en la MTU).
Estoy muy oxidado con estas matemáticas y sé que solo me falta algo.