Descripción general de Cloud Router

Cloud Router es un servicio Google Cloud totalmente distribuido y administrado que utiliza el Protocolo de Puerta de Enlace Fronteriza (BGP) para anunciar rangos de direcciones IP. Programa rutas dinámicas personalizadas en función de los anuncios de BGP que recibe de un par. En lugar de un dispositivo físico o un dispositivo, cada Cloud Router se implementa mediante tareas de software que actúan como bocinas y respuestas de BGP. Un Cloud Router también sirve como plano de control para Cloud NAT. Cloud Router proporciona servicios de BGP para los siguientes productos de Google Cloud:

También recomendamos Cloud Router para la VPN clásica si tu puerta de enlace de VPN local es compatible con BGP.

Cuando conectas tu red local a Google Cloud, Cloud Router usa BGP para intercambiar rutas de forma dinámica entre tu red de VPC de Google Cloud y tu red local. Los cambios de prefijo y siguiente salto se propagan de forma automática entre tu red de VPC y tu red local sin necesidad de usar rutas estáticas.

Cada Cloud Router funciona con uno de los productos de conectividad de red enumerados antes. El intercambio de tráfico directo y el intercambio de tráfico por proveedores no usan Cloud Routers.

Especificaciones

Un Cloud Router puede anunciar rutas de subredes y prefijos personalizados en sus sesiones de BGP. A menos que configures anuncios de ruta personalizados, un Cloud Router solo anuncia rutas de subredes. Los anuncios de ruta personalizados también te permiten configurar un Cloud Router para omitir las rutas de subred de publicidad.

El modo de enrutamiento dinámico de una red de VPC determina qué subred enruta los Cloud Routers en esa red:

  • Cuando se usa el modo de enrutamiento dinámico regional, cada Cloud Router en la red de VPC solo anuncia rutas de subred en la misma región que el Cloud Router.

  • Cuando se usa el modo de enrutamiento dinámico global, cada Cloud Router de la red de VPC anuncia todas las rutas de subred, de todas las regiones de la red de VPC.

El modo de enrutamiento dinámico también controla la manera en que cada Cloud Router aplica los prefijos aprendidos como rutas dinámicas personalizadas en una red de VPC. Para obtener detalles sobre este comportamiento, consulta Efectos del modo de enrutamiento dinámico.

Número de sistema autónomo (ASN)

Cuando creas un Cloud Router, eliges el ASN de Google para todas las sesiones de BGP que usa el Cloud Router. Las instrucciones para cada producto de conectividad de red que se enumeran en la sección Usa Cloud Router proporcionan detalles sobre cómo cada producto usa ASN.

Direcciones IP de BGP

Las sesiones de BGP para los siguientes productos de conectividad de red usan direcciones IP de vínculo local en el rango 169.254.0.0/16 como direcciones IP de BGP:

  • En la interconexión dedicada, puedes especificar candidatos para las direcciones IP de BGP de vínculo local, o Google Cloud puede seleccionar automáticamente las direcciones de vínculo local que no se usan.
  • En el caso de la interconexión de socio, Google Cloud selecciona las direcciones de vínculo local sin usar de forma automática.
  • En el caso de las VPN con alta disponibilidad y las VPN clásicas que usan enrutamiento dinámico, puedes especificar las direcciones IP de BGP cuando creas la interfaz de BGP en el Cloud Router.

Los dispositivos enrutadores usan direcciones IP internas de las VM de Google Cloud como direcciones IP de BGP. Para obtener más información, consulta la sección sobre cómo crear instancias de dispositivos del router.

Acceso a balanceadores de cargas internos

Para obtener detalles sobre cómo acceder a los balanceadores de cargas internos desde una red local conectada, consulta Balanceadores de cargas internos y redes conectadas en la documentación de Cloud Load Balancing.

Tareas de software de Cloud Router

Una o dos, o en raras ocasiones, tres tareas de software se implementan en Cloud Routers.

En la siguiente tabla, se proporcionan situaciones de ejemplo y la cantidad de tareas de software que Google Cloud usa para implementar Cloud Router en cada situación.

  • Para las configuraciones de alta disponibilidad enumeradas en la tabla, se usan dos tareas de software a fin de proporcionar redundancia de software.
  • En el caso de los adjuntos de VLAN, una tarea de software independiente controla cada dominio de disponibilidad perimetral con adjuntos.
