Descripción general de Cloud Router

Cloud Router es un servicio Google Cloud totalmente distribuido y administrado que usa 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 o dispositivo físico, cada Cloud Router consta de tareas de software que actúan como interlocutores 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:

Cada Cloud Router funciona con al menos uno de los productos de conectividad de red enumerados antes.

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

También puedes usar Cloud Router para conectar dos redes de VPC en Google Cloud. En esta situación, conectarás las redes de VPC mediante dos VPN con alta disponibilidad y dos Cloud Router, una VPN con alta disponibilidad y su Cloud Router asociado en cada red.

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 rutas personalizados, un Cloud Router solo anuncia rutas de subredes. Los anuncios de ruta personalizados también te permiten configurar un Cloud Router para omitir el anuncio de rutas de subred.

El modo de enrutamiento dinámico de una red de VPC, ya sea regional o global, determina qué subred enruta los Cloud Routers en esa red. Consulta Anuncios de ruta predeterminados para obtener más información.

En el modo de enrutamiento dinámico, también se controla cómo 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.

Cuando configuras BGP para Cloud Interconnect, VPN con alta disponibilidad y el dispositivo de router, puedes configurar de forma opcional las sesiones de intercambio de tráfico del router para usar la autenticación MD5. Esta función está en vista previa.

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 Cloud Router. Las instrucciones para cada producto de conectividad de red enumerado 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 IPv4 de vínculo local en el rango 169.254.0.0/16 como direcciones IP de BGP:

  • En el caso de la interconexión dedicada, puedes especificar direcciones candidatas de vínculo local para las direcciones de BGP, o Google Cloud puede seleccionar direcciones de vínculo local sin usar de forma automática.
  • 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 de BGP cuando creas la interfaz de BGP en el Cloud Router.

Los dispositivos de router usan direcciones IPv4 internas de las VM de Google Cloud como direcciones IP de BGP. Para obtener más información, consulta Crea instancias de dispositivos de 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.

Compatibilidad con IPv6

Cloud Router admite BGP de varios protocolos (MP-BGP) y puede intercambiar prefijos IPv6 a través de sesiones de IPv4 de BGP. No se admiten sesiones de BGP solo IPv6.

Cloud Router anuncia prefijos IPv6 para redes de VPC que incluyen subredes de pila doble.

Cloud Router puede anunciar rangos de subred IPv6 para redes de VPC que incluyen subredes de doble pila. De forma predeterminada, los rangos de subredes IPv6 internas se anuncian automáticamente. Los rangos de subredes IPv6 externos no se anuncian automáticamente, pero puedes anunciarlos de forma manual mediante anuncios de rutas personalizados.

Puedes habilitar el intercambio de prefijos IPv6 en las sesiones de BGP que se crean para los túneles VPN con alta disponibilidad. Para obtener más información, consulta los siguientes documentos:

Para obtener detalles sobre los anuncios de ruta IPv6, consulta Modos de anuncios de ruta.

Limitaciones de IPv6

Cloud Router solo admite el enrutamiento regional de tráfico IPv6 en túneles VPN con alta disponibilidad. El tráfico de IPv6 se enruta dentro de la región asignada a la puerta de enlace de VPN con alta disponibilidad. No se admite el enrutamiento global para el tráfico IPv6 en túneles VPN con alta disponibilidad.

El intercambio de prefijos IPv6 no es compatible con las sesiones de BGP para los siguientes recursos:

  • Adjuntos de VLAN de interconexión dedicada
  • Adjuntos de VLAN de interconexión de socio
  • Túneles VPN clásicos
  • Dispositivo Router (parte de Network Connectivity Center)

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 (Google Cloud CLI) 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 automatizados de tareas

Google Cloud realiza eventos de mantenimiento regulares para lanzar funciones nuevas y mejorar la confiabilidad. Durante el mantenimiento, se aprovisionan las tareas de software nuevas. 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 que no interrumpa el enrutamiento. Los eventos de mantenimiento no deberían tardar 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 ordenado, este 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é configurado 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 completados, consulta Identifica eventos de mantenimiento del router.

Para obtener información sobre cómo funciona el reinicio ordenado con la detección de reenvío bidireccional (BFD), consulta Reinicio ordenado y BFD.

Modos de anuncios de ruta

Mediante el uso de BGP y un producto de conectividad de red, un Cloud Router anuncia rangos de direcciones IP a tu red local. Esto permite a los clientes de tu red local enviar paquetes a recursos de tu red de VPC y recibirlos de ellos.

Cloud Router ofrece dos modos de anuncio de ruta: anuncios de ruta predeterminados y anuncios de ruta personalizados.

Anuncio de ruta predeterminado

El uso del anuncio de ruta predeterminado configura una sesión de Cloud Router o BGP a fin de anunciar prefijos para los siguientes tipos de rangos de direcciones IP de subred. En el modo de enrutamiento dinámico de la red de VPC, se controla si los rangos de direcciones IP de la subred anunciada solo provienen de la misma región que Cloud Router o si provienen de todas las regiones:

Si anuncias direcciones IPv4 públicas de uso privado, es posible que los sistemas locales no puedan acceder a los recursos de Internet que usan esas direcciones IPv4 públicas.

Los anuncios de ruta de subred se actualizan de forma automática como se describe en Actualizaciones automáticas para anuncios de ruta de subred.

El anuncio de ruta de subred IPv6 se encuentra en Vista previa.

Anuncio de ruta personalizado

