Rutas

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

En una red de VPC, una ruta consta de un único prefijo de destino en formato CIDR y un solo siguiente salto. Cuando una instancia en una red de 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 rango de destino de la ruta.

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

Enrutamiento en Google Cloud

Cada red de VPC usa 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 para una red de VPC se define a nivel de la red de VPC.

Cada instancia de VM tiene un controlador que se mantiene informado sobre todas las rutas aplicables desde la tabla de enrutamiento de la red. Cada paquete que sale de una VM se entrega al siguiente salto apropiado de una ruta aplicable en función de un orden de enrutamiento. Cuando agregas o borras una ruta, el conjunto de cambios se propaga a los controladores de VM mediante un diseño de coherencia eventual.

Tipos de ruta

En las siguientes tablas, se resume la forma en que Google Cloud clasifica las rutas en las redes de VPC.

Tipo y destino	Siguiente salto	Notas
Rutas generadas por el sistema
Rutas predeterminadas que genera el sistema `0.0.0.0/0` para IPv4 `::/0` para IPv6	`default-internet-gateway`	Se aplica a toda la red de VPC Se puede quitar o reemplazar
Ruta de subred Se crea de forma automática para cada rango de direcciones IP de la subred	Red de VPC Reenvía paquetes a VM y balanceadores de cargas internos	Google Cloud la crea, actualiza y quita de forma automática durante los eventos del ciclo de vida de la subred. Las rutas de subred locales se aplican a toda la red de VPC.
Rutas personalizadas
Ruta estática Admite varios destinos	Reenvía paquetes a un siguiente salto de ruta estática.	Para obtener detalles sobre cada siguiente salto de ruta estática, consulta las consideraciones para lo siguiente: Instancias y balanceadores de cargas de red de transferencia interna Instancias de siguiente salto Próximos saltos del balanceador de cargas de red de transferencia interno Siguientes saltos del túnel de VPN clásica
Ruta dinámica Los destinos que no entran en conflicto con las rutas de las subredes ni las rutas estáticas	Par de una sesión de BGP en un Cloud Router	Las rutas se agregan y quitan de forma automática en función de las rutas aprendidas de Cloud Routers en tu red de VPC. Las rutas se aplican a las VM según el modo de enrutamiento dinámico de la red de VPC.
Rutas de intercambio de tráfico entre redes de VPC
Ruta de subred de intercambio de tráfico Representa un rango de direcciones IP de subred en una red de VPC diferente conectada mediante el intercambio de tráfico entre redes de VPC.	Siguiente salto en la red de VPC de intercambio de tráfico	El intercambio de tráfico entre redes de VPC ofrece opciones para intercambiar rutas de subred. Google Cloud la crea, actualiza y quita de forma automática durante los eventos del ciclo de vida de la subred. Las rutas de subred de intercambio de tráfico importadas se aplican a toda la red de VPC.
Intercambio de tráfico de rutas estáticas y dinámicas Rutas estáticas o dinámicas en una red de VPC diferente conectada mediante el intercambio de tráfico entre redes de VPC	Siguiente salto en la red de VPC de intercambio de tráfico	El intercambio de tráfico entre redes de VPC ofrece opciones para intercambiar rutas estáticas. Las rutas estáticas de intercambio de tráfico importadas se aplican a toda la red de VPC. El intercambio de tráfico entre redes de VPC ofrece opciones para intercambiar rutas dinámicas. Las rutas dinámicas de intercambio de tráfico importadas se aplican a una región o a todas las regiones de la red de VPC según la modo de enrutamiento dinámico de la red de VPC queexportaciones las rutas
Rutas de Network Connectivity Center
Ruta de subred de Network Connectivity Center Representa un rango de direcciones IP de subred en un radio de VPC (una red de VPC diferente conectada al concentrador de Network Connectivity Center). ).	Concentrador de Network Connectivity Center	Los administradores de radios de Network Connectivity Center pueden excluir la exportación de rutas de subred. Google Cloud la crea, actualiza y quita de forma automática durante los eventos del ciclo de vida de la subred. Las rutas de subred importadas de Network Connectivity Center se aplican a toda la red de VPC.
Rutas basadas en políticas
Ruta basada en políticas Las rutas basadas en políticas se pueden aplicar a paquetes basados en direcciones IP de origen, direcciones IP de destino, protocolo o una combinación de estos.	Una opción para omitir la evaluación de otras rutas basadas en políticas Un balanceador de cargas de red de transferencia interno	Las rutas basadas en políticas se evalúan antes que otras rutas. Las rutas basadas en políticas se pueden aplicar a todas las VMs de la red, a ciertas VMs seleccionadas por la etiqueta de red o al tráfico que ingresa a la red de VPC mediante los adjuntos de VLAN que identificas. Las rutas basadas en políticas nunca se intercambian a través del intercambio de tráfico entre redes de VPC.

Rutas predeterminadas generadas por el sistema

Cuando creas una red de VPC, se incluye una ruta predeterminada IPv4 generada por el sistema (0.0.0.0/0). Cuando creas una subred de pila doble con un rango de direcciones IPv6 externo en una red de VPC, se agrega una ruta predeterminada IPv6 generada por el sistema (::/0) a esa red si la ruta aún no existe. Las rutas predeterminadas tienen los siguientes fines:

Las rutas IPv4 e IPv6 predeterminadas definen una ruta de acceso fuera de la red de VPC hacia direcciones IP externas en Internet.
Si accedes a los servicios y las API de Google sin usar un extremo de Private Service Connect, la ruta predeterminada puede funcionar como la ruta de acceso a los servicios y las APIs de Google. Para obtener más información, consulta Configura el acceso privado a Google y Accede a las APIs desde las VMs con direcciones IP externas.

Google Cloud solo usa una ruta predeterminada si una ruta con un destino más específico no se aplica a un paquete. A fin de obtener información para usar la especificidad de destino y la prioridad de ruta para seleccionar una ruta, consulta Orden de enrutamiento.

Si deseas aislar por completo tu red de Internet o si necesitas reemplazar la ruta predeterminada por una personalizada, puedes borrar la ruta predeterminada:

Solo para IPv4: si deseas enrutar el tráfico de Internet a un siguiente salto diferente, puedes reemplazar la ruta predeterminada por una ruta estática o dinámica personalizada. Por ejemplo, podrías reemplazarla por una ruta estática personalizada cuyo siguiente salto sea una VM de proxy.
IPv4 e IPv6: si borras la ruta predeterminada y no la reemplazas, se descartan los paquetes destinados a rangos de IP que no están cubiertos por otras rutas.

Rutas de subred

Las rutas de subred definen las rutas de acceso a recursos como VM y balanceadores de cargas internos en una red de VPC.

Cada subred tiene al menos una ruta de subred cuyo destino coincide con el rango de IPv4 principal de la subred. Si la subred tiene rangos de IP secundarios, hay una ruta de subred correspondiente para cada uno de los rangos de direcciones IP secundarios. Si la subred tiene un rango de IPv6, hay una ruta de subred correspondiente para el rango de direcciones IPv6. Para obtener más información sobre los rangos de IP de subred, consulta Subredes.

Las rutas de subred siempre tienen los destinos más específicos. Las otras rutas no pueden anularlos, incluso aunque otra ruta tenga mayor prioridad. Esto se debe a que Google Cloud considera la especificidad del destino antes que la prioridad cuando se selecciona una ruta. Google Cloud usa 0 como prioridad para todas las rutas de subred.

Interacciones con rutas estáticas

Las rutas de subred locales y las rutas de subred de intercambio de tráfico importadas interactúan con rutas estáticas personalizadas de las siguientes maneras:

Google Cloud no te permite crear una ruta estática personalizada que tenga un destino igual o más estrecho que cualquier ruta de subred o ruta de subred de intercambio de tráfico. Por ejemplo:
- Si existe una ruta de subred local o una ruta de subred de intercambio de tráfico para el destino 10.70.1.0/24, no puedes crear una nueva ruta estática personalizada para 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 ni cualquier otro destino que se ajuste a 10.70.1.0/24.
- Si existe una ruta de subred local o una ruta de subred de intercambio de tráfico para el destino 2001:0db8:0a0b:0c0d::/64 no puedes crear una nueva ruta estática personalizada para 2001:0db8:0a0b:0c0d::/64 o cualquier destino que se ajuste a 2001:0db8:0a0b:0c0d::/64, como 2001:0db8:0a0b:0c0d::/96.
Por el contrario, Google Cloud no te permite crear una ruta de subred nueva o una ruta de subred de intercambio de tráfico cuyo destino coincida de manera exacta con una ruta estática personalizada existente o sea más amplia que esta (la contenga). Por ejemplo:
- Si la red de VPC tiene una ruta estática personalizada para el destino 10.70.1.128/25, Google Cloud prohíbe la creación de cualquier ruta de subred o ruta de subred de intercambio de tráfico que tenga un rango de direcciones IPv4 principal o secundario de la subred IPv4 10.70.1.128/25, 10.70.1.0/24 o cualquier otro rango que contenga todas las direcciones IPv4 en 10.70.1.128/25.
- Si tu red de VPC tiene una ruta estática personalizada para el destino 2001:0db8:0a0b:0c0d::/96, Google Cloud prohíbe la creación de cualquier ruta de subred de pila doble o ruta de subred de intercambio de tráfico que tenga un rango de direcciones IPv6 de 2001:0db8:0a0b:0c0d::/64 o cualquier otro rango que contenga todas las direcciones IPv6 en 2001:0db8:0a0b:0c0d::/96.

Interacciones con rutas dinámicas

Las rutas de subred locales y las rutas de subred de intercambio de tráfico importadas interactúan con Cloud Routers de las siguientes maneras:

Cuando los routers de Cloud Router aprenden un prefijo que coincide con precisión con el destino de una subred existente o una ruta de subred de intercambio de tráfico, Google Cloud no crea ninguna ruta dinámica personalizada para el prefijo en conflicto. Por ejemplo, cuando existe una subred o una ruta de subred de intercambio de tráfico con destino 10.70.1.0/24, si los routers de Cloud Router en la red de VPC reciben el prefijo 10.70.1.0/24 a través de BGP, Google Cloud usa la subred o ruta de subred de intercambio de tráfico y no crea ninguna ruta dinámica personalizada para 10.70.1.0/24.
- Cuando se crea una subred o una ruta de subred de intercambio de tráfico cuyo destino coincide con exactitud con un prefijo aprendido por los routers de Cloud Router en la red de VPC, Google Cloud quita la ruta dinámica personalizada para el prefijo en conflicto, de modo que deja espacio para la subred o la ruta de subred de intercambio de tráfico.
Cuando los routers de Cloud Router aprenden prefijos que se ajustan al destino de una subred existente o una ruta de subred de intercambio de tráfico, Google Cloud no crea ninguna ruta dinámica personalizada para los prefijos en conflicto. Por ejemplo, cuando existe una subred o una ruta de subred de intercambio de tráfico con el destino 10.70.1.0/24, si los routers de Cloud Router en la red de VPC reciben los prefijos 10.70.1.0/25 y 10.70.1.128/25 a través de BGP, Google Cloud usa la subred o la ruta de subred de intercambio de tráfico y no crea rutas dinámicas personalizadas para 10.70.1.0/25 y 10.70.1.128/25.
- Cuando se crea una subred o una ruta de subred de intercambio de tráfico cuyo destino contiene prefijos aprendidos por los routers de Cloud Router de la red de VPC, Google Cloud quita las rutas dinámicas personalizadas para los prefijos en conflicto a fin de dejar espacio para la subred o la ruta de la subred de intercambio de tráfico.

Ciclo de vida de las rutas de subred

Las rutas de subred se crean, actualizan y borran cuando creas, modificas o borras subredes o sus rangos de direcciones IP de subred:

Cuando agregas una subred, Google Cloud crea una ruta de subred correspondiente para el rango de direcciones IP principal de la subred.
- Si expandes el rango de direcciones IP principal de una subred, Google Cloud actualiza el destino de la ruta de subred correspondiente.
- Si agregas o quitas un rango de direcciones IP secundario en una subred, Google Cloud crea o destruye una ruta de subred correspondiente para el rango secundario.
Las redes de VPC en modo automático crean una ruta de subred para los rangos de IP principales de cada una de sus subredes creadas de forma automática. Puedes borrar estas subredes solo si conviertes la red de VPC de modo automático a modo personalizado.
No puedes borrar una ruta de subred a menos que modifiques o borres la subred:
- Cuando quitas un rango secundario de una subred, la ruta de subred para ese rango secundario se quita de forma automática.
- Cuando quitas una subred, todas las rutas de subred para los rangos principal y secundario se borran automáticamente. No puedes borrar la ruta de subred para el rango principal de la subred de ninguna otra manera.

La cantidad de rutas de subred en una red de VPC está limitada por la cantidad máxima de rangos de IP de subred (principales y secundarios).

Rutas dinámicas