Situación de ejemplo Cantidad de tareas de software usadas para implementar Cloud Router
Una o más interfaces, cada una conectada a un túnel de VPN clásica. Uno
Una o más interfaces, cada una conectada a un adjunto de VLAN, y los adjuntos de VLAN se encuentran en el mismo dominio de disponibilidad perimetral. Uno
Cualquier cantidad de interfaces, cada una conectada a un túnel VPN con alta disponibilidad, y los túneles están conectados a la misma cantidad de interfaces en una o más puertas de enlace de VPN con alta disponibilidad; por ejemplo, dos túneles, cada uno conectado a interface 0 en diferentes puertas de enlace de VPN con alta disponibilidad. Uno
Al menos dos interfaces, una conectada a un adjunto de VLAN en un dominio de disponibilidad perimetral único y otra conectada a un solo túnel VPN con alta disponibilidad, en el que el dominio de disponibilidad perimetral y los números de interfaz de la puerta de enlace VPN son los mismos (por ejemplo, el primer dominio de disponibilidad perimetral en un par de dominios de disponibilidad perimetral y la primera interfaz de puerta de enlace VPN). Uno
Al menos dos interfaces, cada una conectada a una instancia del dispositivo del router, y una de las interfaces está configurada como una interfaz redundante. Para crear una interfaz redundante, usa la marca redundant-interface (herramienta de línea de comandos de gcloud) o el campo redundantInterface (API de Compute Engine). El dispositivo de router es parte de Network Connectivity Center, que se encuentra en vista previa. Dos
Al menos dos interfaces, cada una conectada a un adjunto de VLAN, y los adjuntos de VLAN están en diferentes dominios de disponibilidad perimetral. Dos
Al menos dos interfaces, cada una de ellas conectada a un túnel VPN con alta disponibilidad, en la que cada túnel está conectado a diferentes números de interfaz de puerta de enlace de VPN con alta disponibilidad, por ejemplo, un túnel conectado a interface 0 de una puerta de enlace de VPN con alta disponibilidad y otro túnel conectado a interface 1 de la misma puerta de enlace o una puerta de enlace diferente. Dos
Un Cloud Router con al menos lo siguiente:
  • Una interfaz conectada a un adjunto de VLAN en edge availability domain 0 o una interfaz conectada a un túnel de VPN con alta disponibilidad que se conecta a interface 0 de una puerta de enlace de VPN con alta disponibilidad.
  • Una interfaz conectada a un adjunto de VLAN en edge availability domain 1 o una interfaz conectada a un túnel de VPN con alta disponibilidad que se conecta a interface 1 de una puerta de enlace de VPN con alta disponibilidad.
  • Una interfaz conectada a un túnel de VPN clásica.
Tres

Mantenimiento de software y reinicios de tareas automatizados

Google Cloud realiza eventos de mantenimiento regulares para lanzar funciones nuevas y mejorar la confiabilidad. Durante el mantenimiento, se aprovisionan nuevas tareas de software. Los registros del router local indican que las sesiones de BGP administradas por esas tareas de software fallaron y regresaron (una oscilación de BGP).

El mantenimiento de Cloud Router es un proceso automático y está diseñado para no interrumpir el enrutamiento. Se espera que los eventos de mantenimiento no tomen más de 60 segundos. Antes del mantenimiento, Cloud Router envía una notificación de reinicio ordenado (un paquete FIN de TCP) al router local.

Si tu router local puede procesar eventos de reinicio ordenados, registra un evento de reinicio ordenado durante el mantenimiento de Cloud Router. Para los routers locales que no admiten el reinicio ordenado, asegúrate de que el temporizador de espera del router local esté establecido en 60 segundos. Para obtener más información, consulta Administra temporizadores de BGP.

Los eventos de mantenimiento de Cloud Router no se anuncian con anticipación porque las rutas no se pierden en los routers locales configurados de forma correcta. Para obtener detalles sobre los eventos de mantenimiento finalizados, consulta Identifica eventos de mantenimiento del router.

Se reinician las tareas automáticas cuando cambian los identificadores de router

Las tareas de software de Cloud Router usan un identificador interno basado en la última interfaz de la lista de interfaces de Cloud Router. Si borras esa interfaz, Google Cloud reinicia las tareas de software de Cloud Router para asignarles identificadores nuevos. En consecuencia, borrar una sesión de BGP a veces puede provocar que todas las demás sesiones de BGP se reinicien como si se hiciera mantenimiento de software. Si esto sucede, las rutas se conservan en los routers locales configurados correctamente.

El identificador interno no es visible para ti y a veces cambia durante el mantenimiento del software y los reinicios automatizados de tareas.

Anuncios de ruta

A través de BGP, Cloud Router anuncia las direcciones IP a las que pueden acceder los clientes en tu red local. Tu red local envía a tus redes de VPC los paquetes que tienen una dirección IP de destino que coincide con un rango de IP anunciado. Después de acceder a Google Cloud, las reglas y rutas de firewall de tu red de VPC determinan cómo Google Cloud maneja los paquetes.

