Rutas

LasGoogle Cloud rutas definen las rutas que sigue el tráfico de red desde una instancia de máquina virtual (VM) hasta otros destinos. Estos destinos pueden estar dentro de tu red de Google Cloud nube privada virtual (VPC) (por ejemplo, en otra máquina virtual) o fuera de ella.

En una red de VPC, una ruta consta de un único prefijo de destino en formato CIDR y un único salto siguiente. Cuando una instancia de una red VPC envía un paquete, Google Cloud entrega el paquete al siguiente salto de la ruta si la dirección de destino del paquete se encuentra dentro del intervalo de destino de la ruta.

En esta página se ofrece una descripción general de cómo funcionan las rutas en Google Cloud.

Enrutamiento en Google Cloud

Todas las redes de VPC usan un mecanismo de enrutamiento virtual distribuido y escalable. No hay ningún dispositivo físico asignado a la red. Algunas rutas se pueden aplicar de forma selectiva, pero la tabla de enrutamiento de una red de VPC se define a nivel de red de VPC.

Cada instancia de VM tiene un controlador que se mantiene informado de todas las rutas aplicables de la tabla de enrutamiento de la red. Cada paquete que sale de una VM se envía al siguiente salto adecuado de una ruta aplicable en función de un orden de enrutamiento. Cuando añades o eliminas una ruta, el conjunto de cambios se propaga a los controladores de la VM mediante un diseño de coherencia final.

Tipos de ruta

En las siguientes tablas se resume cómo Google Cloud categoriza las rutas en las redes de VPC.

Tipo y destino Siguiente salto Notas
Rutas basadas en políticas: las rutas basadas en políticas se evalúan antes que cualquier otro tipo de ruta.
Ruta basada en políticas
Las rutas basadas en políticas se pueden aplicar a los paquetes en función de la dirección IP de origen, la dirección IP de destino, el protocolo o una combinación de estos elementos.

Las rutas basadas en políticas se pueden aplicar a todas las máquinas virtuales de la red, a determinadas máquinas virtuales seleccionadas por etiqueta de red o al tráfico que entra en la red de VPC a través de vinculaciones de VLAN para Cloud Interconnect (en una sola región o en todas las regiones).

Las rutas basadas en políticas nunca se intercambian a través del emparejamiento entre redes de VPC.
Rutas de subred: todos los tipos de rutas de subred se evalúan después de las rutas basadas en políticas, pero antes de las rutas personalizadas.
Ruta de subred local
Se crea automáticamente para cada intervalo de direcciones IP de subred 		Red VPC

Creado, actualizado y eliminado automáticamente por Google Cloud durante los eventos del ciclo de vida de la subred.

Las rutas de subred local se aplican a toda la red de VPC.
Ruta de subred de emparejamiento
Representa un intervalo de direcciones IP de subred en una red de VPC diferente conectada mediante el emparejamiento entre redes de VPC. 		Siguiente salto en la red de VPC emparejada

El emparejamiento entre redes de VPC ofrece opciones para intercambiar rutas de subred.

Creado, actualizado y eliminado automáticamente por Google Cloud durante los eventos del ciclo de vida de la subred.

Las rutas de subred de emparejamiento importadas se aplican a toda la red de VPC.
Ruta de subred de Network Connectivity Center
Representa un intervalo de direcciones IP de subred en un radio de VPC (una red de VPC diferente conectada al hub de Network Connectivity Center) 		Hub de Network Connectivity Center

Los administradores de radios de Network Connectivity Center pueden excluir la exportación de rutas de subred.

Creado, actualizado y eliminado automáticamente por Google Cloud durante los eventos del ciclo de vida de la subred.

Las rutas de subred de Network Connectivity Center importadas se aplican a toda la red de VPC.
Rutas personalizadas: las rutas personalizadas se evalúan después de las rutas basadas en políticas y de las rutas de subred.
Ruta estática local
Admite varios destinos 		Reenvía paquetes a un siguiente salto de ruta estática Para obtener información sobre cada siguiente salto de ruta estática, consulta las consideraciones sobre:
Ruta dinámica local
Destinos que no entran en conflicto con rutas de subred o rutas estáticas		 Peer de una sesión BGP en un Cloud Router Las rutas se añaden y se eliminan automáticamente en función de las rutas aprendidas de los routers de Cloud Router de tu red de VPC.

Las rutas se aplican a las VMs según el modo de enrutamiento dinámico de la red de VPC.
Ruta estática de emparejamiento, ruta dinámica de emparejamiento
Rutas estáticas o dinámicas en una red de VPC diferente conectada mediante un emparejamiento entre redes de VPC 		Siguiente salto en la red de VPC emparejada

El emparejamiento entre redes de VPC ofrece opciones para intercambiar rutas estáticas.

Las rutas estáticas de emparejamiento importadas se aplican a toda la red de VPC.

El emparejamiento de redes de VPC ofrece opciones para intercambiar rutas dinámicas.

Las rutas dinámicas de emparejamiento se aplican a una región o a todas las regiones de la red de VPC en función del modo de enrutamiento dinámico de la red de VPC que exporta las rutas.
Ruta dinámica de Network Connectivity Center
Rutas dinámicas importadas de radios híbridos de Network Connectivity Center ubicados en diferentes redes de VPC 		Hub de Network Connectivity Center

