Unidad de transmisión máxima

La unidad máxima de transmisión (MTU) es el tamaño en bytes del paquete de IP más grande posible, incluidos los encabezados IP, los encabezados de protocolo de capa 4 y los datos de capa 4, que puede caber dentro de una trama Ethernet.

Tamaños válidos de MTU de la red de VPC

Las redes de nube privada virtual (VPC) usan una MTU predeterminada de 1,460 bytes. Puedes configurar la MTU de una red de VPC en cualquier valor entre 1,300 bytes y 8,896 bytes (inclusive). Los tamaños de MTU personalizados comunes son 1,500 bytes (Ethernet estándar) o 8,896 bytes (el máximo posible). Te recomendamos que configures la MTU para cada interfaz de red de instancias de máquina virtual (VM) (NIC) a fin de que coincida con la MTU de la red de VPC a la que está conectada. Para obtener más información, consulta Configuración de VM y MTU.

Comunicación entre las VMs de Google Cloud dentro de las redes de VPC

Cuando se envían y reciben VMs mediante la misma red de VPC o redes de VPC de intercambio de tráfico que tienen MTU idénticas, se pueden enviar paquetes de IP hasta el tamaño de la MTU entre las dos VMs, si las interfaces de ambas VMs están configuradas para usar la MTU de la red de VPC.

Para evitar problemas de desigualdad de MTU, te recomendamos que uses la misma MTU para todas tus redes de VPC conectadas. Si bien esta es la práctica recomendada, no estás obligado a tener MTU idénticas entre redes de VPC conectadas. Para obtener detalles sobre cómo los protocolos manejan situaciones en las que hay una discrepancia de MTU entre redes de VPC, consulta MTU no coincidentes, restricción de MSS y descubrimiento de MTU de rutas de acceso.

Desde la perspectiva de una VM de envío, las rutas a los siguientes destinos representan el tráfico de VM a VM enrutado dentro de una red de VPC:

  • Una dirección IPv4 interna regional en un rango de direcciones IPv4 principal de subred o IPv4 secundario de subred, incluidos los rangos de direcciones IPv4 privadas y los rangos de direcciones IPv4 públicas usadas de forma privada que usan estos destinos recursos:
    • La dirección IPv4 interna principal de la interfaz de red (NIC) de una VM receptora.
    • Una dirección IPv4 interna en un rango de alias de IP de la NIC de una VM receptora.
    • Una dirección IPv4 interna de una regla de reenvío interna para el reenvío de protocolos o un balanceador de cargas de red de transferencia interno.
  • Rangos de direcciones IPv6 internos de subred que usan estos recursos de destino:
    • Una dirección IPv6 del rango de direcciones IPv6 /96 asignado a una NIC de pila doble que recibe la VM.
    • Una dirección IPv6 del rango de direcciones IPv6 /96 de una regla de reenvío interno para el reenvío de protocolos o un balanceador de cargas de red de paso interno.
  • Rangos de direcciones IPv6 externos que usan estos recursos de destino cuando los paquetes se enrutan mediante rutas de subred o rutas de subred de intercambio de tráfico dentro de la red de VPC:
    • Una dirección IPv6 del rango de direcciones IPv6 /96 asignado a una NIC de pila doble que recibe la VM.
    • Una dirección IPv6 del rango de direcciones IPv6 /96 de una regla de reenvío externa para un reenvío de protocolos o un balanceador de cargas de red de paso externo.

Las siguientes rutas de acceso de VM a VM se tratan de la misma manera que la comunicación a destinos fuera de una red de VPC:

  • Si el destino del paquete es una dirección IPv4 externa de la NIC de la VM de Google Cloud receptora.
  • Si el destino del paquete es una dirección IPv4 externa de un balanceador de cargas de red de transferencia externo.
  • Si el destino del paquete es una dirección IPv4 externa de una regla de reenvío para el reenvío de protocolos
  • Si el destino del paquete es una dirección IPv6 externa de la NIC de una VM de Google Cloud, un balanceador de cargas de red de paso externo o una regla de reenvío para el reenvío de protocolos externos y la ruta aplicable en la red de VPC usa un próximo salto de puerta de enlace de Internet predeterminado. En esta situación, las VMs receptoras no están en la misma red de VPC que la VM emisora ni en una red de VPC conectada a la red de VPC de la VM emisora mediante el intercambio de tráfico entre redes de VPC.