Puedes usar los anuncios predeterminados de Cloud Router o especificar explícitamente qué rangos de CIDR se anunciarán. Si no especificas anuncios, Cloud Router usa el predeterminado.

Anuncios de ruta predeterminados

De forma predeterminada, Cloud Router anuncia subredes en su región para el enrutamiento dinámico regional o todas las subredes de una red de VPC para el enrutamiento dinámico global. Cloud Router anuncia subredes nuevas automáticamente. Además, si una subred tiene un rango de IP secundario para configurar direcciones IP de alias, Cloud Router anuncia tanto la dirección IP primaria como la secundaria.

Cada sesión de BGP para un Cloud Router también tiene un anuncio predeterminado. De forma predeterminada, Cloud Router propaga sus anuncios de ruta a todas sus sesiones de BGP. Si configuras anuncios de ruta personalizados en un Cloud Router, sus sesiones de BGP heredan esos anuncios personalizados.

Especifica anuncios de ruta personalizados en los siguientes casos:

  • Para anunciar direcciones IP fuera del rango de IP principal de una subred o uno de sus rangos de IP secundarios. Por ejemplo, para anunciar direcciones IP externas.

  • Para anunciar rutas desde otra red de VPC conectada a tu red de VPC mediante el intercambio de tráfico entre redes de VPC. En este caso, un Cloud Router no anuncia automáticamente las rutas de la subred y las rutas personalizadas importadas de una red de intercambio de tráfico en tu red de VPC. Para anunciarlas, debes crear anuncios de rutas personalizados en Cloud Router en tu red de VPC. También debes asegurarte de que las conexiones de intercambio de tráfico de red de VPC estén configuradas para intercambiar las rutas personalizadas.

Cuando utilizas anuncios personalizados, puedes anunciar subredes o partes de una subred de forma selectiva. De esa manera, puedes evitar que se anuncien ciertas subredes. Si no necesitas estas capacidades, usa los anuncios predeterminados.

Anuncios de ruta personalizados

Cuando configuras anuncios de ruta personalizados, especificas explícitamente las rutas que debe anunciar un Cloud Router. En la mayoría de los casos, los anuncios personalizados son útiles para complementar el anuncio de subred predeterminado con direcciones IP personalizadas. Las direcciones IP personalizadas son direcciones que están fuera del rango de IP de una subred, como las direcciones IP externas reservadas. Sin anuncios de rutas personalizados, se te solicitará que crees y mantengas rutas estáticas para direcciones IP personalizadas.

Cuando configuras anuncios de rutas personalizados, puedes elegir anunciar todas las subredes, lo que emula el comportamiento predeterminado. Puedes elegir no anunciar todas las subredes y, en su lugar, anunciar subredes específicas o ciertos bloques de CIDR dentro de una subred. Por ejemplo, es posible que desees evitar que Cloud Router anuncie subredes particulares. Para ello, anuncia solo las subredes que deseas exponer. Sin embargo, cuando anuncias subredes de forma selectiva, debes agregar subredes nuevas de forma manual al anuncio de ruta personalizado. Cloud Router no anuncia automáticamente las subredes nuevas.

Puedes especificar anuncios de ruta personalizados en un Cloud Router o en una sesión de BGP. Los anuncios de rutas personalizados en Cloud Router se aplican a todas sus sesiones de BGP. Sin embargo, si especificas un anuncio de ruta personalizado en una sesión de BGP, el anuncio de ruta de la sesión de BGP ignora y anula el anuncio de ruta del Cloud Router.

Para cada Cloud Router, puedes especificar un máximo de 200 rangos CIDR. Cada sesión de BGP tiene el mismo límite de 200.

Ejemplos de anuncios de ruta

Los siguientes ejemplos muestran el comportamiento predeterminado y los escenarios de Cloud Router donde los anuncios de rutas personalizados podrían ser útiles. Los ejemplos suponen que hay una conexión existente entre las redes de VPC y las locales, como un túnel VPN con IPsec o una conexión de interconexión dedicada.

Anuncio de ruta predeterminado

Para el enrutamiento dinámico regional, Cloud Router anuncia subredes en su región. En el siguiente diagrama, Cloud Router anuncia subredes en la región us-central1. También anuncia el rango de IP secundario de alias-subnet. Si creas subredes nuevas en us-central1, Cloud Router las anuncia automáticamente. Cloud Router no anuncia las direcciones IP que no están incluidas en el rango de IP de una subred, como las direcciones IP externas.

