Unidade máxima de transmissão

A unidade máxima de transmissão (MTU, na sigla em inglês) é o tamanho, em bytes, do maior pacote de IP possível, incluindo cabeçalhos IP, cabeçalhos de protocolo da camada 4 e dados da camada 4, que cabem em frames Ethernet.

Tamanhos válidos de MTU da rede VPC

As redes de nuvem privada virtual (VPC) usam uma MTU padrão de 1.460 bytes. É possível definir a MTU de uma rede VPC como qualquer valor entre 1.300 e 8.896 bytes (inclusivo). Os tamanhos comuns de MTU personalizados são 1.500 bytes (Ethernet padrão) ou 8.896 bytes (o máximo possível). O Google recomenda que você configure a MTU para cada interface da placa de rede da instância (NIC) de máquina virtual (VM) para corresponder à MTU da rede VPC a que ela está conectada. Para mais informações, consulte Configurações de VMs e MTU.

Comunicação entre VMs do Google Cloud em redes VPC

Ao enviar e receber VMs, use a mesma rede VPC ou redes VPC com peering que tenham MTUs idênticas, pacotes IP até o tamanho da MTU poderão ser enviados entre as duas VMs, se as interfaces de ambas estiverem configuradas para usar a MTU da rede VPC.

Para evitar problemas de incompatibilidade de MTU, o Google recomenda que você use a mesma MTU para todas as redes VPC conectadas. Embora essa seja a prática recomendada, você não precisa ter MTUs idênticas entre as redes VPC conectadas. Para detalhes sobre como os protocolos lidam com situações em que há uma incompatibilidade de MTU entre redes VPC, consulte MTUs incompatíveis, restrição de MSS, descoberta de MTU de caminho.

Da perspectiva de uma VM de envio, os caminhos para os destinos a seguir representam o tráfego de VM para VM roteado dentro de uma rede VPC:

  • Um endereço IPv4 interno regional em um intervalo de endereços IPv4 principal ou secundário da sub-rede, incluindo intervalos de endereços IPv4 particulares e intervalos de endereços IPv4 públicos usados de modo privado, usados por esses destinos recursos:
    • O endereço IPv4 interno principal da interface de rede (NIC) de uma VM de recebimento.
    • Um endereço IPv4 interno em um intervalo de IP do alias da placa de rede (NIC) da VM de recebimento.
    • Um endereço IPv4 interno de uma regra de encaminhamento interno para encaminhamento de protocolo ou para um balanceador de carga de rede de passagem interna.
  • Intervalos de endereços de sub-rede IPv6 internos usados por estes recursos de destino:
    • Um endereço IPv6 do intervalo de endereços IPv6 /96 atribuído a uma pilha dupla que recebe a NIC da VM.
    • Um endereço IPv6 do intervalo de endereços IPv6 /96 de uma regra de encaminhamento interna para encaminhamento de protocolo ou para um balanceador de carga de rede de passagem interna.
  • Intervalos de endereços de sub-rede IPv6 externos usados por esses recursos de destino quando os pacotes são roteados usando rotas de sub-rede ou rotas de sub-rede de peering na rede VPC:
    • Um endereço IPv6 do intervalo de endereços IPv6 /96 atribuído a uma pilha dupla que recebe a NIC da VM.
    • Um endereço IPv6 do intervalo de endereços IPv6 /96 de uma regra de encaminhamento externa para encaminhamento de protocolo ou para um balanceador de carga de rede de passagem externa.

Os caminhos de VM para VM a seguir são tratados da mesma maneira que a comunicação com destinos fora de uma rede VPC:

  • Se o destino do pacote for um endereço IPv4 externo de uma placa de rede (NIC) da VM do Google Cloud de recebimento.
  • Se o destino do pacote for um endereço IPv4 externo de um balanceador de carga de rede de passagem externa
  • Se o destino do pacote for um endereço IPv4 externo de uma regra de encaminhamento para encaminhamento de protocolo
  • Se o destino do pacote for um endereço IPv6 externo de uma placa de rede da VM do Google Cloud, um balanceador de carga de rede de passagem externa ou uma regra de encaminhamento para encaminhamento de protocolo externo e a rota aplicável na rede VPC usa um próximo salto de gateway de Internet padrão. Nesse cenário, as VMs de destino não estão na mesma rede VPC que a VM de envio nem em uma rede VPC conectada à rede VPC da VM de envio usando o peering de rede VPC.