Comunicación a destinos fuera de una red de VPC

Google Cloud procesa los paquetes enviados a destinos fuera de la red de VPC de la VM de envío, como se muestra en la siguiente tabla. Los destinos fuera de la red de VPC de una VM de envío incluyen direcciones IP enrutables de forma pública para recursos fuera de Google Cloud y direcciones IP externas reutilizables de clientes dentro de Google Cloud.

Debido a que Internet suele usar una MTU de 1,500 bytes, mantener el tamaño del paquete de IP en 1,500 bytes o menos suele evitar la pérdida de paquetes relacionada con la MTU.

Situación Comportamiento
Paquetes TCP SYN y SYN-ACK Google Cloud realiza una restricción de MSS si es necesario, y cambia el MSS para garantizar que los paquetes se ajusten a la MTU.
MTU de un paquete de IP entre 1,300 bytes y 1,600 bytes (inclusive) Google Cloud no realiza cambios en el paquete, excepto los paquetes SYN y SYN-ACK, como se explica en la primera fila.
Paquete de IP superior a 1,600 bytes Google Cloud descarta el paquete y envía un mensaje de fragmentación necesaria (ICMP mediante IPv4) o Paquete demasiado grande (ICMPv6) cuando el bit DF está activado y también cuando el bit DF está desactivado.

Comunicación a los servicios y las APIs de Google

Las VMs que usan cualquier tamaño de MTU de red de VPC válida pueden enviar paquetes a los servicios y las APIs de Google, incluidos el Acceso privado a Google y Private Service Connect para APIs de Google. Los detalles de esta sección también se aplican a los recursos locales que envían paquetes a los servicios y las APIs de Google mediante el Acceso privado a Google para hosts locales.

Google Front End (GFE) implementa la ruta de tráfico para las APIs y los servicios de Google descritos en esta sección. Estos GFE usan MTU fijas no configurables. El tráfico de Google Cloud a los servicios y las APIs de Google siempre usa el protocolo TCP: si una VM se conecta a los servicios y las APIs de Google desde una red de VPC cuya MTU no coincide con la MTU del GFE, el segmento El tamaño se negocia mediante el anuncio de TCP MSS como se describe en MTU no coincidentes, restricción de MSS y descubrimiento de MTU de rutas de acceso.

Fuente del paquete Destino del paquete

Cualquier dirección IPv4 interna: la dirección IPv4 interna principal o la dirección IPv4 interna de un rango de alias de IP de la NIC de la VM

Una dirección IPv4 externa asignada a la NIC de la VM mediante una configuración de acceso NAT 1-1: en esta situación, Google Cloud realiza NAT 1-1 en la salida, lo que convierte una dirección IPv4 interna principal original de origen en una dirección IPv4 externa de origen especificada en la configuración de acceso.
  • Direcciones IPv4 de los servicios y las APIs de Google para los dominios predeterminados
  • 199.36.153.4/30 (restricted.googleapis.com)
  • 199.36.153.8/30 (private.googleapis.com)
  • Extremo de Private Service Connect para los servicios y las APIs de Google
Dirección IPv6 externa o interna para las VMs de pila doble
  • Direcciones IPv6 de los servicios y las APIs de Google para los dominios predeterminados
  • 2600:2d00:0002:1000::/64 (restricted.googleapis.com)
  • 2600:2d00:0002:2000::/64 (private.googleapis.com)

Comunicación a través de túneles de Cloud VPN

Cloud VPN tiene una MTU de puerta de enlace para los paquetes encapsulados y una MTU de carga útil para los paquetes antes y después del encapsulamiento.

Para obtener valores de MTU de carga útil precisos y otra información de MTU de Cloud VPN, consulta Consideraciones de MTU en la documentación de Cloud VPN.

Comunicación a través de adjuntos de Cloud Interconnect (VLAN)

Te recomendamos que uses la misma MTU para todos los adjuntos de VLAN que están conectados a la misma red de VPC, y que configures la MTU de la red de VPC con el mismo valor. Para obtener detalles sobre las MTU de los adjuntos de VLAN de Cloud Interconnect, consulta MTU de Cloud Interconnect.

Compatibilidad con marcos jumbo

En la siguiente tabla, se resume la compatibilidad con marcos jumbo entre los productos y las funciones de Google Cloud:

Producto o función Compatibilidad con marcos jumbo
Compute Engine Sí
Cloud Interconnect Sí
Cloud VPN No
API de Google No