Un hub de Network Connectivity Center puede tener radios de VPC y radios híbridos.

Las rutas dinámicas de Network Connectivity Center se aplican a una región o a todas las regiones de la red de VPC en función del modo de enrutamiento dinámico de la red de VPC que contenga el spoke híbrido.
Rutas generadas por el sistema
Rutas predeterminadas generadas por el sistema
0.0.0.0/0 para IPv4
::/0 para IPv6		 default-internet-gateway Se aplica a toda la red VPC

Se puede quitar o sustituir

Rutas de subred

Cada subred tiene al menos una ruta de subred por cada intervalo de direcciones IP asociado a la subred. Para obtener más información sobre los intervalos de IP de subred, consulta el artículo Subredes.

Tipos de rutas de subred

Una red de VPC puede incluir los siguientes tipos de rutas de subred:

  • Rutas de subred de subredes de la misma red de VPC, denominadas rutas de subred locales.
  • Rutas de subred de Network Connectivity Center que se importan desde las VPCs de un hub de Network Connectivity Center.
  • Rutas de subred de emparejamiento que se importan de redes conectadas mediante el emparejamiento entre redes de VPC.

Los intervalos de destino de todos los tipos de rutas de subred deben ser únicos. Para obtener más información, consulta:

Rutas de subred híbridas

Las rutas de subred local y las rutas de subred de emparejamiento pueden ser rutas de subred híbridas si la subred correspondiente se configura como subred híbrida.

Ciclo de vida de las rutas de subred

Todos los intervalos de direcciones IP que forman parte de una subred (intervalos de direcciones IPv4 principales, intervalos de direcciones IPv4 secundarias e intervalos de direcciones IPv6) tienen una ruta de subred correspondiente. Google Cloud crea y elimina rutas de subred en los siguientes casos:

  • Haces un cambio en la configuración de la subred, por ejemplo:

    • Añade o elimina una subred.
    • Amplía un intervalo de IPv4 principal.
    • Añadir o eliminar un intervalo de IPv4 secundario.
    • Añade o elimina un intervalo de IPv6.

  • Google Cloud añade una nueva región, lo que añade automáticamente una nueva subred a las redes de modo automático de VPC. Para obtener información sobre los intervalos de direcciones IPv4 de cada subred por región, consulta los intervalos IPv4 del modo automático.

Rutas dinámicas

Los routers de Cloud Router indican a la red de VPC que cree, actualice y elimine rutas dinámicas en función de los mensajes del protocolo de pasarela fronteriza (BGP) recibidos, las políticas de rutas de BGP aplicables (vista previa) y las rutas aprendidas personalizadas de Cloud Router.

Las rutas dinámicas se crean en una región o en todas las regiones en función del modo de enrutamiento dinámico y del modo de selección del mejor trayecto de la red de VPC que contiene el router de Cloud. Para obtener más información, consulta lo siguiente:

El siguiente salto de una ruta dinámica puede ser uno de los siguientes:

Si un siguiente salto de una ruta dinámica deja de ser accesible, el router de Cloud Router que gestiona su sesión de BGP indica a la red VPC que elimine la ruta dinámica. Para obtener más información, consulta Cambios de estado de BGP.

Tipos de rutas dinámicas

Una red de VPC puede incluir los siguientes tipos de rutas dinámicas:

Google Cloud Resuelve los conflictos entre las rutas dinámicas y las rutas de subred, tal como se describe en Interacciones con rutas dinámicas.

Rutas predeterminadas generadas por el sistema

Una ruta predeterminada tiene el destino más amplio posible: 0.0.0.0/0 para IPv4 y ::/0 para IPv6. Google Cloud Solo utiliza una ruta predeterminada para enviar un paquete cuando este no coincide con una ruta más específica en el orden de enrutamiento.

La ausencia de una ruta predeterminada no aísla necesariamente tu red de Internet, ya que las rutas especiales para los balanceadores de carga de red de paso a través externos y el reenvío de protocolos externos no dependen de una ruta predeterminada.

Cuando crea una red de VPC,Google Cloud añade una ruta predeterminada IPv4 generada por el sistema a la red de VPC. La ruta predeterminada IPv4 generada por el sistema es una ruta estática local que tiene un destino 0.0.0.0/0 y un siguiente salto de pasarela de Internet predeterminada. Una ruta estática local con el destino 0.0.0.0/0 y el siguiente salto de la pasarela de Internet predeterminada proporciona una ruta a direcciones IPv4 externas, incluidas las direcciones IPv4 de Internet. Los siguientes recursos de ejemplo usan esta ruta:

  • Máquinas virtuales con direcciones IPv4 externas asignadas a sus interfaces de red, cuando los paquetes que envían tienen orígenes que coinciden con la dirección IPv4 interna principal de la interfaz de red.
  • Una pasarela de Cloud NAT pública configurada para proporcionar servicios de NAT a las subredes que usan las interfaces de red de las VMs. Tanto en NAT44 como en NAT64, las pasarelas de Cloud NAT públicas siempre dependen de una ruta estática IPv4 local que usa la pasarela de Internet predeterminada como salto siguiente. Para obtener más información sobre el tráfico que pueden traducir las pasarelas Cloud NAT públicas, consulta las especificaciones generales.