Comunicação para destinos fora de uma rede VPC

O Google Cloud processa pacotes enviados para destinos fora da rede VPC da VM de envio, conforme mostrado na tabela a seguir. Os destinos fora da rede VPC de uma VM de envio incluem endereços IP publicamente roteáveis para recursos fora do Google Cloud e endereços IP externos utilizáveis pelo cliente no Google Cloud.

Como a Internet geralmente usa uma MTU de 1.500 bytes, manter o tamanho do pacote IP em 1.500 bytes ou menos geralmente evita a perda de pacotes relacionados à MTU.

Situação Comportamento
Pacotes TCP SYN e SYN-ACK O Google Cloud realiza a limitação de MSS, se necessário, alterando o MSS para garantir que os pacotes se encaixem na MTU.
MTU de pacote IP entre 1.300 e 1.600 bytes (inclusive) O Google Cloud não faz alterações no pacote, exceto nos pacotes SYN e SYN-ACK, conforme discutido na primeira linha.
Pacote IP com mais de 1.600 bytes O Google Cloud descarta o pacote e envia uma mensagem de fragmentação de ICMP quando o bit DF está ativado e também quando o bit DF está desativado.

Comunicação com APIs e serviços do Google

As VMs que usam qualquer tamanho válido de MTU da rede VPC podem enviar pacotes para APIs e serviços do Google, incluindo o uso do Acesso privado do Google e do Private Service Connect for Google APIs. Os detalhes nesta seção também se aplicam a recursos locais que enviam pacotes para APIs e serviços do Google usando o Acesso privado do Google para hosts no local.

O caminho de tráfego para as APIs e os serviços do Google descrito nesta seção é implementado pelos Google Front Ends (GFEs). Esses GFEs usam MTUs fixas e não configuráveis. O tráfego do Google Cloud para APIs e serviços do Google sempre usa o protocolo TCP: se uma VM se conectar a APIs e serviços do Google por uma rede VPC em que a MTU não corresponda à MTU do GFE, o segmento O tamanho é negociado usando uma divulgação TCP MSS, conforme descrito em MTUs incompatíveis, restrição de MSS, descoberta de MTU de caminho.

Origem do pacote Destino do pacote

Qualquer endereço IPv4 interno: endereço IPv4 interno principal ou endereço IPv4 interno de um intervalo de IP do alias da placa de rede da VM

Um endereço IPv4 externo atribuído à placa de rede da VM usando uma configuração de acesso NAT 1-1: nessa situação, o Google Cloud executa NAT 1-1 na saída, convertendo um endereço IPv4 interno primário de origem original em um endereço IPv4 externo de origem especificado na configuração de acesso.
  • Endereços IPv4 de APIs e serviços do Google para os domínios padrão
  • 199.36.153.4/30 (restricted.googleapis.com)
  • 199.36.153.8/30 (private.googleapis.com)
  • Endpoint do Private Service Connect para APIs e serviços do Google
Endereço IPv6 externo ou interno, para VMs de pilha dupla
  • Endereços IPv6 de APIs e serviços do Google para os domínios padrão
  • 2600:2d00:0002:1000::/64 (restricted.googleapis.com)
  • 2600:2d00:0002:2000::/64 (private.googleapis.com)

Comunicação por túneis do Cloud VPN

O Cloud VPN tem uma MTU de gateway para pacotes encapsulados e uma MTU de payload para pacotes antes e depois do encapsulamento.

Para valores precisos de MTU de payload e outras informações sobre MTU do Cloud VPN, consulte Considerações sobre MTU na documentação do Cloud VPN.

Comunicação por anexos do Cloud Interconnect (VLAN)

O Google recomenda usar a mesma MTU para todos os anexos da VLAN conectados à mesma rede VPC e definir a MTU da rede VPC com o mesmo valor. Para mais detalhes sobre as MTUs do anexo da VLAN do Cloud Interconnect, consulte MTU do Cloud Interconnect.

Suporte a frame Jumbo

A tabela a seguir resume o suporte a frames jumbo entre produtos e recursos do Google Cloud:

Produto ou recurso Suporte a frame Jumbo
Compute Engine Sim
Cloud Interconnect Sim
Cloud VPN Não
Serviços compatíveis das APIs do Google Não