Anuncio de ruta predeterminado de Cloud Router.
Anuncio de ruta predeterminado de Cloud Router (haz clic para ampliar)

Anuncio de dirección IP externa

Puedes usar una dirección IP estática externa para una aplicación de Google Cloud que entregue clientes en tu red local. Cuando realizas tareas de mantenimiento en la aplicación, puedes volver a asignar la dirección IP estática a otra VM para minimizar el tiempo de inactividad. Con los anuncios predeterminados de Cloud Router, debes configurar y mantener una ruta estática. En su lugar, puedes utilizar anuncios personalizados para anunciar la dirección IP externa a través de BGP.

En el siguiente diagrama, Cloud Router anuncia la dirección IP externa 1.2.3.4 del servidor proxy. La dirección IP externa se asigna a la dirección IP interna 10.20.0.2 del servidor. Cloud Router no anuncia la dirección IP interna del servidor proxy ni ninguna VM en la subred my-subnet. Los clientes locales solo conocen la dirección IP externa del servidor proxy.

Anuncio de dirección IP externa.
Anuncio de dirección IP externa (haz clic para ampliar)

Para obtener más información, consulta Cómo anunciar rangos de IP personalizados.

Restringe los anuncios de subred

Puedes evitar que se anuncien instancias para que queden ocultas. En el siguiente diagrama, Cloud Router anuncia subnet-1 y subnet-2. Los clientes de la red local pueden llegar a las VM de esas subredes, pero no a las VM de la subred unadvertised-subnet.

Anuncia subredes específicas en Cloud Router.
Anuncia subredes específicas en el Cloud Router (haz clic para ampliar)

Para obtener más información, consulta Cómo anunciar subredes de VPC específicas.

Anuncio de ruta por sesión de BGP

Supón que tienes recursos de producción y pruebas en tu red de VPC y en la red local, y organizaste esos recursos en diferentes subredes. En consecuencia, configura dos sesiones de BGP que anuncien diferentes rangos de direcciones IP. Cuando se utilizan dos sesiones de BGP diferentes, el tráfico vinculado a una subred no se dirige a otra subred de manera inadvertida. En el siguiente ejemplo, se muestran dos sesiones de BGP: prod-bgp que anuncia solo prod-subnet y test-bgp que solo anuncia test-subnet.

Anuncia subredes específicas en una sesión de BGP.
Anuncia subredes específicas en una sesión de BGP (haz clic para ampliar)

Para obtener más información, consulta Cómo anunciar rangos de IP personalizados o Cómo anunciar subredes de VPC específicas.

Rutas dinámicas personalizadas aprendidas

Cuando un Cloud Router recibe varios saltos siguientes para el mismo prefijo de destino, Google Cloud utiliza métricas de ruta y, en algunos casos, la longitud de ruta de acceso de AS para crear rutas dinámicas personalizadas en tu red de VPC. En las siguientes secciones, se describe el proceso.

Efectos del modo de enrutamiento dinámico

El modo de enrutamiento dinámico de una red de VPC determina cómo se aplican las rutas dinámicas personalizadas aprendidas de Cloud Router:

  • En el modo de enrutamiento dinámico regional, Cloud Router crea una ruta dinámica personalizada para el destino y el siguiente salto en la misma región que el Cloud Router. Cloud Router establece la prioridad para esa ruta dinámica personalizada en la prioridad base, que Cloud Router deriva del discriminante de varias salidas (MED) que anuncia tu router local.

  • En el modo de enrutamiento dinámico global, Cloud Router crea una ruta dinámica personalizada para el destino y el siguiente salto en cada región de Google Cloud. En la región que contiene el Cloud Router que aprendió esa ruta, Cloud Router establece la prioridad para la ruta dinámica personalizada en la prioridad base. En el resto de las regiones, Cloud Router establece la prioridad en la prioridad base más un costo de región a región adecuado.

Puedes definir la prioridad de ruta de las rutas a Google Cloud exportadas al router local. Sin embargo, tu router local puede anular esta prioridad de ruta, según su configuración. Por ejemplo, si tu router local modifica la prioridad de la ruta.

En las rutas a locales que aprendió Cloud Router, Cloud Router obtiene la longitud de la ruta de AS y los valores MED, y calcula una prioridad base como se describe en las siguientes dos secciones.

Anteposición de la ruta de acceso de AS y longitud de la ruta de acceso de AS

La anteposición de la ruta de AS es un medio que consiste en quitar la prioridad al siguiente salto de un destino (prefijo) de manera intencional a fin de que se seleccione un siguiente salto diferente para el mismo destino con una longitud de ruta de AS más corta. MED solo se considera cuando las longitudes de la ruta de AS de los siguientes saltos son iguales.

Google Cloud puede usar la ruta de AS para seleccionar el siguiente salto entre las sesiones de BGP que implementa la misma tarea de software de Cloud Router.

Cómo Google Cloud usa la ruta de acceso de AS

La anteposición de la ruta de acceso de AS es irrelevante para el plano de control y la red de VPC. La longitud de la ruta de acceso de AS solo se considera dentro de cada tarea de software de Cloud Router, como se describe en las siguientes situaciones.

Si una sola tarea de software de Cloud Router aprende el mismo destino de dos o más sesiones de BGP:

  • La tarea de software elegirá la sesión de BGP de siguiente salto que tiene la longitud de ruta de acceso de AS más corta.
  • La tarea de software enviará información de destino, siguiente salto y MED al plano de control de Cloud Router.
  • El plano de control usará la información para crear una o más rutas candidatas. La prioridad base de cada candidato se configura en la MED recibida.

Si dos o más tareas de software de Cloud Router aprenden el mismo destino de dos o más sesiones de BGP, se presentarán las siguientes situaciones:

  • Cada tarea de software seleccionará la sesión de BGP de siguiente salto que tiene la longitud de ruta de acceso de AS más corta.
  • Cada tarea de software enviará información de destino, siguiente salto y MED al plano de control de Cloud Router.
  • El plano de control usará la información para crear dos o más rutas candidatas. La prioridad base de cada candidato se configura en la MED recibida.

Luego, el plano de control de Cloud Router instalará una o más rutas dinámicas personalizadas en la red de VPC, según el modo de enrutamiento dinámico de la red de VPC. En el modo de enrutamiento dinámico global, la prioridad de cada ruta dinámica regional personalizada se ajusta en regiones distintas a la región de Cloud Router. Para obtener detalles sobre cómo Google Cloud selecciona una ruta, consulta Orden de enrutamiento en la documentación de VPC.

Prioridad base y MED

Cloud Router utiliza el valor MED anunciado por tu router de intercambio de tráfico para calcular una prioridad base:

  • Si el valor MED de un prefijo de destino está entre 0 y 231 -1 (inclusive), Cloud Router establece la prioridad base en el valor MED.
  • Si el valor MED para el prefijo de destino está entre 231 y 232 -1 (inclusive), Cloud Router establece la prioridad base en 231 -1.

El valor de prioridad final que Cloud Router establece cuando crea rutas dinámicas personalizadas depende del modo de enrutamiento dinámico de la red de VPC. Para obtener más información, consulta Efectos del modo de enrutamiento dinámico.

Rutas estáticas

Cuando una instancia envía un paquete, Google Cloud intenta seleccionar una ruta del conjunto de rutas aplicables de acuerdo con el orden de enrutamiento. Para obtener más detalles, consulta la sección Orden de enrutamiento en la documentación de VPC.

Rangos de IP superpuestos

En los casos en los que tengas una subred de VPC y un anuncio de ruta local con rangos de IP superpuestos, Google Cloud dirige el tráfico de salida en función de sus rangos de IP.

Para obtener más información, consulta la sección Rutas aplicables en la documentación de VPC.

Anuncia una ruta aprendida de una sesión de BGP a otra

En este momento, Cloud Router no admite anunciar una ruta local (a través de anuncios de ruta estática) aprendida de una sesión de BGP a otra. Si lo intentas, es posible que se descarte la ruta.

Para obtener más información sobre cómo intercambiar rutas dinámicas con varias redes de VPC de forma adecuada, consulta Algunos prefijos de IP locales no están disponibles en la página Solución de problemas de Cloud Router.

Límites de rutas aprendidas

Hay dos límites para las rutas aprendidas. Estos límites no definen directamente una cantidad máxima de rutas aprendidas. En cambio, definen la cantidad máxima de prefijos de destino únicos. Para obtener información sobre ellos, consulta Límites.

Para supervisar el uso de estos límites, usa las siguientes métricas:

  • router.googleapis.com/dynamic_routes/learned_routes/used_unique_destinations
  • router.googleapis.com/dynamic_routes/learned_routes/unique_destinations_limit
  • router.googleapis.com/dynamic_routes/learned_routes/any_dropped_unique_destinations

A fin de obtener información sobre los mensajes de registro relacionados con estos límites, las métricas que puedes usar para supervisarlos y cómo resolver problemas, consulta Revisa cuotas y límites en la página de solución de problemas.

Prioridades y prefijos anunciados

Cuando un Cloud Router anuncia prefijos a un par de BGP, incluye una prioridad para cada prefijo en el anuncio (mensaje de BGP). La prioridad anunciada se implementa como un MED.