Cuando creas una subred que tiene un intervalo de direcciones IPv6 externas,Google Cloud añade una ruta predeterminada IPv6 generada por el sistema a la red de VPC si aún no tiene ninguna. La ruta predeterminada IPv6 generada por el sistema es una ruta estática local que tiene un destino ::/0 y un siguiente salto de pasarela de Internet predeterminada. Una ruta estática local con el ::/0destino y el siguiente salto de la pasarela de Internet predeterminada proporciona una ruta a direcciones IPv6 externas, incluidas las direcciones IPv6 de Internet. Pueden usar esta ruta los siguientes elementos:

  • Máquinas virtuales con /96 intervalos de direcciones IPv6 externas asignados a sus interfaces de red, cuando los paquetes que envían tienen orígenes en ese intervalo de direcciones /96.

El acceso a las APIs de Google globales a veces depende de una ruta predeterminada local IPv4 o IPv6 con el siguiente salto de la pasarela de Internet predeterminada:

  • Si accedes a las APIs y los servicios globales de Google enviando paquetes a un endpoint de Private Service Connect para las APIs globales de Google, tu red de VPC no requiere una ruta predeterminada con un salto siguiente de gateway de Internet predeterminado. Google Cloud añade una ruta especial al endpoint.

  • Si accedes a las APIs y los servicios globales de Google enviando paquetes a direcciones IPv4 o IPv6 de los dominios predeterminados, a las direcciones IPv4 o IPv6 de private.googleapis.com o a las direcciones IPv4 o IPv6 de restricted.googleapis.com, puedes usar rutas IPv4 e IPv6 predeterminadas que tengan saltos siguientes de la pasarela de Internet predeterminada, o bien crear y usar rutas estáticas IPv4 e IPv6 que tengan destinos más específicos y saltos siguientes de la pasarela de Internet predeterminada:

Interacciones de ruta

En las siguientes secciones se describen las interacciones entre las rutas de subred y otros tipos de rutas.

Interacciones entre rutas de subred y rutas estáticas

Google Cloud aplica las siguientes reglas a las rutas de subred local, las rutas de subred de emparejamiento y las rutas de subred de Network Connectivity Center salvo que la subred correspondiente se haya configurado como subred híbrida.

  • Google Cloud no te permite crear una ruta estática si el destino de la nueva ruta estática coincide exactamente o se ajusta al destino de una ruta de subred local, de peering o de Network Connectivity Center. Por ejemplo:

    • Si existe una ruta de subred local, de peering o de Network Connectivity Center con el destino 10.70.1.0/24, no puedes crear una ruta estática para 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 ni ningún otro destino que se ajuste a 10.70.1.0/24.

    • Si existe una ruta de subred local o de emparejamiento con el destino 2001:0db8:0a0b:0c0d::/64, no puedes crear una ruta estática para 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96 ni ningún otro destino que se ajuste a 2001:0db8:0a0b:0c0d::/64.

  • Google Cloud no te permite hacer ningún cambio en las subredes que dé como resultado un intervalo de direcciones IP de subred que coincida exactamente con el destino de una ruta estática local o de peering, o que lo contenga. Por ejemplo:

    • Si tu red de VPC tiene una ruta estática con el destino 10.70.1.128/25, no puedes crear una subred que tenga un intervalo de direcciones IPv4 principal o secundario de 10.70.1.128/25, 10.70.1.0/24 o cualquier otro intervalo de direcciones IP que contenga todas las direcciones IPv4 de 10.70.1.128/25.

    • Si tu red de VPC tiene una ruta estática con el destino 2001:db8:a0b:c0d:e0f:f0e::/96, Google Cloud no se puede crear una ruta de subred local o de emparejamiento que tenga un intervalo de direcciones IPv6 de 2001:db8:a0b:c0d::/64 o cualquier otro intervalo que contenga todas las direcciones IPv6 de 2001:db8:a0b:c0d:e0f:f0e::/96.

Interacciones entre rutas de subred y rutas dinámicas

