Pense no túnel como um passageiro dentro de um envelope: o envelope também pesa. E o caminho tem uma balança em cada hop (cada passagem por um roteador): a Maximum Transmission Unit (), que na é, tradicionalmente, de 1.500 bytes. Quando o encapsulamento faz um pacote de tamanho máximo passar desse limite, acontece uma de três coisas: fragmentação, uma rodada de descoberta do limite do caminho ou um black hole (buraco negro) silencioso. Qual das três vai acontecer é o que decide se o túnel funciona normalmente ou se começa a dar problemas que ninguém consegue explicar.

Origens: por que existe um limite máximo

O limite de 1.500 bytes de payload (a carga útil) da Ethernet não é uma lei da física. Ele saiu de um meio-termo de engenharia de 1980: memória para buffer era cara, e uma estação que transmite um frame (quadro) muito longo ocupa sozinha um meio compartilhado. Um teto resolvia as duas coisas, porque limitava o custo e limitava quanto tempo as outras estações teriam de esperar. O número durou mais do que os motivos que o criaram e virou a constante em torno da qual o resto da internet foi ajustado.

O IP foi projetado para atravessar links com limites diferentes, então precisava de uma resposta para o pacote que não cabe. O IPv4 escolheu a fragmentação: qualquer roteador podia dividir um pacote, e o destino o remonta. Funciona, e três décadas de experiência operacional mostraram o preço:

  • Se um fragmento se perde, o pacote inteiro se perde, então a perda é multiplicada, em vez de proporcional.
  • A remontagem exige estado e timers no destino, e isso abre uma superfície para ataques de negação de serviço.
  • Firewalls e load balancers só enxergam os números de porta no primeiro fragmento, então as políticas e o hashing quebram em todos os outros.
  • Muitas redes simplesmente descartam fragmentos, e o que era só uma ineficiência vira uma falha completa.

O IPv6 acabou de vez com a fragmentação nos roteadores. Roteador não pode fragmentar: um pacote que não cabe é descartado com uma mensagem "packet too big" ("pacote grande demais"), e quem enviou é que tem de se adaptar. A ideia do projeto foi tornar o problema visível, em vez de silencioso, o que só funciona se essa mensagem conseguir voltar.

O Path MTU Discovery e por que ele falha em silêncio

O mecanismo do é simples: você envia com o bit de não fragmentar ligado, recebe uma mensagem "fragmentation needed" ou "packet too big" do roteador em que o pacote não passa, baixa a estimativa e repete.

Só que ele falha o tempo todo, porque essas mensagens são ICMP, e o ICMP é bloqueado num número enorme de firewalls, configurados por quem classificou o protocolo como superfície de ataque. O resultado é o black hole de path MTU: o handshake se completa, os pacotes pequenos passam, e a conexão trava no instante em que sai o primeiro pacote de tamanho máximo. Por isso o sintoma clássico é "a página de login abre, mas depois nada carrega", e por isso esse problema é diagnosticado tantas vezes como defeito da aplicação.

O Packetization Layer Path MTU Discovery existe justamente como a resposta que não depende de ICMP: a própria camada de transporte vai testando pacotes cada vez maiores e trata a perda como sinal. Ele demora mais para convergir, mas funciona onde a rede é hostil.

Quanto cada envelope cobra

O custo depende do envelope. O Generic Routing Encapsulation é o barato: um header (cabeçalho) IP novo, de 20 bytes, mais um header de 4 bytes, o que dá 24 bytes, como o artigo sobre GRE detalha. É por isso que a MTU clássica de um túnel num caminho de 1.500 bytes é 1.500 − 24 = 1.476.

O cobra mais e, para ser honesto, cobra uma faixa, não um valor fixo, porque o total depende do modo e da cifra. Um pacote em modo túnel acrescenta um header IP externo novo, o header ESP com o Security Parameter Index e o número de sequência, o vetor de inicialização da cifra, o padding até o alinhamento da cifra e a tag de integridade; com Traversal, entra ainda um header UDP por cima. Numa configuração moderna com -, o número prático para planejamento fica na casa dos 70 e poucos bytes, e é exatamente por isso que as recomendações de campo arredondam tantas vezes a MTU do túnel para baixo, para 1.400, em vez de apertar até o limite teórico. O artigo sobre IPsec explica de onde vem cada um desses bytes; aqui a lição é mais simples: nunca presuma que a conta de um túnel vale para outro.

Empilhe túneis e os custos se somam: GRE sobre IPsec paga as duas contas.

Primeira saída: fragmentação, a pior opção

Roteadores IPv4 podem dividir um pacote grande demais em fragmentos, que o host do outro lado tem de remontar. Funciona, mas é o pior resultado possível: cada fragmento paga mais um header, a perda de qualquer fragmento derruba o pacote inteiro, os middleboxes (os equipamentos no meio do caminho) adoram descartar fragmentos sem pensar duas vezes, e a remontagem consome memória no destino. Pior ainda: muitas vezes quem envia proíbe a fragmentação. O TCP moderno liga o bit Don't Fragment () justamente para descobrir o tamanho real do caminho, e aí um pacote grande demais não é dividido: é descartado, e volta um aviso.

Segunda saída: Path MTU Discovery, a opção frágil