Configurações de VM e MTU

Como prática recomendada, associe a MTU da placa de rede (NIC, na sigla em inglês) de uma VM à MTU da rede VPC a que a placa está conectada:

  • Cada MTU de NIC para uma VM Linux baseada em uma imagem do SO fornecida pelo Google é definida automaticamente para a respectiva MTU da rede VPC usando a opção DHCP 26.

  • Cada MTU de NIC para uma VM do Windows com base em uma imagem do SO fornecida pelo Google é configurada com uma MTU fixa de 1,460 bytes. Se você alterar a MTU de uma rede VPC que contém VMs do Windows com base em imagens do SO fornecidas pelo Google, será necessário alterar a MTU para a VM do Windows.

  • Se você usar imagens personalizadas de SO convidado, será necessário configurar MTUs de placa de rede (NIC, na sigla em inglês) ou verificar se o SO convidado aceita a MTU da rede VPC usando a opção DHCP 26.

  • Se uma VM tiver várias interfaces de rede, defina cada MTU da placa de rede como a respectiva MTU de rede VPC.

  • Se uma MTU da NIC precisar ser diferente da MTU da rede VPC, defina a MTU da NIC como menor que a MTU da rede VPC. A redução forçada da MTU da NIC é vantajosa para alguns cenários de rede avançados.

Como alterar a MTU de uma rede VPC

Se você alterar a MTU de uma rede VPC com VMs em execução, lembre-se das seguintes considerações:

  • Se você reduzir a MTU da rede VPC, precisa interromper e iniciar cada VM. Reiniciar uma VM de dentro do sistema operacional convidado não atualiza a MTU.

  • Se você aumentar a MTU da rede VPC, a execução de VMs usando a rede VPC não aproveitará o aumento da MTU da rede VPC até que elas sejam interrompidas e iniciadas. Até que cada VM seja interrompida e reiniciada, ela continuará usando o valor de MTU anterior (mais baixo).

Para instruções, consulte Alterar a configuração de MTU de uma rede VPC.

Configurações de MTU e GKE

A MTU selecionada para uma interface de pod depende da interface de rede de contêiner (CNI, na sigla em inglês) usada pelos nós do cluster e da configuração de MTU da VPC subjacente. Para mais informações, consulte Pods.

O valor da MTU da interface do pod é 1460 ou herdado da interface principal do nó.

CNI MTU GKE Standard
kubenet 1460 Default
kubenet
(GKE versão 1.26.1 e posterior) 		Herdado Default
Calico 1460

Ativado usando --enable-network-policy.

Para detalhes, consulte Controlar a comunicação entre pods e Serviços usando políticas de rede.
netd Herdado Ativado usando uma destas opções:
GKE Dataplane V2 Herdado

Ativado usando --enable-dataplane-v2.

Para mais detalhes, consulte Como usar o GKE Dataplane V2.

MTUs incompatíveis, restrição de MSS, descoberta de MTU de caminho

Nesta seção, descrevemos como os protocolos TCP e não TCP lidam com MTUs incompatíveis.

Protocolo TCP

O protocolo TCP lida com incompatibilidades de MTU automaticamente. Tanto o cliente quanto o servidor calculam individualmente os próprios valores de tamanho máximo do segmento TCP (MSS, na sigla em inglês) efetivos sempre que uma conexão TCP é aberta. O cliente e o servidor não precisam concordar com um valor MSS efetivo idêntico.

  • Tamanho máximo do segmento TCP efetivo (MSS, na sigla em inglês) do cliente: a maior quantidade de dados transmissíveis em um segmento TCP enviado de um cliente para um servidor é mínimo dos dois valores a seguir:

    • O valor do campo MSS no pacote SYN-ACK recebido pelo cliente do servidor durante o estabelecimento da conexão TCP.

    • A MTU da interface de rede do cliente, menos 40 bytes. Os 40 bytes subtraídos incluem 20 bytes para o cabeçalho IP e 20 bytes para o cabeçalho TCP de base.

  • Tamanho máximo do segmento TCP efetivo (MSS, na sigla em inglês) do servidor: a maior quantidade de dados transmissíveis em um segmento TCP enviado de um servidor para um cliente é o mínimo dos dois valores a seguir:

    • O valor do campo MSS no pacote SYN recebido pelo servidor do cliente durante o estabelecimento da conexão TCP.

    • A MTU da interface de rede do servidor, menos 40 bytes. Os 40 bytes subtraídos incluem 20 bytes para o cabeçalho IP e 20 bytes para o cabeçalho TCP de base.

