Interfaces de red múltiples

En esta página, se proporciona una descripción general de las múltiples interfaces de red para las instancias de Compute Engine. Las instancias con varias interfaces de red se denominan instancias con varias NIC.

Una interfaz de red de instancia se conecta a una red de nube privada virtual (VPC) y puede ser una interfaz de red virtual (vNIC) o una NIC dinámica, en la que una NIC dinámica es una subinterfaz secundaria de una vNIC principal. Las NIC virtuales de una instancia están respaldadas por una o más NIC físicas en el servidor host que ejecuta la instancia. Para obtener más información, consulta Tipos de interfaces de red.

Casos de uso

Las instancias de varias NIC son útiles en las siguientes situaciones:

  • Para conectarse a recursos en redes de VPC independientes: Las instancias con varias NIC pueden conectarse a recursos ubicados en diferentes redes de VPC que no están conectadas entre sí a través del intercambio de tráfico entre redes de VPC o el NCC.

    • Debido a que cada interfaz de una instancia con varias NIC se encuentra en una red de VPC separada, puedes usar cada interfaz para un propósito único. Por ejemplo, puedes usar algunas interfaces para enrutar paquetes entre redes de VPC que transportan tráfico de producción y otra interfaz para fines de administración o configuración.

    • En el SO invitado de cada instancia con varias NIC, debes configurar políticas de rutas y tablas de rutas locales.

  • Para enrutar paquetes entre redes de VPC: Se pueden usar instancias de varias NIC como próximos saltos para las rutas que conectan dos o más redes de VPC.

    • El software que se ejecuta dentro del SO invitado de una instancia con varias NIC puede realizar la inspección de paquetes, la traducción de direcciones de red (NAT) o alguna otra función de seguridad de red.

    • Cuando conectes redes de VPC con instancias multi-NIC, se recomienda configurar dos o más instancias multi-NIC y usarlas como backends para un balanceador de cargas de red de transferencia interno en cada red de VPC. Para obtener más información, consulta Casos de uso en la documentación de los balanceadores de cargas de red de transferencia internos como próximos saltos.

  • Para aumentar el ancho de banda total de la red de una instancia, las instancias con varias NIC admiten un mayor ancho de banda de la siguiente manera:

    • En algunos tipos de máquinas de Google Cloud, las instancias se respaldan con varias NIC físicas en el servidor host. Crear una instancia con varias vNIC, en la que cada vNIC usa una NIC física diferente, aumenta el ancho de banda de red total de la instancia. Para obtener más información, consulta Ancho de banda para varias interfaces de red en la misma red de VPC.

    • En la mayoría de los tipos de máquinas de Google Cloud, las instancias se respaldan con una sola NIC física en el servidor host, y cada NIC virtual usa la misma NIC física. Cuando las vNIC comparten una NIC física, agregar vNIC no aumenta el ancho de banda de la red.

También puedes usar instancias con varias NIC con interfaces de Private Service Connect para conectar redes de productor de servicios y consumidores en diferentes proyectos.

Tipos de interfaces de red

Consulta las siguientes secciones para obtener detalles sobre los tipos de interfaces de red enGoogle Cloud.

Interfaces de red de instancias

Las instancias de Compute Engine se conectan a las redes de VPC a través de interfaces de red que configuras, las cuales pueden ser vNIC o NIC dinámicas. Estas interfaces de red de instancias corresponden al recurso y la propiedad instances.networkInterfaces[] en la API de Compute Engine.

Para obtener más información sobre cada tipo de interfaz de red de instancias, consulta lo siguiente:

  • Interfaz de red virtual (vNIC): Es una interfaz de red definida por software que se expone al SO invitado de tu instancia y que permite que esta se conecte a redes de VPC. Cada instancia debe tener al menos una vNIC.

    • Solo puedes configurar vNICs cuando creas una instancia.

    • El nombre de una vNIC asignada por Google Cloud tiene el siguiente formato: nicN, como nic0. El nombre correspondiente asignado por el SO invitado depende del sistema operativo, como ens4 para Ubuntu.

    • Una vNIC puede ser de uno de los siguientes tipos, según la red de VPC asociada. Cada tipo corresponde a un controlador de red específico en el SO invitado:

      Para obtener información sobre qué tipos de máquinas admiten qué tipos de NIC virtuales, consulta la comparación de series de máquinas.

  • NIC dinámica: Es una secundaria de una vNIC principal que se implementa como una subinterfaz en el SO invitado de tu instancia.

    • Puedes configurar NIC dinámicas cuando creas una instancia o agregarlas más adelante.

    • El nombre de una NIC dinámica asignada por Google Cloud tiene el siguiente formato: nicN.VLAN_ID, como nic0.2. El nombre correspondiente asignado por el SO invitado depende del sistema operativo. Por ejemplo, si usas el agente invitado para administrar NIC dinámicas en Ubuntu, el nombre podría ser a-gcp.ens4.2.

    • Las NIC dinámicas no son compatibles con las redes de VPC que tienen un perfil de red de RDMA.

    Para obtener más información, consulta NIC dinámicas.

Detalles de la NIC dinámica

Si tu caso de uso requiere alguna de las siguientes opciones, usa NIC dinámicas. Asegúrate de revisar también las propiedades y las limitaciones de las NIC dinámicas.

  • Necesitas agregar o quitar interfaces de red a instancias existentes. No es necesario reiniciar ni volver a crear la instancia para agregar o quitar NIC dinámicas.

  • Necesitas más interfaces de red que la cantidad máxima de vNIC. En la mayoría de los tipos de máquinas de Google Cloud, la cantidad máxima es 10. Sin embargo, puedes configurar hasta 16 interfaces en total con NIC dinámicas. Para obtener más información, consulta Cantidad máxima de interfaces de red.

  • Debes configurar instancias de equipos físicos de Compute Engine con varias NIC, que solo tienen una vNIC.

Propiedades de las NIC dinámicas

Consulta la siguiente información sobre las propiedades de las NIC dinámicas:

  • Las NIC dinámicas son interfaces de VLAN que usan el formato de paquete estándar IEEE 802.1Q. Ten en cuenta las siguientes consideraciones:

    • El ID de VLAN de una NIC dinámica debe ser un número entero entre 2 y 255.
    • El ID de VLAN de una NIC Dinámica debe ser único dentro de una vNIC superior. Sin embargo, las NIC dinámicas que pertenecen a diferentes vNICs principales pueden usar el mismo ID de VLAN.

  • Google Cloud usa el siguiente formato para el nombre de un NIC dinámico: nicNUMBER.VLAN_ID, donde

    • nicNUMBER es el nombre de la vNIC principal, como nic0.
    • VLAN_ID es el ID de VLAN que estableciste, como 4.

    Un ejemplo de nombre de NIC dinámica es nic0.4.

  • Crear una instancia con NIC dinámicas o agregar NIC dinámicas a una instancia existente requiere pasos adicionales para instalar y administrar las interfaces de VLAN correspondientes en el SO invitado. Puedes usar uno de los siguientes métodos:

    • Configura la administración automática de NIC dinámicos con el agente invitado.

    • Configura el SO invitado de forma manual.

    Para obtener más información, consulta Configura el SO invitado para las NIC dinámicas.

  • Las NIC dinámicas comparten el ancho de banda de su vNIC principal. Para evitar que alguna de las interfaces de red consuma todo el ancho de banda, debes crear una política de tráfico específica de la aplicación en el SO invitado para priorizar o distribuir el tráfico, por ejemplo, con Linux Traffic Control (TC).

  • Las NIC dinámicas comparten las mismas colas de recepción y transmisión que su vNIC principal. Para configurar una interfaz de red para que use diferentes colas de recepción y transmisión, usa vNIC en lugar de NIC dinámicas.

  • El tipo de pila de una NIC dinámica puede ser igual o diferente al de su vNIC principal. Por ejemplo, puedes crear NIC dinámicas de solo IPv6 y de pila doble en una vNIC principal de solo IPv4.

Limitaciones de las NIC dinámicas

Consulta las siguientes limitaciones de las NIC dinámicas:

NIC físicas

Una NIC física es el componente de hardware instalado directamente en el servidor host en el que se ejecuta una instancia. Según el tipo de máquina de tu instancia, las NIC virtuales de la instancia se asignan a una o más NIC físicas en un servidor host de la siguiente manera:

  • Instancias respaldadas por una NIC física: En la mayoría de los tipos de máquinas, las instancias se ejecutan en un servidor host con una sola NIC física. En una instancia determinada, todas las NIC virtuales de la instancia se asignan a la única NIC física.

  • Instancias respaldadas por varias NIC físicas: Para un conjunto limitado de tipos de máquinas, como los tipos de máquinas C4N y los tipos de máquinas con GPU, las instancias se ejecutan en un servidor host con varias NIC físicas. En una instancia determinada, Compute Engine asigna las vNIC de la instancia a diferentes NIC físicas.

    • Las instancias respaldadas por varias NIC físicas admiten casos de uso, como un mayor ancho de banda de red y la comunicación de GPU a GPU a través de una red de VPC de RoCE. Para obtener más información, consulta Compatibilidad de red para instancias C4N y Redes y máquinas con GPU.

    • Cuando creas la instancia, Compute Engine asigna cada vNIC a una NIC física única, hasta el recuento total de NIC físicas del tipo de máquina de la instancia.

    • Para comprender la compatibilidad con varias NICs físicas, consulta la documentación de una serie de máquinas determinada. Si corresponde, la tabla de tipos de máquinas incluye una columna titulada Cantidad de NIC físicas. Por ejemplo, consulta Tipos de máquinas C4N.

Además, en la mayoría de los tipos de máquinas, las instancias comparten un servidor host con otras instancias. Las instancias que comparten un servidor host también comparten su NIC física o conjunto de NIC físicas. Sin embargo, para algunos tipos de máquinas, como los tipos de máquinas bare metal o los tipos de máquinas H3 y H4D, una sola instancia ocupa un servidor host completo.

Especificaciones

Las siguientes especificaciones se aplican a las instancias con varias interfaces de red:

  • Instancias e interfaces de red: Cada instancia tiene una interfaz nic0. La cantidad máxima de interfaces de red varía según el tipo de máquina de la instancia.

    • Cada interfaz tiene un tipo de pila asociado, que determina los tipos de pila de subred y las versiones de direcciones IP admitidos. Para obtener más información, consulta Tipo de pila y direcciones IP.

  • Requisitos de red y subred: Cada interfaz de red debe usar una subred única en una red de VPC.

    • Se admite la conexión de interfaces de red a subredes en diferentes redes de VPC.

    • Se admite la conexión de interfaces de red a diferentes subredes en la misma red de VPC en los siguientes casos:

    • Debe existir una red de VPC y una subred antes de que puedas crear una instancia cuya interfaz de red use la red y la subred. Para obtener más información sobre la creación de redes y subredes, consulta Crea y administra redes de VPC.

    • No se admite la vinculación de interfaces de red con la agregación de vínculos. Para obtener detalles sobre cómo varias interfaces de red en la misma red de VPC afectan el ancho de banda, consulta Ancho de banda para varias interfaces de red en la misma red de VPC.

  • Proyecto de la instancia y las subredes: En el caso de las instancias con varias NIC en proyectos independientes, cada interfaz de red debe usar una subred ubicada en el mismo proyecto que la instancia.

  • Consideraciones sobre el reenvío de IP, la MTU y el enrutamiento: Las instancias con varias NIC requieren una planificación cuidadosa para las siguientes opciones de configuración específicas de la instancia y la interfaz:

    • La opción de reenvío de IP se puede configurar para cada instancia y se aplica a todas las interfaces de red. Para obtener más información, consulta Habilita el reenvío de IP para instancias.

    • Cada interfaz de red puede usar una unidad de transmisión máxima (MTU) única que coincida con la MTU de la red de VPC asociada. Para obtener más información, consulta Unidad de transmisión máxima.

    • Cada instancia recibe una ruta predeterminada con la opción 121 de DHCP, como se define en la RFC 3442. La ruta predeterminada está asociada a nic0. A menos que se configure manualmente de otra manera, cualquier tráfico que salga de una instancia hacia un destino que no sea una subred conectada de forma directa lo hará a través de la ruta predeterminada en nic0.

      En los sistemas Linux, puedes configurar reglas y rutas personalizadas dentro del SO invitado con el archivo /etc/iproute2/rt_tables y los comandos ip rule y ip route. Para obtener más información, consulta la documentación del SO invitado. Para ver un ejemplo, consulta el siguiente instructivo: Configura el enrutamiento para una interfaz adicional.

Reglas para varias interfaces de red en la misma red de VPC

Compute Engine aplica todas las siguientes reglas cuando dos o más interfaces de red de una sola instancia usan la misma red de VPC:

  • Subred única: Cada interfaz de red debe estar conectada a una subred única.

  • Se deben adjuntar vNIC adicionales a la red que contiene nic0: Se pueden adjuntar dos o más vNIC a la misma red de VPC solo si esa red también contiene la vNIC nic0. Por ejemplo, nic0, nic1 y nic2 se pueden adjuntar a subredes únicas en la misma red de VPC, pero nic1 y nic2 no se pueden adjuntar a la misma red de VPC si nic0 no está adjunto a esa red.

  • Una red que contiene una NIC dinámica y, al menos, otra NIC debe contener la vNIC principal de cada NIC dinámica: Por ejemplo:

    • Para adjuntar las NIC dinámicas nic1.6 y nic1.7 a la misma red de VPC, también debes adjuntar su vNIC principal, nic1, a esa red de VPC.

    • Para adjuntar la NIC dinámica nic1.6 y la vNIC nic2 a la misma red de VPC, también debes adjuntar las vNIC nic1 y nic0 a esa red de VPC. Se requiere adjuntar nic1 porque nic1 es la vNIC principal de la NIC dinámica nic1.6. Se requiere adjuntar nic0 porque la red contiene varias vNIC.

    • Para adjuntar las NIC dinámicas nic2.5 y nic3.6 a la misma red de VPC, también debes adjuntar todas las siguientes vNICs a esa misma red de VPC: nic0, nic2 y nic3. Se requiere adjuntar las vNIC nic2 y nic3 porque son las vNIC principales de las NIC dinámicas nic2.5 y nic3.6. Se requiere adjuntar nic0 porque la red contiene varias vNIC.

  • Red única para cada interfaz de Private Service Connect: No se pueden adjuntar dos o más interfaces de red a la misma red de VPC si una de las interfaces de red usa un adjunto de red en esa red.

Ancho de banda para varias interfaces de red en la misma red de VPC

Varias vNIC en la misma red de VPC afectan el ancho de banda de la red según estas reglas:

  • En el caso de las instancias respaldadas por una NIC física, adjuntar dos o más vNIC a la misma red de VPC nunca aumenta el ancho de banda de la red.

  • En el caso de las instancias respaldadas por varias NIC físicas, adjuntar dos o más vNIC a la misma red de VPC aumenta el ancho de banda de la red cuando Compute Engine asigna las vNIC a diferentes NIC físicas.

Independientemente del tipo de máquina, agregar NIC dinámicas a una instancia no aumenta el ancho de banda, ya que una NIC dinámica usa el ancho de banda de su vNIC principal.

Tipos de pila y direcciones IP

Cuando creas una interfaz de red, especificas uno de los siguientes tipos de pila de interfaz:

  • Solo IPv4
  • Pila doble
  • Solo IPv6

Una instancia de VM puede tener interfaces de red con diferentes tipos de pila.

En la siguiente tabla, se describen los tipos de pila de subred admitidos y los detalles de la dirección IP para cada tipo de pila de interfaz:

Interfaz Subred solo IPv4 Subred de pila doble Subred solo IPv6 Detalles de la dirección IP
Solo IPv4 (pila única) Solo direcciones IPv4. Consulta los detalles de la dirección IPv4.
IPv4 e IPv6 (pila doble) Direcciones IPv4 e IPv6 Consulta los detalles de la dirección IPv4 y los detalles de la dirección IPv6.
Solo IPv6 (pila única) Solo direcciones IPv6. Consulta Detalles de la dirección IPv6.

Cómo cambiar el tipo de pila de la interfaz de red

Puedes cambiar el tipo de pila de una interfaz de red de la siguiente manera:

  • Puedes convertir una interfaz solo IPv4 en una de pila doble si la subred de la interfaz es de pila doble o si detienes la instancia y asignas la interfaz a una subred de pila doble.

  • Puedes convertir una interfaz de pila doble a solo IPv4.

No puedes cambiar el tipo de pila de una interfaz solo IPv6. Las interfaces solo IPv6 solo se admiten cuando se crean instancias.

Detalles de la dirección IPv4

Cada interfaz de red de solo IPv4 o de pila doble recibe una dirección IPv4 interna principal. De forma opcional, cada interfaz admite rangos de IP de alias y una dirección IPv4 externa. A continuación, se indican las especificaciones y los requisitos de IPv4:

  • Dirección IPv4 interna principal: Compute Engine asigna a la interfaz de red una dirección IPv4 interna principal del rango de direcciones IPv4 principal de la subred de la interfaz. DHCP asigna la dirección IPv4 interna principal.

    • Puedes controlar qué dirección IPv4 interna principal se asigna configurando una dirección IPv4 interna estática o especificando una dirección IPv4 interna efímera personalizada.

    • En una red de VPC, la dirección IPv4 interna principal de cada interfaz de red de VM es única.

  • Rangos de IP de alias: De manera opcional, puedes asignar a la interfaz uno o más rangos de IP de alias. Cada rango de IP de alias puede provenir del rango de direcciones IPv4 principal o de un rango de direcciones IPv4 secundario de la subred de la interfaz.

    • Dentro de una red de VPC, el rango de IP de alias de cada interfaz debe ser único.

  • Dirección IPv4 externa: De forma opcional, puedes asignar a la interfaz una dirección IPv4 externa efímera o reservada. Google Cloud garantiza la unicidad de cada dirección IPv4 externa.

Detalles de la dirección IPv6

Compute Engine asigna a cada interfaz de red de pila doble o solo IPv6 un rango de direcciones IPv6 /96 del rango de direcciones IPv6 /64 de la subred de la interfaz:

  • Si el rango de direcciones IPv6 de /96 es interno o externo, depende del tipo de acceso de IPv6 de la subred de la interfaz. Google Cloud garantiza la unicidad de cada rango de direcciones IPv6 internas y externas. Para obtener más información, consulta las especificaciones de IPv6.

    • Si una instancia necesita un rango de direcciones IPv6 interno y un rango de direcciones IPv6 externo, debes configurar dos interfaces de pila doble, dos interfaces de solo IPv6 o una interfaz de pila doble y una interfaz de solo IPv6. La subred que usa una interfaz debe tener un rango de direcciones IPv6 externas, y la subred que usa la otra interfaz debe tener un rango de direcciones IPv6 internas.

  • La primera dirección IPv6 (/128) se configura en la interfaz a través de DHCP. Para obtener más información, consulta Asignación de direcciones IPv6.

  • Puedes controlar qué rango de direcciones IPv6 /96 se asigna configurando un rango de direcciones IPv6 interno o externo estático. Para las direcciones IPv6 internas, puedes especificar una dirección IPv6 interna efímera personalizada.

Si conectas una instancia a varias redes con direcciones IPv6, instala la versión 20220603.00 de google-guest-agent o una posterior. Para obtener más información, consulta No puedo conectarme a la dirección IPv6 de una interfaz secundaria.

Cantidad máxima de interfaces de red

Para la mayoría de los tipos de máquinas, la cantidad máxima de interfaces de red que puedes conectar a una instancia se ajusta según la cantidad de CPU virtuales, como se describe en las siguientes tablas.

Las siguientes son excepciones específicas de la máquina:

  • Las instancias de Bare Metal de Compute Engine admiten una sola vNIC.

  • La cantidad máxima de vNIC es diferente para algunos tipos de máquinas optimizados para aceleradores, como A3, A4 y A4X. Para obtener más información, consulta Familia de máquinas optimizadas para aceleradores.

