Descripción general de Cloud Router

Cloud Router es un servicio de Google Cloud completamente distribuido y administrado. Este se escala con el tráfico de tu red. No es un dispositivo físico que pueda provocar un cuello de botella.

Cuando extiendas tus redes locales a Google Cloud, usa Cloud Router para intercambiar rutas de manera 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 sobre la topología a través de Protocolo de Puerta de Enlace Fronteriza (BGP). Los cambios en la topología se propagan de marea automática entre tu red de VPC y tu red local. No necesitas configurar rutas estáticas.

Cloud Router sirve tanto para redes heredadas como para redes de nube privada virtual (VPC).

Enrutamiento estático frente a enrutamiento dinámico

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. Además, las rutas estáticas no pueden redirigir automáticamente el tráfico si falla un vínculo.

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.

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 descubren de manera automática y rápida los cambios de topología a través de BGP. Los cambios se implementan de forma continua, 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.

Enrutamiento estático para túneles VPN

Sin Cloud Router, puedes configurar tu VPN solo mediante el uso de rutas estáticas. Las desventajas de usar rutas estáticas son:

  • Un cambio en la configuración de la red en cualquier lugar del túnel VPN requiere la creación y eliminación manual de las rutas estáticas correspondientes a estos cambios. Además, los cambios de las rutas estáticas son lentos de converger.
  • Cuando se crea un túnel VPN para trabajar con rutas estáticas, se debe especificar la lista de prefijos de IP en cualquier lugar del túnel antes de crearlo. Esto significa que cada vez que las rutas deben cambiar, el túnel VPN debe actualizarse (borrarse y volver a crearse) con las rutas nuevas, lo que interrumpe el tráfico existente.
  • No hay una manera estándar de configurar rutas estáticas. Los distintos proveedores utilizan diferentes comandos.

En el siguiente ejemplo, tu red combinada consiste en una red de Google Cloud y 29 subredes (una por rack) en la red local en el otro lado del túnel VPN. Para este ejemplo, supón que tu negocio está creciendo de tal manera que necesitas agregar una subred nueva de máquinas cada semana. Esta semana, agregará la subred 10.0.30.0/24, como se muestra en el siguiente diagrama:

Cloud Router para VPN con redes de VPC (haz clic para ampliar)
VPN sin Cloud Router (haz clic para ampliar)

En este caso, la VPN basada en rutas estáticas requeriría los siguientes cambios:

  1. Las rutas estáticas deben agregarse a Google Cloud Platform para llegar a la subred local nueva.
  2. Eliminar y volver a crear el túnel VPN para incluir la subred local nueva.

Los cambios de configuración en las rutas estáticas y los túneles VPN se pueden evitar mediante la implementación de un Cloud Router. Cloud Router realiza intercambio de tráfico con tu puerta de enlace de 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 Platform se propagan automáticamente a tu propia red, y viceversa, a través de BGP, de manera que no tengas que configurar rutas estáticas para tus túneles VPN.

Enrutamiento dinámico para túneles VPN en redes de VPC

Usa las redes de VPC para segmentar de forma regional el espacio de la IP de la red en prefijos (subredes) y controlar desde qué prefijo se asigna la dirección IP interna de la instancia de VM. Usa Cloud Router para habilitar el enrutamiento dinámico de tu túnel VPN y así evitar administrar estas subredes de manera estática, incluida la carga de agregar y quitar rutas estáticas relacionadas para tu VPN.

Un Cloud Router pertenece a una red de VPC y región específicas. Cloud Router anuncia subredes de su red de VPC en la puerta de enlace local a través de BGP. Esto lo realiza en su región local o en todas las regiones de la red, dependiendo del modo de enrutamiento dinámico de la red de VPC. Además, Cloud Router obtiene las rutas locales a través de BGP y habilita la infraestructura de la red para seleccionar la mejor ruta para llegar a los prefijos asociados.

El siguiente ejemplo muestra Cloud Router con redes de VPC en modo personalizado. Si usas redes de VPC con modo automático, Cloud Router anuncia automáticamente el prefijo /20 de la región.

