Вы находитесь на странице: 1из 7

CCNA 2 ENRUTAMIENTO CASO DE ESTUDIO CAPTULO 4 (Tomado y traducido del documento CCNA Exploration: Routing Protocols and Concepts,

, Chapter 4 Case Study, Cisco Learning Institute) Objetivos: Consolidar los conocimientos acerca de las caractersticas de estabilidad del enrutamiento. Consolidar los conocimientos acerca de la operacin de los Protocolos por Vector de Distancia. Consolidad las aptitudes para realizar actividades de descubrimiento y solucin de fallas de enrutamiento. Introduccin: TRED INC. se ha contactado con usted para que resuelva inconvenientes en su red de datos. De acuerdo a la conversacin telefnica, varios segmentos de la red se encuentran fuera de enlace. Topologa:

Escenario: TRED posee oficinas separadas fsicamente. Desde la perspectiva de la red, las oficinas se identifican como: BRANCH1 (B1), BRANCH2 (B2) y MAIN (M). MAIN fue la primera oficina creada y posee la conexin hacia Internet. Tal como se muestra en la topologa, B1 y B2 acceden a Internet va M. A fin de interconectar todos los tres sitios, TRED ha contratado dos enlaces de 512 Kbps con la Ca. Telefnica. El primer enlace WAN conecta B1 con B2 y el segundo, B2 con M. Un tercer enlace de 2 Mbps conecta M hacia el Internet. El ruteador B1 es responsable de rutear los paquetes desde y hacia la Network 1 (192.168.1.0/24). El ruteador B2 es responsable de rutear los paquetes desde y hacia la Network 2 (192.168.2.0/24) y provee la ruta por la que B1 accede a M, Network 3 e Internet. El ruteador M es responsable de proveer la conexin a Internet a todos los sitios de TREND INC. y por rutear los paquetes desde y hacia Network 3 (192.168.3.0/24) que est enlazada directamente a M. El Problema: De acuerdo a su conversacin telefnica, no existe trfico de datos entre Network 1 (bajo B1) y Network 3 (Bajo M). El resto del trfico funciona bien. Debido a la simplicidad de la red, RIPv1 fue escogido como protocolo de enrutamiento. Los reportes indican que todo estuvo trabajando bien hasta hace 1 semana atrs. Una vez en el sitio MAIN, usted revisa la configuracin de M. M tiene correctamente las direcciones IP asignadas a sus interfaces (como se describe en la topologa mostrada) y todas sus interfaces se encuentran en estado UP y activadas. A pesar que el ruteador M es capaz de enviar pings exitosos a la interfaz s0/1 de B2 (192.168.6.1/24), los pings hacia
Network 1 fallan. M tambin es capaz de enviar pings exitosos hacia direcciones aleatorias hacia la Internet (en M existe una ruta por defecto que apunta hacia el ISP y est correctamente configurada). El ruteador M tambin posee una ruta hacia Network 1 (192.168.1.0/24), aprendida desde B2 va RIPv1 la cual emplea la interfaz serial 0/1 de B2 como siguiente salto. Debido a que M tiene rutas RIP en su tabla de enrutamiento, usted asume que RIPv1 est correctamente configurado. Pregunta 1: Es correcto asumir los siguiente?: Debido a que M tiene rutas RIP en su tabla de enrutamiento, usted asume que RIPv1 est correctamente configurado. Respuesta:

Pregunta 2: En cuanto a la presentacin de los mensajes de depuracin, En qu aspecto difieren la ejecucin del comando debug en forma remota va telnet y la ejecucin de este comando debug va conexin puerto de consola en cuanto a la presentacin de los mensajes de

depuracin? (Tip: Investigue el comando a emplear para visualizar los mensajes de depuracin del debug va conexin remota). Respuesta:

Ahora usted est trabajando en B2 va remota desde M por medio de conexin telnet. Para asegurarse que los mensajes de depuracin se encuentran visibles usted ejecuta: B2# terminal monitor B2 tambin tiene correctamente configurado su direccionamiento IP, sus interfaces se encuentran levantadas y en ejecucin. Un vistazo rpido en la tabla de enrutamiento de B2 muestra unas pocas rutas aprendidas va RIP. Usted ejecuta pings desde B2 hacia PC1 (bajo la red Network1), y estos son exitosos. Usted ejecuta una pings adicionales ms desde B2 y obtiene los siguientes resultados: Desde B2 hacia serial 0/0 en B1: exitoso! Desde B2 hacia network 1 en B1: exitoso! Desde B2 hacia serial 0/1 en M: exitoso! Desde B2 hacia una direccin aleatoria en Internet: exitoso! Desde B2 hacia PC2 (en Network 3): falla! La ltima falla lo confunde. M es capaz de hacer ping a B2 (realmente usted est trabajando en B2 desde M!) y, como usted ya verific, M tiene una ruta correcta hacia Network 2 en B2 y es capaz hacer ping con xito hacia esa red. Usted lista la informacin de enrutamiento en B2 y se encuentra como sigue: Rutas en B2 aprendidas via RIPv1: Network 1 (192.168.1.0/24), via 192.168.5.1 (serial0/0 de B1) Network 3 (192.168.3.0/24), via 192.168.5.1 (serial0/0 de B1) Default route via 192.168.6.2 (serial 0/1 de M) Rutas directamente conectadas en B2: Network 2 (192.168.2.0/24), direct connected Network 5 (192.168.5.0/24), direct connected Network 6 (192.168.6.0/24), direct connected B2 posee una ruta aprendida va RIPv1 hacia Network 3 pero fue aprendida desde B1! Esto produce que B2 use a B1 como su siguiente salto hacia Network 3 cuando B2 debera usar M. Ya que B1 enva los paquetes hacia B2 a fin de alcanzar Network 3, existe un lazo de enrutamiento. Para alcanzar Network 2, B1 enva los paquetes hacia B2 el cual los enva de vuelta hacia B1, el cual los vuelve a enviar a B2 y as sucesivamente. Esto impide que Network 1 alcance a Network 3 y vice-versa. Aunque usted ha encontrado el problema, la razn por la que B2 est aprendiendo acerca de Network 3 desde B1 en lugar de M es an desconocida. Pregunta 3: Qu otro comando se puede utilizar para verificar los lazos de enrutamiento? Respuesta:

Pregunta 4:

Qu mtodos son usados por los protocolos de vector de distancia para evitar los lazos de enrutamiento?
Respuesta:

Pregunta 5: Qu debe evitar que B1 anuncie una ruta hacia Network 3 a B2?
Respuesta:

Usted decide echar un vistazo en B1: Ya que todas las interfaces en B2 se encuentran levantadas, usted trata de hacer ping a la interfaz serial0/0 en B1 como una prueba. El ping es exitoso y usted prueba un telnet hacia B1 el cual tambin es exitoso. Ahora usted se encuentra trabajando en B1. Despus de asegurarse que los mensajes de depuracin (debug) sern presentados en su emulador de terminal (como lo hizo en B2), usted revisa la configuracin en B1. B1 tambin tiene configurado RIPv1. Sus direcciones IP estn correctamente configuradas y todas las interfaces de B1 estn levantadas y correctas. Usted ejecuta algunos pings desde B1. Los resultados son los siguientes:
Desde B1 hacia PC1 (en Network 1): exitoso! Desde B1 hacia serial 0/0 en B2: exitoso! Desde B1 hacia Network 2 en B2: exitoso! Desde B1 hacia serial 0/1en M: exitoso! Desde B1 hacia direccin aleatoria en Internet: exitoso! Desde B1 hacia PC2 (en Network 3): falla!

Usted revisa la tabla de enrutamiento en B1 y todos las rutas no se encuentran como esperaba. B1 tiene rutas aprendidas va RIPv1 hacia: Network 2 (192.168.2.0/24), via 192.168.5.2 (serial0/0 de B2) Network 6 (192.168.6.0/24), via 192.168.5.2 (serial0/0 de B2) Default route, via 192.168.5.2 (serial0/0 de B2) Las rutas directamente conectadas en B1 son: Network 1 (192.168.1.0/24), direct connected Network 5 (192.168.5.0/24), direct connected B1 tambin tiene una ruta esttica hacia Network 3: Network 3 (192.168.3.0/24), via 192.168.5.2 (serial0/0 de B2)

El hecho que B1 posea una ruta esttica hacia Network 3 es inesperado ya que B1 debera aprender esa ruta via RIVv1. A pesar de tratarse de una ruta esttica, usa correctamente B2 como el siguiente salto. Aunque B1 posee una ruta esttica hacia Network 3, de todos modos, no puede alcanzar Network 3. Usted revisa las configuraciones avanzadas de RIPv1 usando el comando sh ip protocols y nota que split.-horizon no se encuentra activado. Adems, los temporizadores de B1 para RIPv1 tambin han sido cambiados. Los temporizadores actualmente configurados en B1 se encuentran como se muestra a continuacin: Update: 3 seconds Invalid: 180 seconds Holdown: 1 second Flush: 240 seconds B1 tambin se encuentra configurado para anunciar sus rutas estticas dentro de sus actualizaciones RIPv1. Pregunta 6: Cul es la funcin de cada uno de los temporizadores mostrados arriba? configurados en sus valores por defecto? Respuesta: Se encuentran