Puedes controlar los prefijos que Cloud Router anuncia a todas o algunas de sus sesiones de BGP. Puedes controlar la prioridad anunciada (MED) si defines una prioridad base para los prefijos.

  • Si tu red de VPC usa el modo de enrutamiento dinámico regional, a menos que anuncies rangos personalizados, cada Cloud Router solo anuncia los rangos de la subred en la misma región que Cloud Router. Cada rango se anuncia como un prefijo con el MED como la prioridad base.

  • Si tu red de VPC usa el modo de enrutamiento dinámico global, a menos que anuncies rangos personalizados, cada Cloud Router anuncia rangos de subred desde su región local como prefijos con un MED que coincide con la prioridad base. Además, los Cloud Router anuncian rangos de subred desde diferentes regiones como prefijos con MED iguales a la prioridad base más un costo de región a región. Google Cloud calcula el costo de región a región automáticamente según factores como el rendimiento de la red, la distancia y el ancho de banda disponible entre regiones. Cada costo de región a región tiene un valor específico de un par de regiones: la región de la subred y la región del Cloud Router anunciante.

Cuando los routers locales reciben los prefijos anunciados y sus prioridades, crean rutas que se usan para enviar paquetes a tu red de VPC.

Orientación para las prioridades base

Cuando configuras una sesión de BGP en un Cloud Router, puedes especificar una prioridad base anunciada para la sesión de BGP. La prioridad base anunciada se aplica a todos los prefijos (destinos) que anuncia esa sesión de BGP.

Las prioridades base son números enteros del 0 al 65535. La prioridad base más alta posible es 0. La prioridad base predeterminada es 100. Si no especificas una prioridad base, se usa la prioridad predeterminada.

Las prioridades básicas te permiten controlar qué túneles de Cloud VPN o adjuntos de VLAN usan los sistemas locales para enviar paquetes a tu red de VPC. Puedes crear una combinación personalizada, activo/activo o activo/pasivo de estas topologías mediante la prioridad base. Para ver un ejemplo con túneles VPN con alta disponibilidad, consulta las opciones de enrutamiento activo/activo y activo/pasivo para VPN con alta disponibilidad en la documentación de Cloud VPN.

Cuando elijas las prioridades base, ten en cuenta lo siguiente:

  • Los costos de región a región se encuentran entre 201 y 9999, inclusive. El valor depende de la distancia, la latencia y otros factores entre dos regiones. Google genera los valores de costo de región a región y tú no puedes modificarlos.

  • Las prioridades base para las sesiones de BGP entre los Cloud Routers de una región deben estar entre 0 y 200, inclusive. Debido a que los costos de región a región son de al menos 201, si usas prioridades base de 201 o más, podrías asignar accidentalmente una prioridad menor a la esperada a un túnel de Cloud VPN o un adjunto de VLAN. Otra sesión de BGP en una región diferente podría anunciar el mismo prefijo con una prioridad general más alta (MED, que equivale a la prioridad base más el costo de región a región). Sin no configuras con cuidado las prioridades base en otras regiones, es posible que el tráfico local se entregue a tu red de VPC mediante un túnel de Cloud VPN o un adjunto de VLAN inesperado.

  • Las prioridades base de 10,200 o más garantizan que la prioridad anunciada general de un prefijo (MED, prioridad base más costo de región a región) siempre es menor que cualquier otro prefijo anunciado con prioridad base de 200 o menos.

Para obtener más información sobre cómo establecer una prioridad base, consulta Actualiza la prioridad base de ruta anunciada.

Ejemplos

En esta sección, se proporcionan ejemplos que muestran cómo los costos de región a región influyen en los MED anunciados cuando usas el enrutamiento dinámico global.

VPN con alta disponibilidad con túneles activos/activos

En este ejemplo, tienes una red de VPC con lo siguiente:

  • Una subred en cada una de las siguientes regiones: us-central1, europe-west1 y us-west-1
  • Un Cloud Router que administra dos sesiones de BGP para dos túneles VPN con alta disponibilidad en us-central1
  • Un Cloud Router que administra dos sesiones de BGP para dos túneles VPN con alta disponibilidad en us-west1

Para ver una ilustración de este ejemplo, consulta el siguiente diagrama, que incluye valores de ejemplo para el costo de región a región.

VPN con alta disponibilidad con túneles activos/activos.
VPN con alta disponibilidad con túneles activos/activos (haz clic para ampliar)

Supongamos que cada sesión de BGP tiene la prioridad base predeterminada de 100.

En las siguientes tablas, se muestra cómo se usan la prioridad base y el costo de región a región para calcular los valores de MED anunciados para el tráfico de tu red local a cada subred.