El siguiente diagrama muestra dos subredes regionales diferentes en una red de VPC y 30 subredes en la red local. Las dos redes están conectadas a través de un túnel VPN de Cloud. En este caso, se están agregando subredes nuevas a ambas redes:

  1. Una subred 192.168.1.0/24 nueva en la región us-east-1 de la red de GCP.
  2. Una subred local 10.0.30.0/24 nueva para manejar el aumento de tráfico en tu centro de datos.
Cloud Router para VPN con redes de VPC (haz clic para ampliar)
Cloud Router para VPN con redes de VPC (haz clic para ampliar)

Para propagar automáticamente los cambios en la configuración de la red, el túnel VPN utiliza Cloud Router para establecer una sesión BGP en la puerta de enlace de VPN local, la cual debe ser compatible con BGP. Las subredes nuevas se anuncian sin problemas entre las redes. Las instancias en las subredes nuevas pueden comenzar a enviar y recibir tráfico de inmediato.

Para configurar BGP, se debe asignar una dirección IP adicional a cada extremo del túnel VPN. Estas dos direcciones IP locales deben ser direcciones IP de vínculo local que pertenezcan al rango de direcciones IP 169.254.0.0/16. Estas direcciones no forman parte del espacio de direcciones IP de ninguna de las redes. Estas dos direcciones se utilizan exclusivamente para establecer una sesión de BGP.

Enrutamiento dinámico para túneles VPN en redes heredadas

En las redes heredadas, los cambios en la configuración de la red se propagan automáticamente sin necesidad de volver a configurar las rutas estáticas ni reiniciar el túnel VPN, como en el ejemplo anterior.

La sesión de BGP informa a cada router sobre los cambios locales. Para configurar BGP, se debe asignar una dirección IP adicional a cada extremo del túnel VPN. Estas dos direcciones IP locales deben ser direcciones IP de vínculo local que pertenezcan al rango de direcciones IP 169.254.0.0/16. Estas direcciones no forman parte del espacio de direcciones IP de ningún lado del túnel y se usan exclusivamente para configurar pares de BGP para establecer una sesión de BGP.

Debes configurar dos direcciones IP de vínculo local (ambas desde la misma subred) y una máscara de red en ambos lados del túnel. Después de configurar estos cambios en ambos lados del túnel, se establece una sesión de BGP.

Nuevamente, si una red tiene túneles VPN en varias regiones, se debe crear un Cloud Router en cada región donde se desea tener enrutamiento dinámico. Se puede usar un solo Cloud Router para varias puertas de enlace VPN y para varios túneles en la región de la red a la que pertenece el router.

Modo de enrutamiento dinámico

El modo de enrutamiento dinámico de una red de VPC determina qué subredes son visibles para los Cloud Routers. Puedes configurar el modo de enrutamiento dinámico para que sea global o regional:

  • Con el enrutamiento dinámico global, un Cloud Router anuncia todas las subredes en la red de VPC al router local. Cloud Router propaga las rutas aprendidas desde el router local a todas las regiones.
  • Con el enrutamiento dinámico regional, un Cloud Router anuncia y propaga rutas en su región local.

El modo de enrutamiento dinámico se configura en la red de VPC. Cuando creas o editas una red de VPC, puedes configurar el modo de enrutamiento dinámico en regional o global. Todas las instancias de Cloud Router en la red de VPC utilizan el modo de enrutamiento dinámico de la red. De forma predeterminada, el modo es el regional.

Si cambias el modo de enrutamiento dinámico para una red de VPC, ten en cuenta las implicaciones que podría tener, como interrumpir las conexiones existentes o habilitar rutas no deseadas. Por ejemplo, si cambias al enrutamiento dinámico regional, las instancias de VM que logren conectarse a túneles e interconexiones VPN en otra región podrían perder la conexión. Si cambia al enrutamiento dinámico global, Cloud Router podría anunciar instancias de VM de regiones no deseadas. Para ver o configurar el modo de enrutamiento dinámico, consulta Cómo configurar el enrutamiento dinámico regional o global.

Ejemplo de enrutamiento dinámico regional