Despus de preguntar al administrador de TRED, usted se entera que unos pocos das atrs, el enlace con Network 3 se perdi y que se llam a un tcnico para solucionar el problema. Despus de haber trabajado un da entero en el problema, a pesar que el enlace con Network 3 haba sido levantado, esta red no era capaz de alcanzar Network 1. Debido a que el tcnico no fue capaz de resolver completamente el problema, TRED INC. se comunic con usted. Pudiera haber ocurrido que el tcnico cambi las configuraciones de RIPv1 en B1 en su intento por solucionar el problema de enlace con Network 3. La ruta esttica anunciada, los valores incorrectos en los temporizadores y la no activacin del split-horizon ayudaron a anunciar hacia B2 una ruta incorrecta hacia Network 3. An en B1, usted configura los temporizadores en sus valores por defecto (los cuales son suficientemente buenos para una red pequea como la de TRED INC.), habilita split-horizon y configura B1 para que no contine anunciando sus rutas estticas. Los comandos se documentan para referencias futuras y son los siguientes:
B1(config)# router rip B1(config-router)# timers basic 30 180 180 240 B1(config-router)# no redistribute static B1(config)# int se 0/0 B1(config-if)# ip split-horizon B1(config-if)# end

Usted tambin elimina la ruta esttica hacia Network 3 desde la configuracin de B1. Pregunta 7: Cul es el commando empleado para remover las rutas estticas? Respuesta:

Usted termina la session telnet en B1 y retorna a B2. Todas las rutas requieren un revisin ms detallada. Para acelerar las actualizaciones de enrutamiento usted ejecuta el comando clear ip route * en B1 antes de retornar a B2 y, una vez en B2, usted hace lo mismo. Una vez en B2, usted decide revisar la configuracin avanzada de RIPv1. Aunque splithorizon se encuentra habilitado en B2, los temporizadores tambin han sido cambiados de la misma manera como se encontraban en B1. Usted configura los temporizadores en B2 a sus valores por defecto y revisa la tabla de enrutamiento. Usted nota que ahora, B2 no tiene ruta hacia Network 3. B1 ya no est anunciando a B2 sobre Network 3 y B2 deba haber aprendido acerca de Network 3 desde M. Algo est fallando an. Un ltimo vistazo a la configuracin de M muestra ms huellas del trabajo del tcnico: Network 3 no forma parte de RIPv1 en M y por lo tanto, no est siendo anunciada dentro de las actualizaciones RIPv1 hacia B2. Sus suposiciones previas acerca de que RIPv1 estaba correctamente configurado en M estaban incorrectas. En B1, ejecuta unos cuantos comandos pings extendidos desde Network 1 hacia PC2 (en Network 3) y desde PC1 hacia PC2. Todos los pings son exitosos esta vez. Los comandos ejecutados en M se documentan a continuacin:

M(config)# router rip M(config-router)# network 192.168.3.0 M(config-router)# end Pregunta 8: Porqu los ping extendidos fueron empleados desde Network 1 hacia PC2 en lugar de usar pings regulares? Respuesta:

Usted ejecuta unos pocos pings adicionales y todo se encuentra correcto. Conclusin: En su intento por resolver el problema con Network 3, el tcnico errneamente elimin Network 3 del proceso RIPv1 lo cual hizo que M no anuncie Network 3 hacia B2. Debido a que el trfico desde Network 1 hacia Network 3 era alto, cuando B2 perdi su ruta hacia Network 3, esta fue marcada como fuera de alcance. El tcnico tambin cambi los termporizadores en B1 y en B2 lo cual hizo que B2 acepte nueva informacin acerca de Network 3 desde B1 antes de que B2 pueda informar a B1 que no tena ruta hacia Network 3 (holdown=1 en B2). El tcnico cre una ruta esttica hacia network 3 y la aadi al proceso RIPv1 en B1. B1 alcanz su propio temporizador de actualizacin (update timer) y envio va broadcast su tabla de enrutamiento hacia B2 la cual incluy la ruta incorrecta hacia Network 3. Ya que B2 no tena ruta hacia Network 3 y tena los temporizadores modificados, acept la tabla de enrutamiento de B1 y tom a B1 como el siguiente salto hacia Network 3. Note que debido a que la ruta de B1 hacia Network 3 era via B2, exista un lazo de enrutamiento.

B1 no deba enviar anuncios hacia B2 acerca de Network 3 debido a que aprenda inicialmente esta ruta desde B2. Debido a que el split-horizon tambin haba sido desactivado en B1, B1 termin anunciando informacin acerca de Network 3 de vuelta a B2, creando un lazo. El problema fue resuelto reactivando split-horizon en B1, eliminando la ruta esttica desde B1, corrigiendo los temporizadores en B1 y B2 y aadiendo Network 3 al proceso RIPv1 en M.

Вам также может понравиться