Jumbo Frames: como configurar MTU 9000 sem perder pacotes
|

Jumbo Frames: como configurar MTU 9000 sem perder pacotes

O Ethernet padrão limita cada quadro a 1.500 bytes de payload. Cada quadro carrega os mesmos cerca de 58 bytes de cabeçalho (Ethernet + IP + TCP + FCS) independente do tamanho dos dados úteis, o que dá aproximadamente 3,7% de overhead por quadro nesse MTU padrão. Elevar o MTU para 9.000 bytes — os chamados jumbo frames — derruba esse overhead para menos de 1% e reduz o número de quadros necessários para transmitir o mesmo volume de dados. Fabricantes de storage costumam reportar ganhos de 10% a 30% de throughput em links dedicados a iSCSI, NFS e vMotion, porque menos quadros também significam menos interrupções de CPU na placa de rede. A configuração é simples, mas tem uma armadilha: todo dispositivo no caminho — placa de rede, switch e sistema operacional — precisa aceitar o mesmo MTU, ou o tráfego trava de forma silenciosa.

O que são jumbo frames e onde eles realmente ajudam

Jumbo frame é qualquer quadro Ethernet acima do MTU padrão de 1.500 bytes, normalmente configurado em 9.000 bytes — o teto suportado pela maioria dos switches gerenciáveis e placas de rede de servidor. O ganho não vem de “mais banda”, vem de menos overhead proporcional: com payloads maiores, a mesma quantidade de cabeçalho fixo é diluída em mais dados úteis por quadro.

Isso importa de verdade em três cenários: redes de storage (iSCSI, NFS, SMB para backup), tráfego de replicação entre servidores (vMotion, migração de VM, replicação de banco) e links de backup que movem volumes grandes em janelas curtas. Em navegação web, e-mail ou VoIP, o ganho é irrelevante — os pacotes já são pequenos.

Antes de configurar

Confirme três coisas antes de mexer em produção:

  • Todos os saltos no caminho suportam o MTU maior. Placa de rede, switch e o sistema operacional do outro lado da conexão. Um único dispositivo com MTU 1.500 no meio do caminho quebra a comunicação ou força fragmentação.
  • Isole o tráfego em uma VLAN dedicada. Storage, backup ou vMotion em uma VLAN só sua, roteada apenas entre os hosts que precisam dela. Não aplique jumbo frames na VLAN de usuários ou em qualquer segmento que converse com a internet.
  • Planeje uma janela de manutenção. Mudar o MTU de uma interface ativa geralmente derruba o link por alguns segundos (renegociação), então trate como mudança disruptiva, não como ajuste a quente.

Passo a passo: configurando MTU 9000

1. Confirme que switch e placas suportam jumbo frames

Consulte o datasheet do switch por “jumbo frame support” — o valor varia por modelo e por chip, alguns aceitam até 9.216 bytes, outros travam em 2.000 ou menos em switches não gerenciáveis de entrada. Nas placas de rede, o limite também varia por chipset; controladoras de servidor (Intel X710, Broadcom, Mellanox) suportam 9.000 sem problema, mas onboard de desktop às vezes não.

2. Habilite jumbo frames no switch primeiro

Configure o switch antes dos hosts — se o switch não repassar quadros grandes, qualquer ajuste nos servidores é inútil. Em switches gerenciáveis, a opção normalmente aparece como “Jumbo Frame” ou “Jumbo MTU” nas configurações da porta ou globais, com valores típicos de 9.000 ou 9.216 bytes. Ative apenas nas portas que atendem a VLAN de storage/backup.

3. Configure o MTU no Linux

Para testar sem persistir:

ip link set eth0 mtu 9000

Para persistir com NetworkManager:

nmcli connection modify "eth0" ethernet.mtu 9000
nmcli connection up "eth0"

Para persistir com Netplan (Ubuntu Server), edite /etc/netplan/01-netcfg.yaml:

network:
  version: 2
  ethernets:
    eth0:
      mtu: 9000

E aplique com netplan apply. Para systemd-networkd, crie /etc/systemd/network/10-eth0.network com MTUBytes=9000 na seção [Link].

4. Configure o MTU no Windows Server

Identifique o nome da interface e aplique de forma persistente:

netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Ethernet" mtu=9000 store=persistent

5. Configure jumbo frames em roteador/switch MikroTik

No RouterOS, o parâmetro relevante é o L2MTU, configurado por interface — não existe um MTU global. Verifique o L2MTU máximo do seu modelo antes de aplicar, pois varia por chip de switch:

/interface ethernet set [find default-name=ether1] l2mtu=9000
/interface bridge set bridge1 mtu=9000

Alterar o L2MTU derruba e sobe a interface — todos os dispositivos conectados a ela sofrem uma interrupção breve.

6. Ajuste os parâmetros de montagem em NFS e iSCSI

Jumbo frames por si só não aumentam o tamanho dos blocos de leitura/escrita. Combine com rsize/wsize maiores na montagem NFS para aproveitar o quadro maior:

mount -t nfs -o rsize=1048576,wsize=1048576 storage-server:/export /mnt/storage

7. Teste antes de liberar em produção

O teste que realmente valida ponta a ponta é um ping com o bit “não fragmentar” ativado e payload no limite do MTU novo. No Linux, 8.972 bytes de dados equivalem a um quadro de 9.000 bytes (9000 − 20 de cabeçalho IP − 8 de ICMP):

ping -M do -s 8972 10.0.30.10

No Windows, o equivalente é:

ping -f -l 8972 10.0.30.10

Se o ping falhar com “Frag needed” ou similar, algum salto no caminho ainda está em MTU 1.500 — volte e confira switch por switch antes de mover tráfego real para o link.

O erro mais comum: MTU black hole

Um “buraco negro de MTU” acontece quando um roteador no meio do caminho descarta pacotes grandes com o bit DF (don’t fragment) ativado, e a mensagem ICMP “Fragmentation Needed” que deveria avisar o remetente é bloqueada por um firewall. O remetente nunca aprende que precisa reduzir o tamanho do pacote e continua enviando quadros grandes — todos descartados silenciosamente. O sintoma clássico: a conexão TCP completa o handshake normalmente (pacotes pequenos passam), mas a transferência de dados trava assim que pacotes grandes entram em cena.

Duas formas de resolver: liberar ICMP tipo 3 código 4 nos firewalls do caminho (a correção correta), ou aplicar clamping de MSS para forçar o TCP a negociar segmentos que já respeitem o MTU do caminho:

iptables -t mangle -A FORWARDING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Quando não vale a pena usar jumbo frames

Não configure MTU 9000 em links que saem para a internet ou passam por VPN — provedores e roteadores da rede pública trabalham com MTU 1.500 (ou menos, em conexões PPPoE), e o quadro maior nunca chega inteiro ao destino. Também não compensa em redes pequenas sem link dedicado de storage: se o gargalo real é o link de 1 Gbps compartilhado com tráfego de usuários, jumbo frames não resolvem — o problema é de capacidade, não de overhead de cabeçalho.

Perguntas frequentes

Preciso mudar o MTU da rede inteira ou só dos servidores de storage?
Só da VLAN dedicada a storage, backup ou replicação. Aplicar em toda a rede aumenta a superfície de erro sem trazer benefício nos segmentos que não movem arquivos grandes.

Como sei se meu switch aceita jumbo frames?
Confira o datasheet pelo termo “jumbo frame” ou “jumbo MTU”. Switches gerenciáveis de nível empresarial costumam suportar 9.000 a 9.216 bytes; switches não gerenciáveis de entrada frequentemente limitam a 1.518 ou 2.000 bytes.

Jumbo frames funcionam em VPN ou pela internet?
Não. O MTU da internet pública é 1.500 bytes (menos em PPPoE), então um quadro de 9.000 bytes nunca atravessa esse caminho intacto.

O que acontece se eu configurar MTU 9000 só de um lado da conexão?
Mismatch de MTU entre os dois lados costuma gerar um MTU black hole: conexões pequenas funcionam, transferências grandes travam sem erro claro. Configure os dois lados e o switch entre eles antes de considerar o trabalho concluído.

Vale a pena numa rede pequena ou doméstica?
Raramente. O ganho só aparece com volume alto de tráfego sustentado em links de 10 Gbps ou mais — em uma rede doméstica de 1 Gbps com uso leve, a redução de overhead não é perceptível e o risco de mal configurar supera o benefício.

Conclusão

Jumbo frames são uma otimização de baixo custo e alto retorno quando aplicadas no lugar certo: links dedicados de storage, backup e replicação entre servidores. O trabalho real não é a configuração em si — é garantir que switch, placas de rede e sistemas operacionais dos dois lados concordem no mesmo MTU antes de mover tráfego de produção para o link. Teste sempre com ping -M do (ou ping -f no Windows) no tamanho exato do quadro antes de considerar a mudança concluída, e mantenha o MTU maior isolado na VLAN que realmente precisa dele.

Gostou? Compartilhe.

Posts Similares

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *