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


9

Red de conmutación por error 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.

Respuestas:


7

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.


55
Buena respuesta. Si usa bfd, puede fallar bastante rápido, aunque debes asegurarte de que tus T1 se estén ejecutando antes de ir aquí ... A los T1 les encanta recolectar errores, lo que podría provocar aleteo si los temporizadores de bfd son demasiado bajos
Mike Pennington

44
@MikePennington +1 para BFD. Sin embargo, siempre me gusta señalar (porque me ha mordido personalmente) que desde la era ISR G2 en adelante, BFD puede requerir una actualización de licencia dependiendo de su versión de iOS. Consulte este informe técnico de Cisco para obtener más información.
Brett Lykins

La clave para mí es que usted señaló que las rutas estáticas tienen prioridad sobre las dinámicas, por lo que lo utilizaré para mi ventaja. Investigaré si esos cuadros admitirán EIGRP y lo implementarán si lo hacen. ¡Gracias!
Bote Man

1
La distancia administrativa entra en juego cuando un enrutador conoce la misma ruta en su RIB y necesita decidir entre ellos. En su entorno aislado, no necesitará una puerta de enlace predeterminada en nada que no sean sus servidores; Sus enrutadores tendrán un conocimiento completo de cómo llegar a todo lo demás. Mejor escenario: cuando (no si) tiene un fallo de enlace, ni siquiera se dará cuenta.
Ryan Foley

1
@BoteMan No estoy completamente seguro de lo que está en el otro extremo de la línea DSL. Si su ISP lo controla, aún necesitará una ruta predeterminada en R1 para llegar al exterior. Si controla lo que esté en el otro extremo de la línea DSL, entonces sí, cada enrutador debe tener un conocimiento completo de todas las demás rutas y sus servidores podrán acceder a la línea DSL.
Ryan Foley
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.