Números de interfaz máximos

Usa la siguiente tabla para determinar cuántas interfaces de red pueden adjuntarse a una instancia.

Número de CPU virtuales Cantidad máxima de vNICs Cantidad máxima de NIC dinámicas Cantidad máxima de interfaces de red
(NIC dinámicas y virtuales)
2 o menos 2 1 2
4 4 3 4
6 6 5 6
8 8 7 8
10 10 9 10
12 10 10 11
14 10 11 12
16 10 12 13
18 10 13 14
20 10 14 15
22 o más 10 15 16

Fórmulas de referencia

En la siguiente tabla, se proporcionan las fórmulas que se usan para calcular la cantidad máxima de interfaces de red para una instancia. La fórmula depende de la cantidad de CPU virtuales.

Cantidad de CPU virtuales (X) Cantidad máxima de vNICs Cantidad máxima de NIC dinámicas Cantidad máxima de interfaces de red
(NIC dinámicas y virtuales)
X=1 2 1 2
2 ≤ X ≤ 10 X (X-1) X
X ≥ 12 10 min(15, (X-10)/2 + 9) min(16, (X-10)/2 + 10)

Ejemplos de distribuciones de NIC dinámicas

No es necesario que distribuyas las NIC dinámicas de manera uniforme entre las vNIC. Sin embargo, es posible que desees una distribución uniforme, ya que las NIC dinámicas comparten el ancho de banda de su vNIC principal.

Una instancia debe tener al menos una vNIC. Por ejemplo, una instancia que tiene 2 CPU virtuales puede tener una de las siguientes configuraciones:

  • 1 vNIC
  • 2 vNIC
  • 1 vNIC y 1 NIC dinámica

En las siguientes tablas, se proporcionan ejemplos de configuraciones que distribuyen de manera uniforme las NIC dinámicas entre las vNICs y, al mismo tiempo, usan la cantidad máxima de interfaces de red para una cantidad determinada de CPU virtuales.

2 CPU virtuales y 2 NIC

En la siguiente tabla, se proporcionan ejemplos para una instancia con 2 CPU virtuales que muestran cuántas NIC dinámicas puedes tener para una cantidad determinada de NIC virtuales.

Número de CPU virtuales Cantidad de vNIC Cantidad de NIC dinámicas por vNIC Cantidad total de interfaces de red (NIC virtuales + NIC dinámicas)
2 1 1 2
2 0

4 CPU virtuales y 4 NICs

En la siguiente tabla, se proporcionan ejemplos para una instancia con 4 CPU virtuales que muestran cuántas NIC dinámicas puedes tener para una cantidad determinada de NIC virtuales.

Número de CPU virtuales Cantidad de vNIC Cantidad de NIC dinámicas por vNIC Cantidad total de interfaces de red (NIC virtuales + NIC dinámicas)
4 1 3 4
2 1
4 0

8 CPU virtuales y 8 NICs

En la siguiente tabla, se proporcionan ejemplos para una instancia con 8 CPU virtuales que muestran cuántas NIC dinámicas puedes tener para una cantidad determinada de NIC virtuales.

Número de CPU virtuales Cantidad de vNIC Cantidad de NIC dinámicas por vNIC Cantidad total de interfaces de red (NIC virtuales + NIC dinámicas)
8 1 7 8
2 3
4 1
8 0

14 CPU virtuales y 12 NIC

En la siguiente tabla, se proporcionan ejemplos para una instancia con 12 CPU virtuales que muestran cuántas NIC dinámicas puedes tener para una cantidad determinada de NIC virtuales.

Número de CPU virtuales Cantidad de vNIC Cantidad de NIC dinámicas por vNIC Cantidad total de interfaces de red (NIC virtuales + NIC dinámicas)
14 1 11 12
2 5
4 2
6 1

22 CPU virtuales y 16 NIC

En la siguiente tabla, se proporcionan ejemplos para una instancia con 22 CPU virtuales que muestran cuántas NIC dinámicas puedes tener para una cantidad determinada de NIC virtuales.

Número de CPU virtuales Cantidad de vNIC Cantidad de NIC dinámicas por vNIC Cantidad total de interfaces de red (NIC virtuales + NIC dinámicas)
22 1 15 16
2 7
4 3
8 1

Interacciones de productos

En esta sección, se describen las interacciones entre las instancias con varias NIC y otros productos y funciones en Google Cloud.

VPC compartida

Excepto en el caso de las interfaces de Private Service Connect, la relación entre la subred y el proyecto de una instancia de varias NIC en un proyecto host o de servicio de VPC compartida es la siguiente:

  • Cada interfaz de red de una instancia con varias NIC ubicada en un proyecto host de VPC compartida debe usar una subred de una red de VPC compartida en el proyecto host.

  • Cada interfaz de red de una instancia multi-NIC ubicada en un proyecto de servicio de VPC compartida puede usar cualquiera de las siguientes opciones:

    • Es una subred de una red de VPC en el proyecto de servicio.
    • Es una subred de una red de VPC compartida en el proyecto host.

Para obtener más información sobre la VPC compartida, consulta los siguientes recursos:

DNS interno de Compute Engine

Compute Engine crea registros A y PTR de nombres de DNS internos solo para la dirección IPv4 interna principal de la interfaz de red nic0 de una instancia. Compute Engine no crea registros DNS internos para ninguna dirección IPv4 o IPv6 asociada a una interfaz de red diferente de nic0.

Para obtener más información, consulta DNS interno de Compute Engine.

Rutas estáticas

Las rutas estáticas se pueden limitar a instancias específicas con etiquetas de red. Cuando una etiqueta de red se asocia a una instancia, la etiqueta se aplica a todas las interfaces de red de la instancia. Por lo tanto, agregar o quitar una etiqueta de red de una instancia puede cambiar las rutas estáticas que se aplican a cualquiera de las interfaces de red de la instancia.

Cuando creas una ruta estática cuyo siguiente salto es una instancia, sucede lo siguiente:

  • Si especificas una instancia de próximo salto por nombre y zona (next-hop-instance), los paquetes se entregan solo a la vNIC nic0 de la instancia, y la vNIC nic0 debe estar adjunta a la misma red de VPC en la que se crea la ruta estática.

  • Si especificas una instancia de próximo salto por dirección (next-hop-address), los paquetes se pueden entregar a una vNIC o NIC dinámica específica en la misma VPC en la que se crea la ruta estática.

Para obtener más información, consulta Próximos saltos y características.

Balanceadores de cargas

En la siguiente tabla, se describen las interfaces de red de instancias que cumplen con las condiciones necesarias para recibir tráfico balanceado por carga, incluidas las situaciones en las que varias interfaces están conectadas a la misma red de VPC según las reglas para interfaces de red múltiples en la misma red de VPC. Una interfaz de red que cumple con las condiciones necesarias del balanceador de cargas es una interfaz de destino del balanceador de cargas. Una instancia tiene exactamente una interfaz de destino del balanceador de cargas en cada red de VPC que usa, incluso si tiene dos o más interfaces en la misma red.

Interfaz Condiciones para recibir tráfico con balanceo de cargas
nic0 vNIC

Se puede conectar a una red de VPC con o sin otras interfaces de red:

  • Cuando varias vNIC comparten una red de VPC común con la vNIC nic0, solo nic0 puede recibir tráfico balanceado.
  • Cuando una o más NIC dinámicas comparten una red de VPC común con la vNIC nic0, solo nic0 puede recibir tráfico balanceado por carga.
vNIC no nic0

Debe estar adjunta a una red de VPC sin ninguna otra vNIC:

  • Se puede adjuntar a una red de VPC por sí solo.
  • Cuando una o más NIC dinámicas comparten una red de VPC común con una vNIC principal, solo la vNIC principal puede recibir tráfico balanceado por carga.
NIC dinámica

Debe conectarse a una red de VPC única sin otras interfaces de red (ni otras vNIC ni otras NIC dinámicas).

En las siguientes tablas, se detallan las configuraciones del balanceador de cargas y del grupo de backends que puedes usar para enviar tráfico a una interfaz de destino del balanceador de cargas.

Interfaces de destino del balanceador de cargas para balanceadores de cargas de aplicaciones y balanceadores de cargas de red de proxy

Tipo de grupo de backend
en un servicio de backend de un balanceador de cargas de aplicaciones
o un balanceador de cargas de red del proxy		 Interfaz de destino del balanceador de cargas
nic0 vNIC vNIC no nic0 NIC dinámica
Grupo de instancias
GCE_VM_IP_PORT NEG

Interfaces de destino del balanceador de cargas para balanceadores de cargas de red de transferencia

Para balanceadores de cargas de red de transferencia internos:

Tipo de grupo de backends
en un servicio de backend de un balanceador de cargas de red de transferencia interno		 Interfaz de destino del balanceador de cargas
nic0 vNIC vNIC no nic0 NIC dinámica
Grupo de instancias
GCE_VM_IP NEG

Para balanceadores de cargas de red de transferencia externos:

Tipo de backend
de un balanceador de cargas de red de transferencia externo		 Interfaz de destino del balanceador de cargas
nic0 vNIC vNIC no nic0 NIC dinámica
Grupo de instancias
en un servicio de backend de un balanceador de cargas de red de transferencia externo regional basado en servicios de backend o un balanceador de cargas de red de transferencia externo global
GCE_VM_IP NEG
en un servicio de backend de un balanceador de cargas de red de transferencia externo regional basado en servicios de backend o un balanceador de cargas de red de transferencia externo global
Grupo de destino
de un balanceador de cargas de red de transferencia externo regional basado en grupos de destino

GCE_VM_IP_PORT Interfaces de red y backends de NEG zonales

Cuando creas un NEG zonal nuevo con extremos GCE_VM_IP_PORT, debes especificar una zona, un puerto predeterminado, una red de VPC y una subred en esa red. Ninguno de estos atributos se puede cambiar después de que se crea el NEG zonal.

La subred del NEG debe estar en la misma región que la zona del NEG. Si la red del NEG es una red de VPC en modo automático, puedes omitir la especificación de la subred del NEG. Cuando no especificas una subred, Google Cloud establece la subred del NEG en la subred creada automáticamente en la región que contiene la zona del NEG.