Cloud Router indica a la red de VPC que cree, actualice y quite rutas dinámicas según los mensajes del Protocolo de puerta de enlace fronteriza (BGP) que reciban, políticas de ruta de BGP aplicables (Vista previa) y Rutas aprendidas personalizadas de Cloud Router que configures. El plano de control de Cloud Router instala rutas dinámicas de forma regional en función del modo de enrutamiento dinámico de la red de VPC:

Si una red de VPC usa el modo de enrutamiento dinámico regional, los Cloud Routers de cada región crean rutas dinámicas solo en la misma región que Cloud Router.
Si una red de VPC usa el modo de enrutamiento dinámico global, los Cloud Routers de cada región crean rutas dinámicas en todas las regiones de la red de VPC.

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

Un adjunto de VLAN respaldado por una conexión de interconexión dedicada o una conexión de interconexión de socio
Un túnel de Cloud VPN, ya sea un túnel VPN con alta disponibilidad o una VPN clásica configurada para usar enrutamiento dinámico
Una instancia de VM del dispositivo de router en Network Connectivity Center

Si un siguiente salto para una ruta dinámica se vuelve inaccesible, el Cloud Router que administra su sesión de BGP le indica a la red de VPC que quite la ruta dinámica después de que se cumpla una de las siguientes condiciones:

El temporizador de reinicio ordenado del router de intercambio de tráfico caducó (si el par de BGP admite el reinicio ordenado).
El temporizador de espera del Cloud Router venció. El temporizador de retención de Cloud Router es proporcional al temporizador de keepalive de Cloud Router.

Google Cloud resuelve conflictos entre rutas dinámicas y rutas de subredes locales y de intercambio de tráfico, como se describe en Interacciones con rutas dinámicas.

Rutas de subred de intercambio de tráfico

Las rutas de subred de intercambio de tráfico definen rutas de acceso a los recursos en subredes en otra red de VPC que están conectadas a través del intercambio de tráfico entre redes de VPC. Si deseas obtener más información, consulta Opciones para intercambiar rutas de subredes.

Las rutas de subred locales y de intercambio de tráfico no pueden superponerse. Para obtener más información, consulta Interacciones de rutas de subred y intercambio de tráfico.

La cantidad de rutas de subred por grupo de intercambio de tráfico se controla mediante los rangos de subred por red por cuota de grupo de intercambio de tráfico.

Intercambio de tráfico de rutas estáticas y dinámicas

Cuando usas el intercambio de tráfico entre redes de VPC para conectar dos redes de VPC, puedes exportar rutas estáticas y dinámicas desde una red y, luego, importarlas a la otra red. Para obtener más información, consulte:

La cantidad de rutas estáticas por grupo de intercambio de tráfico y rutas dinámicas por región por grupo de intercambio de tráfico está limitada por cuotas de rutas estáticas y dinámicas por red.

Aplicabilidad y orden

Rutas aplicables

Cada instancia tiene un conjunto de rutas aplicables, que son un subconjunto de todas las rutas en la red de VPC. Las rutas aplicables son las posibles rutas de acceso de salida que un paquete puede tomar cuando se envía desde la instancia.

Se aplican rutas de acceso de retorno especiales cuando se enrutan a balanceadores de cargas de proxy, sistemas de verificación de estado y otros servicios de Google. Para obtener más información, consulta Rutas de acceso de retorno del balanceador de cargas. Estas rutas no se muestran en ninguna tabla de rutas.
Las rutas basadas en políticas se pueden aplicar a paquetes enviados desde instancias de VM de Compute Engine o a paquetes recibidos por los adjuntos de VLAN de Cloud Interconnect. Las rutas basadas en políticas solo se aplican si un paquete coincide con los criterios de la ruta basada en políticas.
Las rutas de subred locales y de intercambio de tráfico se aplican a todas las instancias. Excepto por las rutas basadas en políticas, ningún otro tipo de ruta puede tener un destino que coincida o se ajuste al destino de una ruta de subred local o de intercambio de tráfico. Para obtener más detalles sobre la resolución de conflictos entre rutas estáticas, dinámicas y de subred, consulta Interacciones de rutas dinámicas y subredes y Interacciones de rutas dinámicas y subredes.
Las rutas estáticas personalizadas se pueden aplicar a todas las instancias o a instancias específicas. Las rutas estáticas con un atributo de etiqueta se aplican a instancias que tienen esa misma etiqueta de red. Si la ruta no tiene una etiqueta de red, se aplica a todas las instancias de la red.
Las rutas dinámicas se aplican a las instancias según el modo de enrutamiento dinámico de la red de VPC.

Rutas de acceso de retorno especiales

Las redes de VPC tienen rutas especiales para ciertos servicios. Estas rutas se definen fuera de tu red de VPC, en la red de producción de Google. No aparecen en la tabla de ruta de la red de VPC. No puedes quitarlas ni anularlas, incluso si borras o reemplazas una ruta predeterminada en tu red de VPC. Sin embargo, puedes permitir o denegar paquetes mediante reglas de firewall de VPC, políticas de firewall de red o políticas de firewall jerárquicas.

Rutas de acceso de retorno del balanceador de cargas

Google Cloud usa rutas especiales fuera de tu red de VPC para entregar paquetes entre las siguientes opciones:

Sistemas cliente y backends del balanceador de cargas (para balanceadores de cargas de red de paso externos)
Sistemas proxy y backends del balanceador de cargas (para balanceadores de cargas de proxy externos)
Sondeadores de verificación de estado y backends del balanceador de cargas

Rutas entre proxies de Google Front End (GFE) y backends

Balanceadores de cargas de aplicaciones externos globales, Balanceadores de cargas de aplicaciones clásicos, Balanceadores de cargas de red de proxy clásico y Balanceadores de cargas de red de proxy externos globales usar sistemas de Google Front End (GFE) como proxies

Cuando un cliente envía una solicitud al balanceador de cargas, los GFE finalizan esa primera conexión TCP. Luego, los GFE abren una segunda conexión TCP a las VMs de backend. Google Cloud usa rutas definidas fuera de tu red de VPC para enrutar paquetes entre los proxies de GFE y las VMs de backend.

Rutas de acceso a backends de balanceadores de cargas de red externos

En el caso de los balanceadores de cargas de red de traspaso externos, Google Cloud usa rutas definidas fuera de la red de VPC para enrutar paquetes entre clientes y VMs de backend.

Verificaciones de estado para todos los tipos de balanceadores de cargas

Los paquetes enviados desde los sistemas de sondeo de verificación de estado de Google Cloud usan fuentes de paquetes documentadas en Rangos de IP del sondeo y reglas de firewall.

IAP

Google Cloud incluye rutas hacia y desde 35.235.240.0/20 en cada red de VPC para admitir el reenvío de TCP mediante IAP. La red de producción de Google usa 35.235.240.0/20 como un rango solo interno. Los siguientes saltos de 35.235.240.0/20 se encuentran completamente dentro de la red de producción de Google.

Cloud DNS y Directorio de servicios

Google Cloud incluye rutas desde y hacia 35.199.192.0/19 en cada red de VPC para admitir los destinos de reenvío de Cloud DNS que usan enrutamiento privado, los servidores de nombres alternativos de Cloud DNS que usan enrutamiento privado y el acceso a la red privada para el Directorio de servicios. La red de producción de Google usa 35.199.192.0/19 como un rango solo interno. Los siguientes saltos de 35.199.192.0/19 están completamente dentro de la red de producción de Google.

Acceso a VPC sin servidores

Google Cloud incluye rutas hacia y desde 35.199.224.0/19 en cada red de VPC para admitir el Acceso a VPC sin servidores. La red de producción de Google usa 35.199.224.0/19 como un rango solo interno. Los siguientes saltos de 35.199.224.0/19 se encuentran completamente dentro de la red de producción de Google.

Orden de enrutamiento

En el siguiente proceso, se modela el comportamiento de selección de ruta de la red de VPC, comenzando con el conjunto de rutas aplicables que se describen en la sección anterior.

Rutas de acceso de retorno especiales: Las rutas de acceso de retorno especiales no se muestran en la tabla de ruta de la red de VPC. Las rutas que configuras en una red de VPC no se aplican a los paquetes de respuesta para ciertos balanceadores de cargas de Google Cloud, sistemas de verificación de estado, Identity-Aware Proxy (IAP) y proxies de Cloud DNS. Para obtener detalles, consulta Rutas de acceso de retorno especiales.

Si se aplica una ruta de retorno especial, tu modelo de selección de ruta solo contiene la ruta de retorno especial. Se ignoran todas las demás rutas y la evaluación se detiene en este paso.
Rutas basadas en políticas: Las rutas basadas en políticas se evalúan después de rutas de retorno especiales, pero antes de otros tipos de rutas. Si no hay rutas basadas en políticas en la red de VPC, Google Cloud omite este paso y continúa con el paso más específico.
- Google Cloud evalúa las rutas basadas en políticas solo por su prioridad. Google Cloud evalúa el origen y el destino de un paquete para cada ruta basada en políticas, a partir de la ruta o 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 basada en políticas y continúa evaluando la siguiente ruta basada en políticas en la lista ordenada. La siguiente ruta basada en políticas que se evaluará puede compartir la misma prioridad que la ruta ignorada en la política o puede tener una prioridad más baja.
- Si las características de un paquete no coincide con cualquier ruta basada en políticas después de evaluar todas las rutas basadas en políticas en tu modelo de selección de ruta, Google Cloud ignora todas las rutas basadas en políticas y continúa con el paso de destino más específico.
- Si las características de un paquete coinciden con una ruta basada en políticas de prioridad más alta, Google Cloud primero ignora todas las rutas basadas en políticas de prioridad más baja. 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 tienen prioridades idénticas. Google Cloud ignora las rutas basadas en políticas restantes si las características de un paquete no coinciden. Después de este paso, tu modelo de selección de ruta puede contener una o más rutas basadas en políticas.
  - Si tu modelo de selección de ruta incluye dos o más rutas basadas en políticas de prioridad más alta coincidentes, Google Cloud selecciona una sola 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 con 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 ruta solo incluye una única ruta basada en políticas de mayor prioridad que está configurada para omitir otras rutas basadas en políticas, Google Cloud evalúa las rutas que no están basadas en políticas en el paso de destino más específico e ignora todas las rutas basadas en políticas.
  - Si tu modelo de selección de ruta incluye solo una ruta de prioridad de política de mayor prioridad que no está configurada para omitir otras rutas basadas en políticas, Google Cloud entrega el paquete al balanceador de cargas de red de paso interno de siguiente salto y omite todas las rutas no basadas en políticas.
Destino más específico: Google Cloud determina cuál de las rutas aplicables tiene el destino más específico que contiene la dirección IP de destino del paquete. Google Cloud ignora todas las demás rutas con destinos menos específicos. Por ejemplo, 10.240.1.0/24 es un destino más específico que 10.240.0.0/16. El destino más específico podría ser cualquier tipo de ruta. Sin embargo, las rutas de subred, las rutas de subred de intercambio de tráfico y las rutas de retorno especiales son las más específicas por definición.

Después de este paso, tu modelo de selección de ruta no contiene rutas de acceso de retorno especiales ni rutas basadas en políticas. Solo incluye las rutas con los destinos más específicos.
Siguientes saltos en una sola red de VPC: Este paso solo es aplicable si la red de VPC cuyo comportamiento de ruta estás modelando está conectada a una o más redes de VPC mediante el intercambio de tráfico entre redes de VPC. Con el intercambio de tráfico entre redes de VPC, las rutas personalizadas con destinos idénticos pueden existir en más de una de las redes del grupo de intercambio de tráfico. El requisito modelado en este paso es que Google Cloud seleccione los siguientes saltos que se encuentran en una sola red de VPC.
- Si una o más de las rutas en tu modelo de ruta tienen siguientes saltos dentro de la red de VPC que estás modelando, ignora todas las rutas que tienen siguientes saltos en redes de intercambio de tráfico. En esta situación, Google Cloud solo usa los siguientes saltos en la red de VPC local, incluso si los siguientes saltos para el mismo destino existen en una o más redes de VPC de intercambio de tráfico.
- Si ninguna de las rutas en tu modelo de ruta tiene siguientes saltos dentro de la red de VPC que estás modelando, y todos los siguientes saltos existen en varias redes de intercambio de tráfico, Google Cloud usa un algoritmo interno a fin de seleccionar una sola red de intercambio de tráfico con los siguientes saltos para los destinos más específicos. En este punto, no se tiene en cuenta la prioridad de ruta. Además, si tu red de VPC intercambia tráfico con una red de VPC nueva o si se desconecta de una red de VPC con intercambio de tráfico existente, la red de VPC seleccionada para los siguientes saltos puede cambiar.
Después de este paso, tu modelo de selección de ruta solo contiene las rutas con los destinos más específicos, y los siguientes saltos de estas rutas se encuentran en una sola red de VPC.
Ignora las rutas estáticas personalizadas cuyos próximoss saltos no están en ejecución: En este paso, se modelan dos situaciones en las que Google Cloud ignora los próximos saltos que considera que no están en ejecución. Este paso solo se aplica a las rutas estáticas personalizadas. En su lugar, las rutas dinámicas personalizadas se agregan y quitan de forma automática mediante anuncios de BGP.
- Google Cloud ignora cada instancia de VM de siguiente salto (next-hop-instance o next-hop-address) si se detiene o se borra la VM de siguiente salto. Para obtener más detalles, consulta Comportamiento cuando las instancias se detienen o se borran en la sección Consideraciones para instancias de siguiente salto. Si tu modelo de ruta contiene rutas estáticas cuyas VM de siguiente salto se detienen o borran, quita esas rutas de tu modelo.
- Google Cloud ignora todas las rutas estáticas personalizadas que usan un túnel de VPN clásica de siguiente salto si el túnel no tiene una asociación de seguridad (SA) de fase 1 (IKE). Para obtener más detalles, consulta Orden de las rutas en la documentación de VPN clásica. Si tu modelo de ruta contiene rutas estáticas cuyos siguientes saltos son túneles de VPN clásica sin SA de IKE establecidas, quita esas rutas de tu modelo.
Ignora las rutas de prioridad baja: En este paso, se modela cómo Google Cloud ignora todas las rutas, excepto las que tienen la prioridad más alta.

