martes, 7 de abril de 2009

Trucos para el enrutamiento estático

El enrutamiento estático puede ser una solución muy conveniente para cuando la cantidad de nodos en nuestra red no es tan amplia como para que valga la pena un protocolo dinámico. Pero puede transformarse en un verdadero dolor de cabeza en caso de que no tengamos en cuenta determinadas pautas.

Veamos el siguiente diagrama:



Supongamos que en esta red WAN todos los vínculos entre equipos son del mismo ancho de banda y tienen la misma tasa de error y confiabilidad.

Si tomamos el ejemplo de una comunicación entre Córdoba y Buenos Aires sería prudente realizar enrutamiento estático de tal forma que se balancee la carga entre los tres enlaces que están directamente conectados a ellos. De esta forma, en principio (sin tener en cuenta CEF y otras pautas) podemos decir que cuando sale un paquete desde Córdoba siempre irá por un camino distinto al anterior.

Por ejemplo los paquetes con numeración:
  1. Sale por Tucumán.
  2. Sale por Rosario.
  3. Sale por La Plata.
  4. Sale por Tucumán.
  5. Sale por Rosario.
  6. Sale por La Plata.
  7. [...]

Ahora,  supongamos que se cae el enlace entre Rosario y BsAs, Córdoba no se va a enterar porque no está directamente conectado y no hay un protocolo de enrutamiento que nos avise del fallo. Entonces se seguirá enviando tráfico a Rosario y este último lo descartará por tener el enlace caído.

Por esto podemos decir que 1/3 del tráfico que Córdoba envíe hacia BsAs se va a perder. Esto trae muchos problemas a la red y sus aplicaciones.

Afortunadamente contamos con algunas herramientas para lidiar con este tipo de problema:

La que utilizaremos en este caso se llama IP SLA, y está disponible desde la versión 12.3T de IOS.

La idea es que Córdoba va a estar todo el tiempo tirando un proceso ping a Buenos Aires a través de cada una de las interfases.

Dicho proceso será vinculado a una ruta estática, y por ende cuando un proceso falle se retira la ruta de la tabla automágicamente. A esto se llama 'hacer tracking' a un objeto.

Veamos en principio la configuración de Cordoba  y Buenos Aires:

Router CORDOBA:


interface FastEthernet0/0
description Enlace a Tucuman
ip address 192.168.7.2 255.255.255.252
!
interface FastEthernet0/1
description Enlace a Rosario
ip address 192.168.7.10 255.255.255.252
!
interface FastEthernet1/0
description Enlace a La Plata
ip address 192.168.7.18 255.255.255.252
!
interface FastEthernet1/1
description LAN
ip address 192.168.7.33 255.255.255.224
!
ip route 192.168.7.4 255.255.255.252 192.168.7.1 name TUCUMAN-BAIRES
ip route 192.168.7.12 255.255.255.252 192.168.7.9 name ROSARIO-BAIRES
ip route 192.168.7.20 255.255.255.252 192.168.7.17 name LAPLATA-BAIRES
ip route 0.0.0.0 0.0.0.0 192.168.7.1 name viaTUCUMAN
ip route 0.0.0.0 0.0.0.0 192.168.7.9 name viaROSARIO
ip route 0.0.0.0 0.0.0.0 192.168.7.17 name viaLAPLATA
!

Ahora vamos a configurar el IP SLA en CORDOBA para que detecte las caídas del servicio:

ip sla 1
icmp-echo 192.168.7.6 source-ip 192.168.7.2
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 192.168.7.14 source-ip 192.168.7.10
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo 192.168.7.22 source-ip 192.168.7.18
ip sla schedule 3 life forever start-time now

Ahora vinculamos tres objetos track con el ID de IP SLA correspondiente:
track 1 rtr 1 reachability
track 2 rtr 2 reachability
track 3 rtr 3 reachability

Y luego configuramos las rutas estáticas para que sean dependientes de cada track que le corresponda:
ip route 0.0.0.0 0.0.0.0 192.168.7.1 name viaTUCUMAN track 1
ip route 0.0.0.0 0.0.0.0 192.168.7.9 name viaROSARIO track 2
ip route 0.0.0.0 0.0.0.0 192.168.7.17 name viaLAPLATA track 3

Ahora solo hay que dejar que el IP SLA haga su trabajo sacando las rutas estáticas cuando el vecino no sea alcanzable. Obviamente en cualquier momento podemos verificar la configuración:
CORDOBA#show track
Track 1
Response Time Reporter 1 reachability
Reachability is Up
12 changes, last change 10w1d
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
STATIC-IP-ROUTING 0
Track 2
Response Time Reporter 2 reachability
Reachability is Up
6 changes, last change 15w4d
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
STATIC-IP-ROUTING 0
Track 3
Response Time Reporter 3 reachability
Reachability is Up
38 changes, last change 1w2d
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
STATIC-IP-ROUTING 0

También podemos verificar los niveles de SLA que nos dan nuestros proveedores:
CORDOBA#show ip sla statistics details  

Round Trip Time (RTT) for       Index 1
Latest RTT: 1 ms
Latest operation start time: 10:34:54.500 UTC Mon Apr 13 2009
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 40
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never

Round Trip Time (RTT) for       Index 2
Latest RTT: 1 ms
Latest operation start time: 10:34:54.500 UTC Mon Apr 13 2009
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 35
Number of failures: 5
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never

Round Trip Time (RTT) for       Index 3
Latest RTT: 1 ms
Latest operation start time: 10:34:54.500 UTC Mon Apr 13 2009
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 38
Number of failures: 2
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never

Con esta configuración básica podemos ver que el proveedor de WAN que mejor servicio nos da es el correspondiente al SLA 1 (Index 1), que es el que nos provee el enlace contra Tucumán.

La configuración de IP SLA en IOS puede ser tremendamente compleja, y puede permitirnos incluso dejar scripts de configuración que se accionan en caso de algún evento preconfigurado.

Podemos no solamente hacer ping, sino realizar consultas HTTP, DNS y varios más para determinar que el servicio monitoreado está andando bien.

Esta es la config más básica, pero creo que les va a ser muy útil en sus redes.

Hasta el próximo post.

6 comentarios:

fede dijo...

Hola ariel,
como todas las que lei, muy buena tu explicacion:D

¿Para que sirven las tres últimas rutas?:
ip route 0.0.0.0 0.0.0.0 192.168.7.1 name viaTUCUMAN
ip route 0.0.0.0 0.0.0.0 192.168.7.9 name viaROSARIO
ip route 0.0.0.0 0.0.0.0 192.168.7.17 name viaLAPLATA
Estas tres, ¿son las que hacen posible el balanceo de carga?

Las rutas estáticas por defecto se suelen utilizar en los router stub, ¿que es un router stub?

Gracias por tu ayuda Ariel, un saludo:D

Ariel Weher dijo...

Antes que nada una red stub es una red con un único punto de salida, como es el caso de la LAN de Córdoba y de Buenos Aires. El routerstub solo necesita una ruta por defecto (o en este caso 3 que balancean) para poder llegar a cualquier lado.

Saludos

Anónimo dijo...

aca tambien la imagen esta rota, la podrias arreglar ?

Ariel S. Weher dijo...

Ya está arreglada. Saludos y gracias

Unknown dijo...

cuando falla un enlace hay registo en el log del router?

Anónimo dijo...

que pasa cuando el enlace principal vuelve??? se restaura la ruta original

Publicar un comentario