MTU correto
MTU correto explicado: padrao 1500, PPPoE 1492, como o PMTUD funciona, calculo para VPN e como diagnosticar problemas causados por MTU incorreto.
O MTU correto para a maioria das conexoes Ethernet e 1500 bytes, mas conexoes PPPoE usam 1492 e VPNs precisam de valores ainda menores. Um MTU incorreto nao gera uma mensagem de erro clara: o sintoma classico e um site que carrega o texto mas nao carrega imagens, ou HTTPS que trava logo apos o handshake. O problema fica meses sem diagnostico. Este artigo mostra como identificar o MTU certo para cada tipo de conexao e como ajustar em cada sistema operacional.
O que e MTU e por que 1500 nao serve para tudo
MTU (Maximum Transmission Unit) define o tamanho maximo 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 padrao.
Quando um pacote maior que o MTU do enlace precisa passar, o sistema tem duas opcoes. A primeira e fragmentar: divide o pacote em partes menores, cada uma com seu proprio cabecalho, 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 Codigo 4 (Fragmentation Needed) informando o MTU disponivel.
O problema surge quando firewalls bloqueiam ICMP. Sem o retorno do ICMP, o emissor nunca sabe que precisa reduzir o tamanho do pacote. A conexao estabelece normalmente, começa a enviar dados e... para. Silenciosamente. O handshake TCP funciona porque os pacotes SYN/SYN-ACK sao pequenos. Os dados reais, maiores, ficam presos.
Tabela de MTU por tipo de conexao
| Tipo de conexao | MTU recomendado | Overhead | Base normativa |
|---|---|---|---|
| Ethernet padrao (LAN) | 1500 | Nenhum alem do frame Ethernet | RFC 894 |
| PPPoE (ADSL / fibra PPPoE) | 1492 | 8 bytes de cabecalho PPPoE | RFC 2516, RFC 4638 |
| PPPoE com VLAN 802.1Q | 1472 | 8 PPPoE + 4 VLAN tag | RFC 2516 + IEEE 802.1Q |
| WireGuard | 1420 | 60 bytes de overhead do tunel | WireGuard whitepaper |
| IPsec ESP modo tunel | 1400-1420 | ~80 bytes (ESP + IV + padding) | RFC 4303 |
| OpenVPN (UDP) | 1380-1400 | Variavel conforme config e cipher | OpenVPN manual |
| OpenVPN (TCP) | 1350-1380 | Overhead TCP adicional ao tunel | OpenVPN manual |
| Wi-Fi 802.11 (MSDU) | 1500 | Fragmentacao feita na camada Wi-Fi | IEEE 802.11 |
| IPv6 (minimo garantido) | 1280 | MTU minimo mandatorio do IPv6 | RFC 8200 |
O MTU de 1492 para PPPoE e resultado direto do protocolo: o cabecalho 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 automatico definido na RFC 1191 (IPv4) e RFC 8200 (IPv6) para descobrir o menor MTU ao longo do caminho ate o destino. O objetivo e evitar fragmentacao 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 maximo configurado localmente. Se algum roteador no caminho tiver MTU menor, ele descarta o pacote e retorna ICMP Tipo 3 Codigo 4 (Fragmentation Needed) com o MTU disponivel naquele enlace. O emissor reduz o MTU dos proximos pacotes e repete o processo ate 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 nao 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 intermediarias. E especialmente util em redes onde ICMP e filtrado.
Sintomas de MTU incorreto
| Sintoma | Explicacao | MTU provavel errado |
|---|---|---|
| Site carrega texto mas nao carrega imagens ou CSS | Pacotes pequenos (HTML) passam; pacotes maiores (imagens) sao descartados | MTU configurado acima do limite do enlace |
| HTTPS trava logo apos o handshake | SYN/SYN-ACK passam (pequenos); Certificate e Application Data sao descartados | MTU acima do Path MTU real |
| Download começa e para apos alguns KB | Cabecalho HTTP passa; dados iniciam e sao fragmentados ou descartados | MTU incorreto na interface de saida |
| VPN conecta mas trafego nao flui | Overhead do tunel reduz MTU efetivo; pacotes encapsulados excedem o MTU fisico | MTU da interface VPN nao ajustado para o overhead do protocolo |
| Problema especifico por site; outros funcionam | Servidor do site especifico usa pacotes maiores ou tem PMTUD bloqueado | Problema no PMTUD do caminho, nao no MTU local |
MTU em VPN: como calcular o valor certo
VPNs encapsulam os pacotes originais dentro de um tunel, adicionando bytes de cabecalho. O calculo basico e: MTU da VPN = MTU do enlace externo menos overhead do protocolo de tunel.
Para descobrir experimentalmente o MTU correto com a VPN ativa:
- Com a VPN conectada, abra o terminal.
-
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 - Se receber resposta, aumente o tamanho em 10 bytes e repita.
- Se receber "Fragmentation needed" ou timeout, diminua o tamanho em 1 byte ate encontrar o maior pacote que passa.
- Some 28 bytes (20 bytes cabecalho IP + 8 bytes cabecalho ICMP) ao valor encontrado: esse e o MTU correto para a interface da VPN.
Exemplo pratico: 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 padrao documentado do WireGuard.
Fluxo de diagnostico de problema de MTU
- Confirme o sintoma: site carrega parcialmente, HTTPS trava apos conexao estabelecida, download inicia e para. Se o problema e generalizado em todos os sites, o MTU pode nao ser a causa (verifique DNS e conexao primeiro).
-
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). -
Verifique o MTU configurado no sistema:
Windows:netsh interface ipv4 show subinterfaces
Linux:ip link show
macOS:ifconfig | grep mtu - Compare: se o MTU configurado e maior que o Path MTU descoberto no passo 2, ha mismatch e o PMTUD nao esta corrigindo automaticamente (ICMP provavelmente bloqueado na rota).
-
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 - Verifique o roteador: a maioria dos roteadores tem campo de MTU nas configuracoes WAN. Para conexoes PPPoE, configure 1492. Aplicar no roteador resolve para todos os dispositivos da rede de uma vez.
Como configurar o MTU por sistema operacional
Windows
Verificar: netsh interface ipv4 show subinterfaces
Configurar de forma persistente: netsh interface ipv4 set subinterface "Wi-Fi" mtu=1492 store=persistent
Substitua "Wi-Fi" pelo nome exato da interface listado no comando de verificacao.
Linux
Verificar: ip link show
Configurar temporariamente: sudo ip link set dev eth0 mtu 1492
Para persistir apos reinicio no NetworkManager: edite o arquivo de conexao em /etc/NetworkManager/system-connections/ e adicione mtu=1492 na secao [ethernet] ou [802-11-wireless].
macOS
Verificar: ifconfig | grep mtu
Configurar: sudo ifconfig en0 mtu 1492
No macOS a alteracao via terminal nao persiste apos reinicio. Para tornar permanente, crie um script de inicializacao via LaunchDaemon ou use a interface grafica em Configuracoes do Sistema > Rede.
Roteador (recomendado para redes inteiras)
Acesse o painel do roteador (geralmente 192.168.0.1 ou 192.168.1.1). Localize as configuracoes WAN ou PPPoE. Altere o campo MTU para 1492. Salve e reinicie o roteador. Essa configuracao aplica o MTU correto para todos os dispositivos da rede sem necessidade de ajustes individuais.
MTU e conexoes PPPoE no Brasil
Grande parte das conexoes de fibra residencial no Brasil usa PPPoE como protocolo de autenticacao na camada WAN, incluindo planos da Vivo (AS26599), Claro NET (AS28573) e TIM Live (AS26615). Nesses casos, o MTU correto e 1492, nao 1500.
Roteadores fornecidos pelos proprios provedores geralmente chegam pre-configurados com MTU 1492. O problema aparece quando o usuario troca o equipamento por um modelo proprio 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 configuracoes PPPoE.
Um MTU de 1500 em conexao PPPoE causa fragmentacao continua. Em conexoes rapidas (500 Mbps ou mais), essa fragmentacao pode reduzir o throughput efetivo de forma mensuravel e aumentar a latencia media porque cada pacote grande gera um fragmento adicional que precisa ser remontado no destino.
A RFC 4638 define uma extensao opcional ao PPPoE que permite negociar MTU maior que 1492, mas a adocao pelos provedores brasileiros nao e universal. Ao trocar o roteador, assuma 1492 como padrao seguro para PPPoE e ajuste para cima somente se o provedor confirmar suporte ao tag PPP-Max-Payload da RFC 4638.
Perguntas frequentes
MTU (Maximum Transmission Unit) e o tamanho maximo de um pacote de dados que pode transitar por um enlace de rede sem ser fragmentado. Para Ethernet padrao, o valor e 1500 bytes, definido na RFC 894. Conexoes com protocolos de encapsulamento como PPPoE ou VPNs tem MTU menor porque o cabecalho do protocolo adicional consome parte dos 1500 bytes disponiveis.
O protocolo PPPoE adiciona um cabecalho de 8 bytes ao frame Ethernet (6 bytes de cabecalho PPPoE + 2 bytes de identificador de protocolo PPP). Como o limite do payload Ethernet e 1500 bytes, sobram 1492 para o pacote IP. Usar MTU 1500 em conexao PPPoE forca fragmentacao de todos os pacotes que chegam no tamanho maximo.
Os problemas classicos: site carrega texto mas nao carrega imagens, HTTPS trava logo apos o handshake TLS, downloads que iniciam e param sem mensagem de erro, e VPN que conecta mas nao roteia trafego. O sintoma e insidioso porque conexoes simples (ping, DNS, HTTP basico) funcionam normalmente, mas transfers de dados maiores falham silenciosamente.
PMTUD (Path MTU Discovery) e o mecanismo automatico pelo qual o sistema operacional descobre o menor MTU ao longo do caminho ate o destino. Ele usa pacotes com flag DF (Don't Fragment) e mensagens ICMP de retorno para ajustar o tamanho dos pacotes. Falha quando firewalls bloqueiam ICMP Tipo 3 Codigo 4 (Fragmentation Needed). Sem esse retorno, o sistema nao sabe reduzir o MTU e a conexao trava misteriosamente com pacotes de dados maiores.
O MTU padrao recomendado para a interface WireGuard e 1420 bytes, assumindo link subjacente com MTU 1500. O WireGuard adiciona 60 bytes de overhead por pacote (20 bytes cabecalho IP + 8 bytes UDP + 32 bytes de cabecalho WireGuard). Em conexoes PPPoE (MTU 1492), o MTU da interface WireGuard deve ser calculado como 1492 menos 60 bytes de overhead = 1432 bytes. Ajustar para valores incorretos causa ou fragmentacao ou descarte de pacotes.
Use o ping com flag DF (sem fragmentacao) e tamanhos decrescentes. No Windows: ping -f -l 1472 8.8.8.8. Se retornar "Packet needs to be fragmented", reduza o valor em 10 bytes e repita ate encontrar o maior que passa. Some 28 bytes (20 IP + 8 ICMP) ao valor encontrado: esse e o Path MTU do seu caminho. Para descobrir o MTU da interface VPN especificamente, realize o teste com a VPN conectada.
Ferramentas relacionadas
Configurar o MTU correto e um ajuste que se faz uma vez e evita problemas sutis e persistentes. Para conexoes PPPoE brasileiras, 1492 e o valor certo. Para VPNs, calcule subtraindo o overhead do protocolo do MTU base do link fisico. O PMTUD cuida do ajuste automatico quando ICMP nao esta bloqueado na rota; quando esta, configurar manualmente e a unica saida.
Teste de Ping
Leituras Relacionadas
- Perda de pacotes causas — Perda de pacotes causas: congestionamento, hardware defeituoso, interferencia Wi-Fi, ISPs regionais BR. Fluxograma de diagnostico passo a passo com ping e traceroute.
- Internet lenta diagnostico — Internet lenta diagnostico: fluxograma BR passo a passo com ping, traceroute e DNS. Exemplos com operadoras brasileiras, CGNAT e modem padrao de provedor.
- TCP vs UDP — TCP vs UDP: handshake, garantia de entrega, latencia e casos de uso reais. Comparativo com QUIC e HTTP/3 e exemplos de jogos, streaming e DNS.