Con el enrutamiento dinámico regional, podrías tener un túnel VPN de Cloud, además de instancias de VM en una única región de GCP. El túnel extiende tu red local a una red de VPC. Las instancias de VM en otras regiones podrían necesitar conectarse a la red local, pero llegan al túnel. Para sortear esta restricción, puedes crear rutas estáticas. Sin embargo, mantener rutas estáticas puede dar lugar a errores e interrumpir el tráfico.

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

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

Ejemplos de enrutamiento dinámico global

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

El siguiente ejemplo muestra una red de VPC con enrutamiento dinámico global. El Cloud Router en us-west1 anuncia subredes en dos regiones distintas: us-west1 y us-central1. Las instancias de VM en ambas regiones obtienen de manera dinámica los hosts locales.

Enrutamiento dinámico global de Cloud Router (haz clic para ampliar)
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 conmutar por error a otra región.

El siguiente ejemplo muestra dos túneles VPN de Cloud en dos regiones distintas. Las instancias de VM (10.128.0.0/20) utilizan tunnel-us-west1 en la región us-west1 para llegar a ambas subredes en la red local. De manera similar, las instancias de VM (10.138.0.0/20) en us-central1 utilizan el túnel tunnel-us-central1.

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

Las rutas se configuran para que las instancias de VM prefieran sus túneles locales (los túneles en su región). Cloud Router establece diferentes pesos para las rutas locales y las remotas con el mismo destino. Si un túnel falla, Cloud Router puede redirigir el tráfico de manera adecuada.

En el siguiente ejemplo, tunnel-us-west1 falla. El tráfico hacia y desde las instancias de VM (10.128.0.0/20) se redirige a través de tunnel-us-central1 en lugar de descartarse.

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

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 tu red de VPC que tenga una dirección IP de destino que coincida con un rango de IP anunciado. Después de llegar a GCP, las reglas de firewall y las rutas de tu red de VPC determinan cómo GCP 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.

Predeterminados

De forma predeterminada, Cloud Router anuncia subredes en su región para el enrutamiento dinámico regional o en todas las subredes de una red de VPC para el enrutamiento dinámico global. Cloud Router anuncia automáticamente las 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.

Para anunciar direcciones IP fuera del rango de una subred, como las direcciones IP externas reservadas, debes especificar anuncios personalizados. Además, cuando utilizas anuncios personalizados, puedes anunciar de forma selectiva subredes o partes de una subred. De esa manera, puedes evitar que se anuncien ciertas subredes. Si no necesitas estas capacidades, usa los anuncios predeterminados.

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 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 que quieres exponer. Sin embargo, cuando anuncias subredes de forma selectiva, las subredes nuevas se deben agregar manualmente 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 ruta personalizados en el 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 la sesión ignora y omite el anuncio de ruta del Cloud Router.

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

Ejemplos

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 interconexión dedicada.

Anuncio de ruta predeterminado

Para el enrutamiento dinámico regional, Cloud Router anuncia subredes en su región. En el siguiente ejemplo, 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 (haz clic para ampliar)
Anuncio de ruta predeterminado de Cloud Router (haz clic para ampliar)

Puedes usar una dirección IP estática externa para una aplicación de GCP que entregue a clientes en tu red local. Cuando realizas el mantenimiento de la aplicación, puedes volver a asignar la dirección IP estática a otra instancia de 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 ejemplo, 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 10.20.0.2 del servidor. Cloud Router no anuncia la dirección IP interna del servidor proxy ni ninguna instancia de 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 (haz clic para ampliar)
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 ejemplo, Cloud Router anuncia subnet-1 y subnet-2. Los clientes en la red local pueden llegar a las instancias de VM en esas subredes, pero no a las instancias en la subred unadvertised-subnet.

Anuncia subredes específicas en el Cloud Router (haz clic para ampliar)
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 prueba en tus redes de VPC y local, y que organizaste esos recursos en diferentes subredes. En consecuencia, configura dos sesiones de BGP que anuncien diferentes rangos de direcciones IP. Al utilizar dos sesiones de BGP diferentes, el tráfico vinculado a una subred no se dirige a otra subred de manera inadvertida. El siguiente ejemplo muestra dos sesiones de BGP: prod-bgp, que anuncia solo a prod-subnet, y test-bgp, que anuncia solo a test-subnet.