Un anuncio de ruta personalizado te permite controlar los prefijos que anuncia un Cloud Router. Puedes especificar anuncios de ruta personalizados (incluidos los prefijos de ruta predeterminados, 0.0.0.0/0 o ::/0) para todas las sesiones de BGP en un Cloud Router o por sesión de BGP. Existen dos categorías de anuncios de ruta personalizados:

  • Solo puedes anunciar prefijos IPv4 y, también, IPv6 personalizados. Este tipo de anuncio personalizado omite las rutas de subred que se anunciarían mediante el anuncio de ruta predeterminado.

  • Puedes anunciar prefijos IPv4 y, también, IPv6 personalizados, además de las rutas de subred. Este tipo de anuncio personalizado incluye las mismas rutas de subred anunciadas mediante Anuncio de ruta predeterminado.

Si eliges anunciar rutas de subredes, sus anuncios se actualizan de forma automática como se describe en Actualizaciones automáticas para anuncios de ruta de subred.

Si se cumplen las condiciones para el anuncio de IPv6, Cloud Router anuncia rangos de subred IPv6 internos cada vez que elijas anunciar rutas de subredes. Debes agregar cualquier rango de subred IPv6 externo a tu lista de prefijos personalizados para anunciarlos.

Para conocer la cantidad máxima de prefijos que se pueden anunciar en cada sesión de BGP, consulta cantidad máxima de anuncios de ruta personalizados por sesión de BGP en la página de límites de Cloud Router. Este máximo se aplica a los anuncios personalizados para todo Cloud Router y de forma individual por sesión de BGP.

Para obtener más información, consulta los siguientes documentos:

Prefijos efectivos anunciados

El modo de anuncio de ruta se puede configurar en todo Cloud Router y en las sesiones de BGP individuales del Cloud Router. En la siguiente tabla, se describe qué prefijos se anuncian en la sesión de BGP, según el modo de anuncio seleccionado del Cloud Router y la sesión de BGP.

Modo para Cloud Router Modo para la sesión de BGP Prefijos anunciados en la sesión de BGP
default default La sesión de BGP hereda la configuración de Cloud Router. Las rutas de subred se anuncian como se describe en Anuncio de ruta predeterminado.
personalizado default La sesión de BGP hereda la configuración de Cloud Router. Las rutas personalizadas configuradas en todo Cloud Router se anuncian como se describe en Anuncio de ruta personalizado. Estas pueden contener algunas o todas las rutas de las subredes.
predeterminado o personalizado personalizado La sesión de BGP no hereda la configuración de Cloud Router. Las rutas personalizadas configuradas en la sesión de BGP se anuncian como se describe en Anuncio de ruta personalizado. Estas pueden contener algunas o todas las rutas de las subredes.

Actualizaciones automáticas para anuncios de ruta de subred

Cloud Router actualiza de forma automática los anuncios de ruta de la subred en las siguientes situaciones:

Condiciones para los anuncios de IPv6

Cloud Router puede anunciar rutas IPv6 (vista previa) cuando se cumplen todas las condiciones siguientes:

  • El producto de conectividad de red usado con Cloud Router, como la puerta de enlace de VPN con alta disponibilidad, está configurado para usar el tipo de pila doble IPv4 e IPv6.
  • La sesión BGP está configurada de forma específica para habilitar el intercambio de prefijos IPv6. Consulta Habilita o inhabilita el intercambio de prefijos IPv6.

Para anunciar rangos de subred IPv6 internos, tu red de VPC debe tener un rango IPv6 interno asignado (ULA) y debes haber creado al menos una subred de doble pila con un rango de subred IPv6 interno.

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

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, MED y origen

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.

Para que MED se aplique durante la mejor selección de ruta entre varias rutas aprendidas para el mismo destino, el valor del atributo de origen de BGP para las rutas recibidas debe ser el mismo. De lo contrario, la selección se realiza según el valor del atributo de origen, que precede al paso de comparación de MED en el proceso de mejor selección de ruta (RFC 4271).

Cloud Router anuncia rutas de BGP a sus pares con el valor del atributo de origen establecido en Incomplete. Este valor es el tipo de origen menos preferido en la selección de ruta.

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.

Transferencia de datos de sitio a sitio

Si necesitas transferir datos entre dos sitios externos a Google Cloud, usa el Centro de conectividad de red. Network Connectivity Center funciona con Cloud Router para permitirte anunciar rutas de forma dinámica entre sesiones de BGP.

Cloud Router por sí solo no es compatible con esta funcionalidad (ya sea de forma dinámica o mediante la configuración de anuncios de ruta personalizados que coincidan con los prefijos aprendidos). Si agregas un anuncio de ruta personalizado a una sesión de BGP y ese anuncio se superpone con una ruta aprendida de otra sesión de BGP, la ruta aprendidas podría descartarse.

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 asegurados. Para obtener información sobre ellos, consulta Límites.

Las rutas IPv4 e IPv6 se consideran en el mismo máximo y no tienen límites separados.

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.

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 que envía tráfico a la puerta de enlace de Internet. La ruta predeterminada solo para IPv4 es 0.0.0.0/0 y para IPv6 e IPv4 de pila doble es 0.0.0.0/0, ::/0.

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.

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. Los pares en ambos lados del túnel intercambian rutas estáticas, pero no rutas dinámicas.

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.

Eventos de mantenimiento

Cloud Router se somete a un mantenimiento periódico, que tarda menos de 60 segundos. Cloud Router no está disponible durante los eventos de mantenimiento. 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 en tu router local (par) 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 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 del 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?