MTU correto

O que e MTU e por que 1500 não serve para tudo

MTU (Maximum Transmission Unit) define o tamanho máximo em bytes de um pacote que pode transitar por um enlace de rede sem ser fragmentado. O valor de 1500 bytes para Ethernet foi definido na RFC 894 e corresponde ao limite fisico do frame Ethernet padrão.

Quando um pacote maior que o MTU do enlace precisa passar, o sistema tem duas opções. A primeira e fragmentar: divide o pacote em partes menores, cada uma com seu próprio cabeçalho, aumentando o overhead total. A segunda e descartar o pacote e notificar o emissor, se o pacote tiver a flag DF (Don't Fragment) ativada. Nesse caso, o roteador que encontrou o MTU menor envia de volta uma mensagem ICMP Tipo 3 Código 4 (Fragmentation Needed) informando o MTU disponível.

O problema surge quando firewalls bloqueiam ICMP. Sem o retorno do ICMP, o emissor nunca sabe que precisa reduzir o tamanho do pacote. A conexão estabelece normalmente, começa a enviar dados e para. Silenciosamente. O handshake TCP funciona porque os pacotes SYN/SYN-ACK são pequenos. Os dados reais, maiores, ficam presos.

Como um pacote e fragmentado em roteadores

O SVG abaixo ilustra o que acontece quando um pacote IP de 1500 bytes tenta atravessar um enlace PPPoE com MTU de 1492 bytes.

MTU padrão por tipo de conexão (comparativo visual)

Tabela de MTU por tipo de conexão

A composição de um frame Ethernet com payload TCP fica clara quando visualizada em camadas coloridas no estilo book-style. Cada celula mostra um cabeçalho ou região de dados, com o tamanho em bytes:

Em PPPoE, soma-se um cabeçalho extra de 8 bytes após o Ethernet, reduzindo o MSS para 1452 bytes. Em WireGuard, o overhead total chega a 60 bytes (20 IP + 8 UDP + 32 WireGuard), reduzindo o MTU efetivo para 1420.

O MTU de 1492 para PPPoE e resultado direto do protocolo: o cabeçalho PPPoE tem 6 bytes fixos mais 2 bytes de identificador de protocolo PPP, totalizando 8 bytes de overhead. Como o frame Ethernet suporta 1500 bytes de payload, sobram 1492 para o pacote IP.

Como o PMTUD descobre o MTU do caminho

PMTUD (Path MTU Discovery) e o mecanismo automático definido na RFC 1191 (IPv4) e RFC 8200 (IPv6) para descobrir o menor MTU ao longo do caminho até o destino. O objetivo e evitar fragmentação sem ter que configurar manualmente o MTU de cada destino.

O processo funciona assim: o emissor envia pacotes com flag DF ativada e com o MTU máximo configurado localmente. Se algum roteador no caminho tiver MTU menor, ele descarta o pacote e retorna ICMP Tipo 3 Código 4 (Fragmentation Needed) com o MTU disponível naquele enlace. O emissor reduz o MTU dos próximos pacotes e repete o processo até chegar ao destino. O menor valor encontrado vira o Path MTU para aquele destino especifico.

A RFC 4821 define o PLPMTUD (Packetization Layer Path MTU Discovery), uma abordagem alternativa que não depende de ICMP. Em vez disso, usa probes na camada de transporte (TCP ou SCTP) com tamanhos crescentes para descobrir o MTU do caminho sem necessidade de mensagens ICMP intermediárias.

Sintomas de MTU incorreto

MTU em VPN: como calcular o valor certo

VPNs encapsulam os pacotes originais dentro de um tunel, adicionando bytes de cabeçalho. O calculo básico e: MTU da VPN = MTU do enlace externo menos overhead do protocolo de tunel.

Para descobrir experimentalmente o MTU correto com a VPN ativa:

1. Com a VPN conectada, abra o terminal.
2. Execute o ping com tamanho decrescente e flag DF:
   Windows: ping -n 1 -f -l 1400 8.8.8.8
   Linux/macOS: ping -c 1 -M do -s 1400 8.8.8.8
3. Se receber resposta, aumente o tamanho em 10 bytes e repita.
4. Se receber "Fragmentation needed" ou timeout, diminua o tamanho em 1 byte até encontrar o maior pacote que passa.
5. Some 28 bytes (20 bytes cabeçalho IP + 8 bytes cabeçalho ICMP) ao valor encontrado: esse e o MTU correto para a interface da VPN.

Exemplo prático: se o maior pacote ICMP que passa com VPN WireGuard e 1392 bytes, o MTU correto da interface WireGuard e 1392 + 28 = 1420 bytes. Esse valor bate com o padrão documentado do WireGuard.

Fluxo de diagnóstico de problema de MTU

1. Confirme o sintoma: site carrega parcialmente, HTTPS trava após conexão estabelecida, download inicia e para. Se o problema e generalizado em todos os sites, o MTU pode não ser a causa (verifique DNS e conexão primeiro).
2. Teste ping com tamanhos decrescentes (Windows):
   ping -f -l 1472 8.8.8.8 (testa 1500 bytes total)
   ping -f -l 1464 8.8.8.8 (testa 1492 bytes total)
   Se 1464 falhar e 1456 funcionar, o Path MTU e 1484 (1456 + 28 = 1484 bytes).
3. Verifique o MTU configurado no sistema:
   Windows: netsh interface ipv4 show subinterfaces
   Linux: ip link show
   macOS: ifconfig | grep mtu
4. Compare: se o MTU configurado e maior que o Path MTU descoberto no passo 2, ha mismatch e o PMTUD não esta corrigindo automaticamente (ICMP provavelmente bloqueado na rota).
5. Ajuste o MTU na interface:
   Windows: netsh interface ipv4 set subinterface "Ethernet" mtu=1492 store=persistent
   Linux: sudo ip link set dev eth0 mtu 1492
   macOS: sudo ifconfig en0 mtu 1492
6. Verifique o roteador: para conexões PPPoE, configure 1492 nas configurações WAN. Aplicar no roteador resolve para todos os dispositivos da rede de uma vez.

Como configurar o MTU por sistema operacional

Linux: persistindo o MTU via NetworkManager

Para tornar a alteração permanente no Linux com NetworkManager, edite o arquivo de conexão em /etc/NetworkManager/system-connections/ e adicione mtu=1492 na secao [ethernet] ou [802-11-wireless]. Reinicie o NetworkManager com sudo systemctl restart NetworkManager.

Roteador (recomendado para redes inteiras)

Acesse o painel do roteador (geralmente 192.168.0.1 ou 192.168.1.1). Localize as configurações WAN ou PPPoE. Altere o campo MTU para 1492. Salve e reinicie o roteador. Essa configuração aplica o MTU correto para todos os dispositivos da rede sem necessidade de ajustes individuais.

MTU e conexões PPPoE no Brasil

Grande parte das conexões de fibra residencial no Brasil usa PPPoE como protocolo de autenticação na camada WAN, incluindo planos da Vivo (AS26599), Claro NET (AS28573) e TIM Live (AS26615). Nesses casos, o MTU correto e 1492, não 1500.

Roteadores fornecidos pelos próprios provedores geralmente chegam pre-configurados com MTU 1492. O problema aparece quando o usuário troca o equipamento por um modelo próprio comprado separadamente, especialmente roteadores de gaming ou dual-WAN. Esses equipamentos costumam vir de fabrica com MTU 1500, e a interface WAN precisa ser ajustada manualmente para 1492 nas configurações PPPoE.

Um MTU de 1500 em conexão PPPoE causa fragmentação continua. Em conexões rápidas (500 Mbps ou mais), essa fragmentação pode reduzir o throughput efetivo de forma mensurável e aumentar a latência média porque cada pacote grande gera um fragmento adicional que precisa ser remontado no destino.

Como verificar o MTU atual da sua conexão

Antes de ajustar qualquer coisa, convem saber o MTU que esta sendo usado atualmente. No Windows, o comando netsh interface ipv4 show subinterfaces lista as interfaces de rede com seus MTUs configurados. A coluna "MTU" mostra o valor para cada interface (Ethernet, Wi-Fi, adaptador VPN etc.). No Linux, ip link show exibe o MTU de cada interface na linha que contém "mtu". No macOS, ifconfig | grep -i mtu lista todos.

Para verificar o Path MTU real, e não apenas o MTU configurado localmente, use o teste de ping com flag DF descrito na secao de diagnóstico. O Path MTU pode ser menor que o MTU local se houver um roteador intermediário com MTU menor no caminho.

MSS clamping e sua relação com o MTU em PPPoE

MSS (Maximum Segment Size) e o parâmetro TCP que define o tamanho máximo dos dados em cada segmento TCP, negociado durante o handshake via opção MSS no segmento SYN. Para Ethernet com MTU 1500, o MSS ideal e 1460 (1500 menos 20 bytes de cabeçalho IP e 20 de cabeçalho TCP). Para PPPoE com MTU 1492, o MSS deve ser 1452.

Quando o MSS anunciado pelo cliente e maior que o MTU efetivo do enlace PPPoE, o servidor envia segmentos TCP que são fragmentados no roteador PPPoE. Se o roteador também tem ICMP bloqueado, o PMTUD falha e a conexão trava. A solucao nos roteadores de borda e o MSS clamping: o roteador intercepta os segmentos SYN e reduz o MSS anunciado para o valor correto antes de encaminhar. Essa função e ativada automaticamente em muitos roteadores de consumo quando o modo PPPoE e selecionado, mas pode precisar ser habilitada manualmente em firmware mais antigo.

Jumbo frames em redes corporativas e NAS

Em redes locais de alta performance (conexões 10GbE entre servidores ou NAS), e possível configurar MTU maior que 1500, os chamados jumbo frames, com valores típicos de 9000 ou 9216 bytes. Jumbo frames reduzem o overhead de cabeçalho por bit de dado transferido e diminuem a carga de CPU dos adaptadores de rede. Para funcionar, todos os dispositivos no caminho (switches, NICs, servidores e NAS) precisam ter o mesmo MTU configurado. Um dispositivo com MTU 1500 no caminho entre dois equipamentos com jumbo frames força fragmentação ou descarte silencioso dos frames grandes.

Em redes residenciais e SOHO, jumbo frames não trazem benefício prático. O MTU de 1500 e o padrão correto para essas redes. Jumbo frames só fazem sentido em redes de data center ou produtoras de vídeo com transferências massivas de arquivos grandes dentro da LAN.

Diagnose rápida: o teste dos dois sites

Uma forma prática de confirmar suspeita de MTU incorreto: tente acessar dois tipos de sites diferentes. Se sites simples com pouco CSS (como uma página de texto puro ou o google.com) carregam normalmente mas sites ricos em imagens e scripts (YouTube, Instagram, portais de noticias) travam ou mostram elementos faltando, o MTU e o candidato principal. Os pacotes pequenos de HTML básico passam; os pacotes maiores de assets são descartados ou fragmentados sem entrega completa.

Erros comuns de MTU e como evitar

Usar MTU 1500 em conexão PPPoE

O erro mais frequente em roteadores próprios no Brasil. O roteador vem de fabrica configurado para Ethernet padrão (1500), e o usuário seleciona o tipo de conexão PPPoE mas não ajusta o MTU. Resultado: fragmentação continua de todos os pacotes no tamanho máximo. A solucao e trocar para 1492 nas configurações WAN do roteador.

Usar MTU 1500 em interface WireGuard

Ao configurar WireGuard manualmente (sem um cliente que auto-detecta), o arquivo de configuração wg0.conf precisa ter MTU = 1420 na secao [Interface]. Sem essa linha, a interface usa o MTU padrão da plataforma (1500), causando pacotes encapsulados maiores que o MTU fisico, que são descartados ou fragmentados.

Configurar MTU só no dispositivo mas não no roteador

Ajustar o MTU na interface de rede do computador para 1492 sem ajustar no roteador resolve o problema para aquele dispositivo, mas outros dispositivos da rede continuam com o MTU incorreto. A correção ideal e no roteador, que aplica MSS clamping automaticamente para todos os clientes.

Verificando MTU com Wireshark

Para diagnosticar problemas de MTU de forma definitiva, o Wireshark permite capturar e analisar o trafego real de rede. Instale o Wireshark (gratuito, disponível em wireshark.org para Windows, macOS e Linux) e siga esses passos:

1. Inicie o Wireshark e selecione a interface de rede ativa.
2. Reproduza o problema (acesse o site que não carrega completamente).
3. No filtro, use tcp.flags.reset == 1 || icmp.type == 3 para ver resets TCP e mensagens ICMP de fragmentação.
4. Uma mensagem ICMP Tipo 3 Código 4 (Fragmentation Needed) confirma o problema de MTU. O campo "Next-Hop MTU" na mensagem indica o MTU do enlace problematico.
5. Para verificar o tamanho dos pacotes TCP enviados, use o filtro tcp && tcp.len > 1400 e veja quais tamanhos estao sendo usados.

Se o Wireshark mostrar resets TCP frequentes após pacotes grandes (acima de 1492 bytes em PPPoE, por exemplo) sem mensagem ICMP correspondente, confirma PMTUD black hole: o roteador descarta o pacote e bloqueia o ICMP sem notificar o emissor.

MTU e latência: a relação indireta

Um MTU corretamente configurado não reduz diretamente a latência de um ping simples. O que pode acontecer indiretamente: com MTU incorreto, pacotes grandes precisam ser fragmentados e os fragmentos remontados no destino, adicionando pequena latência ao throughput real (não ao RTT de um ping pequeno). Em conexões de alta velocidade acima de 500 Mbps, a CPU do processador de rede do roteador pode ser impactada pelo overhead de remontagem de fragmentos, aumentando a latência de todos os pacotes, incluindo os pequenos.

Para a maioria dos usuários residenciais, a diferença de latência e negligenciavel mesmo com MTU incorreto. O impacto principal e em throughput e na falha silenciosa de conexões que usam pacotes grandes: o problema de site que carrega texto mas não carrega imagens descrito anteriormente.

Automated MTU discovery em sistemas modernos

O Linux kernel 3.x+ com a implementação TCP de Packetization Layer Path MTU Discovery (PLPMTUD, RFC 4821) faz descoberta de Path MTU sem depender de ICMP. Em vez de usar pacotes com flag DF, usa probes TCP de tamanhos crescentes. Isso contorna o problema de ICMP bloqueado. Sistemas Windows 10+ e macOS Sonoma+ também implementam variantes dessa abordagem.

Na prática, sistemas modernos tem menos problemas de MTU do que sistemas mais antigos exatamente por causa dessas melhorias. Quando o problema de MTU ainda aparece em 2026, geralmente e em roteadores com firmware antigo, em configurações de VPN manuais, ou em dispositivos embarcados sem suporte ao PLPMTUD moderno.

Perguntas frequentes