Descripción general de Cloud Router

Cloud Router es un servicio de Google Cloud completamente distribuido y administrado que programa rutas dinámicas personalizadas y escala con tu tráfico de red. Sirve tanto para redes heredadas como para redes de nube privada virtual (VPC).

Cloud Router no es una opción de conectividad, sino un servicio que funciona a través de conexiones de Cloud VPN o Interconnect para proporcionar enrutamiento dinámico mediante el Protocolo de puerta de enlace fronteriza (BGP) para tus redes de VPC. Cloud Router no es compatible con conexiones de intercambio de tráfico directo o intercambio de tráfico por proveedores.

Tampoco es un dispositivo físico que pueda causar un cuello de botella y no se puede usar solo. Sin embargo, se requiere o se recomienda usarlo en los siguientes casos:

  • Obligatorio para Cloud NAT
  • Obligatorio para Cloud Interconnect y VPN con alta disponibilidad
  • Opción de configuración recomendada para la VPN clásica

Cuando extiendas tus redes locales a Google Cloud, usa Cloud Router para intercambiar rutas de forma dinámica entre tus redes de Google Cloud y tus redes locales. Cloud Router realiza intercambio de tráfico con tu puerta de enlace o router de VPN. Los routers intercambian información de topología a través del BGP.

Los cambios de topología se propagan de forma automática entre tu red de VPC y tu red local. Cuando usas Cloud Router, no necesitas configurar rutas estáticas.

Tareas de software de Cloud Router

Los Cloud Routers se implementan mediante uno, dos o, en casos excepcionales, tres tareas de software.

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

  • En la configuración de HA que se muestra en la tabla, se usan dos tareas de software para proporcionar redundancia de software.
  • Para 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 utilizadas para implementar el Cloud Router
Una o más interfaces, cada una conectada a un túnel VPN clásico. Uno
Una o más interfaces, cada una conectada a un adjunto de VLAN, en la que los adjuntos de VLAN están en el mismo dominio de disponibilidad perimetral. Uno
Cualquier cantidad de interfaces, cada una de ellas conectada a un túnel VPN con alta disponibilidad, en la que todos los túneles están conectados al mismo número de interfaz 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 de ellas conectada a un adjunto de VLAN, en la que 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 VPN con alta disponibilidad que está conectado 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 VPN con alta disponibilidad que está conectado a interface 1 de una puerta de enlace de VPN con alta disponibilidad.
  • Una interfaz conectada a un túnel VPN clásico.
Tres

Enrutamiento estático

Con las rutas estáticas, debes crear o mantener una tabla de enrutamiento. Un cambio de topología en cualquiera de las redes requiere que actualices de forma manual las rutas estáticas. Si un vínculo falla, las rutas estáticas no pueden redirigir automáticamente el tráfico.

El enrutamiento estático es adecuado para redes pequeñas con topologías estables. Además, tienes un control estricto de las tablas de enrutamiento. Los routers no envían anuncios entre redes.

Enrutamiento estático para túneles de Cloud VPN

Sin Cloud Router, solo puedes usar rutas estáticas para configurar tus túneles de Cloud VPN. Las desventajas de usar rutas estáticas son las siguientes:

  • Un cambio en la configuración de la red en cualquier lado de un túnel de Cloud VPN requiere la creación y eliminación manual de las rutas estáticas relacionadas. Además, los cambios de rutas estáticas demoran más tiempo en converger.
  • Cuando creas un túnel de Cloud VPN para trabajar con rutas estáticas, debes especificar la lista de prefijos de IP en ambos lados del túnel antes de crearlo. Esto significa que cada vez que deban cambiar las rutas, debes borrar y volver a crear el túnel de Cloud VPN y configurar nuevas rutas, lo que interrumpe el tráfico existente.
  • No hay una manera estándar de configurar rutas estáticas. Los distintos proveedores usan diferentes comandos.

Si deseas evitar cambios de configuración en las rutas estáticas y los túneles de Cloud VPN, implementa un Cloud Router. Cloud Router realiza intercambio de tráfico con tu puerta de enlace de Cloud VPN mediante el uso de BGP para intercambiar información de la topología. De hecho, los cambios de topología de red en tu red de Google Cloud se propagan automáticamente a tu propia red mediante BGP, de modo que no tengas que configurar rutas estáticas para tus túneles de Cloud VPN.

Enrutamiento dinámico

Con Cloud Router, puede usar BGP para intercambiar información de enrutamiento entre redes. En lugar de configurar manualmente las rutas estáticas, las redes detectan cambios de topología a través de BGP de manera automática y rápida. Los cambios se implementan sin problemas y sin interrumpir el tráfico. Este método de intercambio de rutas a través de BGP se conoce como enrutamiento dinámico.

El enrutamiento dinámico es adecuado para redes de cualquier tamaño. Te libera de mantener rutas estáticas. Además, si un vínculo falla, el enrutamiento dinámico puede redirigir el tráfico automáticamente, si es posible. Para habilitar el enrutamiento dinámico, crea un Cloud Router. Luego, configura una sesión de BGP entre el Cloud Router y tu puerta de enlace o router local.

Requisitos de enrutamiento dinámico para Cloud Interconnect y Cloud VPN

Debes tener un Cloud Router antes de poder hacer lo siguiente:

Cuando creas un Cloud Router, puedes elegir el ASN del lado de Google. Si no especificas un ASN, Google Cloud elige uno por ti. Sin embargo, debes especificar manualmente el ASN del router local (de intercambio de tráfico) en la configuración del Cloud Router.

Puedes especificar direcciones IP de BGP de las siguientes maneras:

  • En el caso de la interconexión dedicada, puedes especificar rangos de direcciones IP o hacer que Google Cloud los seleccione.
  • En la interconexión de socio, no especificas direcciones IP de BGP.
  • 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.

En las siguientes dos secciones, se describen ejemplos para el enrutamiento dinámico regional y el enrutamiento dinámico global. Para obtener más información sobre los modos de enrutamiento dinámico de las redes de VPC, consulta Descripción general de la red de VPC en la documentación de VPC.

Para obtener información sobre el modo de enrutamiento dinámico y los balanceadores de cargas, consulta Balanceadores de cargas internos y redes conectadas en la documentación de Cloud Load Balancing.

Ejemplo de enrutamiento dinámico regional

Con el enrutamiento dinámico regional, es posible que tengas un túnel de Cloud VPN y, también, instancias de máquina virtual (VM) en una sola región de Google Cloud. El túnel extiende tu red local a una red de VPC. Es posible que las VM de otras regiones necesiten conectarse a la red local, pero no puedan acceder al túnel. Para sortear esta restricción, puedes crear rutas estáticas. Sin embargo, mantener rutas estáticas puede dar lugar a errores y también interrumpir el tráfico.

En el siguiente diagrama, Cloud Router tiene visibilidad para los recursos solo en la región us-west1. Las VM de otras regiones, como us-central1, no pueden acceder al túnel de Cloud VPN.

Enrutamiento dinámico regional de Cloud Router.
Enrutamiento dinámico regional de Cloud Router (haz clic para ampliar)

Ejemplo de enrutamiento dinámico global

Con el enrutamiento dinámico global, Cloud Router tiene visibilidad de los recursos en todas las regiones. Por ejemplo, si tienes VM en una región, pueden acceder a un túnel de Cloud VPN de otra región automáticamente sin mantener rutas estáticas.

En el siguiente ejemplo, se muestra una red de VPC con enrutamiento dinámico global. El Cloud Router de us-west1 anuncia subredes en dos regiones diferentes: us-west1 y us-central1. Las VM de ambas regiones aprenden de manera dinámica acerca de los hosts locales.

Enrutamiento dinámico global de Cloud Router.
Enrutamiento dinámico global de Cloud Router (haz clic para ampliar)

Para las topologías redundantes, el enrutamiento dinámico (BGP) proporciona suficiente información a la VPC y a las redes locales, de modo que cuando una ruta falla, se redirecciona el tráfico. Si una conexión en una región tiene un problema, el tráfico puede conmutarse por error a otra región.

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 paquetes a tus redes de VPC 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 automáticamente subredes nuevas. 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 los 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, 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 entre redes 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, debes anunciar solo las subredes que deseas exponer. Sin embargo, cuando anuncias subredes de forma selectiva, debes agregar manualmente subredes nuevas al anuncio de ruta personalizado. Cloud Router no anunciará 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 de 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 direcciones IP externas

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, el 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 del servidor 10.20.0.2. 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 direcciones IP externas.
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 el 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 ese 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 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 más 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, consulta Algunos prefijos de IP locales no están disponibles en la página de solución de problemas de Cloud Router.

Límites de las 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 más información sobre estos límites, consulta los límites.

Para supervisar el uso en función 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 tus 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, excepto que reemplazaste los dos túneles de Cloud VPN en la región us-west1 por 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)

Quieres 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.

Reinicio ordenado

Cloud Router respeta los mensajes de reinicio ordenado enviados por tu router local. Si has configurado tu router local con un reinicio ordenado, puede enviar una notificación a Cloud Router cada vez que tu router necesite instalar actualizaciones de software o llevar a cabo tareas de mantenimiento periódicas. Cloud Router retiene las rutas dinámicas personalizadas aprendidas de tu router local durante el período definido por la configuración del temporizador de reinicio ordenado en tu router local.

Para obtener más información sobre los temporizadores de reinicio ordenado, consulta Configuración del temporizador de BGP.

Configuración del temporizador de BGP

Cloud Router y tu router local mantienen la comunicación mediante el siguiente conjunto de configuraciones de temporizador.

Temporizador de keepalive
Este es el intervalo entre las señales de monitoreo de funcionamiento de BGP intercambiadas entre un Cloud Router y el router local correspondiente. Junto con el temporizador de espera, el temporizador keepalive indica la disponibilidad de cada router para con otro. En el router local, configura el temporizador keepalive en 20 segundos.
Temporizador de espera
Este temporizador realiza un seguimiento de la cantidad de tiempo mínima desde que se detectó la última señal de keepalive. Indica cuánto tiempo debe esperar el Cloud Router o el router local antes de quitar las rutas aprendidas del otro router. En el router local, configura el temporizador keepalive en 60 segundos.
Temporizador de reinicio ordenado

