Configurar redundancia usando estática flotante

7

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

Beto
fuente
¿Estás haciendo BGP al ISP? si es así, esto se vuelve más fácil, si no, bueno ... hay formas pero no será tan divertido.
Olipro
1
El requisito es que no quieran ejecutar ningún protocolo de enrutamiento con el ISP
Bob
1
@bob, por favor dime que tu empresa está encriptando el tráfico entre oficinas que están enviando a través de Internet
Mike Pennington
¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:

9

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

Túnel HQ-Backup

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 .

Mike Pennington
fuente
@bob, ¿qué modelo de equipo de red tiene en cada sitio? si cisco eqpt, incluya qué conjunto de características de ios tiene
Mike Pennington
5

(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.

ytti
fuente
Lamento mucho el problema, fue mi error no decir que no debería haber ningún protocolo de enrutamiento que se ejecute con el ISP :(
bob
Entonces, lo mejor que puede hacer es usar 'IP SLA' para rastrear las rutas estáticas. Para ser robusto frente a los problemas relacionados con el seguimiento, necesitaría tres rutas 1) apuntando a primario, rastreado 2) apuntando a secundario rastreado 3) apuntando a primario, no rastreado (3er es necesario, por lo que si todo el seguimiento falla, aún intentará usar la conexión primaria, en lugar de darse por vencido). Otras preguntas en este sitio tienen ejemplos de IP SLA.
ytti
La respuesta original cambió para reflejar el nuevo requisito
ytti
1
El OP realmente necesita cifrar su tráfico a través de Internet ... después de revisar la pregunta varias veces, estoy cada vez más convencido de que actualmente está enviando su tráfico interno como texto sin cifrar.
Mike Pennington
1
Se nota el drama obligatorio en torno a la pedantería. Confiar en cada clave en los scripts es una solución aceptable siempre que otras personas ingresen manualmente a los mismos dispositivos con la comprobación de claves habilitada ... cuando pasas tu vida automatizando sesiones de CLI, hay ciertas elecciones que nunca harías como humano para mantener tu trabaje en espiral hacia ratholes de soluciones de baja probabilidad. El diagrama del OP puede o no reflejar la referencia al mismo ISP ... eso podría ser simplemente un artefacto de no querer complicar un diagrama ascii-art con lo que considera detalles innecesarios
Mike Pennington