10.0.1.0/24 (us-central1)

En esta tabla, se muestran las sesiones de BGP que anuncian el rango de direcciones IP de la subred 10.0.1.0/24, que se encuentra en us-central1.

El tráfico de tu red local usa el túnel VPN con alta disponibilidad en us-central1 porque sus sesiones de BGP tienen el MED anunciado más bajo.

Túnel VPN Prioridad base Costo de región a región MED anunciado Clasificación de la ruta
central-tunnel-0,
central-tunnel-1
100 0 100 Primera opción
west-tunnel-0,
west-tunnel-1
100 250 350 Segunda opción

10.0.2.0/24 (europe-west1)

En esta tabla, se muestran las sesiones de BGP que anuncian el rango de direcciones IP de la subred 10.0.2.0/24, que se encuentra en europe-west1.

El tráfico de tu red local usa el túnel VPN con alta disponibilidad en us-central1 porque sus sesiones de BGP tienen el MED anunciado más bajo.

Túnel VPN Prioridad base Costo de región a región MED anunciado Clasificación de la ruta
central-tunnel-0,
central-tunnel-1
100 300 400 Primera opción
west-tunnel-0,
west-tunnel-1
100 350 450 Segunda opción

10.0.3.0/24 (us-west1)

En esta tabla, se muestran las sesiones de BGP que anuncian el rango de direcciones IP de la subred 10.0.3.0/24, que se encuentra en us-west1.

El tráfico de tu red local usa el túnel VPN con alta disponibilidad en us-west1 porque sus sesiones de BGP tienen el MED anunciado más bajo.

Túnel VPN Prioridad base Costo de región a región MED anunciado Clasificación de la ruta
central-tunnel-0,
central-tunnel-1
100 250 350 Segunda opción
west-tunnel-0,
west-tunnel-1
100 0 100 Primera opción

VPN con alta disponibilidad con túneles activos/pasivos

En este ejemplo, se usa la misma topología que en el ejemplo anterior, pero con prioridades base modificadas para alcanzar un par de túneles VPN con alta disponibilidad activos/pasivos en cada región:

  • Un túnel principal cuya sesión de BGP tiene la prioridad base predeterminada de 100
  • Un túnel secundario cuya sesión de BGP tiene una prioridad menor de 351

En las siguientes tablas, se muestra cómo se usan la prioridad base y el costo de región a región para calcular los valores de MED anunciados para el tráfico de tu red local a cada subred.

10.0.1.0/24 (us-central1)

En esta tabla, se muestran las sesiones de BGP que anuncian el rango de direcciones IP de la subred 10.0.1.0/24, que se encuentra en us-central1.

El tráfico de tu red local usa el túnel VPN principal en us-central1 porque su sesión de BGP tiene el MED anunciado más bajo. Si ese túnel no está disponible, el tráfico usa el túnel principal en us-west1.

Túnel VPN Prioridad base Costo de región a región MED anunciado Clasificación de la ruta
central-tunnel-0 100 0 100 Primera opción
central-tunnel-1 351 0 351 Tercera opción
west-tunnel-0 100 250 350 Segunda opción
west-tunnel-1 351 250 601 Cuarta opción

10.0.2.0/24 (europe-west1)

En esta tabla, se muestran las sesiones de BGP que anuncian el rango de direcciones IP de la subred 10.0.2.0/24, que se encuentra en europe-west1.

El tráfico de tu red local usa el túnel VPN principal en us-central1 porque su sesión de BGP tiene el MED anunciado más bajo. Si ese túnel no está disponible, el tráfico usa el túnel principal en us-west1.

Túnel VPN Prioridad base Costo de región a región MED anunciado Clasificación de la ruta
central-tunnel-0 100 300 400 Primera opción
central-tunnel-1 351 300 651 Tercera opción
west-tunnel-0 100 350 450 Segunda opción
west-tunnel-1 351 350 701 Cuarta opción

10.0.3.0/24 (us-west1)

En esta tabla, se muestran las sesiones de BGP que anuncian el rango de direcciones IP de la subred 10.0.3.0/24, que se encuentra en us-west1.

El tráfico de tu red local usa el túnel VPN principal en us-west1 porque su sesión de BGP tiene el MED anunciado más bajo. Si ese túnel no está disponible, el tráfico usa el túnel principal en us-central1.

Túnel VPN Prioridad base Costo de región a región MED anunciado Clasificación de la ruta
central-tunnel-0 100 250 350 Segunda opción
central-tunnel-1 351 250 601 Cuarta opción
west-tunnel-0 100 0 100 Primera opción
west-tunnel-1 351 0 351 Tercera opción

Interconexión dedicada de preferencia global

