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). Recomendamos que você configure a MTU para cada interface da placa de rede da instância (NIC) do Compute Engine para corresponder à MTU da rede VPC a que ela está conectada. Para mais informações, consulte Instâncias de computação e configurações de MTU.

Comunicação entre instâncias de computação em redes VPC

Pacotes IP até o tamanho da MTU podem ser enviados entre duas instâncias de computação, se o seguinte se aplicar:

  • As instâncias de envio e recebimento usam a mesma rede VPC ou redes VPC com peering que têm MTUs idênticas.
  • As interfaces de ambas as instâncias estão configuradas para usar a MTU da rede VPC.

Para evitar problemas de incompatibilidade de MTU, recomendamos que você use a mesma MTU para todas as redes VPC conectadas. Embora essa seja a prática recomendada, você não é obrigado a configurar MTUs idênticas em 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 instância de envio, os caminhos para os destinos a seguir representam o tráfego de instância para instância 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 instância de recebimento.
    • Um endereço IPv4 interno em um intervalo de IP do alias da placa de rede (NIC) de uma instância 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 à placa de rede (NIC) de uma instância de recebimento.
    • 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 à placa de rede (NIC) de uma instância de recebimento.
    • 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 instância para instância a seguir são tratados da mesma forma que a comunicação com destinos fora de uma rede VPC network:

  • Se o destino do pacote for um endereço IPv4 externo de uma placa de rede (NIC) de uma instância 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 (NIC) de uma instância, 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 instâncias de recebimento não estão na mesma rede VPC que a instância de envio nem em uma rede VPC conectada à rede VPC da instância de envio usando o peering de rede VPC.

Comunicação para destinos fora de uma rede VPC

Cloud de Confiance processa pacotes enviados de instâncias de computação para destinos fora da rede VPC da instância de envio, conforme mostrado na tabela a seguir. Os destinos fora da rede VPC de uma instância de envio incluem endereços IP publicamente roteáveis para recursos fora do Google Cloud e endereços IP externo utilizáveis pelo cliente no Google Cloud.Cloud de Confiance Cloud de Confiance

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 Cloud de Confiance 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) Cloud de Confiance 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 Cloud de Confiance descarta o pacote e envia uma mensagem "Fragmentação necessária (ICMP via IPv4)" ou "Pacote muito grande (ICMPv6)" quando o bit DF está ativado e também quando ele está desativado.

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

As instâncias de computação 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 de Cloud de Confiance para APIs e serviços do Google sempre usa o protocolo TCP: se uma instância de computação se conectar a APIs e serviços do Google por uma rede VPC em que a MTU não corresponda à MTU do GFE, o tamanho do segmento é 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 instância

Um endereço IPv4 externo atribuído à placa de rede da instância usando uma configuração de acesso NAT 1-1: nessa situação, Cloud de Confiance realiza 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
  • 177.222.88.4/30 (restrito.s3nsapis.fr)
  • 177.222.88.0/30 (particular.s3nsapis.fr)
  • Endpoint do Private Service Connect para APIs e serviços do Google
Endereço IPv6 externo ou interno, para instâncias de pilha dupla ou somente IPv6 instâncias
  • Endereços IPv6 de APIs e serviços do Google para os domínios padrão
  • 2a13:7500:8302:1::/64 (restrito.s3nsapis.fr)
  • 2a13:7500:8302::/64 (particular.s3nsapis.fr)

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)

Recomendamos 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.

Comunicação por endpoints de firewall

Se você usar endpoints de firewall, configure uma MTU adequada para sua rede VPC. Se a configuração de MTU da rede VPC exceder o tamanho do pacote compatível com o endpoint de firewall, o Cloud Next Generation Firewall não poderá realizar a inspeção da camada 7. Para mais informações, consulte Tamanho do pacote compatível.

Suporte a frame Jumbo

Os frames jumbo têm um payload com mais de 1.460 bytes de tamanho. A tabela a seguir resume o suporte a frames jumbo para Cloud de Confiance produtos e recursos:

Produto ou recurso Suporte a frame Jumbo
Compute Engine Sim
Cloud Interconnect Sim
Endpoints de firewall Sim
Cloud VPN Não
APIs do Google Não

Instâncias de computação e configurações de MTU

Como prática recomendada, faça a correspondência da MTU da placa de rede (NIC) de uma instância de computação com a MTU da rede VPC a que a NIC está conectada. A configuração da MTU da NIC varia de acordo com o sistema operacional e a configuração:

  • Instâncias do Linux baseadas em uma imagem do SO pública: cada MTU de NIC é definida automaticamente para a respectiva MTU da rede VPC usando a opção DHCP 26.

  • Instâncias do Windows baseadas em uma imagem do SO pública: por padrão, cada MTU de NIC é configurada com uma MTU fixa de 1,460 bytes. Se você alterar a MTU de uma rede VPC que contém instâncias do Windows com base em imagens do SO pública, será necessário alterar a configuração da MTU das instâncias do Windows.

  • Imagens personalizadas de SO convidado: é 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.

  • Instâncias com várias interfaces de rede: defina cada MTU da placa de rede (NIC) como a respectiva MTU de rede VPC.

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

Como alterar a MTU de uma rede VPC

Para evitar problemas de conectividade, antes de alterar a MTU da rede VPC, é necessário primeiro interromper cada instância de computação. Reiniciar uma instância de dentro do sistema operacional convidado não atualiza a MTU. Se você optar por configurar instâncias com uma MTU menor que a MTU da rede, o requisito de interromper a instância antes de alterar a MTU ainda será aplicado.

Para mais informações sobre como alterar a MTU da rede, consulte Mude a configuração da 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 Padrão
kubenet
(GKE versão 1.26.1 e posterior) 		Herdado Padrão
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. Cloud de Confiance usa a restrição de MSS sempre que envia pacotes para destinos fora de uma rede VPC network.

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. Cloud de Confiance _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 instância de computação de destino está localizada, Cloud de Confiance descarta o pacote. Se o pacote tiver o conjunto de bits DF, Cloud de Confiance também enviará uma mensagem de Fragmentação necessária (ICMP over IPv4) ou Pacote muito grande (ICMPv6) de volta para o remetente.

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

  • 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 instância de computação que esteja enviando pacotes use a descoberta de MTU de caminho (PMTUD). Para ilustrar como a PMTUD funciona, considere o exemplo a seguir com duas instâncias de computação em redes VPC diferentes conectadas usando o peering de rede VPC:

  • A instância de envio tem uma placa de rede (NIC) em uma rede VPC cuja MTU é de 8.896 bytes.
  • A instância de recebimento tem uma placa de rede (NIC) em uma rede VPC cuja MTU é de 1.460 bytes.
  • A instância 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 à instância de recebimento, Cloud de Confiance envia uma mensagem de Fragmentação necessária ou Pacote muito grande para a instância 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 instância de envio usa essas informações para diminuir o tamanho do pacote de IP ao enviar pacotes subsequentes para a instância 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