Los NEG zonales con extremos GCE_VM_IP_PORT aplican las siguientes reglas para agregar extremos:

  • Si solo especificas un nombre de instancia para el extremo, la instancia debe estar en la misma zona que el NEG y tener una interfaz de destino del balanceador de cargas en la subred del NEG. La dirección IP del extremo se establece en la dirección IPv4 interna principal de la interfaz de destino del balanceador de cargas, y el puerto del extremo se establece en el puerto predeterminado del NEG.

  • Si especificas un nombre de instancia y una dirección IP, o un nombre de instancia, una dirección IP y la información del puerto para el extremo, la instancia debe estar en la misma zona que el NEG, y se debe cumplir con lo siguiente:

    • Si especificas una dirección IPv4, esta debe ser una dirección IPv4 interna principal o una dirección IPv4 de un rango de IP de alias asociado a una interfaz de destino del balanceador de cargas en la subred del NEG.

    • Si especificas una dirección IPv6, esta debe ser una sola dirección IPv6 del rango de direcciones IPv6 /96 de la interfaz de destino del balanceador de cargas en la subred del NEG.

    • El puerto del extremo es el que especificas. Si no especificas un puerto, el puerto del extremo se establece en el puerto predeterminado del NEG.

GCE_VM_IP Interfaces de red y backends de NEG zonales

Cuando creas un NEG zonal nuevo con extremos GCE_VM_IP, debes especificar una zona, una red de VPC y una subred en esa red. Ninguno de estos atributos se puede cambiar después de que se crea el NEG zonal.

La subred del NEG debe estar en la misma región que la zona del NEG. Si la red del NEG es una red de VPC en modo automático, puedes omitir la especificación de la subred del NEG. Cuando no especificas una subred, Google Cloud establece la subred del NEG en la subred creada automáticamente en la región que contiene la zona del NEG.

Los NEG zonales con extremos GCE_VM_IP aplican las siguientes reglas para agregar extremos:

  • Si solo especificas un nombre de instancia para el extremo, la instancia debe estar en la misma zona que el NEG y tener una interfaz de destino del balanceador de cargas en la subred del NEG.

  • Si especificas un nombre de instancia y una dirección IP para agregar un extremo, la instancia debe estar en la misma zona que el NEG, y la dirección IP debe ser la dirección IPv4 interna principal de una interfaz de destino del balanceador de cargas en la subred del NEG.

Dado que una instancia solo puede tener una NIC en la subred del NEG, solo puede tener un extremo GCE_VM_IP por NEG zonal, y el extremo siempre se identifica con la dirección IPv4 interna principal de la interfaz de destino del balanceador de cargas. Las direcciones IP de destino reales de los paquetes con balanceo de cargas coinciden con una regla de reenvío del balanceador de cargas de red de transferencia.

Interfaces de red y backends de grupos de instancias

La red de VPC y la subred asociadas con un grupo de instancias se configuran de forma implícita con una de las siguientes acciones:

  • En los grupos de instancias administrados (MIG), la subred y la red de VPC del grupo de instancias se configuran en la subred y la red de la vNIC nic0 definidas en la plantilla de instancias.

  • En los grupos de instancias no administrados, la red de VPC y la subred del grupo de instancias se establecen en la red y la subred de la vNIC nic0 de la primera instancia que agregas al grupo de instancias no administrado. No puedes cambiar la red de VPC ni la subred del grupo de instancias más adelante, incluso si quitas la primera instancia que agregaste al grupo.

Google Cloud aplica las siguientes reglas cuando se agregan instancias a un grupo de instancias no administrado después de que se hayan establecido la red de VPC y la subred del grupo de instancias:

  • La vNIC nic0 de una instancia que se agregará a un grupo de instancias debe coincidir con la red y la subred del grupo de instancias. Esta regla se aplica porque la interfaz de red virtual nic0 siempre es una interfaz de destino del balanceador de cargas.

  • Para cada interfaz de destino del balanceador de cargas de una instancia que se agregará a un grupo de instancias, si la interfaz de destino del balanceador de cargas está adjunta a una red de VPC a la que están adjuntas las interfaces de destino del balanceador de cargas de las instancias existentes, tanto las interfaces de destino del balanceador de cargas nuevas como las existentes deben usar la misma subred.

Reglas de firewall

El conjunto de reglas de firewall (desde las políticas de firewall jerárquicas, las políticas de firewall de red globales, las políticas de firewall de red regionales y las reglas de firewall de VPC) es único para cada interfaz de red. Asegúrate de que cada red tenga reglas de firewall adecuadas para permitir el tráfico desde y hacia una instancia de varias NIC. Para determinar qué reglas de firewall se aplican a una interfaz de red y la fuente de cada regla, consulta Obtén reglas de firewall efectivas para una interfaz de VM.

Las reglas de firewall se pueden limitar a instancias de VM específicas con etiquetas de red o etiquetas seguras, las cuales se aplican a todas las interfaces de red de una instancia. Para obtener más información, consulta Comparación de etiquetas seguras y etiquetas de red.

