Pregunta

¿Por qué existen las rutas a los sitios IPsec en el Socket incluso cuando los túneles IPsec están caídos?

Por ejemplo, un sitio IPsec fue configurado con un rango nativo de 10.80.80.0/24

Este sitio está actualmente caído.

En el CMA, bajo Monitoring > Routing Table, no vemos la red 10.80.80.0/24

Sin embargo, en la interfaz de usuario de Socket, todavía muestra la ruta:

Respuesta

Los Sockets pueden ser probados para su alcance, con sus rangos normalmente presentes en las tablas de enrutamiento de otros Sockets solo si son alcanzables. De lo contrario, estos rangos se muestran en gris en la página de monitoreo de la interfaz de usuario del Socket. Estos rangos pingables son del tipo REMOTE_SITE, y el alcance se prueba mediante pings que los Sockets envían entre sí.

En contraste, los sitios IPsec no pueden ser "pingueados"; por lo tanto, los Sockets consideran que estos sitios IPsec remotos están siempre conectados, y sus rangos estáticos son siempre alcanzables. Estos se ven como REMOTE_RANGE. Esto es una limitación conocida, ya que no se puede probar la alcanzabilidad de los REMOTE_RANGEs estáticos.

Estudio de caso

Esto será un problema si el cliente tiene el siguiente diseño:

El sitio IPsec tiene una subred de 10.10.10.0/24, y el sitio Socket tiene una subred LAN BGP de la red 10.10.0.0/16. La intención es que, cuando el túnel IPsec esté caído, el tráfico destinado a 10.10.0.0/16 debe ser enrutado a través del sitio Socket. Sin embargo, esto no es factible. Dado que la tabla de rutas del Socket todavía tiene la ruta 10.10.10.0/24 a través del sitio IPsec (aunque el túnel IPsec esté caído), el Socket dejará el paquete. 

Solución:

1. Publicar el rango 10.10.10.0/24 dinámicamente mediante el BGP
2. O, usar un rango nativo en el sitio IPsec que no se superponga con el rango de red de otro sitio