Este ejemplo es similar a los ejemplos anteriores, con la excepción de que reemplazaste los dos túneles de Cloud VPN en la región us-west1 con dos adjuntos de VLAN.

Para ver una ilustración de este ejemplo, consulta el siguiente diagrama.

Interconexión dedicada de preferencia global.
Interconexión dedicada de preferencia global (haz clic para ampliar)

Deseas priorizar los adjuntos de VLAN. Especifica prioridades base más grandes para los túneles VPN con alta disponibilidad en la región us-central1 a fin de quitarles su prioridad.

En las siguientes tablas, se muestra cómo se usan la prioridad base y el costo de región a región para calcular los valores de MED anunciados para el tráfico de tu red local a cada subred.

10.0.1.0/24 (us-central1)

En esta tabla, se muestran las sesiones de BGP que anuncian el rango de direcciones IP de la subred 10.0.1.0/24, que se encuentra en us-central1.

El tráfico de tu red local usa el adjunto de VLAN en us-west1 porque sus sesiones de BGP tienen el MED anunciado más bajo.

Túnel VPN o adjunto de VLAN Prioridad base Costo de región a región MED anunciado Clasificación de la ruta
central-tunnel-0,
central-tunnel-1
351 0 351 Segunda opción
west-attachment-0,
west-attachment-1
100 250 350 Primera opción

10.0.2.0/24 (europe-west1)

En esta tabla, se muestran las sesiones de BGP que anuncian el rango de direcciones IP de la subred 10.0.2.0/24, que se encuentra en europe-west1.

El tráfico de tu red local usa el adjunto de VLAN en us-west1 porque sus sesiones de BGP tienen el MED anunciado más bajo.

Túnel VPN o adjunto de VLAN Prioridad base Costo de región a región MED anunciado Clasificación de la ruta
central-tunnel-0,
central-tunnel-1
351 300 651 Segunda opción
west-attachment-0,
west-attachment-1
100 350 450 Primera opción

10.0.3.0/24 (us-west1)

En esta tabla, se muestran las sesiones de BGP que anuncian el rango de direcciones IP de la subred 10.0.3.0/24, que se encuentra en us-west1.

El tráfico de tu red local usa el adjunto de VLAN en us-west1 porque sus sesiones de BGP tienen el MED anunciado más bajo.

Túnel VPN o adjunto de VLAN Prioridad base Costo de región a región MED anunciado Clasificación de la ruta
central-tunnel-0,
central-tunnel-1
351 250 601 Segunda opción
west-attachment-0,
west-attachment-1
100 0 100 Primera opción

Ruta predeterminada

Cuando no se especifica una ruta para una IP de destino en particular, el tráfico se envía a una ruta predeterminada, la cual actúa como último recurso cuando no existen otras opciones. Por ejemplo, las redes de VPC de Google Cloud incluyen automáticamente una ruta predeterminada (0.0.0.0/0) que envía tráfico a la puerta de enlace de Internet.

A veces, es recomendable que el tráfico se dirija a tu red local de forma predeterminada. Para hacerlo, puedes anunciar una ruta predeterminada desde tu router local a Cloud Router. Con Cloud Router, no necesitas crear ni administrar rutas estáticas. Si anuncias una ruta predeterminada desde tu red local, verifica que tenga prioridad sobre otras rutas predeterminadas creadas automáticamente (que tenga un valor MED más bajo). Ve a la Página de rutas, visualiza la Prioridad para las rutas con 0.0.0.0/0 en el Rango de IP de destino y visualiza Default internet gateway en el Siguiente salto.

Cómo usar Cloud Router

Para usar Cloud Router con un producto de conectividad de red, consulta la documentación de ese producto. Los pasos para crear un Cloud Router o usar uno existente se incluyen en los siguientes pasos.

Producto Enrutamiento Documentación
Interconexión dedicada Requiere enrutamiento dinámico con Cloud Router Crea adjuntos de VLAN
Interconexión de socio Requiere enrutamiento dinámico con Cloud Router Crea adjuntos de VLAN
Dispositivos de router Requiere enrutamiento dinámico con Cloud Router Crea instancias de dispositivos de router
VPN con alta disponibilidad Requiere enrutamiento dinámico con Cloud Router Crea una puerta de enlace de VPN con alta disponibilidad a una puerta de enlace de VPN de intercambio de tráfico
Crea una puerta de enlace de VPN con alta disponibilidad entre las redes de Google Cloud
VPN clásica El enrutamiento dinámico con Cloud Router es opcional Crea una VPN clásica mediante el enrutamiento dinámico
Crea una VPN clásica mediante el enrutamiento estático

¿Qué sigue?