Configuración de VMs y MTU

Como práctica recomendada, haz coincidir la MTU de la NIC de una VM con la MTU de la red de VPC a la que está conectada la NIC:

  • Cada MTU de NIC para una VM de Linux basada en una imagen de SO pública se configura automáticamente en la MTU de la red de VPC correspondiente mediante la opción 26 de DHCP.

  • Cada MTU de NIC para una VM de Windows basada en una imagen de SO pública está configurada con una MTU fija de 1,460 bytes. Si cambias la MTU de una red de VPC que contiene VMs de Windows basadas en imágenes de SO públicas, debes cambiar la configuración de MTU para la VM de Windows.

  • Si usas imágenes de SO invitado personalizadas, debes configurar las MTU de NIC o verificar que el SO invitado acepte la MTU de la red de VPC mediante DHCP Opción 26.

  • Si una VM tiene varias interfaces de red, configura cada NIC de NIC a la respectiva MTU de red de VPC.

  • Si una MTU de NIC debe diferir de la MTU de la red de VPC, establece la MTU de la NIC en un valor menor que la MTU de la red de VPC. Disminuir a la fuerza la MTU de la NIC es beneficioso para algunas situaciones de herramientas de redes avanzadas.

Cambia la MTU de una red de VPC

Si cambias la MTU de una red de VPC con VM en ejecución, ten en cuenta las siguientes consideraciones:

  • Si reduces la MTU de la red de VPC, debes iniciar y detener cada VM. Reiniciar una VM desde su sistema operativo invitado no actualiza su MTU.

  • Si aumentas la MTU de la red de VPC, la ejecución de VM mediante la red de VPC no aprovechará la mayor MTU de la red de VPC hasta que las VMs se detengan y se inicien. Hasta que cada VM se detenga y se reinicie, la VM continúa usando el valor de MTU anterior (más bajo).

Para obtener instrucciones, consulta Cambia la configuración de MTU de una red de VPC.

Configuración de GKE y MTU

La MTU seleccionada para una interfaz de Pod depende de la Interfaz de red de contenedor (CNI) que usan los nodos del clúster y la configuración de MTU de VPC subyacente. Para obtener más información, consulta Pods.

El valor de MTU de la interfaz del Pod es 1460 o se hereda de la interfaz principal del nodo.

CNI MTU GKE Standard
kubenet 1,460 Predeterminado
kubenet
(GKE versión 1.26.1 y posteriores) 		Heredada Predeterminado
Calico 1,460

Se habilita mediante --enable-network-policy.

Para obtener más información, consulta Controla la comunicación entre Pods y Services mediante las políticas de red.
netd Heredada Se habilita mediante cualquiera de las siguientes opciones:
GKE Dataplane V2 Heredada

Se habilita mediante --enable-dataplane-v2.

Para obtener más información, consulta Usa GKE Dataplane V2.

MTU no coincidentes, restricción de MSS, descubrimiento de MTU de ruta de acceso

En esta sección, se describe cómo los protocolos TCP y no TCP manejan las MTU no coincidentes.

Protocolo TCP

El protocolo TCP controla las discrepancias de MTU de manera automática. El cliente y el servidor calculan de forma individual sus propios valores de tamaño máximo de segmento (MSS) TCP efectivo cada vez que se abre una conexión TCP. El cliente y el servidor no tienen que acordar un valor de MSS efectivo idéntico.

  • Tamaño máximo de segmento TCP (MSS) efectivo del cliente: la mayor cantidad de datos transmisibles en un segmento TCP enviado de un cliente a un servidor es el mínimo de los dos valores siguientes:

    • El valor del campo MSS en el paquete SYN-ACK que recibió el cliente desde el servidor durante el establecimiento de la conexión TCP.

    • La MTU de la interfaz de red del cliente, menos 40 bytes. Los 40 bytes restados incluyen 20 bytes para el encabezado IP y 20 bytes para el encabezado TCP base.

  • Tamaño máximo de segmento TCP (MSS) efectivo del servidor: la mayor cantidad de datos transmisibles en un segmento TCP enviado de un servidor a un cliente es el mínimo de los dos valores siguientes:

    • El valor del campo MSS en el paquete SYN que recibió el servidor desde el cliente durante el establecimiento de la conexión TCP.

    • La MTU de la interfaz de red del servidor, menos 40 bytes. Los 40 bytes restados incluyen 20 bytes para el encabezado IP y 20 bytes para el encabezado TCP base.

