Configurar redundancia usando estática flotante

Quería publicar mi diseño de red, pero no tengo la reputación requerida. Así que he creado un diagrama de red a continuación:

       ISP
       / \
      /   \
     /     \
    HQ------Branch
    |         |
  HQ-PC      B-PC

Lo que estoy tratando de hacer es utilizar el enlace WAN entre HQ y Branch como enlace de respaldo y no debe llevar ningún dato a menos que el enlace entre HQ a ISP o Branch a ISP esté inactivo. Lo que significa que solo debe usarse estrictamente como un enlace de respaldo.

Lo que he hecho es usar estática flotante para configurar la redundancia. Sin embargo, no está funcionando como esperaba. Lo que he hecho son:

1) una ruta predeterminada en el cuartel general y la sucursal al ISP (0.0.0.0 0.0.0.0 NEXT-HOP-IP)

2) ruta estática en ISP a HQ y Branch (HQ / BRANCH-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP)

3) una ruta estática (preferida) en HQ (BRANCH-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP-TO-ISP)

4) una ruta estática (preferida) en Branch (HQ-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP-TO-ISP)

5) una ruta estática flotante (de respaldo) en HQ (BRANCH-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP-TO-HQ-THROUGH-BACKUP-LINK)

6) una ruta estática flotante (de respaldo) en Branch (HQ-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP-TO-BRANCH-THROUGH-BACKUP-LINK)

Sin embargo, hay un problema. Por ejemplo, si el enlace entre ISP y HQ está inactivo, cuando quiero hacer ping de HQ-PC a B-PC, el paquete se enviará con éxito de HQ-PC a B-PC, pero el paquete que regresa de B-PC será enviado al ISP y no a través del enlace de respaldo.

Lo siento por una publicación tan larga, pero ¿hay alguien que pueda ayudarme? Si mi explicación no está clara, no dude en consultar. Gracias por adelantado

EDITAR: Perdón por la confusión, no debería haber ningún protocolo de enrutamiento ejecutándose con el ISP

Como mencionó, sus rutas estáticas se rompen, porque no existe una forma existente de forzar la conmutación por error al enlace WAN en ambos sitios cuando un sitio pierde el enlace ascendente a Internet.

La mejor solución a este problema es configurar algún tipo de túnel enrutado (procedente de las direcciones de enlace ISP en R1 y R2 en el diagrama) a través de Internet, ejecutar un protocolo de enrutamiento dinámico (OSPF / EIGRP) a través de su túnel y copia de seguridad WAN y establezca las métricas de enrutamiento para que el enlace WAN sea mucho más alto

Dado que obtiene el túnel de los enlaces de Internet en ambos lados, si alguno de los dos pierde la conectividad a Internet, el túnel se rompe (y el IGP se recupera en su enlace WAN). Si hace esto, asegúrese de que PMTUD funcione a través del túnel para que se tenga en cuenta la sobrecarga del túnel. Este tipo de VPN cifrada entre oficinas es bastante común, por lo que es una topología familiar para cualquiera que tenga que soportar esta red en el futuro.

El problema que enfrenta con su diseño actual es que todo su tráfico de tráfico entre oficinas parece no estar cifrado (al menos si leo su pregunta al pie de la letra). Si aún no lo está haciendo, le recomendaría encarecidamente que encripte todo el tráfico entre sus sitios corporativos, si va a través de Internet .

(La respuesta original de todo BGP cambió, según la solicitud de OP de no enrutamiento dinámico al ISP)

Como sugirió @Mike, el enrutamiento túnel + dinámico, especialmente en el revestimiento INET, es una solución sólida. Pero si por alguna razón no desea un túnel (no es compatible con HW, no quiere perder MTU, el enrutamiento dinámico no es aceptable ni siquiera internamente) su otra opción son las rutas rastreadas 'IP SLA'.

Explicaré cómo ayuda en el problema exacto que describe, donde la sucursal continúa devolviendo el tráfico a INET, mientras que debe usar el enlace directo.

En rama tendrías:

ip route HQNet HQMask InetIF InetNH track 1 50
ip route HQNet HQMask DirectIF DirectNH 100
ip route HQStableTestIP 255.255.255.255 InetIF InetNH
!
track 1 ip sla 1
!
ip sla 1
 icmp-echo <HQStableTestIP> source-interface InetIF
ip sla schedule 1 start-time now

Ahora, si no se puede acceder a HQ a través de INET, el seguimiento debería fallar, y la ruta más específica de INET debería invalidarse y debería recurrir a la siguiente mejor ruta que apunte al enlace directo.