Problemas conocidos

En esta sección, se describen los problemas conocidos relacionados con el uso de varias interfaces de red en Google Cloud.

Errores de creación y disminución del rendimiento cuando se usan NIC dinámicas con instancias de GPU

Las NIC dinámicas no son compatibles con el uso de instancias de GPU. Si creas una instancia con GPU con NIC dinámicas o agregas NIC dinámicas a una instancia con GPU existente, es posible que se produzcan los siguientes problemas:

  • La operación falla con un error como el siguiente:

    Internal error. Please try again or contact Google Support. (Code: 'CODE')

  • La operación se realiza correctamente, pero la instancia experimenta una disminución del rendimiento, como un ancho de banda de red significativamente menor.

Estos problemas se producen porque la configuración de la NIC dinámica genera errores cuando Compute Engine intenta distribuir las NIC virtuales de la instancia en las NIC físicas del servidor host.

Se descartan paquetes cuando se usan NIC dinámicas con rangos de IP de alias, reenvío de protocolos o balanceadores de cargas de red de transferencia.

El agente invitado agrega automáticamente rutas locales en las siguientes situaciones para las vNIC, pero no para las NIC dinámicas:

  • Cuando configuras un rango de IP de alias, el agente invitado crea una ruta local para el rango de IP de alias.
  • Cuando creas una instancia de destino que hace referencia a una instancia de procesamiento para el reenvío de protocolos, el agente invitado crea una ruta local para la dirección IP de la regla de reenvío asociada.
  • Cuando agregas un backend a un balanceador de cargas de red de transferencia, el agente invitado crea una ruta local para la dirección IP de la regla de reenvío asociada.

Debido a que no se agregan las rutas locales para las NIC dinámicas, es posible que estas experimenten pérdida de paquetes.

Para resolver este problema, agrega las direcciones IP de forma manual de la siguiente manera:

  1. Conéctate a la instancia con SSH.

  2. Si configuras un rango de alias de IP, haz lo siguiente. En caso contrario, puede omitir este paso.

    1. En /etc/default/instance_configs.cfg, asegúrate de que el parámetro de configuración ip_aliases esté establecido en true.

    2. Si el parámetro de configuración ip_aliases está establecido en false, modifica el archivo para cambiarlo a true y, luego, reinicia el agente invitado:

      systemctl restart google-guest-agent

  3. Configura una ruta local para el rango de IP del alias o la dirección IP de la regla de reenvío con el siguiente comando:

    ip route add to local IP_ADDRESS dev DYNAMIC_NIC_DEVICE_NAME proto 66

    Reemplaza lo siguiente:

    • IP_ADDRESS: Es el rango de IP alias o la dirección IP de la regla de reenvío para la que deseas agregar una ruta local.
    • DYNAMIC_NIC_DEVICE_NAME: Es el nombre del dispositivo de la NIC dinámica para la que deseas agregar una ruta local. Por ejemplo, a-gcp.ens4.3

Problemas con la instalación y la administración de NIC dinámicas en las versiones del agente invitado de 20250901.00 a 20251120.01

Si configuras la administración automática de NIC dinámicas y tu instancia ejecuta el agente invitado en una versión entre 20250901.00 y 20251120.01, es posible que encuentres los siguientes problemas:

  • El agente de invitado no puede instalar ni administrar NIC dinámicas en el SO invitado de tu instancia.

    Es posible que recibas un error que incluya Cannot find device cuando ejecutes comandos en el SO invitado que hagan referencia a NIC dinámicas.

  • Si se borran varias NIC dinámicas, se vuelve inaccesible el servidor de metadatos.

Causa principal

A partir de la versión 20250901.00, el agente invitado migró a una nueva arquitectura basada en complementos para mejorar la modularidad. En un principio, la nueva arquitectura no admitía la instalación y administración automáticas de NIC dinámicas.

Solución

Para resolver estos problemas, actualiza tu instancia para que use la versión 20251205.00 o posterior del agente invitado:

  1. Para actualizar el agente invitado a la versión más reciente, consulta Actualiza el entorno invitado.
  2. Para confirmar la versión del agente invitado que ejecuta tu instancia, consulta Cómo ver los paquetes instalados por versión del sistema operativo.

Si es necesario, puedes solucionar estos problemas de forma temporal en las instancias que ejecutan versiones del agente invitado de 20250901.00 a 20251120.01. Para ello, sigue las instrucciones de Compatibilidad con versiones anteriores para revertir a la arquitectura anterior del agente invitado.

Las operaciones de NIC dinámicas fallan cuando una instancia de procesamiento se encuentra en varios grupos de instancias

Si agregas o borras una NIC dinámica, y la operación se atasca en un estado RUNNING con un progreso del 0% y, finalmente, falla con un error INTERNAL_ERROR, es posible que la instancia de procesamiento esté en varios grupos de instancias (administrados o no administrados).

Para permitir que se complete la operación, quita la instancia de todos los grupos de instancias, excepto de uno. Puedes quitar una instancia de un grupo de instancias administrado o quitar una instancia de un grupo de instancias no administrado.

¿Qué sigue?