Anuncia subredes específicas en una sesión de BGP (haz clic para ampliar)
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.

Mejor ruta para el tráfico de salida desde GCP a tu red local

Si Cloud Router recibe varias rutas para el mismo destino, GCP usa métricas de ruta y, en algunos casos, la ruta de interacciones AS para determinar la mejor ruta. En la siguiente lista, se describe el algoritmo utilizado para el tráfico de salida con uno o más Cloud Routers que administran rutas dinámicas para una red de VPC.

  1. Si tienes varias sesiones de BGP en un solo Cloud Router, la salida se determina por la primera condición que se cumpla:
    1. Todo el tráfico de salida se envía a la ruta con la ruta de interacciones AS más corta.
    2. Si las rutas tienen las mismas rutas de interacciones AS, todo el tráfico de salida se envía a la que tiene el valor más bajo del Discriminante de salidas múltiples (MED) (la métrica de ruta más baja).
    3. Si las rutas tienen las mismas rutas de interacciones AS y los mismos valores MED (las mismas métricas de ruta), el tráfico de salida se balancea en todas las rutas mediante el uso de parcheado múltiple de igual costo (ECMP).
  2. Si usas varios Cloud Routers en la misma región, GCP solo usa métricas de ruta para determinar la mejor ruta. La ruta de interacciones AS no se utiliza. La salida se determina por la primera condición que se cumpla:
    1. Todo el tráfico de salida se envía a la ruta con el valor más bajo del Discriminante de salidas múltiples (MED) (la métrica de la ruta más baja).
    2. Si las rutas tienen los mismos valores MED (las mismas métricas de ruta), el tráfico de salida se balancea en todas las rutas mediante el uso de ECMP.
  3. Las rutas estáticas tienen prioridad sobre las rutas dinámicas de Cloud Router en casos de conflicto. Una ruta estática con el mismo prefijo y la misma métrica de ruta que una ruta dinámica siempre tiene prioridad, por lo que se ignoran las rutas dinámicas en conflicto.

Cómo superponer rangos de IP entre una subred de VPC y un anuncio de ruta local

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

Si el rango de IP de la subred es más amplio o el mismo que el anuncio de ruta local, GCP ignora el anuncio local. Todo el tráfico de salida de GCP destinado al rango de IP de la subred se dirige a la subred de VPC. Por ejemplo, si tienes una subred con un rango de IP de 10.2.0.0/16 y un anuncio de ruta local 10.2.1.0/24, GCP ignora los anuncios locales y dirige el tráfico 10.2.0.0/16 a la subred de VPC.

Si el rango de IP de la subred es más reducido que el anuncio de ruta local, el tráfico de salida de GCP se dirige a la subred de VPC si la IP de destino está dentro del rango de IP de la subred. Todo el tráfico de salida restante que coincida con el anuncio local se dirige a la red local. Por ejemplo, si tienes una subred con un rango de IP de 10.2.0.0/16 y un anuncio de ruta local 10.0.0.0/8, GCP dirige el tráfico destinado para 10.0.0.0/8 a la red local, a menos que el destino coincida con 10.2.0.0/16, el cual GCP dirige a la subred.

Métricas de ruta

Cuando Cloud Router anuncia o propaga rutas, utiliza métricas de ruta para especificar las prioridades de ruta. Cuando tienes varias rutas entre tu red de VPC y la red local, las métricas de ruta determinan una ruta prioritaria. Este valor es equivalente al valor del Discriminante de múltiples salidas (MED). Una métrica de ruta más baja (MED) indica una prioridad más alta.

Una métrica de ruta se compone de una prioridad de ruta anunciada base y un costo regional. La prioridad base es un valor especificado por el usuario, mientras que el costo regional es un valor generado por Google que no puedes modificar. El costo regional representa el costo de comunicación entre dos regiones en una red de VPC. Cloud Router agrega estos dos valores para generar una métrica de ruta.