Después de este paso, tu modelo de selección de ruta puede estar vacío o puede contener una o más rutas. Si tu modelo contiene rutas, todas estas tienen todas estas características:
- Destinos idénticos y más específicos
- Todos los siguientes saltos en la misma red de VPC: la red de VPC local o una sola red de VPC con intercambio de tráfico.
- Siguientes saltos que no se sabe que estén inactivos
- Prioridades idénticas y más altas

Selecciona solo la categoría de preferencia más favorable: Google Cloud evita el enrutamiento ECMP entre los diferentes tipos de siguientes saltos. Para modelar este comportamiento, considera el sistema de categoría de preferencia descrito en la siguiente tabla. En este paso, se define mejor el modelo de ruta para que solo contenga rutas que son del mismo tipo de ruta o una combinación del tipo de ruta y el tipo de siguiente salto.

Categoría de preferencia	Combinación de categoría y siguiente salto
Primera opción (preferencia más alta)	Rutas estáticas personalizadas con una instancia de siguiente salto en ejecución (`next-hop-instance` o `next-hop-address`) o un túnel de VPN clásica de siguiente salto establecido con SA de IKE
Segunda opción	Rutas dinámicas personalizadas aprendidas de cualquier sesión de BGP de cualquier Cloud Router
Tercera opción	Una sola ruta estática personalizada con un próximo salto del balanceador de cargas de red de transferencia interno Google Cloud usa un algoritmo interno para seleccionar un balanceador de cargas de red de transferencia interno de próximo salto, ignorando los otros próximos saltos del balanceador de cargas de red de transferencia interno con la misma prioridad. Para obtener más detalles, consulta “El mismo destino y varios balanceadores de cargas de red de transferencia internos de próximo salto” en la sección Consideraciones para próximos saltos del balanceador de cargas de red de transferencia interno.
Cuarta opción	Una ruta estática personalizada con el siguiente salto `default-internet-gateway`

Al final de este paso, puede haber cero, una, dos o más rutas en el modelo de ruta.

Enviar o descartar paquete: Lo que sucede depende de la cantidad de rutas restantes en el modelo de ruta:
- Si el modelo de ruta está vacío, el paquete se descarta con un error de destino de ICMP o red inaccesible. Google Cloud nunca recurre a una ruta menos específica que pueda tener un siguiente salto en funcionamiento.
- Si el modelo de ruta contiene una sola ruta, Google Cloud envía el paquete al siguiente salto. Para los siguientes saltos de VM, Google Cloud no valida que el siguiente salto de VM pueda procesar paquetes. Para obtener más información, consulta Consideraciones comunes de próximos saltos de balanceadores de cargas de red de transferencia internos y de instancias. Si la ruta única es una ruta de subred o una ruta de subred de intercambio de tráfico y no hay un recurso de Google Cloud en la dirección IP de destino del paquete, el paquete se descarta.
- Si el modelo de ruta contiene dos o más rutas, las rutas comparten el mismo destino más específico, se ubican en una sola red de VPC, tienen siguientes saltos que no se sabe que estén inactivos, tienen la misma prioridad más alta y pertenecen a una combinación de tipo de ruta y siguiente salto (categoría de preferencia). Google Cloud distribuye paquetes entre los siguientes saltos que implementan rutas múltiples de igual costo (ECMP) mediante un algoritmo de hash. Los cálculos de hash se realizan para cada paquete en el momento en que se envía, en función de la cantidad actual de siguientes saltos. Google Cloud usa un hash de cinco tuplas si el paquete contiene información de puertos. De lo contrario, usa un hash de tres tuplas. Si el modelo de ruta cambia a medida que se envían paquetes posteriores, Google Cloud podría dirigir esos paquetes a un siguiente salto diferente, incluso si el hash es el mismo.

Rutas estáticas

Puedes crear rutas estáticas de las siguientes dos maneras:

Puedes crear rutas estáticas de forma manual mediante la consola de Google Cloud, gcloud compute routes create o la API de routes.insert.
Si usas la consola de Google Cloud para crear un túnel de VPN clásica que no use el enrutamiento dinámico, es posible que Cloud VPN cree rutas estáticas correspondientes de forma automática. Para obtener más información, consulta Redes y enrutamiento de túneles de Cloud VPN.

Puedes intercambiar rutas estáticas con una red de VPC con intercambio de tráfico, como se describe en Opciones para intercambiar rutas estáticas personalizadas en la documentación de intercambio de tráfico entre redes de VPC.

Parámetros de ruta

Las rutas estáticas admiten los siguientes atributos:

Nombre y Descripción. Estos campos identifican la ruta. El nombre es obligatorio, pero la descripción es opcional. Cada ruta en el proyecto debe tener un nombre único.
Red. Cada ruta debe estar asociada con solo una red de VPC.
Siguiente salto. El próximo salto identifica el recurso de red al que se envían los paquetes. Todos los tipos de próximo salto admiten destinos de IPv4, mientras que algunos tipos de próximo salto admiten destinos de IPv6. Para obtener más información, consulta Próximos saltos y características.
Rango de destino. El rango de destino es una sola notación CIDR IPv4 o IPv6. Los destinos de las rutas estáticas deben seguir las reglas descritas en Interacciones con rutas estáticas personalizadas y en Interacciones con rutas estáticas y de subred. El destino más amplio posible para una ruta estática IPv4 es 0.0.0.0/0. El destino más amplio posible para una ruta estática IPv6 es ::/0.
Prioridad. Los números más bajos indican prioridades más altas. La prioridad más alta posible es 0, y la prioridad más baja posible es 65,535.
Etiquetas de red. Puedes hacer que una ruta estática se aplique solo a instancias de VM seleccionadas en la red de VPC, identificadas por una etiqueta de red. Si no especificas una etiqueta de red, Google Cloud hace que la ruta estática se aplique a todas las instancias de la red. Las rutas estáticas con etiquetas nunca se intercambian cuando se usa el intercambio de tráfico entre redes de VPC.

