Saudações.

Esse tutorial é um guia técnico sobre o protocolo Ethernet, os limites para tamanhos de pacotes (MTU), a natureza dos quadros e as implicações técnicas desses fatores em rede de computadores.

1 – Origem do MTU

O MTU (Maximum Transmission Unit – Unidade Máxima de Transmissão) é um limite aplicado a transmissão de pedaços de dados.

Quando se deseja transmitir arquivos ou blocos de dados como por exemplo, 1 megabyte, transmitir a unidade inteira implica em riscos de qualquer bit ser corrompido e comprometer a confiabilidade da informação, a retransmissão do bloco inteiro precisaria ocorrer até se alcançar uma transferência integra.

Esse tipo de abordagem é ineficiente, transmitir os pedaços um a um e repetir apenas o pedaço corrompido ou perdido é mais eficiente e rápido.

Dilema: Qual seria o tamanho desse pedaço?

1.1 – Criação do MTU

A primeira referência ocorreu na RFC 791 (setembro de 1981) na especificação do IPv4 de autoria de Jon Postel no ISI (Information Sciences Institute) da USC (parte do programa DARPA Internet) e define o MTU de 1500 bytes para o pacote IP.

A RFC 879 de 1983 listou os MTUs da época: ARPANET e MILNET com 1007 bytes, Ethernet (10 Mb) com 1.500 bytes, e Proteon PRONET com 2046 bytes.

Um pacote IP pode ter qualquer tamanho entre:

• Mínimo: somente o cabeçalho com 20 bytes (160 bits);
• MTU de Internet: cabeçalho e corpo somando 1.500 bytes (12.000 bits);
• Máximo teórico: cabeçalho e corpo somando 65.535 bytes (524.280 bits).

Ao transmitir um pacote IP com 1.500 bytes a transmissão eletrônica precisará lidar com 12.000 bits em sequência, quanto maior a sequência de bits maior a chance de um único bit ser corrompido ou mal interpretado.

1.2 – Inicio, meio e fim do quadro

O pacote não é transmitido diretamente nas trilhas eletrônicas dos circuitos até os cabos. Ele precisa ser encapsulado (bytes adicionais no começo e no fim) para que os chips saibam onde ele começa e termina, separando pacotes uns dos outros.

A camada 2 é responsável por esse transporte. Cada pacote encapsulado se chama quadro (frame).

Este formato teórico educativo carece de endereços dos nós envolvidos nas camadas eletrônicas (identificador de nó). O protocolo de camada 2 pode ter apenas o nó de destino (realmente útil) ou o nó de destino e origem. Para que o protocolo seja apto a transportar outros protocolos alem do IP, um campo com tipo do protocolo é bem vindo.

1.3 – Sistema anti-corrupção

A motivação do MTU é reduzir a corrupção de transmissão, para detectar a corrupção de qualquer bit os protocolos de camada 2 implementam o campo FCS (frame checksum).

Todos os bytes do quadro passam pela função CRC-32 que retorna um número verificador de 4 bytes (32 bits) a ser armazenado no campo FCS.

Quando o quadro é recebido pela outra ponta o calculo é refeito e o checksum calculado deve ser idêntico ao checksum recebido para que o quadro seja considerado integro.

Quadros corrompidos (FCS checksum error) são silenciosamente descartados.
Sem feedback, não há mensagem de retorno ao transmissor.

Protocolos de rádio (wireless, família IEEE 802.11) podem implementar ACK entre as partes para confirmar a recepção e retransmitir em caso de erros ou perda do ACK, por conta disso esses protocolos apresentam latência muito variante.

1.4 – Protocolos de camada 2

Dois protocolos eram comuns nessa época: PPP e Ethernet.

O PPP caiu em desuso como protocolo de gestão de linhas e passou a ser incorporado no Ethernet como PPPoE (com incremento de 8 bytes no cabeçalho ethernet).

O Ethernet – IEEE 802.3 é o padrão mais difundido nas telecomunicações.

1.5 – O extinto protocolo PPP

O PPP (Point-to-Point Protocol) lidava com a transmissão ponta a ponta de pacotes entre as duas extremidades de uma linha (serial ou paralela).

Foi muito utilizado no começo da Internet com o uso de linhas telefônicas (MODEM e ISDN). Sua principal característica é possuir um overhead de 8 bytes (64 bits).

Não existe a necessidade de identificar o endereço eletrônico da outra ponta, o campo “address” é uma constante 11111111 (1 byte hexadecimal 0xFF).

O FCS do PPP pode ter 2 (CRC-16) ou 4 bytes (CRC-32).

1.6 – Ethernet e o L2-MTU

O protocolo Ethernet foi padronizado pelo IEEE na família 802.3 e passou a ser amplamente utilizado em redes locais, datacenters, fibras ópticas de curta e longa distância.

O MTU da camada 3 implica diretamente na camada 2 ethernet.

O protocolo ethernet começou com o suporte a MTUs de até 1500 bytes gerando quadros de até 1518 bytes (14 + 1500 + 4):

Um pacote IP de 1500 bytes transmitido entre dois nós (computadores ou roteadores) em uma rede LAN tem a seguinte anatomia:

Agora vem a parte mais complicada.

O protocolo ethernet possui várias sub-camadas, a manipulação do quadro é a mais simples e a transmissão no meio é a parte mais complexa:

O CHIP ethernet da placa de rede (NIC – Network Interface Card) e do Switch devem ser capazes de processar uma sequência entre sinalizações IGP de 12.208 bits – esse é o limite REAL DE MTU, intransponível, definido no projeto do chip.

O chip responsável pela leitura (RX) irá descartar qualquer sequência cujo contador de bytes ultrapasse 1.526 sem encontrar um IGP + Preamble + SFD.

O limite de software é o MTU (L3-MTU).
O limite de hardware é o L2-MTU do chip.

Os fabricantes de chips normalmente anunciam o o limite considerando apenas a carga explicita do quadro ethernet, ou seja, MAC+MAC+EtherType+Payload+FCS.

Nunca confie. A melhor forma de ter certeza é fazendo a homologação de MTU explicitamente entre os equipamentos, criando pacotes com vários tamanhos até ver qual desaparece.

1.7 – Slot time e origem do pacote mínimo

Quando o ethernet de 10 Mbit/s foi criado havia a camada eletrônica CSMA/CD (Carrier Sense Multiple Access with Collision Detection) que determinava se o TX estava livre para transmissão quando a rede ficava 1 slot time sem transmissões (RX informa silêncio).

Esse slot time era calculado como o tempo necessário para alcançar todos os nós da rede considerando a velocidade do meio em transmitir 64 bytes (512 bits) em uma rede de 10Mbit/s com limite de 2,5 kilometros de cabo e era, originalmente, 51,2 microssegundos.

Calculo:

• velocidade da luz no cobre × distância máxima × ida e volta = tempo mínimo de transmissão => slot time.

Para que nenhum quadro fosse transmitido num tempo menor que 1 slot time, nenhum quadro poderia ter menos que 64 bytes. Surgiu a regra:

“Em uma rede ethernet, nenhum quadro pode ter menos de 64 bytes”.

Essa regra não se aplica aos outros protocolos (não ethernet), mas infelizmente se aplica a todas as tecnologias modernas da familia IEEE, até mesmo nas que não usam CSMA/CD (você não pode ligar tudo no mesmo arame coaxial como antigamente).

Problema: A regra ainda é válida mesmo com a rede ethernet alcançando 800 Gbit/s.

1.8 – Pacote mínimo e padding

O MTU Ethernet possui o “Minimum and Minimum Transmission Unit“.

Quando o quadro ethernet tem 18 bytes de tamanho mínimo e ao transmitir um pacote IP com apenas 20 bytes de cabeçalho, somam-se 38 bytes totais.

Nota-se que para atingir o tamanho mínimo será necessário inflar o quadro.

No quadro de 38 bytes faltam 26 bytes de enchimento (packet padding) para alcançar o tamanho mínimo de 64 bytes (512 bits, 1 slot time).

O padding deve ser feito no pacote que ocupa o payload e não no quadro. O software que cria o pacote deve cumprir essa regra ao injeta-lo na rede.

Considerando:

• Ethernet com 18 bytes de cabeçalhos estruturais;
• Pacote IP com 20 bytes de cabeçalho (tamanho mínimo);

Nenhum pacote IP pode ser criado com menos de 48 bytes.

• Ethernet (18 bytes) + IP (48 bytes) = 64 bytes no quadro.

E assim surge a regra:

“Em uma rede ethernet, nenhum pacote IPv4 pode ter menos de 48 bytes”.

Observe que isso não ocorre no IPv6:

• Ethernet com 18 bytes de cabeçalhos;
• Pacote IPv6 com 40 bytes de cabeçalho;
• IPv6 next-header:
  • O menor cabeçalho de payload (Fragment Header, Hop-by-Hop Options ou Routing Header) que tem um tamanho fixo de 8 bytes;
  • O Payload de qualquer next-header.

Assim: Ethernet (18) + IPv6 (40) + Next-header (8) = 66 bytes.

2 – Evolução do padrão de MTU

A década de 1980 foi o amanhecer dos padrões de rede que dominam a Internet nos dias de hoje.

O MTU de 1500 na camada 3 foi hard-coded nos softwares e soldado a quente nos chips.

Ele está tão entranhado na Internet que é impossível propor qualquer produto de telecomunicações aos usuários finais que suba esse valor.

Algumas regras para o MTU:

• Pacote mínimo: nenhum pacote pode ser enviado em redes ethernet com menos de 48 bytes totais;
• Pacote máximo: nenhum pacote pode ultrapassar o teto de 65.536 bytes, inclusive esse é o MTU da interface loopback de todos os sistemas, softwares conversam entre si por ela usando esse pacote máximo;
• MTU mínimo IPv4: nenhuma interface pode ter um MTU inferior a 68 bytes (RFC 791);
• MTU mínimo IPv6: Nenhuma interface pode ter um MTU inferior a 1.280 bytes (RFC 2460 seguida da RFC 8200);
• MTU mínimo nominal: Para interfaces com IPv4 e IPv6, 1.280 bytes é o piso inferior que não deve ser reduzido ainda mais.

Concluímos que para os protocolos IPv4 e IPv6, todo MTU entre 1.280 bytes e 1.500 bytes é válido e utilizável sem muitos transtornos.

Régua de MTU:

3 – VLAN, o primeiro Vilão

No início dos anos 90 surgiu uma tecnologia que permitia segregar redes LAN por meio de identificadores de LAN chamados VID (vlan identification).

Os quadros passam a usar um cabeçalho adicional de 4 bytes para identificar de qual LAN virtual ele participa.

Novo quadro usando tag de VLAN 802.1q:

Topologia de rede simples com transporte de uma LAN entre dois departamentos:

Os switchs VLAN trouxeram ao mercado chips capazes de suportar 1522 bytes de L2-MTU, 4 bytes a mais, esse novo grande quadro foi chamado de baby giants (bebês gigantes).

Agora imagine: O que acontece se um switch comum com chip antigo (padrão 1980) for colocado entre dois switchs VLAN?

Pacotes IP com 1500 bytes saindo do PC entram na porta de acesso com 1518 bytes (12.144 bits) e saem na porta trunk com 1522 bytes (12.176 bits, baby giant), o chip no switch legado (cinza) entende que a sequência passou do limite de 12.176 bits suportado e descartará a transmissão. O pacote some no switch legado com chip velho.

Esse é o problema de L2-MTU que deve-se evitar, não podemos negociar com chips limitados às regras dos anos 1980, eles somem com os dados no meio da rede.

2.1 – VLAN de serviço

Para piorar um pouco, as operadoras precisavam separar as VLANs da infra de transporte (service vlans) das VLANs dos clientes (customers vlans), assim surgiu a VLAN de serviço (S-VLAN) usando IEEE 802.1ad (Q-in-Q Provider Bridge8 02.1ad), adicionando mais 4 bytes no quadro.

Novo quadro usando tag de VLAN 802.1ad transportando um cliente com suas vlans 802.1q:

Pacotes IP com 1500 bytes entram na porta de acesso com 1518 bytes (12.144 bits), recebem a tag de vlan 802.1q (C-VLAN) e alcançam 1522 bytes (12.176 bits, baby giant), ao serem entregues para o switch da operadora eles recebem a tag de serviço 802.1ad (S-VLAN) e atingem 1526 bytes (12.208 bits).

Obviamente, qualquer chip das 2 gerações anteriores dentro do backbone metro-ethernet fazem o quadro desaparecer!

4 – PPPoE, o segundo Vilão

Até aqui temos o uso da rede ethernet transportando o pacote IP, damos a esse tipo de rede com IP fixo ou DHCP o nome de IPoE (IP over Ethernet).

Quando as operadoras que estavam usando PPP e ATM passaram a operar redes ethernet combinadas com redes de distruibuição DSL, eles preferiram usar a adaptação do PPP sobre Ethernet e assim surgiu o PPPoE.

Como o protocolo ethernet ja conta com o campo FCS nativo e o endereço é baseado no MAC, descartamos os campos address e fcs do PPP e criamos um protocolo híbrido:

Diferente da VLAN que precisou de novos chips a cada nova implementação de encapsulamento, o PPPoE não teve essa mesma relevância para os fabricantes de chips.

O protocolo PPPoE nasceu em 1999 na RFC 2516.

As operadoras que estavam com implementações de switchs com S-VLAN não tinham como acomodar os 8 bytes adicionais e preferiram fazer uma alteração inédita: reduzir o MTU dos pacotes para acomodar os quadros PPPoE nas redes ethernet.

4.1 – Efeito colateral do MTU 1492

Um pacote criado no cliente que possui um MTU 1500 (PC -> roteador) não cabe no MTU do salto 1492 entre o roteador e a operadora (roteador concentrador BNG, PPPoE Server).

A fragmentação foi o primeiro efeito colateral grave. O pacote de 1500 bytes é quebrado em dois:

• A primeira parte carrega o payload e o cabeçalho original cabendo em 1492 bytes e alterações no cabeçalhos para informar que há pedaços vindo pelo caminho (more-fragments);
• Os 8 bytes do payload restantes precisam de um cabeçalho IP (cópia do primeiro) contendo 20 bytes, as opções de fragmentação e os 8 bytes restantes, totalizando o fragmento com 28 bytes.

4.2 – Clamp MSS

Como uma gambiarra se resolve com outra gambiarra, os roteadores CPE e BNG fazem o CLAMP-MSS:

• Sempre que pacotes IP transportando TCP com o campo MSS em 1460, valor natural para redes com MTU 1500, esses roteadores alteram o campo para (1492-40 = 1452);
• Com essa alteração forjada, cliente e servidor pensam estar estabelecendo conexões com uma ponta de MTU menor e reduzem o tamanho máximo do segmento (MSS) para o menor valor entre as partes – 1452 bytes.
• Desse ponto em diante, nenhuma das pontas na conexões TCP emite payload maior que 1452 (1452 bytes de payload + 20 bytes de cabeçalho TCP + 20 bytes de cabeçalho IP = 1492 bytes de pacote IP);
• A fragmentação não ocorrerá quando for feita usando protocolo TCP.

Mas… a fragmentação ocorrerá em todos os demais protocolos: UDP, ICMP, GRE, etc.

Não há como fugir desse problema pois o PPPoE nasceu violando o consenso de 1500 bytes como MTU universal.

Tabela de valores de MSS:

MTU PPPoE	MSS IPv4	MSS IPv6
1500 (baby frame)	1460	1440
1492 (padrão)	1452	1432
1480 (mikrotik)	1440	1420

4.3 – MTU Discovery

O problema pode ser detectado com um PING de payload ICMP 1472 bytes (1472 de payload ICMP + 8 bytes de cabeçalho ICMP + 20 bytes de cabeçalho IP = 1500 bytes) e com a opção “dont-fragment” do cabeçalho IPv4 marcada:

Os roteadores são proibidos de fragmentar pacotes quando o “dont-fragment” está ativado e o roteador que tentou fragmentar retorna um ICMP “too-big” informando da limitação.

Dessa forme é possível rastrear gargalos de MTU no caminho.

Essa técnica se chama “path mtu discovery” ou “pmtu discovery“.

4.4 – Baby Frame

Em 2006, com quase 7 anos de intensa operação com PPPoE no mercado e depois de todos os fabricantes de firmwares e chips terem se adaptado às cambiarras de MTU 1492 e Clamp-MSS de ~1452 (ou menos), saiu a RFC 4638 (Accommodating MTU Greater Than 1492 in the PPPoE).

Esse padrão recomendado aconselha negociar MTU de 1500 bytes ou maiores nas opções de MRU e MTU nas negociações entre as pontas do túnel PPPoE.

Infelizmente ela chegou tarde demais, ninguêm implementou até hoje e a mistura extrema de vários fabricantes obriga a aplicação do clamp-mss globalmente, não tem como orientar “aplique o clamp apenas em túneis PPPoE com MTU menor que 1500”.

5 – Overhead, o ladrão de banda

Existe um cálculo que pouca gente faz quando opera redes ethernet.

Pacotes IP com 1500 bytes ocupam 1518 bytes na camada ethernet mas consomem 1538 bytes da linha de transmissão:

A cada pacote IP com 1500 bytes, utiliza-se de fato 1538 bytes (12.304 bits) do enlace ethernet. Esses 38 bytes perdidos usam tempo de transmissão e largura de banda sem ser útil ao usuário, apenas 97,2% da velocidade pode ser consumida considerando somente o overhead ethernet (ainda tem o overhead IP, TCP e TLS a considerar):

• Enlace de 1 Gigabit: Nunca passará de 972 Mbit/s;
• Enlace de 10 Gigabit: Nunca passará de 9.720 Mbit/s;
• Enlace de 100 Gigabit: Nunca passará de 97.200 Mbit/s;

Parece pouca perda, mas vai piorar.

Agora considere pacotes pequenos de 46 bytes (pacote mínimo transportável):

A cada pacote IP com 46 bytes (368 bits), utiliza-se de fato 84 bytes (672 bits) do enlace ethernet na camada 1, uma inflação de overhead que dobra o consumo de rede (45,24% do tráfego é overhead), sobrando apenas 54,76% de recursos sendo utilizados para dados úteis.

Uma aplicação que gere pacotes pequenos em quantidades relevantes pode decrementar pela metade a banda do enlace:

• Enlace de 1 Gigabit: Nunca passará de 547 Mbit/s;
• Enlace de 10 Gigabit: Nunca passará de 5.470 Mbit/s;
• Enlace de 100 Gigabit: Nunca passará de 54.700 Mbit/s;

Logo, chegamos a conclusão que você deve alocar sempre 50% a mais para que sua rede suporte um ataque de pacotes pequenos (syn flood, syn-ack flood, dns flood, etc).

6 – JumboFrame

No início dos anos 2000 o mercado de datacenters foi muito aquecido e surgiu a necessidade de transportar operações de I/O pela rede ethernet e concorrer com protocolos como iSCSI e FiberChannel.

Transportar pacotes IPs em grandes unidades não era mais um problema com que se preocupar na camada física, os enlaces de 10Gbit se espalharam para todo lado.

Para isso, os chips de switchs e roteadores passaram a suportar pacotes IP com um novo padrão de 9.000 bytes e com muito espaço para cabeçalhos VLAN, S-VLAN, MPLS e afins.

Atualmente a rede ethernet oferece interfaces de até 800 Gbit/s.

7 – Conclusão

As grandes lições desse artigo são:

• Não use equipamento velho, toda a infra deve suportar transportar JumboFrame nativamente e todos os pontos com Internet devem ser capazes de navegar com MTU nativo de 1500 bytes;
• PPPoE é gambiarra;
• Clamp-MSS é uma gambiarra encima de outra gambiarra;
• Se algum enlace ethernet da sua rede passou de 54% de uso ela ja está comprometida e deve ser dobrada.

“Tudo o que acontece uma vez pode nunca mais acontecer,
mas tudo o que acontece duas vezes,
acontecerá certamente uma terceira.“
Provérbio Árabe

Terminamos por hoje!

Patrick Brandão, patrickbrandao@gmail.com