Para el enrutamiento dinámico regional, dado que Cloud Router solo maneja rutas en su región, este no agrega ningún costo regional a las métricas de ruta. Cloud Router utiliza solo la prioridad de ruta anunciada base.

Para el enrutamiento dinámico global, todos los Cloud Routers anuncian y propagan las mismas rutas. Sin embargo, cada Cloud Router puede usar diferentes métricas de ruta debido a los costos regionales.

Prioridad de ruta anunciada base

Cuando calcula las métricas de ruta, Cloud Router comienza con el valor de la prioridad de ruta anunciado base y luego agrega los costos regionales. Este valor base es la métrica de ruta mínima para las rutas anunciadas. Cuando configuras una sesión de BGP en un Cloud Router, puedes especificar una prioridad de ruta anunciada base, la cual se aplica a todas las rutas para esa sesión. De forma predeterminada, el valor de prioridad de anuncio base es 100.

La prioridad de ruta anunciada base te permite establecer prioridades para las rutas. Por ejemplo, es posible que tengas un túnel VPN y una interconexión dedicada que conecte tus redes de VPC y local. Puedes establecer la prioridad de ruta anunciada, de manera que el tráfico prefiera la interconexión dedicada. Si la interconexión no está disponible, el tráfico atraviesa el túnel. Para obtener más información, consulta las topologías de ejemplo.

Costo regional

Cuando un Cloud Router anuncia rutas de regiones distintas de su región (rutas de regiones remotas de GCP) o propaga rutas a regiones remotas, agrega un costo regional.

El costo regional puede variar desde 201 a 9,999, ambos incluidos. El valor depende de la distancia, la latencia y otros factores entre dos regiones. Google genera el valor del costo regional, y tú no puedes modificarlo. Para obtener más información sobre los costos regionales, consulta las topologías de ejemplo.

Los costos regionales ayudan a priorizar las rutas según la proximidad de la región. Por ejemplo, imagina que tienes dos conexiones entre tus redes de VPC y local, como dos túneles VPN con sus propios Cloud Routers. Una conexión está en us-central1 y otra en europe-west1. Al agregar un costo regional a las métricas de ruta, el tráfico entre las redes de us-central1 prioriza el túnel us-central1. Del mismo modo, el tráfico entre redes de europe-west1 prioriza el túnel europe-west1. Sin los costos regionales, el tráfico se dirigirá de manera equitativa a través de ambas conexiones, provocando incoherencias en el rendimiento de la red.

Para las rutas aprendidas, Cloud Router agrega costos regionales cuando propaga las rutas aprendidas a regiones remotas de GCP. Esto ayuda a mantener la simetría entre el tráfico de entrada y el de salida entre las redes de VPC y local. Cloud Router agrega costos regionales al valor de MED anunciado por tu router local.

Valores de prioridad base sugeridos

Para ajustar las prioridades entre las rutas en una sola región, usa valores menores a 201. Esto garantiza que los costos regionales no afecten las prioridades de ruta globales. Una ruta de otra región (una región remota) no puede tener una prioridad inferior a 201. Si utilizas valores más altos, los costos regionales podrían afectar las prioridades de tu ruta. Por ejemplo, supón que tienes una conexión principal y una de respaldo. Si estableces la prioridad base de la conexión de respaldo demasiado alta, es posible que le otorgues prioridad a las rutas de otras regiones en lugar de a la conexión de respaldo.

Para eliminar la prioridad de una ruta global en una red de VPC, usa valores superiores a 10,200. Esto garantiza que todas las demás rutas inferiores a 201 tengan prioridad independientemente de los costos regionales.

En los casos en que todas las rutas en una región tengan la misma prioridad, puedes utilizar el valor predeterminado de 100.

Topologías de ejemplo

Los siguientes ejemplos explican cómo influyen los costos regionales en las métricas de ruta cuando utilizas el enrutamiento dinámico global.