Próximos saltos y características

En la siguiente tabla, se resume la compatibilidad de características de ruta estática por tipo de próximo salto:

Tipo de salto siguiente	IPv4	IPv6	ECMP¹
Puerta de enlace de próximo salto (`next-hop-gateway`) Especifica una puerta de enlace de Internet predeterminada para definir una ruta de acceso a direcciones IP externas.
Instancia de próximo salto por nombre y zona (`next-hop-instance`) Envía paquetes a una VM de próximo salto que se identifica por nombre y zona y se encuentra en el mismo proyecto como la ruta. A fin de obtener más información, consulta Consideraciones para instancias de próximo salto.
Instancia de próximo salto por dirección (`next-hop-address`) Envía paquetes a una VM de próximo salto que identifica la dirección IPv4 principal de su interfaz de red. A fin de obtener más información, consulta Consideraciones para instancias de próximo salto.
Balanceador de cargas de red de transferencia interna de próximo salto por nombre y región de la regla de reenvío (`next-hop-ilb`) Envía paquetes a backends de un balanceador de cargas de red de transferencia interno identificado por el nombre y la región de la regla de reenvío. Para obtener más información, consulta Consideraciones para próximos saltos de balanceador de cargas de red de transferencia interna.
Balanceador de cargas de red de transferencia interna de próximo salto por dirección (`next-hop-ilb`). Envía paquetes a backends de un balanceador de cargas de red de paso interno que se identifica mediante la dirección IP de la regla de reenvío del balanceador de cargas. Para obtener más información, consulta Consideraciones para próximos saltos de balanceador de cargas de red de transferencia interna.
Túnel de VPN clásica de próximo salto (`next-hop-vpn-tunnel`) Envía paquetes a un túnel de VPN clásica de próximo salto mediante el enrutamiento basado en políticas o VPN basadas en rutas. A fin de obtener más información, consulta Consideraciones para próximos saltos de túnel de VPN clásica.

¹Multiruta de igual costo (ECMP) significa que dos o más rutas estáticas pueden compartir el mismo rango de destino y prioridad. Aunque puedes crear dos o más rutas estáticas en una red de VPC con el mismo destino, la misma prioridad y el próximo salto de puerta de enlace de Internet predeterminado, el efecto es el mismo que tener una sola ruta estática que use el próximo salto de puerta de enlace de Internet predeterminado para ese destino y prioridad.

Proyecto y red de próximo salto

Un próximo salto de ruta estática está asociado a una red de VPC y a un proyecto:

Red: excepto según se indica en la tabla que aparece a continuación, la red de VPC del próximo salto debe coincidir con la red de VPC de la ruta.
Proyecto: Excepto por lo que se indica en la tabla a continuación, el próximo salto debe estar ubicado en el proyecto que contiene la red de VPC del próximo salto (un proyecto independiente o un proyecto host de VPC compartida). Algunos próximos saltos se pueden ubicar en los proyectos de servicio de VPC compartida.

Tipo de salto siguiente	Puede estar en una red de VPC con intercambio de tráfico	Puede estar en un proyecto de servicio de VPC compartida
Puerta de enlace del próximo salto: (`next-hop-gateway`)
Instancia de próximo salto por nombre (`next-hop-instance`)
Instancia de próximo salto por dirección (`next-hop-address`)
Balanceador de cargas de red de transferencia interna de próximo salto por nombre y región de la regla de reenvío (`next-hop-ilb`)
Balanceador de cargas de red interno de próximo salto por dirección (`next-hop-ilb`)
Túnel de VPN clásica de próximo salto (`next-hop-vpn-tunnel`)

Consideraciones comunes de próximos saltos de balanceadores de cargas de red de transferencia interno y de instancias

El enrutamiento basado en instancias hace referencia a una ruta estática con un siguiente salto que es una instancia de VM (next-hop-instance o next-hop-address).

El balanceador de cargas de red de transferencia interno como próximo salto hace referencia a una ruta estática con un próximo salto que es un balanceador de cargas de red de transferencia interno (next-hop-ilb).

Si configuras el enrutamiento basado en instancias o un balanceador de cargas de red de transferencia interno como un próximo salto, ten en cuenta los siguientes lineamientos:

Debes configurar las VM de backend o la instancia de siguiente salto para reenviar paquetes desde cualquier dirección IP de origen. Para configurar el reenvío, habilita el reenvío de IP (can-ip-forward) por VM cuando crees la VM. Para las VM creadas de forma automática como parte de un grupo de instancias administrado, habilita el reenvío de IP en la plantilla de instancias que usa el grupo de instancias. Debes hacer que esta configuración cambie además de realizar cualquier otro ajuste de la configuración del sistema operativo que sea necesario para enrutar paquetes.
El software que se ejecuta en la VM de backend o en la instancia de siguiente salto debe configurarse de forma correcta. Por ejemplo, las VM de dispositivos de terceros que funcionan como routers o firewalls se deben configurar de acuerdo con las instrucciones del fabricante.
Las VM de backend o la instancia de siguiente salto deben tener reglas de firewall adecuadas. Debes configurar las reglas de firewall que se aplican a los paquetes enrutados. Ten en cuenta lo siguiente:
- Las reglas de firewall de entrada aplicables a instancias que realizan funciones de enrutamiento deben incluir las direcciones IP de las fuentes de los paquetes enrutados. La regla de denegación de acceso implícita bloquea todos los paquetes entrantes, por lo que al menos debes crear reglas de firewall de permiso de entrada personalizadas.
- Las reglas de firewall de salida aplicables a instancias que realizan funciones de enrutamiento deben incluir las direcciones IP de los destinos de los paquetes enrutados. La regla de permiso de salida implícita lo permite, a menos que hayas creado una regla de denegación de salida específica para anularla.
- Ten en cuenta si la VM de backend o la instancia de siguiente salto realiza la traducción de direcciones de red (NAT) cuando crea las reglas de firewall.
Para obtener más información, consulta Reglas de firewall implícitas.
La región de origen de un paquete enviado por una VM de backend o una instancia de próximo salto es la región en la que se encuentra la VM de backend o la instancia de próximo salto. Por ejemplo, los paquetes procesados por VMs de backend o instancias de próximo salto en us-west1 se pueden enviar a destinos a los que solo se puede acceder en us-west1, incluso si la VM de backend o la instancia de próximo salto originalmente recibió el paquete de un recurso en una región diferente de us-west1. Los siguientes son algunos ejemplos de recursos a los que solo se puede acceder en la misma región que una VM que envía un paquete:
- Balanceadores de cargas de red de paso interno, balanceadores de cargas de aplicaciones internos y balanceadores de cargas de red de proxy interno regional con el acceso global desactivado
- Túneles de Cloud VPN, adjuntos de VLAN de Cloud Interconnect y VM del dispositivo de router de conectividad de red si la red de VPC usa enrutamiento dinámico regional