Google Cloud aplica las siguientes reglas a menos que se haya configurado una subred como subred híbrida.

  • Google Cloud no crea una ruta dinámica si un Cloud Router envía un prefijo que coincide exactamente con el destino de una ruta de subred local, de peering o de Network Connectivity Center, o que se ajusta a él. Por ejemplo:

    • Si existe una ruta de subred local, de emparejamiento o de Network Connectivity Center con el destino 10.70.1.0/24 y un Cloud Router de la red de VPC, una red de VPC emparejada o una red que contenga un spoke híbrido de Network Connectivity Center recibe 10.70.1.128/25, 10.70.1.0/24 o cualquier otro prefijo que se ajuste a 10.70.1.0/24, Google Cloud no se crea ninguna ruta dinámica local, de emparejamiento o de Network Connectivity Center para los prefijos conflictivos recibidos.

    • Si existe una ruta de subred local, de emparejamiento o de Network Connectivity Center con el destino 2001:0db8:0a0b:0c0d::/64 y un Cloud Router de la red de VPC, una red de VPC emparejada o una red que contenga un spoke híbrido de Network Connectivity Center recibe 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 o cualquier otro prefijo que se ajuste a 2001:0db8:0a0b:0c0d::/64, Google Cloud no se crearán rutas dinámicas locales, de emparejamiento o de Network Connectivity Center para los prefijos en conflicto recibidos.

  • Google Cloud elimina cualquier ruta dinámica que ya exista si cambia alguna subred y se crea una nueva ruta de subred local, de peering o de Network Connectivity Center cuyo destino coincida exactamente con el destino de la ruta dinámica local, de peering o de Network Connectivity Center que ya exista, o lo contenga. Por ejemplo:

    • Si tu red VPC tiene una ruta dinámica local, de peering o de Network Connectivity Center con el destino 10.70.1.128/25,Google Cloud se elimina la ruta dinámica cuando se crea una nueva ruta de subred local, de peering o de Network Connectivity Center para 10.70.1.128/25, 10.70.1.0/24 o cualquier otro intervalo de direcciones IP que contenga todas las direcciones IPv4 de 10.70.1.128/25.

    • Si tu red de VPC tiene una ruta dinámica local, de emparejamiento o de Network Connectivity Center con el 2001:db8:a0b:c0d::/96destino Google Cloud , se elimina la ruta dinámica cuando se crea una nueva ruta de subred local, de emparejamiento o de Network Connectivity Center para 2001:db8:a0b:c0d::/64.

Aplicabilidad y orden

Rutas pertinentes

Cada instancia, túnel VPN de Cloud y vinculación de VLAN tiene un conjunto de rutas aplicables, es decir, rutas que se aplican a ese recurso concreto. Las rutas aplicables son un subconjunto de todas las rutas de la red de VPC.

Los siguientes tipos de ruta se aplican siempre a todas las instancias de VM, vinculaciones de VLAN y túneles de Cloud VPN:

Los siguientes tipos de rutas se pueden configurar para que se apliquen solo a determinadas instancias de VM, vinculaciones de VLAN o túneles de Cloud VPN:

  • Las rutas basadas en políticas se pueden aplicar a lo siguiente:

    • Todas las instancias de VM, las vinculaciones de VLAN y los túneles de Cloud VPN
    • Solo las instancias de VM identificadas por etiquetas de red
    • Solo vinculaciones de VLAN de una región concreta

  • Las rutas estáticas se pueden aplicar a lo siguiente:

    • Todas las instancias de VM, las vinculaciones de VLAN y los túneles de Cloud VPN
    • Solo las instancias de VM identificadas por etiquetas de red

  • Las rutas dinámicas se pueden aplicar a instancias de VM, vinculaciones de VLAN y túneles VPN de Cloud en la región que contiene el siguiente salto de la ruta dinámica o en todas las regiones, en función del modo de enrutamiento dinámico de la red de VPC.

Rutas especiales

Las redes de VPC tienen rutas especiales para determinados servicios. Estas rutas especiales no aparecen en la tabla de rutas de tu red VPC. No puedes quitar ninguna ruta especial. Sin embargo, puedes permitir o denegar paquetes mediante reglas de cortafuegos de VPC o políticas de cortafuegos.

Rutas de balanceadores de carga de red de paso a través externos y reenvío de protocolos externos

Los balanceadores de carga de red de paso a través externos y el reenvío de protocolos externo usan sistemas Maglev para enrutar paquetes de clientes en Internet a máquinas virtuales de backend e instancias de destino en tu red de VPC. Estos sistemas Maglev enrutan los paquetes que tienen destinos que coinciden con el destino de la regla de reenvío externa.

Cada regla de reenvío de un balanceador de carga de red de paso a través externo o de un reenvío de protocolo externo también proporciona una ruta para que sus máquinas virtuales de backend o su instancia de destino envíen paquetes a destinos fuera de la red de VPC:

  • Los paquetes enviados por las VMs de backend o las instancias de destino pueden ser paquetes de respuesta salientes (enviados al cliente) o paquetes salientes que inicien una nueva conexión.
  • Los orígenes de los paquetes deben coincidir con la dirección IP de la regla de reenvío. El protocolo y el puerto de origen del paquete no tienen que coincidir con el protocolo y la especificación del puerto de la regla de reenvío.
  • Las rutas de enrutamiento de las reglas de reenvío no dependen de una ruta predeterminada ni del uso del siguiente salto de la pasarela de Internet predeterminada.
  • No es necesario que las VMs de backend ni las instancias de destino tengan habilitado el reenvío de IP.

Rutas entre Google Front Ends y backends

Los balanceadores de carga de aplicación externos y los balanceadores de carga de red de proxy externos usan Google Front Ends (GFEs). Los GFEs de segunda capa abren conexiones TCP a tus VMs de backend y envían paquetes desde las siguientes fuentes:

  • 35.191.0.0/16 y 130.211.0.0/22 para IPv4
  • 2600:2d00:1:1::/64 para IPv6

