Por que justamente 1500

O limite de 1500 bytes de payload (a carga útil) da não vem de nenhuma lei da física. Foi uma decisão econômica de 1980: memória era cara, os primeiros controladores guardavam frames (quadros) inteiros em buffer, numa RAM escassa, e num cabo coaxial compartilhado uma estação não podia monopolizar o meio por muito tempo a cada frame. Mil e quinhentos bytes equilibravam o custo do buffer e o overhead. Esse número entrou na especificação DIX da Ethernet, o IEEE 802.3 o herdou, e quatro décadas e meia de hardware, drivers e premissas foram construídas em cima dele. Todos os motivos por trás do número já desapareceram (a RAM é farta, os links são comutados e full-duplex, e a 400 Gb/s um frame de tamanho máximo é serializado em nanossegundos), mas o número continua aí, porque a internet é muito boa em cumprir promessas de compatibilidade.

Esse limite se aplica à (Maximum Transmission Unit, a unidade máxima de transmissão): o maior pacote IP que um link transporta. Da MTU vem o (Maximum Segment Size, o tamanho máximo de segmento), o maior pedaço de dados da aplicação que o TCP (Transmission Control Protocol) coloca num segmento. Num link comum de 1500 bytes, são 1500 menos 20 bytes de header (cabeçalho) IPv4 menos 20 bytes de header TCP: os famosos 1460 (RFC 879, seção 7).

O que é (e o que não é) um jumbo frame

Jumbo frame é qualquer frame Ethernet que carrega mais de 1500 bytes de payload. Na prática, a indústria convergiu para 9000 bytes, e vale ser preciso sobre o status desse número: é uma convenção de mercado, um padrão de fato, e não um padrão do . O grupo de trabalho 802.3 já se recusou várias vezes a padronizar um tamanho máximo maior: até o projeto que aumentou o frame para acomodar os campos de envelope tinha como objetivo "Maintain the maximum data field length (1500 octets)", manter o campo de dados em no máximo 1500 octetos (IEEE P802.3as, objetivos, novembro de 2004). Por isso o 9000 aparece nos datasheets dos fabricantes, e não no padrão. É exatamente por isso que o suporte, os valores default e o comportamento nos casos-limite mudam de uma plataforma para outra, e também é por isso que você configura o valor explicitamente, em vez de presumir que ele já está lá.

Por que mais ou menos nove mil? Porque esse valor passa com folga dos blocos de 8 KiB (kibibyte), comuns nas aplicações de storage e NFS (Network File System), e ainda sobra espaço para os headers; ao mesmo tempo, fica bem dentro da cobertura do (Frame Check Sequence) de 32 bits da Ethernet, cuja detecção de erros perde eficácia à medida que o frame cresce. Datasheets de switch costumam informar uma MTU de sistema de 9216 bytes; a documentação da série QFX da Juniper, por exemplo, dá para a MTU de interface a faixa "64 through 9216 bytes", de 64 a 9216 bytes (Juniper, mtu (QFX Series)). Não é um tamanho de jumbo concorrente, e sim folga: espaço para um pacote IP de 9000 bytes mais tags de (Virtual Local Area Network), labels (Multiprotocol Label Switching) e outros encapsulamentos.

Isso leva a uma distinção que resolve a maior parte da confusão sobre MTU. Encapsulamentos que vão dentro do payload Ethernet, como (Point-to-Point Protocol over Ethernet), (Generic Routing Encapsulation) e (Virtual Extensible ), diminuem a MTU interna que sobra para uso. Os labels MPLS entram nesse grupo, embora muita gente os trate como tags de VLAN: "When a frame is carrying a labeled IP datagram, the Frame Payload consists of the label stack entries and the IP datagram", ou seja, a pilha de labels conta dentro do payload do frame (RFC 3032, seção 3.1), e "Each label stack entry is represented by 4 octets", cada label ocupa 4 octetos (seção 2.1). Por isso, um caminho com labels deixa 4 octetos a menos por label para o pacote IP, a não ser que a MTU do link seja aumentada para acomodá-los: num link mantido no payload convencional de 1500 bytes da Ethernet, sobram 1496 bytes com um label, 1492 com dois e 1488 com três, o número que a própria 3032 usa (seção 3.2). A tag 802.1Q da VLAN é diferente, porque a mesma definição deixa "802.1Q headers", os headers 802.1Q, fora do payload do frame (seção 3.1): a tag vai no header do frame, não mexe na MTU IP, e quem cresce é o frame. Uma única tag 802.1Q transforma um frame cheio de 1518 bytes num baby giant de 1522 bytes (IEEE 802.3 overview, março de 2011): o payload continua igual, e o header é que cresceu. Jumbo frames aumentam o próprio payload; baby giants aumentam só o envelope.