Esse aviso é o próprio mecanismo. Um roteador que precisa descartar um pacote marcado com DF devolve uma mensagem ICMP "Fragmentation Needed" que informa a MTU que ele conseguiria encaminhar; quem enviou diminui o tamanho e tenta de novo. Isso é o Path MTU Discovery () e, quando funciona, o caminho se ajusta sozinho. Quando falha, falha em silêncio: algum firewall no caminho descarta o ICMP, quem enviou nunca fica sabendo, e a conexão apresenta o sintoma típico de um black hole de PMTUD. Pacotes pequenos passam, handshakes passam, e tudo trava no momento em que os dados de verdade começam a fluir. Se a conexão abre normalmente, seguindo o ciclo de vida do TCP, mas o primeiro segmento de tamanho máximo morre, desconfie da balança, e não da aplicação.

Terceira saída: MSS clamping, a correção que funciona de primeira

O TCP negocia o Maximum Segment Size () no handshake: cada ponta anuncia o maior payload que deve receber. Esses valores de MSS passam em texto claro por todos os equipamentos do caminho, e o truque está aí: um endpoint de túnel pode reescrever para baixo o MSS anunciado quando o SYN passa por ele, e assim as duas pontas nunca chegam a montar um segmento grande demais para o envelope. Sem fragmentos, sem depender de ICMP, sem esperar a descoberta: o tamanho já está certo desde o primeiro byte de dados. A conta é mecânica: MSS = MTU do túnel − 40 (20 do IP + 20 do TCP, mais se houver opções). Num túnel GRE de 1.476 bytes, isso dá 1.436; num túnel conservador, de 1.400, dá 1.360. O clamping só ajuda o TCP (protocolos sobre UDP precisam manter os datagramas num tamanho modesto ou depender do PMTUD), mas é no TCP que está a maior parte da dor de cabeça.

Para onde os bytes vão, de fato

Cada camada de envelope tira a sua parte dos mesmos 1.500 bytes. São valores aproximados, e vale a pena tê-los de cabeça:

  • Header IPv4: 20 bytes; header IPv6: 40, e é por isso que um túnel que cabia sobre IPv4 pode não caber sobre IPv6.
  • Header TCP: 20 bytes, mais com opções como timestamps e selective acknowledgement (a confirmação seletiva).
  • Tag de : 4 bytes por tag; : cerca de 50 bytes no total, contando os headers externos.
  • GRE: de 4 a 16 bytes; : 8, e é por isso que tantos links de banda larga ficam em 1.492.
  • IPsec: varia bastante com o modo e a cifra, em geral de 50 a 80 bytes; o modo túnel acrescenta um segundo header IP.
  • : cerca de 60 bytes sobre IPv4 e 80 sobre IPv6, e é por isso que a recomendação usual para ele é 1.420.

Daí vêm duas consequências. Os encapsulamentos se somam: um projeto de VXLAN sobre IPsec paga os dois. E a perda é assimétrica: a pilha de quem envia não sabe nada do túnel no meio do caminho, então a conta de bytes tem de ser feita onde o encapsulamento acontece.

Jumbo frames invertem o problema dentro de um data center: payloads de 9.000 bytes reduzem de forma significativa o processamento por pacote no tráfego de storage e de replicação, mas exigem que todos os equipamentos do caminho estejam configurados para isso. Basta um switch esquecido em 1.500 num domínio jumbo para produzir exatamente o sintoma de black hole descrito acima, com uma dificuldade a mais: ele só aparece em transferências grandes.

A correção que funciona, e as que não funcionam

O é a resposta confiável para o TCP. O equipamento na borda do túnel reescreve o MSS no handshake, e assim as pontas negociam um tamanho que cabe antes de qualquer pacote grande ser enviado. Funciona na primeira tentativa, não precisa de ICMP e é um único ajuste em quase toda plataforma que termina túneis.

Vale conhecer os limites dele: o clamping só ajuda o TCP, porque só o TCP tem um MSS para reescrever. O tráfego sobre UDP não é afetado, seja QUIC, payload de (rede privada virtual), DNS sobre UDP ou vídeo. É por isso que o QUIC, de propósito, testa e controla o tamanho dos próprios datagramas, e é por isso que aplicações UDP não deveriam presumir 1.500.

O checklist que resolve a maior parte desses casos:

  • Faça MSS clamping em toda borda de túnel, com o valor calculado a partir do overhead medido, e não de um número guardado de memória.
  • Libere nos firewalls o ICMP tipo 3 código 4 e o "packet too big" do ; bloquear essas mensagens é a causa mais comum desse tipo de falha.
  • Teste com um payload grande e com o bit de não fragmentar ligado, e não com um ping de tamanho padrão: um ping padrão não prova nada sobre o limite do caminho.
  • Confirme a MTU de todos os equipamentos de um caminho jumbo antes de habilitar jumbo em qualquer um deles.

O hábito na prática

As orientações para encaminhar tráfego à nuvem deixam esse hábito bem concreto: a documentação de túneis da Zscaler (verificada em 2026-07-21) manda o operador configurar a MTU do túnel com o menor valor entre a MTU do appliance e a MTU medida do caminho e, se mesmo assim aparecer problema, voltar para 1.400. Folga conservadora vale mais do que máximo teórico: é a experiência de campo resumida numa frase. O checklist completo, para qualquer túnel, em qualquer lugar: conheça o overhead do seu envelope, subtraia esse valor da menor MTU do caminho, configure o túnel com o resultado, faça o clamping do MSS nesse valor menos 40 e deixe o PMTUD como rede de proteção, não como a peça que sustenta tudo. Frames maiores mudam os números, mas não o método: os jumbo frames só mudam o teto de lugar.

Fontes