Google Cloud usa rutas en la red de Google para enviar paquetes desde esos intervalos de origen a las máquinas virtuales de backend de tu red de VPC. Cada red de VPC incluye rutas que permiten a las VMs enviar paquetes de respuesta a los intervalos.

Rutas de comprobaciones del estado

Las comprobaciones del estado de todos los balanceadores de carga y de la reparación automática de grupos de instancias gestionados envían paquetes a tus VMs de backend desde intervalos de direcciones IP de sondeo de comprobación del estado.

Google Cloud usa rutas en la red de Google para enviar paquetes desde sistemas de sondeo de comprobación de estado a las máquinas virtuales de tu red de VPC. Cada red de VPC incluye rutas que permiten que las VMs envíen paquetes de respuesta a los sistemas de comprobación del estado.

Rutas de Identity-Aware Proxy (IAP)

La redirección TCP mediante IAP usa 35.235.240.0/20 para IPv4 y 2600:2d00:1:7::/64 para IPv6 como intervalos solo internos con saltos siguientes que están completamente dentro de la red de Google. Google no publica rutas a estos intervalos en Internet.

Las rutas de la red de Google envían paquetes desde 35.235.240.0/20 o 2600:2d00:1:7::/64 a las máquinas virtuales de tu red de VPC cuando usas el reenvío de TCP de IAP. Cada red de VPC incluye rutas que permiten a las VMs enviar paquetes de respuesta a estos intervalos.

Rutas de Cloud DNS y Directorio de servicios

Las siguientes funciones de Cloud DNS y de Directorio de servicios usan 35.199.192.0/19 como intervalo solo interno con saltos siguientes que están completamente dentro de la red de Google. Google no publica rutas a 35.199.192.0/19 en Internet.

Las rutas de la red de Google envían paquetes desde 35.199.192.0/19 a las VMs de tu red de VPC cuando usas estas funciones de Cloud DNS y Service Directory. Cada red de VPC incluye rutas que permiten a las VMs enviar paquetes de respuesta a 35.199.192.0/19.

Rutas de Acceso a VPC sin servidor

Acceso a VPC sin servidor usa 35.199.224.0/19 como intervalo solo interno con saltos siguientes que están completamente dentro de la red de Google. Google no publica rutas a 35.199.224.0/19 en Internet.

Las rutas de la red de Google envían paquetes desde 35.199.224.0/19 a las instancias del conector de acceso a VPC sin servidor. Cada red de VPC incluye rutas que permiten que las instancias de conector envíen paquetes de respuesta a 35.199.224.0/19.

Rutas de los puntos finales de Private Service Connect para las APIs de Google globales

Cuando creas un endpoint de Private Service Connect para APIs de Google globales,Google Cloud añade una ruta para el endpoint a tu red de VPC. El destino de la ruta es la dirección IP interna global del endpoint.

Orden de enrutamiento