Restrição de MSS do TCP

O TCP MSS clamping é um processo em que um dispositivo de rede entre um cliente e um servidor muda os valores MSS nos pacotes SYN e SYN-ACK à medida que os encaminha entre o cliente e o servidor. O Google Cloud usa a restrição de MSS sempre que envia pacotes para destinos fora de uma rede VPC.

Túneis do Cloud VPN e anexos da VLAN do Cloud Interconnect também usam a restrição do MSS. Para mais informações, consulte Encapsulamento e processamento de pacotes na documentação do Cloud VPN e na MTU do Cloud Interconnect.

As redes VPC não executam a restrição MSS para pacotes roteados pelos próximos saltos em uma rede VPC porque o protocolo TCP em si é suficiente.

Protocolos não TCP

Outros protocolos, como UDP, exigem cuidado especial quando duas MTUs de rede VPC diferentes estiverem envolvidas. É responsabilidade de um sistema de envio emitir pacotes que se encaixem na MTU da interface de rede, a MTU da interface de rede do sistema receptor e a MTU de todas as redes intermediárias. O Google Cloud não executa a fragmentação de IP nos pacotes roteados pelos próximos saltos em uma rede VPC.

Quando um pacote IP é muito grande para ser entregue, por exemplo, quando o pacote excede a MTU da rede VPC em que a NIC da VM de destino está localizada, o Google Cloud descarta o pacote. Se o pacote tiver o conjunto de bits DF, o Google Cloud também enviará uma mensagem de Fragmentação necessária (ICMP over IPv4) ou Pacote muito grande (ICMPv6) de volta ao remetente.

O Google Cloud envia uma mensagem de "Fragmentação necessária" ou "Pacote muito grande" nas seguintes circunstâncias, mesmo quando um bit DF não está definido:

  • Se a MTU da rede VPC for menor que 1.600 bytes e o pacote que está sendo enviado exceder a MTU da rede VPC.
  • Se a MTU da rede VPC for de 1.600 bytes ou mais e o pacote que está sendo enviado exceder 1.600 bytes.

As mensagens de fragmentação de ICMP necessárias ou pacote muito grande são necessárias para que uma VM que esteja enviando pacotes use a descoberta de MTU de caminho (PMTUD, na sigla em inglês). Para ilustrar como a PMTUD funciona, considere o exemplo a seguir com duas VMs em redes VPC diferentes conectadas usando o peering de rede VPC:

  • A VM de envio tem uma NIC em uma rede VPC com MTU de 8.896 bytes.
  • A VM de recebimento tem uma NIC em uma rede VPC com MTU de 1.460 bytes.
  • A VM de envio emite um pacote IP de 8.000 bytes com o bit Não fragmentar (DF) definido. Como o pacote é muito grande para ser entregue à VM de destino, o Google Cloud envia uma mensagem de "Fragmentação necessária" ou "Pacote muito grande" para a VM de envio. Essa mensagem indica o maior tamanho de pacote IP possível que o remetente pode usar ao tentar retransmitir pacotes para a conexão.
  • O sistema operacional da VM de envio usa essas informações para diminuir o tamanho do pacote de IP ao enviar pacotes subsequentes para a VM de recebimento.

A PMTUD tem os seguintes requisitos extras porque os pacotes com fragmentação necessária gerados por PMTUD ou em pacotes muito grandes usam o protocolo ICMP e têm origens que correspondem ao destino de um pacote original:

  • É preciso configurar as regras de firewall de VPC de entrada ou as regras em políticas de firewall de modo que o ICMP (para IPv4) ou o ICMPv6 (para IPv6) sejam permitidos a partir de origens que correspondem aos destinos originais do pacote. Para simplificar a configuração do firewall, permita o ICMP e o ICMPv6 de todas as origens.
  • As regras de encaminhamento para o balanceador de carga de rede de passagem interna e o encaminhamento de protocolo interno precisam usar o protocolo L3_DEFAULT para que processem o ICMP para PMTUD e o protocolo usado pelo pacote original.

A seguir

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho da VPC em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Faça uma avaliação gratuita da VPC