O que se ganha de fato com jumbo frames

O argumento clássico, de livro, é a eficiência no fio. Um segmento TCP de tamanho máximo num link de 1500 bytes entrega 1460 bytes de payload para cada 1538 bytes no fio (somando 14 de header Ethernet, 4 de FCS e 20 de preâmbulo e intervalo entre frames): 94,93% de eficiência. Esses 20 são um preâmbulo de 7 octetos, um start-of-frame delimiter de 1 octeto e um intervalo entre pacotes de 96 bits (12 octetos) (Juniper, Ethernet frames; IEEE 802.3, interpretação 1-11/09). Com 9000, a mesma conta dá 8960 de 9038: 99,14%. O ganho é real, mas modesto: uns quatro pontos percentuais de banda.

O ganho que historicamente pesava mais era o do trabalho por pacote. Cada frame custa um overhead fixo de interrupções, processamento de protocolo e controle por pacote em cada NIC (Network Interface Card, a placa de rede), switch e host do caminho; seis vezes menos frames para o mesmo gigabyte significavam seis vezes menos de tudo isso, e na época em que um núcleo de CPU mal conseguia dar conta de um link de 10 Gb/s, era isso que fazia toda a diferença. Os offloads modernos reduziram essa vantagem: o TSO (TCP Segmentation Offload) e o LRO/GRO (Large/Generic Receive Offload) deixam a pilha de rede do host trabalhar como se lidasse com segmentos enormes, enquanto a NIC fatia e remonta os frames no tamanho que vai para o fio. Com isso, boa parte do benefício de CPU fica garantida sem mexer na MTU da rede. Um resumo honesto, nos dias de hoje: jumbo frames ainda ajudam de forma mensurável em storage, replicação e tráfego east-west em grande volume (e importam para a folga dos overlays, como se vê mais abaixo), mas são uma otimização com custo real de coordenação, não um upgrade de graça.

Onde eles compensam: redes de storage iSCSI (Internet Small Computer System Interface) e NFS, links de backup e replicação, tráfego de migração a quente no estilo do vMotion, fabrics de HPC (High-Performance Computing) e RDMA (Remote Direct Memory Access), e o underlay que fica por baixo das redes overlay. Todos são caminhos controlados e delimitados, dentro do data center. O padrão é exatamente esse: jumbo frames funcionam bem onde um único time controla cada hop (cada equipamento no caminho).

A falha é silenciosa

É daqui que vem a má fama dos jumbo frames. Um MTU mismatch (MTUs diferentes ao longo do caminho) não vai degradando a rede de um jeito que dê para perceber: ele cria um black hole (o tráfego some sem aviso), e um black hole seletivo.

