Orden de las rutas

En esta página, se describe cómo se interpretan las rutas para los túneles de Cloud VPN en redes de Cloud VPN y heredadas.

Rutas VPN

Las rutas VPN definen una ruta de salida para el tráfico que sale de tu red de GCP:

  • Las rutas para túneles de Cloud VPN que usan enrutamiento dinámico son administradas por un Cloud Router. Estas rutas no se pueden editar ni quitar manualmente. Las rutas con destinos a redes locales o de intercambio de tráfico se crean y se quitan automáticamente mediante el Cloud Router asociado con el túnel en función de los anuncios de BGP de la puerta de enlace VPN de par. El siguiente salto para una ruta dinámica es la dirección IP de BGP del par local.

  • Si usas GCP Console para crear túneles mediante el enrutamiento basado en políticas o VPN basadas en rutas, GCP crea una ruta estática con un destino coincidente para cada rango de IP en el selector de tráfico remoto. Si creas los túneles con los comandos de gcloud, debes crear manualmente las rutas estáticas correspondientes. El siguiente salto para una ruta estática de VPN es el túnel de Cloud VPN adecuado.

Orden de enrutamiento

Con rutas de subred

Las redes de VPC tienen una ruta creada por subred. Estas rutas de subred muestran un próximo salto de red virtual en GCP Console, y cada una define una ruta de comunicación hacia su subred asociada. Las redes heredadas solo tienen una "ruta de subred" para toda la red.

GCP utiliza el siguiente procedimiento para enrutar el tráfico desde una instancia de máquina virtual (VM) o, también, otro recurso hacia un destino:

  • Las rutas de subred siempre se consideran primero porque GCP requiere que las rutas de subred tengan los destinos más específicos. Si el destino de un paquete coincide con el destino dentro de una ruta de subred, el paquete se entrega a la subred GCP. No puedes anular una ruta de subred con ningún otro tipo de ruta.

  • Se consideran las rutas VPN si ninguna ruta de subred tiene un destino coincidente para un paquete y si el túnel VPN está disponible. GCP envía el paquete al siguiente salto de la ruta con el destino más específico. Si más de una ruta tiene el mismo destino más específico, se usa la prioridad de la ruta: si está disponible una ruta única con la prioridad más alta, el paquete se envía a su siguiente salto; si más de una ruta tiene la misma prioridad, el paquete puede enviarse al siguiente salto de cualquiera de las rutas mediante el enrutamiento de varias rutas de igual costo (ECMP). Consulta cuando los túneles están inactivos para obtener más detalles sobre qué sucede con las rutas cuando los túneles de Cloud VPN no están disponibles.

Los siguientes ejemplos ilustran cómo funcionan las rutas VPN junto con las rutas de subred. En cada ejemplo, 10.2.0.0/16 representa un rango de IP local:

  • Subred GCP con el mismo rango de IP: Si tu red de GCP contiene una subred que usa el rango 10.2.0.0/16, GCP te impide crear un túnel de Cloud VPN mediante el enrutamiento basado en políticas o la VPN basada en rutas si el selector de tráfico remoto incluye 10.2.0.0/16. Si el túnel de Cloud VPN usa enrutamiento dinámico, el Cloud Router asociado ignora las rutas anunciadas con un destino de 10.2.0.0/16. El tráfico destinado a 10.2.0.0/16 permanece en GCP.

  • Subred de GCP con un rango de IP más amplio: Si tu red de GCP contiene una subred que usa un rango de IP incluyente y mayor como 10.0.0.0/8, GCP te impide crear un túnel de Cloud VPN mediante enrutamiento basado en políticas o VPN basada en rutas si un selector de tráfico remoto incluye 10.0.0.0/8 o un rango más específico. Si el túnel de Cloud VPN usa enrutamiento dinámico, el Cloud Router asociado ignora las rutas anunciadas con los destinos que se ajustan a 10.0.0.0/8 (que incluye rangos más específicos). Todo el tráfico destinado a 10.0.0.0/8 permanece en GCP.

  • Subred de GCP con un rango de IP más reducido: Si tu red de GCP contiene una subred con un rango de IP más reducido incluido, como 10.2.99.0/24, puedes crear un túnel de Cloud VPN para el rango más amplio 10.2.0.0/16 mediante cualquiera de las opciones de enrutamiento. El tráfico destinado a 10.2.99.0/24 aún se enrutará a la subred de GCP. El tráfico destinado a 10.2.0.0/16 , pero fuera de 10.2.99.0/24 (como el tráfico hacia 10.2.100.8) se enviará a través del túnel VPN.

Con otras rutas VPN

Si no se encuentra ningún destino con una ruta de subred, GCP resuelve las rutas para los túneles VPN de la siguiente manera:

  • Las rutas que usan un túnel de Cloud VPN como un próximo salto se ignoran si el túnel no está activo.

  • GCP envía el paquete al siguiente salto de la ruta con el destino más específico.

  • Si más de una ruta tiene el mismo destino más específico, se usa la prioridad de la ruta:

    • Si una única ruta con la prioridad más alta está disponible, el paquete se envía a su siguiente salto.

      • Si más de una ruta tiene la misma prioridad más alta, el paquete se entrega al siguiente salto de cualquiera de las rutas mediante ECMP. Esto significa que el tráfico se distribuye entre varios saltos siguientes, por lo que se equilibra entre los túneles de Cloud VPN disponibles y aplicables. Este método de equilibrio se basa en un hash, de modo que todos los paquetes del mismo flujo usan el mismo túnel siempre que ese túnel esté activo.

Cuando los túneles están inactivos

Cuando los túneles de Cloud VPN no están disponibles, GCP interpreta sus rutas asociadas de la siguiente manera:

  • Si un túnel de Cloud VPN usa enrutamiento dinámico, su Cloud Router asociado quita automáticamente las rutas aprendidas cuando el túnel está inactivo. Las rutas aprendidas son aquellas con un próximo salto de IP de BGP para la puerta de enlace VPN local o de par correspondiente. Siempre que no haya conflictos con las rutas de subred, las rutas aprendidas se vuelven a agregar cuando el túnel vuelve a activarse. Según tu red, el Cloud Router asociado puede demorar hasta 40 segundos de tiempo de procesamiento en quitarlas.

  • Los túneles que usan enrutamiento basado en políticas o VPN basadas en rutas tienen rutas estáticas correspondientes. GCP ignora las rutas estáticas con los próximos saltos que apuntan a los túneles de Cloud VPN que están inactivos.

Si un segundo túnel de Cloud VPN proporciona una ruta alternativa al mismo destino, aún debes esperar la pérdida de paquetes cada vez que un túnel de Cloud VPN esté inactivo. Los paquetes en tránsito pueden descartarse y se quitan las rutas dinámicas solo después de que el Cloud Router asociado haya completado su procesamiento.

¿Qué sigue?

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...