Consideraciones para instancias de siguiente salto

Próximo salto por nombre y zona de instancia (next-hop-instance): Cuando creas una ruta estática que tiene una instancia de próximo salto especificada por nombre de instancia y zona, Google Cloud requiere lo siguiente: existe una instancia con ese nombre en la zona especificada y cumple con lo siguiente:
- La instancia se encuentra en el mismo proyecto que la ruta.
- La instancia tiene una interfaz de red (NIC) en la red de VPC de la ruta (no una red de VPC con intercambio de tráfico).
Siempre que exista una ruta estática cuyo próximo salto se especifique por nombre de zona y zona, se aplica lo siguiente:
- Google Cloud actualiza de forma automática la programación para el próximo salto en cualquiera de los siguientes casos:
  - Cambia la dirección IPv4 interna principal de la instancia de próximo salto.
  - Reemplazas la instancia de próximo salto, y la instancia de reemplazo tiene el mismo nombre, está en la misma zona y proyecto, y tiene una interfaz de red en la red de VPC de la ruta.
- Google Cloud no actualiza la programación del próximo salto en los siguientes casos:
  - Cuando se borra la instancia
  - El rango de direcciones IPv6 asignado a los cambios de NIC de la instancia
  - Cuando se anula la asignación de la dirección IPv4 o IPv6 de la instancia
Dirección IP interna de la instancia de próximo salto (next-hop-address): Cuando creas una ruta estática que tiene una instancia de próximo salto especificada por una dirección IPv4 interna, Google Cloud Verifica que la dirección IPv4 de la VM de próximo salto se ajuste a un rango IPv4 de subred de una subred en la red de VPC de la ruta. Sin embargo, Google Cloud programa la ruta solo si la dirección del próximo salto es una dirección IPv4 interna principal que se asigna a una NIC de VM en la red de VPC de la ruta (no una red de VPC con intercambio de tráfico).

Google Cloud actualiza la programación de forma automática para el próximo salto cuando la dirección IPv4 del próximo salto se mueve a una VM diferente, siempre que la VM de reemplazo cumpla con los mismos requisitos.
Instancias de próximo salto en proyectos de servicio de VPC compartida: Cuando especificas una VM de próximo salto por dirección IP, la VM puede estar ubicada ya sea en el mismo proyecto que la ruta (un proyecto independiente o un proyecto host de VPC compartida) o la VM se puede encontrar en un proyecto de servicio de VPC compartida. Cuando especificas una VM de próximo salto por zona y nombre de instancia, la VM de próximo salto debe estar ubicada en el mismo proyecto que la ruta y la red de VPC (un proyecto independiente o un proyecto host de VPC compartida).
Latencia y costos de región a región: Cuando usas una VM como un siguiente salto, el siguiente salto se encuentra en una zona de una región. La ruta que usa el siguiente salto está disponible para todas las instancias en la misma red de VPC o para seleccionar instancias con una etiqueta de red coincidente. Google Cloud no tiene en cuenta la distancia regional para las rutas que usan una instancia como siguiente salto, por lo que es posible crear una ruta que envíe tráfico a una VM de siguiente salto en una región diferente. Enviar paquetes de una región a otra agrega costos de transferencia de datos salientes y agrega latencia a la red.
No hay verificación de estado ni validación de configuración: Google Cloud nunca verifica si una instancia de próximo salto cumple con todos los requisitos descritos en la sección Consideraciones comunes de próximos saltos de balanceadores de cargas de red de transferencia internos y de instancias. Inhabilitar la interfaz de red de la VM mediante la configuración del sistema operativo invitado de la instancia no hace que Google Cloud ignore la instancia del siguiente salto.
No hay hash simétrico cuando se conectan dos redes de VPC: Google Cloud no ofrece hash simétrico cuando se usan dos o más VM de siguiente salto que tienen varias interfaces de red en una configuración que cumple con todos los criterios siguientes:
- Las VM tienen una interfaz de red en una red de VPC y otra interfaz en una segunda red de VPC.
- En cada red de VPC, existe un conjunto de al menos dos rutas estáticas personalizadas para el mismo destino, con la misma prioridad, y cada ruta del conjunto hace referencia a una VM de siguiente salto única.
Si usas dos o más VM con varias interfaces para conectar redes de VPC y necesitas que la misma VM procese paquetes para una conexión determinada en ambas direcciones, necesitas hash simétrico, que solo es compatible con los balanceadores de cargas de red internos de próximo salto. Para obtener detalles sobre el hash simétrico, consulta Hash simétrico en la documentación de los balanceadores de cargas de red de transferencia internos como próximos saltos.
Comportamiento cuando se detienen o borran instancias: Google Cloud no te impide detener ni borrar una VM de próximo salto de ruta estática (especificada por nombre y zona o por la dirección interna). Cuando una VM de próximo salto no está en ejecución, el enrutamiento del destino depende de si existen otras rutas para el mismo destino y si esas otras rutas tienen próximos saltos. Para ilustrar este comportamiento, considera los siguientes ejemplos:
- Los paquetes cuyos destinos se ajustan a 192.168.168.0/24 se envían al próximo salto de route-vm-b en la siguiente situación en la que no se ejecuta el próximo salto para la ruta de mayor prioridad. Este enrutamiento se produce porque Google Cloud ignora los próximos saltos que no se ejecutan antes de considerar el paso de ignorar las rutas de prioridad baja del orden de enrutamiento:
  - route-vm-a, destino 192.168.168.0/24, prioridad 10, la VM de próximo salto se detiene
  - route-vm-b, destino 192.168.168.0/24, prioridad 20, la VM de próximo salto se ejecuta
  - route-vm-c, destino 192.168.168.0/24, prioridad 30, la VM de próximo salto se ejecuta