Supón que tienes una red de VPC con dos túneles VPN con sus propios Cloud Routers. Un túnel está en us-central1 y el otro en us-west1. De forma predeterminada, el tráfico de entrada a esas regiones utiliza los túneles correspondientes en sus respectivas regiones. Sin embargo, ¿qué sucede si deseas llegar a instancias de VM que no están en esas regiones, como las instancias de europe-west1? El siguiente diagrama muestra cómo los costos regionales afectan las métricas de ruta.

Métricas de ruta de Cloud Router para rutas anunciadas (haz clic para ampliar)
Métricas de ruta de Cloud Router para rutas anunciadas (haz clic para ampliar)

Ambos Cloud Routers anuncian rutas en europe-west1, pero con diferentes métricas de ruta. El Cloud Router en us-central1 anuncia rutas a europe-west1 con una métrica de ruta más baja que a us-west1, debido a la distancia, la latencia y otros factores. El ejemplo supone que el costo regional para europe-west1 es de 300 para us-central1, y de 350 para us-west1. El tráfico de entrada utiliza el túnel us-central1, que tiene una métrica de ruta más baja. Tiene una métrica de ruta de 350, en comparación con los 400 para el túnel us-west1.

De manera similar, Cloud Router agrega un costo regional al valor MED de las rutas aprendidas (especificadas por tu router local). De forma predeterminada, el tráfico de salida de la región europe-west1 también usa el túnel us-central1, ya que tiene una métrica de ruta más baja. De esta manera, el tráfico de entrada y el de salida mantienen la simetría.

Métricas de ruta de Cloud Router para rutas aprendidas (haz clic para ampliar)
Métricas de ruta de Cloud Router para rutas aprendidas (haz clic para ampliar)

Prioridades de ruta dentro de una región

Supón que creas un túnel de respaldo para la redundancia en us-west1. Debes especificar una prioridad base más alta para el túnel de respaldo, de manera que el tráfico de entrada a us-west1 le dé prioridad al túnel principal, como se muestra en el siguiente ejemplo:

Prioridades base para rutas dentro de una región (haz clic para ampliar)
Prioridades base para rutas dentro de una región (haz clic para ampliar)

Si el túnel principal falla, el tráfico de entrada a us-west1 prioriza el túnel de respaldo con una métrica de ruta de 51, en lugar del túnel de us-central1, que tiene una métrica de ruta de 400:

Prioridades base para rutas dentro de una región (haz clic para ampliar)
Prioridades base para rutas dentro de una región (haz clic para ampliar)

De manera similar, para el tráfico de salida desde la red de VPC a tu red local, usa valores de MED inferiores a 201 para priorizar una ruta sobre otra. De lo contrario, el tráfico de salida desde la red de VPC a tu red local podría no ser simétrico con el tráfico de entrada.

En los casos en que todos los túneles o las interconexiones en una región tengan la misma prioridad, puedes utilizar la prioridad de ruta base predeterminada de 100.

Ruta preferida global

Supón que tienes una interconexión dedicada y un túnel VPN en diferentes regiones. Debes priorizar la interconexión dedicada porque es más rentable para tus cargas de trabajo que el túnel VPN. Especifica una prioridad base de 10,051 para que las rutas del túnel VPN dejen de darle prioridad. Como resultado, todo el tráfico de entrada utilizará la interconexión dedicada, independientemente de los costos regionales. Las métricas de ruta para la interconexión dedicada no excederán los 10,051. El tráfico usa el túnel VPN solo si la interconexión falla.

Prioridades base para rutas globales (haz clic para ampliar)
Prioridades base para rutas globales (haz clic para ampliar)

También deberás realizar los mismos ajustes en tu router local para que el tráfico de salida desde la red de VPC a la red local siempre prefiera utilizar la interconexión dedicada.

Para obtener más información sobre cómo establecer una prioridad base, consulta Cómo establecer sesiones de BGP o Cómo actualizar la prioridad de ruta anunciada base.

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 GCP incluyen automáticamente una ruta predeterminada (0.0.0.0/0) que envía tráfico a la puerta de enlace de Internet.

En algunos casos, es posible que desees 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 Rutas y consulta la Prioridad para las rutas con 0.0.0.0/0 en el Rango de IP de destino y Default internet gateway en Siguiente salto.

