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 Compute Engine (NIC) de modo que coincida con la MTU de la red de VPC a la que está conectada. Para obtener más información, consulta Instancias de procesamiento y configuración de MTU.

Comunicación entre instancias de procesamiento dentro de redes de VPC

Se pueden enviar paquetes de IP hasta el tamaño de la MTU entre dos instancias de procesamiento si se cumplen las siguientes condiciones:

  • Las instancias de envío y recepción usan la misma red de VPC o redes de VPC de intercambio de tráfico que tienen MTU idénticas.
  • Las interfaces de ambas instancias 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. Aunque esa es la práctica recomendada, no estás obligado a configurar MTU idénticas en 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 instancia de envío, las rutas a los siguientes destinos representan el tráfico de instancia a instancia 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 instancia receptora.
    • Una dirección IPv4 interna en un rango de alias de IP de la NIC de una instancia 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 usados por estos recursos de destino:
    • Una dirección IPv6 del rango de direcciones IPv6 /96 asignado a la NIC de una instancia receptora.
    • 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 transferencia 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 la NIC de una instancia receptora.
    • 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 instancia a instancia se tratan de la misma manera que la Comunicación a destinos fuera de una red de VPC network:

  • Si el destino del paquete es una dirección IPv4 externa de la NIC de una instancia 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 instancia, 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 instancias receptoras no están en la misma red de VPC que la instancia emisora ni en una red de VPC conectada a la red de VPC de la instancia 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 desde instancias de procesamiento a destinos fuera de la red de VPC de la instancia emisora, como se muestra en la siguiente tabla. Los destinos fuera de la red de VPC de una instancia emisora 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 generalmente usa 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 ningún cambio en el paquete, excepto en los paquetes SYN y SYN-ACK, como se explicó 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 instancias de procesamiento 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 uso de Acceso privado a Google y Private Service Connect para las 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 instancia de procesamiento 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 tamaño del segmento 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 instancia

Una dirección IPv4 externa asignada a la NIC de la instancia 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 (restringidogoogleapis.com)
  • 199.36.153.8/30 (privadogoogleapis.com)
  • Extremo de Private Service Connect para los servicios y las APIs de Google
Dirección IPv6 externa o interna para las instancias de pila doble o solo IPv6
  • Direcciones IPv6 de los servicios y las APIs de Google para los dominios predeterminados
  • 2600:2d00:0002:1000::/64 (restringidogoogleapis.com)
  • 2600:2d00:0002:2000::/64 (privadogoogleapis.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)

Google recomienda 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 adjunto de VLAN de Cloud Interconnect, consulta MTU de Cloud Interconnect.

Comunicación a través de extremos de firewall

Si usas extremos de firewall, configura una MTU adecuada para tu red de VPC. Si la configuración de MTU de tu red de VPC supera el tamaño del paquete que admite el extremo de firewall, Cloud Next Generation Firewall no puede realizar la inspección de la capa 7 de forma correcta. Para obtener más información, consulta Tamaño de paquete admitido.

Compatibilidad con marcos jumbo

Los marcos jumbo tienen una carga útil de más de 1,460 bytes. En la siguiente tabla, se resume la compatibilidad con marcos jumbo para Google Cloud productos y funciones:

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

Instancias de procesamiento y configuración de MTU

Como práctica recomendada, haz coincidir la MTU de la NIC de una instancia de procesamiento con la MTU de la red de VPC a la que está conectada la NIC. La configuración de MTU de la NIC varía según el sistema operativo y la configuración:

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

  • Instancias de Windows basadas en una imagen de SO pública: De forma predeterminada, cada MTU de NIC está configurada con una MTU fija de 1,460 bytes. Si cambias la MTU de una red de VPC que contiene instancias de Windows basadas en imágenes de SO públicas, debes cambiar la configuración de MTU de las instancias de Windows.

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

  • Instancias con interfaces de red múltiples: Configura cada MTU 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, configura la MTU de la NIC en un valor inferior a la MTU de la red de VPC. La disminución forzosa de la MTU de la NIC es ventajosa para algunas situaciones de redes avanzadas.

Cambia la MTU de una red de VPC

Para evitar problemas de conectividad, antes de cambiar la MTU de la red de VPC, primero debes detener cada instancia de procesamiento. Reiniciar una instancia desde su sistema operativo invitado no actualiza su MTU. Si eliges configurar instancias con una MTU inferior a la MTU de la red, el requisito de detener la instancia antes de cambiar la MTU sigue siendo válido.

Para obtener más información sobre cómo cambiar la MTU de la red, 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 network.

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 instancia de procesamiento 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) a l remitente.

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

  • 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 instancia de procesamiento 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 instancias de procesamiento en diferentes redes de VPC que están conectadas mediante el intercambio de tráfico entre redes de VPC:

  • La instancia emisora tiene una NIC en una red de VPC cuya MTU es de 8,896 bytes.
  • La instancia receptora tiene una NIC en una red de VPC cuya MTU es de 1,460 bytes.
  • La instancia 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 instancia receptora, Google Cloud envía un mensaje de fragmentación necesaria o paquete demasiado grande a la instancia 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 instancia emisora usa esta información para reducir el tamaño del paquete de IP cuando envía paquetes posteriores a la instancia 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 e implementar cargas de trabajo.

Probar la VPC gratis