Ok, acabei de resolver um problema de jumbo-frames entre alguns Xserves, um Netgear GSM7224 e um Drobo B800i. Descobriu-se que os Xserves (Mac OS X 10.6.8 Server) e o Drobo B800i aceitam o MTU em bytes como normalmente esperado (1500-9000), mas o Netgear parece ter desejado isso, incluindo os vários cabeçalhos / rodapés de Ethernet (reboques ) e eu finalmente terminei com o Xserves & Drobo configurado com uma MTU de 9000 e as portas Netgear definidas como uma MTU de 9216.
Usei os seguintes comandos para testar e verificar a MTU entre os dois Xserves no Netgear (Nota: estes são os comandos do Mac OS X, os do Windows e Linux são diferentes):
ping -D -s <mtu> <ip_address>
traceroute -F <ip_address> <mtu>
O uso do modelo anterior é anotado na man
página como "Especifique o número de bytes de dados a serem enviados. O padrão é 56, que se traduz em 64 bytes de dados ICMP quando combinado com os 8 bytes de dados do cabeçalho ICMP". Nos testes, descobri que ping -D 1472 <ip_address>
era o equivalente a MTU 1500 devido aos 8 bytes de dados do cabeçalho ICMP mais aos cabeçalhos IP de 20 bytes (veja isso e isso ). Tudo isso faz sentido.
Agora, por que o comando equivalente para uma 9000 MTU ping -D -s 8164 <ip_address>
? Eu verifiquei que esse é o limite antes de começar a receber erros "sendto: Message too long", mas também que o 9000 MTU está funcionando corretamente como traceroute -F <ip_address> 9000
funciona e traceroute -F <ip_address> 9001
não funciona . Então, por que 8164? Eu esperava 8972 (MTU - 28 bytes, assim como para 1500 MTU).
Além disso, por que 9216 MTU para o Netgear? Contei 42 bytes para os cabeçalhos MAC e Ethernet (incluindo o CRC), mais 20 para os cabeçalhos IP (que devem ser usados na MTU).
Estou muito enferrujado nessa matemática e sei que estou perdendo alguma coisa.