Esta es la cantidad de tiempo que espera el router local, sin señales de keepalive periódicas, después de recibir un mensaje de notificación de reinicio ordenado del Cloud Router correspondiente, antes de esperar nuevas señales de keepalive. Si no se reciben nuevas señales de keepalive, el router local quitará las rutas que aprendió del Cloud Router.

Cloud Router establece este valor en 1 segundo. En tu router local, configura un temporizador de reinicio ordenado en un valor que sea adecuado para tus necesidades. Cada router comunica su valor de temporizador de reinicio ordenado al par a través del mensaje OPEN cuando se establece una sesión de BGP.

Cloud Router retira las rutas dinámicas personalizadas que aprende de los dispositivos locales cuando determina que un túnel de Cloud VPN del siguiente salto o una conexión de Cloud Interconnect están inactivos.

Temporizador de inactividad

Esta configuración determina el tiempo que un router espera antes de borrar las rutas aprendidas después de recibir un mensaje de fin de registro (EOR) del otro router. Este temporizador se pone en marcha cuando la sesión de BGP se reinicia después de un reinicio ordenado, pero el prefijo en cuestión no se ha solucionado mediante un mensaje de UPDATE (actualización). Te recomendamos que establezcas el temporizador de inactividad en 300 segundos en tu router local para que coincida con la configuración de Cloud Router.

Túneles de Cloud VPN redundantes

Si la puerta de enlace local no admite el reinicio ordenado, un error en cualquiera de los lados de la sesión de BGP hará que la sesión falle y se interrumpa el tráfico. Después de que se excede el tiempo de espera de BGP, que es de 60 segundos para Cloud Router, las rutas se retiran de ambos lados. El tráfico de Cloud VPN enrutado dinámicamente ya no entra en el túnel. Se seguirán entregando las rutas estáticas del túnel.

Sin la función de reinicio ordenado, la implementación de dos puertas de enlace locales, con un túnel cada una, proporcionará redundancia y conmutación por error. Esta configuración permite que un túnel y sus dispositivos se desconecten para actualizaciones de software o mantenimiento sin interrumpir el tráfico. Además, si un túnel falla, el otro túnel puede mantener las rutas activas y el flujo del tráfico.

Ciclos de actualización

Cloud Router se actualiza periódicamente, lo que demora menos de 60 segundos. Cloud Router no está disponible durante la actualización. El temporizador de espera BGP determina cuánto tiempo se conservan las rutas aprendidas cuando el router paritario de BGP no está disponible. El temporizador de espera de BGP se negocia para que sea el más bajo de los dos valores de ambos lados. Cloud Router utiliza un valor de 60 segundos para el temporizador de espera de BGP. Recomendamos que configures el temporizador de espera de BGP de tus pares en 60 segundos o más (el valor predeterminado es de 3 minutos). Como resultado, ambos routers conservan sus rutas durante estas actualizaciones y el tráfico continúa fluyendo.

Durante los ciclos de mantenimiento de la puerta de enlace de Cloud VPN con una sola puerta de enlace de Cloud VPN, el uso de Cloud Router agrega unos 20 segundos al tiempo de recuperación del túnel, porque la sesión de BGP se restablece y las rutas deben volver a aprenderse. Los tiempos de recuperación de la puerta de enlace de Cloud VPN suelen ser de alrededor de un minuto. Si hay puertas de enlace de Cloud VPN redundantes, el tráfico no se verá afectado, porque solo se elimina una puerta de enlace de Cloud VPN a la vez.

ID del router de BGP y reinicios de la sesión de BGP

Cloud Router selecciona su dirección IP de interfaz más alta para el ID de router de BGP y lo conserva mientras la dirección esté disponible. Si borras la interfaz de Cloud Router que se usa para el ID de router de BGP, Cloud Router debe seleccionar un nuevo ID de router. Esta selección hace que se reinicien todas tus sesiones de BGP. El ID del router también puede cambiar si Cloud Router se reinicia por un mantenimiento periódico.

Recursos adicionales

Para obtener más información sobre cómo usar el enrutamiento dinámico y estático con un servicio compatible, consulta la siguiente documentación.

Producto Enrutamiento Documentación
Interconexión dedicada Estático No compatible
Interconexión dedicada Dinámica Crea adjuntos de VLAN
VPN clásica Basada en políticas, estática Crea una VPN clásica mediante el enrutamiento estático.
VPN clásica o VPN con alta disponibilidad Dinámica Crea una VPN clásica mediante el enrutamiento dinámico
Crea una puerta de enlace de VPN con alta disponibilidad a una puerta de enlace de VPN de intercambio de tráfico
Crea una VPN con alta disponibilidad entre redes de Google Cloud

¿Qué sigue?