Reinicio ordenado

Cloud Router tiene habilitado el reinicio ordenado. El reinicio ordenado permite que el dispositivo de BGP local se desconecte y luego se recupere dentro del período de reinicio ordenado, sin interrumpir el flujo de tráfico. Esta función protege contra interrupciones cuando los agentes de BGP necesitan actualizaciones de software y otros tipos de mantenimiento, o fallan temporalmente.

Habilita el reinicio ordenado en tu dispositivo de BGP si es compatible con esta función.

Túnel VPN de Cloud con reinicio ordenado

En el siguiente ejemplo, si Cloud Router requiere una actualización de mantenimiento, puede actualizarse sin causar interrupciones en el tráfico, siempre que vuelva a estar en línea dentro del período de reinicio ordenado.

Reinicio ordenado y Cloud Router (haz clic para ampliar)
Reinicio ordenado y Cloud Router (haz clic para ampliar)

Configuración del temporizador de BGP

Cloud Router y tu router local mantienen la comunicación con el siguiente conjunto de configuraciones del temporizador:

Temporizador keepalive: es el intervalo entre señales de monitoreo de funcionamiento periódicas de BGP, que se intercambian entre un Cloud Router y su router par local correspondiente. Junto con el temporizador de espera, el temporizador keepalive indica la disponibilidad de cada router para con otro. Google recomienda configurar el temporizador keepalive en 20 segundos en tu router local.

Temporizador de espera: este temporizador realiza un seguimiento de la cantidad mínima de tiempo desde que se detectó la última señal de monitoreo de funcionamiento exitosa de keepalive. Indica cuánto tiempo debe esperar el Cloud Router o el router local antes de quitar las rutas aprendidas del otro router. Google recomienda configurar el temporizador de espera en 60 segundos en tu router local.

Temporizador de reinicio ordenado: es la cantidad de tiempo que esperará tu router local, sin señales de monitoreo de funcionamiento de keepalive, después de recibir un mensaje de notificación de reinicio ordenado del Cloud Router correspondiente, y antes de esperar señales de monitoreo de funcionamiento nuevas de keepalive. Si no se reciben señales de monitoreo de funcionamiento nuevas de keepalive, tu router local quitará las rutas aprendidas del Cloud Router. Google recomienda que este temporizador se configure en 60 segundos.

Temporizador stalepath: esta configuración determina cuánto tiempo esperará un router antes de borrar las rutas aprendidas luego 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). Google recomienda configurarlo en 300 segundos para que coincida con la configuración de Cloud Router.

Túneles VPN de Cloud redundantes

Si la puerta de enlace local no es compatible con el reinicio ordenado, entonces una falla en cualquiera de los lados de la sesión de BGP provocará que la sesión falle y el tráfico se interrumpa. 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 VPN enrutado de manera dinámica ya no entrará en el túnel. Las rutas estáticas para el túnel seguirán en mantenimiento.

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.

El siguiente ejemplo muestra una casilla única como el Cloud Router, pero con dos direcciones IP. Las dos direcciones son interfaces de Ethernet independientes dentro de la misma tarea de Cloud Router. Cada interfaz se usa para una sesión BGP independiente, con una puerta de enlace local por separado. En este caso práctico en particular, dado que estos túneles VPN se crean con fines de redundancia, ambas sesiones de BGP intercambian exactamente el mismo conjunto de prefijos de ruta, pero con diferentes siguientes saltos que apuntan a diferentes túneles VPN.

Redundancia sin reinicio ordenado (haz clic para ampliar)
Redundancia sin reinicio ordenado (haz clic para ampliar)

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). Luego, ambos routers conservarán sus rutas durante estas actualizaciones y el flujo del tráfico continuará.

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

Pasos siguientes

Para obtener más información sobre el uso del enrutamiento estático y dinámico 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 Crear adjuntos de VLAN
Cloud VPN Basado en políticas Crear un túnel VPN con rutas basadas en políticas
Cloud VPN Estático Crear un túnel VPN con rutas estáticas
Cloud VPN Dinámica Crear un túnel VPN con rutas dinámicas
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...