Fijación de MSS de TCP

La fijación de MSS de TCP es un proceso en el que un dispositivo de red entre un cliente y un servidor cambia los valores de MSS en los paquetes SYN y SYN-ACK a medida que enruta los paquetes entre el cliente y el servidor. Google Cloud usa la fijación de MSS cada vez que envía paquetes a destinos fuera de una red de VPC.

Los túneles de Cloud VPN y los adjuntos de VLAN de Cloud Interconnect también usan la fijación de MSS. Para obtener más información, consulta Encapsulamiento y procesamiento de paquetes en la documentación de Cloud VPN y MTU de Cloud Interconnect.

Las redes de VPC no realizan la fijación de MSS para los paquetes enrutados por los próximos saltos dentro de una red de VPC porque el protocolo TCP es suficiente.

Protocolos que no son TCP

Otros protocolos, como UDP, requieren un cuidado especial cuando se involucran dos MTU de red de VPC diferentes. Es responsabilidad de un sistema de envío emitir paquetes que se ajusten a la MTU de la interfaz de red, la MTU de la interfaz de red del sistema receptor y la MTU de todas las redes intermedias. Google Cloud no realiza la fragmentación de IP para los paquetes enrutados por los siguientes saltos dentro de una red de VPC.

Cuando un paquete de IP es demasiado grande para entregarse, por ejemplo, cuando el paquete supera la MTU de la red de VPC en la que se encuentra la NIC de la VM receptora, Google Cloud descarta el paquete. Si el paquete tiene configurado el bit DF, Google Cloud también envía un mensaje de fragmentación necesario (ICMP mediante IPv4) o paquete demasiado grande (ICMPv6) al remitente.

Google Cloud envía un mensaje de fragmentación necesario o de paquete demasiado grande en las siguientes circunstancias, incluso cuando un bit DF no está configurado:

  • Si la MTU de la red de VPC es inferior a 1,600 bytes y el paquete que se envía supera la MTU de la red de VPC.
  • Si la MTU de la red de VPC es de 1,600 bytes o más, y el paquete que se envía supera los 1,600 bytes.

La fragmentación de ICMP es necesaria o los paquetes demasiado grandes son necesarios para que una VM que envía paquetes use el descubrimiento de la MTU de la ruta (PMTUD). Para ilustrar cómo funciona PMTUD, considera el siguiente ejemplo con dos VMs en diferentes redes de VPC que están conectadas mediante el intercambio de tráfico entre redes de VPC:

  • La VM emisora tiene una NIC en una red de VPC cuya MTU es de 8,896 bytes.
  • La VM receptora tiene una NIC en una red de VPC cuya MTU es de 1,460 bytes.
  • La VM emisora emite un paquete de IP de 8,000 bytes cuyo bit No fragmentar (DF) está configurado. Debido a que el paquete es demasiado grande para entregarse a la VM receptora, Google Cloud envía un mensaje de fragmentación obligatorio o de paquete demasiado grande a la VM emisora. Este mensaje indica el tamaño de paquete de IP más grande posible que el remitente puede usar cuando intenta volver a transmitir paquetes para la conexión.
  • El sistema operativo de la VM emisora usa esta información para reducir el tamaño del paquete de IP cuando se envían paquetes posteriores a la VM receptora.

PMTUD tiene los siguientes requisitos adicionales porque los paquetes de fragmentación generados por PMTUD o los paquetes demasiado grandes usan el protocolo ICMP y tienen fuentes que coinciden con el destino de un paquete original:

  • Debes configurar las reglas de firewall de VPC o las reglas en las políticas de firewall de entrada permitida, de modo que ICMP (para IPv4) o ICMPv6 (para IPv6) se permitan desde fuentes que coincidan con los destinos de paquetes originales. Para simplificar la configuración de firewall, considera permitir ICMP e ICMPv6 de todas las fuentes.
  • Las reglas de reenvío para el balanceador de cargas de red interno y el reenvío de protocolos internos deben usar el protocolo L3_DEFAULT a fin de procesar ICMP para PMTUD y el protocolo que usa el paquete original.

¿Qué sigue?

Pruébalo tú mismo

Si es la primera vez que usas Google Cloud, crea una cuenta para evaluar el rendimiento de VPC en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Probar la VPC gratis