Imagine um host mandando pacotes de 9000 bytes por um caminho em que um dos links ainda está em 1500. Se o bit (Don't Fragment) do pacote estiver ligado, e as pilhas modernas ligam esse bit, o roteador com a MTU menor é obrigado a descartar o pacote e devolver uma mensagem (Internet Control Message Protocol) de "Fragmentation Needed" (Packet Too Big, no ) (RFC 792; RFC 4443, seção 3.2). O (, a descoberta da MTU do caminho) depende totalmente de essa mensagem chegar. Se um firewall no meio do caminho descarta ICMP, um "hardening" infelizmente muito comum, quem enviou nunca descobre por que nada chega do outro lado. O resultado é o sintoma clássico: o ping funciona, o handshake TCP funciona, requisições pequenas funcionam, e a conexão trava assim que começa a passar dado de verdade, porque só os segmentos de tamanho máximo morrem. No IPv6 o risco é maior: "fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path", só a origem fragmenta, nunca os roteadores do caminho (RFC 8200, seção 4.5). Então o host ou descobre a MTU do caminho, com o PMTUD ou com a variante dele para a packetization layer, o DPLPMTUD (RFC 8899), ou mantém todo pacote dentro da MTU mínima de link do IPv6, de 1280 octetos (RFC 8200, seção 5); e o Packet Too Big do ICMPv6 não é opcional.

Na prática, há três defesas. Primeira: mantenha a MTU uniforme em cada domínio L2. Vale a regra do tudo ou nada: no mesmo domínio de broadcast, ou todos os hosts, portas de switch e interfaces de roteador usam a mesma MTU, ou nenhum deles usa jumbo. Segunda: deixe passar as mensagens ICMP do tipo too-big, porque o mecanismo depende delas. Terceira: nas fronteiras que você não controla, faça , ou seja, reescreva a opção MSS do handshake TCP para caber no link mais estreito. É essa solução pragmática que faz o PPPoE a 1492 (RFC 2516, seção 7) e túneis de todo tipo funcionarem para o público em geral.

Overlays: onde jumbo frames e encapsulamento se encontram

É nas redes overlay que a conta dos jumbo frames vira trabalho do dia a dia. O VXLAN coloca o frame Ethernet interno inteiro dentro de headers novos: 8 bytes de VXLAN, 8 de UDP (User Datagram Protocol), 20 de IPv4 externo e 14 de Ethernet interno, num total de 50 bytes (70 com header externo IPv6) (RFC 7348, seção 5). Se isso rodar sobre um underlay de 1500 bytes, o tráfego interno fica espremido em 1450, e os guests precisam fragmentar ou fazer MSS clamping. Há duas soluções limpas, em linha com a recomendação da RFC de que a MTU do underlay acomode "the larger frame size due to the encapsulation", o frame maior que o encapsulamento produz (seção 4.3): subir a MTU do underlay para pelo menos 1550 ou, como é praxe em data center, usar um underlay de 9000 bytes e entregar aos tenants confortáveis 8950. O custa o mesmo, com as opções cobradas à parte, porque o header fixo dele tem 8 bytes (RFC 8926, seção 3.4); o GRE custa 24, um header de 4 bytes mais o header IPv4 externo (RFC 2784, seção 2.1); o , 60: 16 bytes de campos de header e uma tag de autenticação de 16 bytes, por cima do UDP e do IPv4 (artigo do WireGuard, seção 5.4.6). A regra vale de forma geral: overlays gastam MTU, jumbo frames devolvem.

Como ativar sem dor de cabeça

Configurar jumbo frames é fazer todos os equipamentos concordarem, de dentro para fora: primeiro os switches e roteadores (folga no tamanho do frame e MTU das interfaces), depois os hosts, um domínio L2 de cada vez, e nunca "a rede inteira" numa mudança só. Em seguida, teste com um ping no tamanho máximo, com a fragmentação proibida. No Linux: ping -M do -s 8972 <alvo> (ping(8)); no Windows: ping /f /l 8972 <alvo> (Microsoft, ping). O número mágico 8972 é só 9000 menos 20 bytes de header IPv4 menos 8 do header ICMP echo. Se esse ping passar e o de 8973 falhar, a MTU do caminho é exatamente 9000, e você provou isso de ponta a ponta. E saiba onde parar: tudo o que fica voltado para a internet continua em 1500, porque o caminho público é a única cadeia de camada 2 e camada 3 que você nunca vai controlar.

Todas as contas deste artigo (MTUs internas, valores de MSS, tamanhos de frame, exigências do underlay e o par de eficiências) são exatamente o que a calculadora de MTU / MSS faz a partir de qualquer MTU de link e pilha de encapsulamento que você informar.

Fontes