Unidad máxima de transmisión
La unidad de transmisión máxima (MTU) es el tamaño, en bytes, del paquete de IP más grande posible, incluidos los encabezados de IP, los encabezados de protocolo de la capa 4 y los datos de la capa 4, que se puede incluir en un marco de Ethernet.
Tamaños de MTU de red de VPC válidos
Las redes de nube privada virtual (VPC) usan una MTU predeterminada de 1460 bytes. Puedes definir el valor de MTU de una red VPC en cualquier valor entre 1300 y 8896 bytes (ambos incluidos). Los tamaños de MTU personalizados más habituales son 1500 bytes (Ethernet estándar) u 8896 bytes (el máximo posible). Te recomendamos que configures la MTU de cada interfaz de red (NIC) de la instancia de máquina virtual (VM) para que coincida con la MTU de la red de VPC a la que esté conectada. Para obtener más información, consulta Máquinas virtuales y ajustes de MTU.
Comunicación entre Google Cloud máquinas virtuales de redes de VPC
Cuando las VMs de envío y recepción usan la misma red de VPC o redes de VPC emparejadas que tienen MTUs idénticos, se pueden enviar paquetes IP de hasta el tamaño del MTU entre las dos VMs, siempre que las interfaces de ambas VMs estén configuradas para usar el MTU de la red de VPC.
Para evitar problemas de discrepancia de MTU, te recomendamos que uses el mismo MTU en todas tus redes de VPC conectadas. Aunque es la práctica recomendada, no es obligatorio que las MTUs sean idénticas en las redes de VPC conectadas. Para obtener información sobre cómo gestionan los protocolos las situaciones en las que hay una diferencia de MTU entre redes de VPC, consulta Diferencias de MTU, ajuste de MSS y descubrimiento de MTU de ruta.
Desde el punto de vista de una máquina virtual de envío, las rutas a los siguientes destinos representan el tráfico entre máquinas virtuales enrutado dentro de una red de VPC:
- Una dirección IPv4 interna regional en un intervalo de direcciones IPv4 principal de subred o de direcciones IPv4 secundarias de subred, incluidos los intervalos de direcciones IPv4 privadas y los intervalos de direcciones IPv4 públicas de uso privado, que utilizan estos recursos de destino:
- La dirección IPv4 interna principal de la interfaz de red (NIC) de una máquina virtual receptora.
- Una dirección IPv4 interna en un intervalo de IP de alias 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 para un balanceador de carga de red de paso a través interno.
- Intervalos de direcciones de subred IPv6 internas que usan estos recursos de destino:
- Una dirección IPv6 del
/96
intervalo de direcciones IPv6 asignado a la NIC de una VM receptora. - Una dirección IPv6 del
/96
intervalo de direcciones IPv6 de una regla de reenvío interna para el reenvío de protocolos o para un balanceador de carga de red interno de tipo pasarela.
- Una dirección IPv6 del
- Intervalos de direcciones de subred IPv6 externas que usan estos recursos de destino cuando los paquetes se enrutan mediante rutas de subred o rutas de subred de emparejamiento en la red de VPC:
- Una dirección IPv6 del
/96
intervalo de direcciones IPv6 asignado a la NIC de una VM receptora. - Una dirección IPv6 del intervalo de direcciones IPv6
/96
de una regla de reenvío externa para el reenvío de protocolos o para un balanceador de carga de red passthrough externo.
- Una dirección IPv6 del
Las siguientes rutas de máquina virtual a máquina virtual se tratan de la misma forma que la comunicación con destinos fuera de una red de VPC:
- Si el destino del paquete es una dirección IPv4 externa de la NIC de unaGoogle Cloud VM receptora.
- Si el destino del paquete es una dirección IPv4 externa de un balanceador de carga de red de paso a través 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 una NIC de una máquina virtual, un balanceador de carga de red de pases 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 salto siguiente de la pasarela de Internet predeterminada. Google CloudEn este caso, 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 emparejamiento entre redes de VPC.
Comunicación con destinos fuera de una red de VPC
Google Cloud procesa los paquetes enviados a destinos que están fuera de la red de VPC de la máquina virtual que los envía, tal como se muestra en la siguiente tabla. Los destinos que están fuera de la red VPC de una máquina virtual de envío incluyen direcciones IP de enrutamiento público para recursos que están fuera de Google Cloud y direcciones IP externas que pueden usar los clientes dentro deGoogle Cloud.
Como Internet suele usar un MTU de 1500 bytes, si el tamaño del paquete IP es de 1500 bytes o menos, normalmente se evita la pérdida de paquetes relacionada con el MTU.
Situación | Comportamiento |
---|---|
Paquetes SYN y SYN-ACK de TCP | Google Cloud realiza el ajuste de MSS si es necesario, cambiando el MSS para asegurarse de que los paquetes se ajusten a la MTU. |
MTU de paquetes IP entre 1300 y 1600 bytes (ambos incluidos) | Google Cloud no hace ningún cambio en el paquete, excepto en los paquetes SYN y SYN-ACK, como se ha explicado en la primera fila. |
Paquete IP de más de 1600 bytes | Google Cloud elimina el paquete y envía un mensaje Fragmentation Needed (ICMP sobre IPv4) o Packet Too Big (ICMPv6) tanto cuando el bit DF está activado como cuando está desactivado. |
Comunicación con APIs y servicios de Google
Las VMs que usen cualquier tamaño de MTU de red VPC válido pueden enviar paquetes a las APIs y los servicios de Google, incluido el uso del acceso privado de Google y de 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 las APIs y los servicios de Google mediante el acceso privado a Google para hosts locales.
El tráfico a las APIs y los servicios de Google que se describe en esta sección se implementa mediante Google Front Ends (GFEs). Estos GFE usan MTUs fijos no configurables. El tráfico de Google Cloud a las APIs y los servicios de Google siempre usa el protocolo TCP: si una VM se conecta a las APIs y los servicios de Google desde una red VPC cuyo MTU no coincide con el MTU de GFE, el tamaño del segmento se negocia mediante el anuncio de MSS de TCP, tal como se describe en MTUs no coincidentes, fijación de MSS y descubrimiento de MTU de ruta.
Origen del paquete | Destino del paquete |
---|---|
Cualquier dirección IPv4 interna: dirección IPv4 interna principal o dirección IPv4 interna de un intervalo de IPs de alias 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 el tráfico de salida, convirtiendo una dirección IPv4 interna principal de origen en una dirección IPv4 externa de origen especificada en la configuración de acceso. |
|
Dirección IPv6 externa o interna de máquinas virtuales de doble pila o solo IPv6 |
|
Comunicación a través de túneles de Cloud VPN
Cloud VPN tiene un MTU de pasarela para los paquetes encapsulados y un MTU de carga útil para los paquetes antes y después del encapsulado.
Para consultar los valores exactos de la MTU de la carga útil y otra información sobre la MTU de Cloud VPN, consulta la sección Consideraciones sobre la MTU de la documentación de Cloud VPN.
Comunicación a través de vinculaciones de Cloud Interconnect (VLAN)
Le recomendamos que utilice el mismo MTU para todas las vinculaciones de VLAN que estén conectadas a la misma red de VPC y que defina el MTU de la red de VPC con el mismo valor. Para obtener información sobre las MTUs de las vinculaciones de VLAN de Cloud Interconnect, consulta MTU de Cloud Interconnect.
Compatibilidad con tramas jumbo
En la siguiente tabla se resume la compatibilidad con tramas gigantes de los productos y las funciones de Google Cloud:
Producto o función | Compatibilidad con tramas jumbo |
---|---|
Compute Engine | Sí |
Cloud Interconnect | Sí |
Cloud VPN | No |
APIs de Google | No |
Máquinas virtuales y ajustes de MTU
Como práctica recomendada, haz que la MTU de la NIC de una VM coincida con la MTU de la red de VPC a la que está conectada la NIC:
El MTU de cada NIC de una VM Linux basada en una imagen de SO pública se define automáticamente en el MTU de la red VPC correspondiente mediante la opción 26 de DHCP.
Cada MTU de NIC de una VM Windows basada en una imagen de SO pública se configura con un MTU fijo de
1,460
bytes. Si cambias la MTU de una red de VPC que contiene máquinas virtuales Windows basadas en imágenes de SO públicas, debes cambiar la configuración de MTU de una máquina virtual Windows.Si usas imágenes de SO invitado personalizadas, debes configurar las MTUs de NIC o verificar que el SO invitado acepta la MTU de la red de VPC mediante la opción 26 de DHCP.
Si una VM tiene varias interfaces de red, define el MTU de cada NIC en el MTU de la red de VPC correspondiente.
Si el MTU de una NIC debe ser diferente del MTU de la red de VPC, defina el MTU de la NIC en un valor inferior al MTU de la red de VPC. Reducir por la fuerza la MTU de la NIC es ventajoso en algunos casos de redes avanzadas.
Cambiar la MTU de una red de VPC
Si cambias la MTU de una red de VPC con máquinas virtuales en ejecución, ten en cuenta lo siguiente:
Si reduces la MTU de la red de VPC, debes detener e iniciar cada VM. Si reinicias una VM desde su sistema operativo invitado, no se actualizará su MTU.
Si aumentas la MTU de la red de VPC, las VMs que utilicen la red de VPC no aprovecharán el aumento de la MTU de la red de VPC hasta que se hayan detenido e iniciado. Hasta que se haya detenido y reiniciado cada VM, la VM seguirá usando el valor de MTU anterior (inferior).
Para obtener instrucciones, consulta Cambiar el ajuste de MTU de una red VPC.
GKE y ajustes de MTU
El valor de MTU seleccionado para una interfaz de Pod depende de la interfaz de red de contenedores (CNI) que usen los nodos del clúster y del valor de MTU de la VPC subyacente. Para obtener más información, consulta Pods.
El valor de MTU de la interfaz de Pod es 1460
o se hereda de la interfaz principal del nodo.
CNI | MTU | GKE Standard |
---|---|---|
kubenet | 1460 | Predeterminado |
kubenet (versión 1.26.1 de GKE y posteriores) |
Heredada | Predeterminado |
Calico | 1460 |
Se habilita mediante Para obtener más información, consulta el artículo Controlar la comunicación entre pods y servicios mediante políticas de red. |
netd | Heredada | Se habilita de una de las siguientes formas: |
GKE Dataplane V2 | Heredada |
Se habilita mediante Para obtener más información, consulta Usar GKE Dataplane V2. |
MTUs no coincidentes, ajuste de MSS y descubrimiento de MTU de la ruta
En esta sección se describe cómo gestionan los protocolos TCP y no TCP las MTUs que no coinciden.Protocolo TCP
El protocolo TCP gestiona las discrepancias de MTU automáticamente. Tanto el cliente como el servidor calculan individualmente sus propios valores de tamaño máximo de segmento (MSS) de 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 (MSS) de TCP efectivo del cliente: la mayor cantidad de datos transmisibles en un segmento de TCP enviado de un cliente a un servidor es el mínimo de los dos valores siguientes:
Valor del campo MSS del paquete SYN-ACK que recibe el cliente del 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 (MSS) de TCP efectivo del servidor: la mayor cantidad de datos transmisibles en un segmento de TCP enviado de un servidor a un cliente es el mínimo de los dos valores siguientes:
Valor del campo MSS del paquete SYN que recibe el servidor del cliente durante el establecimiento de la conexión TCP.
El 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.
Limitación de MSS de TCP
El ajuste 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 el ajuste de MSS siempre que envía paquetes a destinos fuera de una red de VPC.
Los túneles de Cloud VPN y las vinculaciones de VLAN de Cloud Interconnect también usan el ajuste de MSS. Para obtener más información, consulta Encapsulación y procesamiento de paquetes en la documentación de Cloud VPN y MTU de Cloud Interconnect.
Las redes de VPC no realizan el ajuste de MSS para los paquetes enrutados por los saltos siguientes dentro de una red de VPC, ya que el protocolo TCP es suficiente.
Protocolos no TCP
Otros protocolos, como UDP, requieren especial atención cuando se utilizan dos MTUs de redes de VPC diferentes. Es responsabilidad del sistema de envío emitir paquetes que se ajusten a la MTU de su interfaz de red, a la MTU de la interfaz de red del sistema receptor y a la MTU de todas las redes intermedias. Google Cloud No realiza la fragmentación de IP de los paquetes enrutados por los saltos siguientes dentro de una red de VPC.
Cuando un paquete IP es demasiado grande para enviarse (por ejemplo, cuando el paquete supera la MTU de la red VPC en la que se encuentra la NIC de la VM receptora), Google Cloud retira el paquete. Si el paquete tiene el bit DF
definido, Google Cloud también envía un mensaje Fragmentation Needed (ICMP sobre IPv4) o Packet Too Big (ICMPv6) al remitente.
Google Cloud envía un mensaje de fragmentación necesaria o paquete demasiado grande
en las siguientes circunstancias, incluso cuando el bit DF
está desactivado:
- Si el MTU de la red de VPC es inferior a 1600 bytes y el paquete que se envía supera el MTU de la red de VPC.
- Si el MTU de la red de VPC es de 1600 bytes o más y el paquete que se envía supera los 1600 bytes.
Los mensajes de fragmentación necesaria de ICMP o paquete demasiado grande son necesarios para que una VM que envía paquetes use detección de MTU de ruta (PMTUD). Para ilustrar cómo funciona PMTUD, vamos a ver el siguiente ejemplo con dos VMs en redes de VPC diferentes que están conectadas mediante el emparejamiento entre redes de VPC:
- La VM de envío tiene una NIC en una red de VPC cuya MTU es de 8896 bytes.
- La VM receptora tiene una NIC en una red de VPC cuya MTU es de 1460 bytes.
- La VM de envío emite un paquete IP de 8000 bytes cuyo bit No fragmentar (
DF
) está activado. Como el paquete es demasiado grande para enviarse a la VM receptora,Google Cloud envía un mensaje de fragmentación obligatoria o de paquete demasiado grande a la VM emisora. Este mensaje indica el tamaño máximo posible del paquete de IP que puede usar el remitente cuando intenta retransmitir paquetes para la conexión. - El sistema operativo de la VM emisora usa esta información para reducir el tamaño del paquete IP al enviar paquetes posteriores a la VM receptora.
PMTUD tiene los siguientes requisitos adicionales porque los paquetes Fragmentation Needed o Packet Too Big generados por PMTUD usan el protocolo ICMP y tienen orígenes que coinciden con el destino de un paquete original:
- Debes configurar reglas de cortafuegos de VPC de entrada o reglas en políticas de cortafuegos para que se permita ICMP (en el caso de IPv4) o ICMPv6 (en el caso de IPv6) desde fuentes que coincidan con los destinos de los paquetes originales. Para simplificar la configuración del cortafuegos, te recomendamos que permitas ICMP e ICMPv6 de todas las fuentes.
- Las reglas de reenvío del balanceador de carga de red interno de tipo pasarela y del reenvío de protocolos interno deben usar el protocolo
L3_DEFAULT
para que procesen tanto ICMP para PMTUD como el protocolo usado por el paquete original.
Siguientes pasos
- Para ver otro MTU en funcionamiento, consulta Crear y verificar una red con MTU de trama gigante.
- Crea una red de VPC con un MTU especificado.
- Cambia el ajuste de MTU de una red VPC.
Pruébalo
Si es la primera vez que utilizas Google Cloud, crea una cuenta para evaluar el rendimiento de VPC en situaciones reales. Los nuevos clientes también reciben 300 USD en crédito gratuito para ejecutar, probar y desplegar cargas de trabajo.
Probar VPC gratis