Puede haber más de una ruta aplicable para un paquete determinado. En los siguientes pasos se describe el proceso que sigue Google Cloud para seleccionar una ruta.

  1. Rutas especiales: algunas rutas especiales no se muestran en las tablas de rutas de la red de VPC.Google Cloud Para obtener más información, consulta Rutas especiales.

    Si se aplica una ruta especial, el modelo de selección de rutas solo contendrá la ruta especial. El resto de las rutas se ignoran y la evaluación se detiene en este paso.

  2. Rutas basadas en políticas: las rutas basadas en políticas se evalúan después de las rutas especiales, pero antes que otros tipos de rutas. Si no hay ninguna ruta basada en políticas en la red VPC,Google Cloud se salta este paso y continúa con el paso de las rutas de subred.

    Google Cloud evalúa las rutas basadas en políticas únicamente por su prioridad. Google Cloud evalúa el origen y el destino de un paquete en cada ruta basada en políticas, empezando por la ruta o las rutas basadas en políticas de mayor prioridad. Si las características de un paquete no coinciden con una ruta basada en políticas,Google Cloud ignora esa ruta y sigue evaluando la siguiente ruta basada en políticas de la lista ordenada. La siguiente ruta basada en políticas que se evalúa puede tener la misma prioridad que la ruta basada en políticas que se ha descartado o una prioridad inferior.

    • Si las características de un paquete no coinciden con ninguna ruta basada en políticas después de evaluar todas las rutas basadas en políticas de tu modelo de selección de rutas, Google Cloud ignora todas las rutas basadas en políticas y continúa con el paso de las rutas de subred.

    • Si las características de un paquete coinciden con una ruta basada en políticas de máxima prioridad, Google Cloud primero se ignoran todas las rutas basadas en políticas de menor prioridad. Si quedan dos o más rutas basadas en políticas en la lista, Google Cloud evalúa cada una de las rutas basadas en políticas restantes que tengan prioridades idénticas. Google Cloud ignora las rutas basadas en políticas restantes si las características de un paquete no coinciden con ellas. Después de este paso, el modelo de selección de rutas puede contener una o varias rutas basadas en políticas.

    • Si tu modelo de selección de rutas incluye dos o más rutas basadas en políticas que coinciden y tienen la prioridad más alta, Google Cloud selecciona una ruta basada en políticas mediante un algoritmo interno. Es posible que la ruta basada en políticas seleccionada no sea la coincidencia más específica para el origen o el destino del paquete. Para evitar esta ambigüedad, te recomendamos que crees rutas basadas en políticas que tengan prioridades únicas.

    • Si tu modelo de selección de rutas incluye solo una ruta basada en políticas de máxima prioridad que está configurada para saltarse otras rutas basadas en políticas, Google Cloud ignora todas las rutas basadas en políticas y continúa con el paso de las rutas de subred.

    • Si tu modelo de selección de rutas incluye solo una ruta basada en políticas de máxima prioridad que no está configurada para omitir otras rutas basadas en políticas, Google Cloud envía el paquete al siguiente salto del balanceador de carga de red de transferencia interna y no tiene en cuenta las rutas que no se basan en políticas.

  3. Rutas de subred: Google Cloud determina si el destino del paquete se ajusta al intervalo de destino de una ruta de subred local, de emparejamiento o de Network Connectivity Center en la red de VPC.

    • No hay ninguna ruta de subred coincidente: si el destino de un paquete no coincide con el intervalo de destino de ninguna ruta de subred, Google Cloud se ignoran todas las rutas de subred. Elimina todas las rutas de subred de tu modelo de selección de rutas y ve al paso Destino más específico para evaluar las rutas estáticas y dinámicas.

    • Ruta de subred normal coincidente: en la mayoría de las subredes, si el destino de un paquete coincide con el intervalo de destino de una ruta de subred normal,Google Cloud se utiliza exclusivamente la ruta de subred Google Cloud, se ignoran todas las demás rutas y la evaluación se detiene en este paso. Si el destino del paquete no está asociado a un recurso o pertenece a una instancia de VM detenida, el paquete se descarta.

    • Ruta de subred híbrida coincidente: si el destino de un paquete coincide con el intervalo de destino de una ruta de subred híbrida y con una dirección IP asociada a una instancia de VM en ejecución o a una regla de reenvío interna, Google Cloud se envía el paquete mediante la ruta de subred híbrida. Google Cloud Se ignoran todas las demás rutas y la evaluación se detiene en este paso.

      Si el destino no coincide con una VM en ejecución o con una regla de reenvío interna, consulta Recursos no coincidentes en subredes híbridas.

  4. Destino más específico: al principio de este paso, Google Cloud ha ignorado todas las rutas especiales, las rutas basadas en políticas y las rutas de subred.

    Google Cloud determina qué rutas estáticas o dinámicas aplicables tienen el destino más específico que contiene la dirección IP de destino del paquete. Google Cloud Ignora todas las rutas excepto las que tienen el destino más específico. Por ejemplo, 10.240.1.0/24 es un destino más específico que 10.240.0.0/16.

    Al final de este paso, el modelo de selección de rutas solo contendrá rutas estáticas o dinámicas con destinos idénticos.

  5. Selecciona solo el tipo de ruta personalizada más favorable: en este paso, Google Cloud elimina todas las rutas personalizadas, excepto el tipo de ruta personalizada más favorable. Las rutas personalizadas locales tienen prioridad sobre las rutas dinámicas de Network Connectivity Center, y estas últimas tienen prioridad sobre las rutas personalizadas de peering.

    En la siguiente tabla se resume la lógica que usa Google Cloud en este paso.

    Categoría de ruta personalizada Qué ocurre
    Rutas dinámicas locales y rutas estáticas locales

    Si tu modelo de ruta contiene al menos una ruta dinámica local o una ruta estática local para el destino, Google Cloud elimina los siguientes tipos de ruta personalizada, si están presentes en el modelo de ruta:

    • Rutas dinámicas de Network Connectivity Center desde radios híbridos en diferentes redes de VPC
    • Rutas dinámicas de emparejamiento (importadas de otras redes de VPC conectadas mediante el emparejamiento entre redes de VPC)
    Rutas dinámicas de Network Connectivity Center Si se cumplen todas las condiciones siguientes, Google Cloud elimina todas las rutas dinámicas y estáticas de emparejamiento del modelo de ruta:
    • Tu modelo de ruta no contiene ninguna ruta personalizada local para el destino
    • Tu modo de ruta contiene al menos una ruta dinámica de Network Connectivity Center para el destino.
    • La ruta dinámica de Network Connectivity Center procede de un spoke híbrido de otra red de VPC.
    Rutas de emparejamiento dinámicas y estáticas El tipo de ruta personalizada menos favorable contiene rutas personalizadas de peering. Las rutas personalizadas de peering del destino solo se utilizan cuando el modelo de ruta no contiene ninguna ruta personalizada local ni ninguna ruta dinámica de Network Connectivity Center para el destino.

  6. Selecciona los siguientes saltos de las rutas personalizadas de emparejamiento de una sola red de VPC: los siguientes saltos del mismo destino deben estar en la misma red de VPC. Este paso solo se aplica si tu modelo de ruta contiene rutas estáticas o dinámicas de emparejamiento que se importan de dos o más redes de VPC diferentes conectadas mediante el emparejamiento entre redes de VPC.

    Google Cloud usa un algoritmo interno para importar rutas personalizadas de emparejamiento de una única red de VPC. La red de aplicación similar queGoogle Cloud selecciona puede cambiar si tu red de VPC se empareja con una nueva red de VPC o si se desconecta de una red de VPC de aplicación similar.

  7. Ignorar las rutas estáticas y dinámicas con saltos siguientes inutilizables: en este paso se simulan situaciones en las queGoogle Cloud ignora los saltos siguientes que no funcionan o no son válidos.

    • Especificación de dirección IP de VM del siguiente salto no válida: el next-hop-address de una ruta estática debe coincidir con una dirección IP asignada a una VM de la red de VPC de la ruta. La dirección IP debe asignarse a la interfaz de red de la VM de una de las siguientes formas:

      • Una dirección IPv4 interna principal
      • Una dirección IPv6 interna
      • Una dirección IPv6 externa

      Si la dirección IP especificada por next-hop-address coincide con otro tipo de recurso (como un intervalo de IPs de alias) o no coincide con ningún recurso,Google Cloud ignora la ruta.

    • Máquina virtual de siguiente salto detenida o eliminada: Google Cloud ignora cada ruta estática cuya instancia de máquina virtual de siguiente salto se haya detenido o eliminado. Este comportamiento se aplica a las rutas cuyos siguientes saltos se especifican mediante next-hop-instance o next-hop-address. Para obtener más información, consulta Comportamiento cuando se detienen o eliminan instancias.

    • Especificación de dirección IP de balanceador de carga del siguiente salto no válida: en el caso de las rutas estáticas que tienen un balanceador de carga del siguiente salto especificado por dirección IP, la dirección IP debe coincidir con una regla de reenvío de un balanceador de carga de red interno de tipo pasarela que se encuentre en la red de VPC de la ruta o en una red de VPC emparejada. Si la dirección IP del siguiente salto coincide con la regla de reenvío de un balanceador de carga de otro tipo o no coincide con ninguna regla de reenvío,Google Cloud ignora la ruta.

    • Túnel VPN clásico con siguiente salto no establecido: Google Cloud ignora cada ruta estática con un túnel VPN clásico de siguiente salto que no tenga una asociación de seguridad (SA) de fase 1 (IKE) activa. Para obtener más información, consulta el orden de las rutas en la documentación de VPN clásica.

    • Ruta dinámica con un siguiente salto no funcional: incluso antes de que se interrumpa la sesión BGP responsable de programar una ruta dinámica, Google Cloudse ignora una ruta dinámica si su siguiente salto (túnel de Cloud VPN, vinculación de VLAN o VM del dispositivo Router) no funciona. Esta situación suele durar solo unos segundos, hasta que se elimina la ruta dinámica cuando se interrumpe la sesión BGP del router de Cloud Router correspondiente.

    Google Cloud no valida si el SO invitado de una VM del siguiente salto o de una VM de backend de un balanceador de carga del siguiente salto está procesando paquetes. Para obtener más información, consulta Consideraciones comunes a los saltos siguientes de los balanceadores de carga de red de paso a través internos y de instancias.

  8. Ignorar rutas de baja prioridad: en este paso se muestra cómo Google Cloud descarta todas las rutas excepto las que tienen la prioridad más alta.

    Después de este paso, el modelo de ruta puede estar vacío o contener una o varias rutas. Si tu modelo no está vacío, todas las rutas de tu modelo tienen las siguientes características:

    • Prioridades idénticas
    • Siguientes saltos que no se han ignorado
    • Destinos idénticos
    • Tipos de rutas que no están basadas en políticas ni son rutas de subred

  9. Selecciona los siguientes saltos de las rutas dinámicas de Network Connectivity Center de una sola red de VPC: los siguientes saltos del mismo destino deben estar ubicados en la misma red de VPC. Este paso solo se aplica si tu modelo de ruta contiene rutas dinámicas de Network Connectivity Center importadas de dos o más radios híbridos ubicados en redes de VPC diferentes.

    Google Cloud usa un algoritmo interno para importar rutas dinámicas de Network Connectivity Center desde radios híbridos ubicados en una sola red de VPC. Los radios híbridos seleccionados pueden cambiar si añades o quitas radios híbridos del centro de conectividad de red. Para evitar esta ambigüedad, asegúrate de que las rutas dinámicas de Network Connectivity Center tengan prioridades únicas cuando se cumplan las siguientes condiciones:

    • Las rutas tienen destinos idénticos.
    • Las rutas se importan de dos o más radios híbridos en diferentes redes de VPC.

  10. Selecciona solo la categoría de preferencia más favorable: Google Cloud no realiza multipath de igual coste (ECMP) entre rutas que pertenezcan a diferentes categorías de preferencia, tal como se define en este paso.

    Categoría de preferencia Tipo de ruta y tipo de siguiente salto
    Primera preferencia (la más preferida) Una o varias rutas estáticas con instancias de siguiente salto (next-hop-instance o next-hop-address) o túneles de VPN clásica de siguiente salto.
    Segunda preferencia Una o varias rutas dinámicas de un mismo tipo.
    Tercera opción Una sola ruta estática con un balanceador de carga de red de paso a través interno como siguiente salto.
    Cuarta preferencia (la menos preferida) Una o varias rutas estáticas con el siguiente salto default-internet-gateway.

    En este paso, cuando hay dos o más rutas estáticas con un balanceador de carga de siguiente salto, Google Cloud selecciona una sola ruta estática mediante un algoritmo interno.Google Cloud no realiza ECMP entre varios balanceadores de carga. Para obtener más información, consulta Consideraciones sobre los próximos saltos del balanceador de carga de red de paso a través interno.

    Después de este paso, el modelo de ruta puede estar vacío o contener una o varias rutas. Si tu modelo no está vacío, todas las rutas de tu modelo tienen estas características:

    • Categoría de preferencia idéntica
    • Prioridades idénticas
    • Siguientes saltos que no se han ignorado
    • Siguientes saltos en una red de VPC
    • Destinos idénticos
    • Tipos de rutas que no están basadas en políticas ni son rutas de subred

  11. Enviar o soltar paquete: en función del número de rutas que queden en el modelo de ruta, Google Cloud envía o suelta el paquete:

    • Si el modelo de ruta contiene una sola ruta, Google Cloud envía el paquete al siguiente salto, con la siguiente excepción:

      Los balanceadores de carga de red con paso a través internos de salto siguiente que no tienen habilitado el acceso global no se pueden alcanzar desde regiones que no sean la del balanceador de carga. Por lo tanto, si un balanceador de carga de salto siguiente no tiene habilitado el acceso global, Google Cloud rechaza todos los paquetes enviados desde instancias de VM, vinculaciones de VLAN y túneles de Cloud VPN en regiones distintas a la del balanceador de carga. Para cambiar este comportamiento, habilita el acceso global.

    • Si tu modelo de ruta contiene dos o más rutas, Google Cloud realiza ECMP, distribuyendo los paquetes entre los siguientes saltos. La selección del siguiente salto depende de un cálculo de hash y del número de saltos siguientes. Google Cloud usa un hash de cinco tuplas si el paquete contiene información de puerto; de lo contrario, usa un hash de tres tuplas. No se garantiza una selección de siguiente salto coherente para un hash determinado.Google Cloudpuede dirigir paquetes a un siguiente salto diferente aunque el hash sea el mismo y el modelo de ruta no haya cambiado.

    • Si el modelo de ruta está vacío, Google Cloud descarta el paquete con un mensaje de tipo 3 y código 0 de ICMP (red no accesible).