- En este ejemplo, se descartan los paquetes cuyos destinos se ajustan a 192.168.168.0/24, en el que todas las VM de próximo salto para las rutas 192.168.168.0/24 no se ejecutan, aunque una ruta para el 192.168.0.0/16 más amplio tenga una VM de próximo salto que se ejecuta. Los paquetes se descartan porque Google Cloud ignora las rutas con rangos de destino más amplios (máscara de subred) en el paso de destino más específico, que ocurre antes del paso de ignorar rutas estáticas personalizadas cuyos próximos saltos no se estén ejecutando del orden de enrutamiento:
  - route-vm-x, destino 192.168.168.0/24, prioridad 10, se detiene la VM de próximo salto
  - route-vm-y, destino 192.168.168.0/24, prioridad 20, se detiene la VM de próximo salto
  - route-vm-z, destino 192.168.0.0/16, prioridad 0, la VM de próximo salto se está ejecutando

Consideraciones para próximos saltos de balanceadores de cargas de red de transferencia internos

Reglas de reenvío compatibles. Google Cloud solo admite reglas de reenvío del balanceador de cargas de red de traspaso interno del próximo salto. Google Cloud no admite reglas de reenvío de próximo salto que usan otros balanceadores de cargas, reenvío de protocolos o extremos de Private Service Connect.
Métodos de especificación y red y proyecto de la regla de reenvío. Puedes especificar una regla de reenvío de próximo salto mediante uno de los siguientes tres métodos. El método de especificación que uses determina si la red de la regla de reenvío debe coincidir con la red de la ruta y en qué proyecto se puede ubicar la regla de reenvío:
- Por nombre (--next-hop-ilb) y región (--next-hop-ilb-region) de la regla de reenvío: Cuando especificas una regla de reenvío de próximo salto por nombre y región, la red de la regla de reenvío debe coincidir con la red de VPC de la ruta. La regla de reenvío debe estar ubicada en el mismo proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto host de VPC compartida).
- Por vínculo de recurso de la regla de reenvío: El vínculo del recurso de una regla de reenvío usa el siguiente formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, donde PROJECT_ID es el ID del proyecto que contiene la regla de reenvío, REGION es la región de la regla de reenvío y FORWARDING_RULE_NAME es el nombre de la regla de reenvío. Cuando especificas una regla de reenvío de próximo salto por su vínculo de recurso, la red de la regla de reenvío debe coincidir con la red de VPC de la ruta. La regla de reenvío se puede ubicar en ya sea en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto host de VPC compartida) o en un proyecto de servicio de VPC compartida.
- Por una dirección IPv4 de la regla de reenvío: cuando especificas una regla de reenvío de próximo salto por su dirección IPv4, la red de la regla de reenvío puede ser tanto la red de VPC de la ruta como una red de VPC con intercambio de tráfico. La regla de reenvío se puede ubicar ya sea en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto host de VPC compartida) o en un proyecto de servicio de VPC compartida.
Efecto del acceso global. Las rutas estáticas personalizadas que usan los próximos saltos del balanceador de cargas de red de transferencia interno se programan en todas las regiones. La posibilidad de que el siguiente salto se pueda usar depende del parámetro de configuración de acceso global del balanceador de cargas. Con el acceso global habilitado, se puede acceder al siguiente salto del balanceador de cargas en todas las regiones de la red de VPC. Con el acceso global inhabilitado, solo se puede acceder al siguiente salto del balanceador de cargas en la misma región del balanceador de cargas. Con el acceso global inhabilitado, los paquetes enviados desde otra región a una ruta mediante un próximo salto de balanceador de cargas de red de transferencia interno se descartan.
Cuando todos los backends están en mal estado. Cuando todos los backends de un balanceador de cargas de red de transferencia interno no aprueban las verificaciones de estado, las rutas que usan ese próximo salto de balanceador de cargas aún están activas. Los paquetes que procesa la ruta se envían a uno de los backends del balanceador de cargas del siguiente salto según la distribución de tráfico.
No se admiten las reglas de reenvío que usen una dirección IP interna común (--purpose=SHARED_LOADBALANCER_VIP). Los balanceadores de cargas de red de transferencia internos de próximo salto y las reglas de reenvío del balanceador de cargas de red de transferencia interno con una dirección IP común son funciones excluyentes entre sí. Un balanceador de cargas de red de transferencia interno de próximo salto debe usar una dirección IP que sea única para la regla de reenvío del balanceador de cargas para que solo se haga referencia a un servicio de backend (un balanceador de cargas) sin ninguna ambigüedad. Es posible que las reglas de reenvío que usan una dirección IP interna común hagan referencia a diferentes servicios de backend (diferentes balanceadores de cargas de red de transferencia internos).
Varias rutas con los mismos destinos y prioridades, pero diferentes balanceadores de cargas de red de transferencia internos de próximo salto. Google Cloud nunca distribuye el tráfico entre dos o más balanceadores de cargas de red de transferencia internos de próximo salto mediante ECMP. En cambio, Google Cloud selecciona solo un balanceador de cargas de red de transferencia interno de próximo salto mediante un algoritmo interno y determinista. Para evitar esta ambigüedad, puedes usar etiquetas de red únicas para cada ruta.

Google Cloud selecciona un solo próximo salto cuando las rutas estáticas con diferentes próximos saltos de balanceador de cargas de red de transferencia interno tienen la misma prioridad y el mismo destino.
Varias rutas con los mismos destinos, prioridades y balanceadores de cargas de red de transferencia internos de próximo salto. Sin una etiqueta de red, Google Cloud no te permite crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y próximo salto de balanceador de cargas de red de transferencia interno. Con las etiquetas de red, puedes crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y próximo salto de balanceador de cargas de red de transferencia interno.

Consideraciones para siguientes saltos de túnel de VPN clásica

Costos y latencia de región a región: Google Cloud no tiene en cuenta la distancia regional de las rutas que usan un túnel de VPN clásica de siguiente salto. Enviar tráfico a un túnel de VPN clásica de siguiente salto en otra región agrega costos de transferencia de datos salientes y, además, ingresa la latencia de la red. Como práctica recomendada, usa un túnel de VPN con alta disponibilidad con enrutamiento dinámico, ya que esa configuración considera la distancia regional.
Comportamiento cuando los túneles de VPN clásica no se están ejecutando: Las rutas estáticas personalizadas cuyos próximos saltos son túneles de VPN clásica no se quitan de forma automática cuando los túneles de VPN clásica no están en ejecución. Para obtener detalles sobre lo que sucede cuando los túneles no están en ejecución, consulta Cuando los túneles están inactivos en la documentación de VPN clásica.

¿Qué sigue?

Para crear y administrar rutas, consulta Usa rutas.
Para obtener una descripción general de las redes de VPC de Google Cloud, consulta Redes de VPC.
Para crear, modificar o borrar redes de VPC, consulta Crea y administra redes de VPC.