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:
- Sale por Tucumán.
- Sale por Rosario.
- Sale por La Plata.
- Sale por Tucumán.
- Sale por Rosario.
- Sale por La Plata.
- [...]
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.
No hay comentarios:
Publicar un comentario