Cómo proporcionar conmutación por error para la diversidad espacial T1

He heredado una red pequeña, insular y dedicada que está esencialmente libre de problemas, por lo que, naturalmente, quiero mejorarla :-) Bajé el conocimiento de mi red y la comprensión a alrededor de 2 a 3 en una escala de 1-10 después de leer Publicaciones de redes aquí. Solo he incluido los enrutadores pertinentes en mi diagrama para mayor claridad.

Actualmente hay una combinación de aproximadamente 6-8 Cisco 2800 y 2900 en cada campus con tarjetas de voz para una aplicación local dedicada, que utiliza rutas estáticas para obtener paquetes entre los 2 campus. Están ejecutando c2801-spservicesk9-mz.124-3g en R1 y R2, y c2800nm-adventerprisek9-mz.124-15.t3 en R3 y R4.

Esta es una red fija e inmutable que sirve solo a esta aplicación dedicada. No hay computadoras de escritorio ni computadoras portátiles yendo y viniendo, solo los enrutadores Cisco conectados a través de muxes de fibra de terceros en una topología de anillo en cada campus con un par de máquinas de servidor conectadas (parte de los "otros nodos").

En algún momento, el cliente decidió que sería una gran idea instalar un segundo T1 entre R2 y R3 para redundancia. Según mis pruebas, el enrutamiento estático no tiene forma de emplear ese segundo T1. Incluso con AD / métrica en una ruta secundaria a la nueva T1, solo el enrutador cuya T1 ha fallado lo sabe, pero los otros enrutadores de ese campus no.

Estaba considerando usar objetos de seguimiento de ip después de leer tales soluciones aquí para mantener las cosas simples y minimizar el malestar en la red. Luego leí donde EIGRP es la forma preferida de manejar esto.

Pero si el enrutamiento dinámico es el camino a seguir, debe implementarse de manera que no interrumpa el servicio. Todo esto es remoto para mí y requeriría que contrate a un técnico local para que esté en caso de que pierda la conectividad durante la reconfiguración. Con suerte, con una red tan pequeña e inmutable, esta interrupción podría minimizarse.

Entonces, ¿debería estar investigando cómo emplear objetos de seguimiento de IP o EIGRP para lograr este enrutamiento de conmutación por error T1?

EDITAR: Aquí están las rutas configuradas actualmente para R4. Estoy bastante seguro de que hay algo malo aquí, pero intenté exactamente una vez simplificarlo y retrocedí cuando cometí un pequeño error y perdí la conectividad con el Campus B. Las interrupciones son un gran no-no. Decidí dejarlo lo suficientemente bien hasta que ideé un mejor enfoque.

ip route 10.0.0.0 255.0.0.0 10.1.1.8
ip route 10.1.1.8 255.255.255.252 Serial0/3/0
ip route 192.168.30.0 255.255.255.0 Serial0/3/0
ip route 192.168.6.0 255.255.255.0 Serial0/3/0
ip route 192.168.8.0 255.255.255.0 FastEthernet0/0
ip route 10.0.2.128 255.255.255.192 192.168.31.2
ip route 10.2.160.0 255.255.255.0 192.168.31.2
ip route 192.168.254.0 255.255.255.0 192.168.31.2
ip route 192.168.6.0 255.255.255.0 192.168.8.11 110 name fallback
ip route 0.0.0.0 0.0.0.0 10.1.1.9
ip route 0.0.0.0 0.0.0.0 192.168.8.11 110 name fallback

La configuración de ruta para R3 es simple:

ip route 0.0.0.0 0.0.0.0 192.168.8.15
ip route 0.0.0.0 0.0.0.0 10.1.1.5 110

Gracias.

Esta es una red fija e inmutable que sirve solo a esta aplicación dedicada.

Creo que está descubriendo que esto rara vez es la norma con las redes, incluso con redes que no cambian; por lo tanto, por qué estás aquí preguntando cómo automatizar esto. Eventualmente, otro enlace entra en línea que requiere que usted rediseñe todos sus esfuerzos anteriores. Este es, por definición, cuál es el propósito de un protocolo de enrutamiento. ¡Es para asegurarse de que no tenga que usar rutas estáticas en todas partes!

Según mis pruebas, el enrutamiento estático no tiene forma de emplear ese segundo T1.

Puede configurar una especie de SLA IP que puede mantener su sistema en funcionamiento tal como está permitiendo la conmutación por error en caso de que Old T1falle.

Un ejemplo de este tipo de configuración para R4 sería algo como esto.

R4(config)# ip sla 1
R4(config)# icmp-echo 10.1.1.9 source-interface Serial0/3/0
R4(config)# timeout 1000
R4(config)# threshold 2
R4(config)# frequency 3
R4(config)# ip sla schedule 1 life forever start-time now
R4(config)# track 1 ip sla 1 reachability
R4(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.9 track 1
R4(config)# ip route 0.0.0.0 0.0.0.0 192.168.8.11 100

_{Versión modificada de la configuración de muestra firewall.cx .}

Pero, como está descubriendo rápidamente, es la forma menos que ideal de hacer esto. La automatización de esto con EIGRP es probablemente su mejor opción, ya que tiene todo el hardware de Cisco.

Pero si el enrutamiento dinámico es el camino a seguir, debe implementarse de manera que no interrumpa el servicio.

Si configura EIGRP junto con sus rutas estáticas. Se construirán relaciones de vecinos EIGRP y sus tablas de enrutamiento se completarán con rutas a las diferentes ubicaciones. Realmente no debería ocurrir ninguna interrupción, porque sus enrutadores tendrán una tabla de enrutamiento completamente poblada con conocimiento de cómo llegar a las otras subredes.

Solo recuerde, una vez que todo esté configurado y funcionando sin problemas tanto con EIGRP como con enrutamiento estático, seguirá utilizando sus rutas estáticas hasta que las elimine. Hecho correctamente, ni siquiera debería notar una falla en el flujo de tráfico.

Compare sus configuraciones anteriores con un ejemplo de configuración EIGRP para R4.

R4(config)#router eigrp 1
R4(config-router)#no auto-summary
R4(config-router)#network 10.1.1.8
R4(config-router)#network 192.168.8.0

Por lo general, es así de simple para una red tan pequeña.