AMPLIACIÓN DE REDES PRÁCTICA 1: FRAME RELAY Y ...

Práctica 1: Frame Relay y Control de Tráfico
Además de la condición impuesta por la varianza el balanceo de tráfico tiene otro requisito. Para que la
segunda ruta se tome en consideración es necesario que el siguiente router tenga una mejor métrica que el
router actual. Por ejmplo en nuestro caso la métrica de Castellón hacia Alicante es la misma que la de
Valencia a Alicante, pues en ambos casos se atraviesa un enlace de las mismas características (bandwidth
128, delay 2000). En estas condiciones , sea cual sea el valor de la varianza, Valencia nunca enviará
tráfico hacia Alicante vía Castellón, pues la métrica que le presenta Castellón no es más baja que la suya
propia. Por tanto para que la ruta vía Castellón sea tomada en cuenta tenemos que darle alguna ventaja en
la métrica, aunque sea pequeña, al PVC Castellón-Alicante. Para ello bajaremos a 19ms el retardo de la
subinterfaz Serial 0.302 en Castellón y el de la Serial 0.203 en Alicante. De esta forma conseguimos que
el PVC Castellón-Alicante presente una métrica ligeramente inferior que los otros dos.
Ahora en el ‘Show IP ROute’ ejecutado en el router de Valencia veremos aparecer también la ruta
vía Castellón. Los alumnos deben anotar los valores que corresponden a la LAN de Alicante.
Con esto ya debe haber reparto de tráfico entre los dos PVCs, como podremos comprobar si hacemos un
‘ping –R –n’ entre el host de Valencia y el de Alicante. Pero aunque el ‘ping –R -n’ nos muestra un
aparente reparto de tráfico entre las dos rutas, si enviamos un número elevado de paquetes con el ‘ping –
f’ y miramos los contadores de las interfaces del router RS observaremos que todo el tráfico sale por una
misma interfaz (podemos utilizar el comando ‘CLEar COunters’ para hacer más fácilmente el
seguimiento). ¿A que se debe este comportamiento? La explicación es la siguiente: los routers
normalmente no consultan la tabla de routing para cada paquete que envían por sus interfaces sino que,
para acelerar el proceso de enrutamiento, construyen una tabla en memoria cache en la que a cada
dirección IP de destino le asocian una interfaz de salida, y solo una. Esto se conoce como conmutación
por destino o también ‘fast switching’ (conmutación rápida). Podemos ver la tabla de cache de routing
mediante el comando ‘Show IP CAche’ donde comprobaremos que la dirección IP hacia la que iban
dirigidos los pings está asociada a la interfaz por la que estaba saliendo todo el tráfico con el ‘ping –f’.
Como todos los paquetes los estamos enviando hacia una misma dirección IP el uso de la IP cache
impide en la práctica el balanceo de tráfico entre los dos PVCs. Si hiciéramos pings a direcciones
diferentes veríamos que unas se asocian con una subinterfaz y otras con la otra, produciéndose un
efectivo reparto de tráfico entre ambos PVCs.
Para conseguir el reparto de tráfico entre más de una ruta cuando todos los paquetes van dirigidos a un
mismo destino, comoen nuestro caso, tenemos que deshabilitar la conmutación por destino, es decir
deshabilitar la tabla de routing IP cache. Esto lo haremos en modo Configuración de Interfaz para la
interfaz Serial 0 mediante el comando ‘NO IP ROute-cache’. Con esto esa interfaz y todas sus
subinterfaces pasan a funcionar en el modo conmutación por paquete, también llamado ‘process
switching’ (conmutación por proceso) y balancean tráfico paquete a paquete, aún en el caso de que todo
vaya destinado a la misma dirección IP. Podemos comprobar que hemos desactivado la cache de routing
con el comando ‘Show IP CAche’ o con el comando ‘Show IP INterface subinterfaz’
que nos dirá ‘IP fast switching is disabled’.
Una vez desactivado el fast switching repetiremos el ‘ping –f’ entre Valencia y Alicante y
comprobaremos que ahora sí que hay reparto de tráfico entre ambas subinterfaces. Además podremos
comprobar que el reparto no es homogéneo, sino inversamente proporcional al valor de la métrica de
cada ruta. Para ver esto debemos proceder de la siguiente forma:
1. Lanzamos el ‘ping –f’ del host de Valencia al de Alicante.
2. Ejecutamos un ‘CLEar COunters’ (de todas las interfaces).
3. Esperamos medio minuto aproximadamente (que corresponde a unos 3000 paquetes) y
abortamos el ping con CTRL/C.
4. Ejecutamos un ‘Show Interfaces Serial 0.103’ y ‘Show Interfaces
Serial 0.102’ y observamos los contadores de paquetes transmitidos por cada subinterfaz.
En principio deberíamos fijarnos únicamente en los paquetes transmitidos, ya que son estos los que
dependen de los valores de las métricas (el reparto de tráfico entrante depende de los valores de las
métricas en los otros routers, Castellón y Alicante). De cualquier modo como en este caso tenemos una
situación simétrica los contadores de paquetes recibidos deberían seguir el mismo reparto.
P2-21