Recursos inigualables en subredes híbridas

Si tu modelo de ruta contiene una ruta de subred híbrida y el destino del paquete coincide con una dirección IP asociada a una VM detenida o no está asociada a ningún recurso de la subred híbrida,Google Cloud utiliza un proceso diferente para enrutar el paquete. En los siguientes pasos se describe el proceso que usa Google Cloud para enrutar estos paquetes:

  1. Identifica la red de VPC que contiene la subred híbrida:

    • La subred híbrida y el recurso que envía paquetes a la subred híbrida pueden usar la misma red de VPC. En este caso, la subred híbrida crea una ruta de subred local correspondiente en esa red VPC.

    • La subred híbrida y el recurso que envía paquetes a la subred híbrida pueden estar en redes de VPC diferentes conectadas mediante el emparejamiento entre redes de VPC. En este caso, la subred híbrida crea una ruta de subred de emparejamiento correspondiente en la red VPC que usa el recurso que envía paquetes.

  2. Empieza con todas las rutas de la red de VPC que contiene la subred híbrida y, a continuación, elimina las siguientes rutas:

    • Todas las rutas basadas en políticas
    • Todas las rutas de subred
    • Todas las rutas estáticas que tienen etiquetas de red
    • Todas las rutas cuyos destinos son más amplios que la subred híbrida y que la contienen ruta que se ha encontrado en el primer modelo de ruta

  3. Elige el destino más específico siguiendo los pasos para seleccionar solo la categoría de preferencia más favorable en el orden de la ruta.

  4. Sigue estas reglas para determinar si Google Cloud envía o descarta el paquete:

    • Si el modelo de ruta contiene una sola ruta y el siguiente salto de la ruta está en la misma región que la subred híbrida, Google Cloud envía el paquete al siguiente salto.

    • Si el modelo de ruta contiene dos o más rutas, Google Cloud realiza ECMP entre esas rutas. Si el siguiente salto está en la misma región que la subred híbrida, Google Cloud envía el paquete al siguiente salto.

    • Google Cloud descarta el paquete con un mensaje ICMP de tipo 3 y código 0 (red no accesible) si el modelo de ruta está vacío o si el siguiente salto se encuentra en una región distinta a la de la subred híbrida.

    Las siguientes rutas tienen saltos siguientes en regiones distintas a la de la subred híbrida, por lo que siempre provocan pérdidas de paquetes:

    • Rutas dinámicas aprendidas por los routers de Cloud Router en regiones distintas a la de la subred híbrida, aunque el modo de enrutamiento dinámico de la red de VPC que contiene los routers de Cloud Router sea global
    • Rutas estáticas que tienen saltos siguientes en regiones distintas a la de la subred híbrida, incluidos todos los balanceadores de carga de red con paso a través internos de diferentes regiones, aunque tengan habilitado el acceso global

Siguientes pasos