MTU vs MSS e PMTUD

[... se está pingando, não é a rede]

"Dizer que 'se está pingando, não é a rede', é um dos mitos mais perigosos da nossa área. Às vezes, o ICMP de 64 bytes passa, mas o dado morre na primeira "esquina" por causa de um detalhe invisível: o MTU."

Você já pegou aquele chamado "fantasma" que ninguém no N1 ou N2 resolve?

O site carrega o HTML, mas trava no CSS e nas imagens. O SSH fecha o handshake, mas "congela" ao dar um "ls -la". A aplicação funciona em uma filial, mas na outra fica instável.

Aí o analista revisa rota, olha regra de firewall, reinicia serviço... e nada. O problema parece oculto. 

A pergunta real é: você validou o MTU do caminho?

Em cenários de infraestrutura moderna com PPPoE, túneis GRE, IPsec ou VXLAN, o Overhead é inevitável. Cada camada extra de protocolo "rouba" bytes do pacote original.

Se o pacote estoura o MTU e o bit DF (Don’t Fragment) está ativo, o roteador descarta o pacote. Se o seu firewall ainda bloqueia o ICMP (especialmente o Type 3 Code 4), você acabou de quebrar o PMTUD (Path MTU Discovery). O resultado? O tráfego morre silenciosamente.

Aqui vai uma explicação direta, prática e voltada para quem realmente trabalha com rede.

MTU (Maximum Transmission Unit)

O MTU define o maior tamanho de pacote que pode ser transmitido por uma interface sem fragmentação.

Ele atua na camada de enlace e rede (L2/L3).

Características principais:

• Inclui tudo: cabeçalho IP + TCP/UDP + payload

• Valor padrão Ethernet: 1500 bytes

• Configurado em: diretamente na interface

Impacto prático:

Se um pacote ultrapassa o MTU de algum ponto do caminho:

• Ele será fragmentado (quando permitido), ou

• Será descartado

Fragmentação gera:

• Mais processamento

• Mais latência

• Mais chance de perda

MSS (Maximum Segment Size)

O MSS é um conceito exclusivo do TCP e define o tamanho máximo do payload dentro de um segmento.

Ele atua na camada de transporte (L4).

Características principais:

• Considera apenas os dados (payload)

• Não inclui cabeçalhos

• É negociado durante o three-way handshake

• Não é configurado diretamente na interface (normalmente)

Relação entre MTU e MSS

Em uma rede IPv4 padrão:

Cabeçalho IP: 20 bytes
Cabeçalho TCP: 20 bytes

Então:

MSS = MTU - 40

Exemplo clássico:

MTU = 1500
MSS = 1460

No IPv6:

Cabeçalho IP = 40 bytes

Resultado:

MSS = 1440

Onde tudo quebra na prática

Aqui começa a parte que realmente importa.

Em ambientes com encapsulamento, o MTU efetivo diminui:

• PPPoE → -8 bytes

• GRE → -24 bytes

• IPsec → variável (pode passar de -60 bytes)

Se nada for ajustado, acontece o seguinte:

1. O host envia com MSS 1460

2. O pacote cresce após encapsulamento

3. Ultrapassa o MTU do caminho

4. Resultado: fragmentação ou drop

E aí aparecem os sintomas clássicos.

O custo do transporte: Overhead

Para entender por que o MTU diminui, precisamos falar de Overhead. Em redes, Overhead é o "custo" de cabeçalhos extras que adicionamos para encapsular um pacote.

Imagine que o MTU de 1500 bytes é o tamanho total de um caminhão. Se você coloca uma carga dentro de uma caixa (IP), e essa caixa dentro de um container (VPN), o espaço para a carga real diminui.

Principais "vilões" do MTU:

+----------------------+------------------+------------------------+

| Protocolo            | Overhead (Bytes) | MTU Resultante (Típico)|

+----------------------+------------------+------------------------+

| PPPoE                | 8                | 1492                   |

+----------------------+------------------+------------------------+

| GRE                  | 24               | 1476                   |

+----------------------+------------------+------------------------+

| VXLAN                | 50               | 1450                   |

+----------------------+------------------+------------------------+

| IPsec (ESP)          | ~56 (Varia)      | 1400 - 1440            |

+----------------------+------------------+------------------------+

PMTUD: O mecanismo de descoberta

O PMTUD (Path MTU Discovery) é o processo automático que o IP usa para evitar a fragmentação. Ele funciona assim:

1. O host envia um pacote com o bit DF (Don't Fragment).

2. Se um roteador no caminho tem um MTU menor que o pacote, ele o descarta.

3. O roteador envia um ICMP Type 3 Code 4 (Fragmentation Needed) de volta para a origem avisando: "Ei, aqui só passa X bytes".

4. A origem aprende e diminui o tamanho dos próximos pacotes.

Onde mora o perigo: Se você (ou o seu provedor) bloqueia o ICMP indiscriminadamente, esse aviso nunca chega. A origem continua enviando pacotes grandes, o roteador continua descartando, e você fica com uma conexão que "estabelece mas não navega".

O Mensageiro Silencioso: ICMP Type 3 Code 4 e a RFC 1191

Se o MTU é a regra e o Overhead é o obstáculo, o ICMP Type 3 Code 4 é o guarda de trânsito.

De acordo com a RFC 1191, que padronizou o Path MTU Discovery (PMTUD), quando um roteador não consegue encaminhar um pacote porque ele é grande demais para o próximo salto e o bit DF (Don't Fragment) está ativo, ele precisa avisar a origem.

Esse aviso é a mensagem ICMP de Tipo 3 (Destination Unreachable) com o Código 4 (Fragmentation Needed and DF set).

A especificação da RFC 1191:

A RFC especifica que, dentro dessa mensagem ICMP, o roteador deve incluir um campo chamado Next-Hop MTU. É nesse campo que o roteador diz: "Ei, eu dropei seu pacote de 1500, mas se você enviar com 1476, ele passa".

Por que as redes param?

O problema é que muitos administradores bloqueiam o ICMP Type 3 indiscriminadamente em seus firewalls. Quando isso acontece, criamos o chamado PMTUD Black Hole (Buraco Negro de PMTU):

O roteador dropa o pacote grande. > O roteador tenta avisar a origem (Type 3, Code 4). > O firewall bloqueia o aviso.

A origem nunca sabe o que aconteceu e tenta reenviar o pacote grande para sempre.

Resultado: O famoso sintoma da conexão que estabelece (handshake ok), mas não trafega dados (payload dropado).

MSS Clamping (o salva-vidas)

O MSS Clamping resolve isso na borda da rede.

O roteador intercepta o SYN e reduz o MSS anunciado.

Exemplo MikroTik:

/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=1436 passthrough=yes

Esse valor normalmente vem de:

MTU real do caminho menos 40

Jumbo Frames (MTU 9000)

Jumbo Frames são quadros Ethernet maiores que o padrão, geralmente 9000 bytes.

Mas isso não é melhor por padrão. É contexto.

Por que o padrão ainda é 1500?

Mesmo hoje, a internet continua usando 1500 por motivos bem sólidos:

1. Compatibilidade global: A internet é heterogênea.
   Se um único equipamento no caminho não suportar jumbo frame: O pacote é descartado

2. Taxa de erro: Quadros maiores:
   > Maior chance de erro
   > Retransmissões mais custosas

3. Latência em links lentos: Em links mais lentos:
   > Um pacote grande monopoliza o meio
   > Impacta voz, jogos e aplicações sensíveis

Quando usar Jumbo Frames

A resposta curta: apenas em ambiente controlado. Casos reais:

Storage (iSCSI)

• Menos pacotes

• Menos overhead de CPU

• Mais throughput

Backup e replicação

• Tráfego massivo

• Ganho direto de eficiência

Virtualização (vMotion / Live Migration)

• Transferência de RAM entre hosts

• Necessidade de throughput alto

HPC e Big Data

• Troca constante de grandes volumes de dados

Eficiência: MTU 1500 vs 9000

+----------------+------------+--------------+------------+

| Tipo de Quadro |  MTU Total | Payload Útil | Eficiência |

|----------------+------------+--------------+------------+ 

| Padrão         | 1500 bytes | 1442 bytes   | ~ 96.1%    | 

+----------------+------------+--------------+------------+ 

| Jumbo Frame    | 9000 bytes | 8942 bytes   | ~ 99.3%    | 

+----------------+------------+--------------+------------+ 

A diferença parece pequena, mas em larga escala é absurda. Requisito crítico (e onde todo mundo erra). Jumbo Frame só funciona se 100% do caminho suportar:

• NIC

• Switch

• Hypervisor

• Storage

Se um único ponto estiver em MTU 1500:

• O pacote é descartado silenciosamente

Esse é um dos problemas mais difíceis de diagnosticar.

Descobrindo o MTU real (Path MTU)

O teste de ping com o bit DF (Don't Fragment) setado é a ferramenta padrão para descobrir o Path MTU (PMTU), ou seja, o maior tamanho de pacote que consegue atravessar toda a rota entre dois hosts sem ser fragmentado ou descartado.

Quando você seta o bit DF, você está dizendo aos roteadores no caminho: "Se este pacote for maior que o MTU da sua interface de saída, não o fragmente; apenas o descarte e me avise."

Como executar o teste

O comando varia conforme o sistema operacional, mas a lógica é enviar pacotes de tamanhos crescentes até encontrar o limite.

No Windows

CMD

ping [IP_ou_Host] -f -l 1472

• -f: Seta o bit Don't Fragment.

• -l 1472: Define o tamanho do payload (dados) como 1472 bytes.

No Linux

Bash

ping [IP_ou_Host] -M do -s 1472

• -M do: Força o caminho com bit DF.

• -s 1472: Define o tamanho do payload.

Por que 1472?

Porque o ping usa ICMP:

IP: 20 bytes
ICMP: 8 bytes

Então:

1472 + 28 = 1500

Como encontrar o MTU correto

Você reduz o valor até funcionar.

Exemplo real com túnel GRE:

1472 falha
1460 falha
1448 sucesso

Resultado:

MTU real = 1476
MSS ideal = 1436

O erro mais crítico que vejo em produção. Bloquear ICMP. Especificamente:

Type 3 Code 4 (Fragmentation Needed)

Quando isso é bloqueado:

• O Path MTU Discovery quebra

• O TCP não consegue ajustar o tamanho dos pacotes

• O tráfego começa a falhar silenciosamente

Sintomas típicos:

• Site abre parcialmente

• SSH trava ao listar diretórios

• Downloads param no meio

Conclusão

MTU e MSS não são detalhes. São fundamentos.

Se você trabalha com ISP, VPN, MPLS, CGNAT ou Data Center, vai lidar com isso cedo ou tarde.

Resumo direto:

• MTU define o limite do pacote

• MSS ajusta o TCP para evitar fragmentação

• Encapsulamento reduz MTU

• MSS Clamping evita problemas

• Jumbo Frames só em ambiente controlado

• ICMP não é opcional