Troubleshooting redes IP enfoque en Enlaces WAN

Carrera: Ingeniera en Conectividad y de Redes Profesor: Eduardo Miguel Aranda Acebedo Ramo: Deteccin de Problemas de Red Seccin 016v Alumno: Julio Menndez Ziga

M ANEJO DE FALLAS.
Troubleshooting Procedimientos Generales

Etapa 1

Recopilacin de sntomas: la resolucin de problemas comienza con el proceso de recopilacin y documentacin de los sntomas que se observan en la red, en los equipos de comunicaciones o los reportes usuarios. El administrador de red determina cules componentes de la red se vieron afectados y cmo cambi la funcionalidad de la red en comparacin con un estado normal de funcionamiento. Los sntomas pueden aparecer de varias formas diferentes; como alertas del sistema de administracin de redes, mensajes de la consola y quejas de usuarios.

Etapa 2

Identificacin y aislamiento del problema: el problema no se asla realmente hasta que se identifica un solo origen o un conjunto de problemas relacionados. Para esto, el administrador de red examina la informacin recopilada de los sntomas y procede a descartar hasta llegar a una hiptesis nica, la cual deber verificar.

Etapa 3

Correccin del problema y documentacin: una vez que se identific y aisl la causa del problema, el administrador de red trabaja para corregir el problema mediante la implementacin, prueba y documentacin de una solucin. Si el administrador de red determina que la accin correctiva ha generado otro problema, se documenta el intento de solucin, se eliminan los cambios y el administrador de red vuelve a recopilar sntomas y a aislar el problema.

M ETODOLOGAS TSHOOT 1.- Examen de la capa superior (7) a la inferior (1). 2.- Examen de la capa inferior (1) a la superior (7). 3.- Divide y conquistaras (Examen comienza en el centro: capa 3 hacia abajo (1) y hacia arriba (7)). 4.- Examen de la ruta fsica del trfico. (El problema podra provenir del primer equipo de conmutacin). 5.- Comparacin de configuracin entre dispositivos que cumplen la misma funcin o que interactan en la ruta del trfico. 6.- Metodologa 6 no merece una mencin pues estara contenida en una o varias de las anteriores.

M TODO TSHOOT ELEGIDO:

Examen de la capa inferior (1) a la superior (7).

NOTA: En este caso solo hasta capa 3 por ser un enlace WAN

APLICACIN ENLACE SERIAL WAN PROTOCOLO PPP

Conocimientos asociados.#show ip int brief

Entrega un informe resumido de cada interfaz, subinterface, loopback con su ip asignada IP Address estado en capa1 Status y capa2 Protocol. Ejem:
Interface Ethernet0 Serial2/0 IP-Address 10.108.00.5 10.108.100.5 OK? YES YES Method NVRAM NVRAM Status up up Protocol up down

*De aqu nos interesa el Status y Protocol*

Status: indica si hay conectividad elctrica en la interfaz, si esta Down y no esta administrativamente Down, debera estar UP si esta es Ethernet, aunque el cable no sea el correcto en norma, de acuerdo a los equipos conectados o aun si el cable estuviese desconectado. Pero si es una interfaz serial subir elctricamente solo si:

1.-Est conectada a su par.

2.-Ambas estn administrativamente UP.

4.- No existan problemas fsicos de en los medios y equipos de transmisin.

5.- Es necesario que se detecte seal CD (Carrier Detect) en ambos extremos.

Para saber cul es el extremo DCE debe usarse el comando sh controllers serial x/x en modo usuario privilegiado, veamos un ejemplo:

Router#sh controllers serial 2/0 Interface Serial2/0 Hardware is PowerQUICC MPC860 DTE V.35 clocks stopped.---> Indica que este extreme es el DTE, que el cable conectado es un V.35 y que el relog no est funcionando.

Protocol: Hace referencia al protocolo de capa 2 que trabaja en el enlace como PPP, SDLC, HDLC, ATM ETC. Si este est Down, indica que no se ha establecido el enlace, en otras palabras no ha existido comunicacin bidireccional o est a resultado en una negociacin fallida.

ESTADO DE INTERFACE

Serial2/0 is up, line protocol is down

HIPTESIS POSIBLES FALLAS

1.- Posible error de configuracin local o remota. 2.- Keepalives no estn siendo enviados por el router remoto. 3.- Un problema en el proveedor de servicio de la lnea u de otro tipo se ha producido (lnea con ruido o equipo remoto ha fallado). 4.- Un problema de tiempo se ha producido en el cable (SCTE5 no est presente en CSU / DSU). 5.- Una local o remota CSU/DSU ha fallado. 6.- Error de hardware en equipo local remoto. 7.- En el extremo DCE el reloj est mal configurado o no esta configurado. 8.- El dispositivo DTE no soporta o no est configurado para SCTE modo.

DESCARTES

1.- Verificar estado de los cables. 2.- Verificar estado de la CSU/DSU local. 3.- Llamar al proveedor y preguntar por alguna falla masiva o cada de equipo en particular. 4.- Verificar configuraciones. 5.- Verificar configuracin de cloc en extremo DCE y verificar su velocidad.

PRUEBAS

1.- Verifique todos los cables. Asegrese de que el cable est conectado a la interfaz correcta, a la correcta CSU / DSU. Utilice el comando show controllers serialx/x para determinar qu cable est conectado a cada interfaz.

2.- Poner el mdem, CSU, DSU o en modo de bucle local y utilizar los comando show interfaces serial x/x para determinar si el protocolo de lnea aparece. Si el protocolo de lnea sube (up), es probable que sea un problema del ISP o de un equipo remoto.

3.- Si el problema parece estar en el extremo remoto, repita el paso anterior en el mdem remoto, CSU, o ESD.

4.- Si el protocolo de lnea no sube, contine en modo de bucle local y ejecute el paso 5.

5.- Habilitar la depuracin (comandos debug) en interface serial.

Precaucin: Debido a que a la salida de depuracin se le asigna una alta prioridad en la CPU, esta puede
dejar el sistema inutilizable. Por esta razn, utilice los comandos de depuracin slo para solucionar problemas especficos o durante la solucin de problemas de sesiones con el personal de soporte tcnico de Cisco. De otra forma, lo mejor es usar comandos de depuracin durante los perodos de bajo trfico de red y menos usuarios.

Verifique: Esto debera causar que los paquetes Kepalives incrementen. Especficamente, los
valores mineseen y yourseen deberan incrementarse cada 10 segundos.

Ejemplo:

* En este ejemplo vemos que se pierden 4 Keepalives pero solo la interface pasa a estado Down, despus de la prdida o no recepcin de 3 sucesivos, porque se supera el hold-time establecido para la interfaz.

Nota: En el caso de este informe la falla es en una encapsulacin PPP. Pero el resultado debera ser el mismo que el mostrado en la interfaz HDLC si no se estuvieran recibiendo los paquetes Keepalives.

En el caso de PPP los Kepalives son sustituidos por mensajes LCP que actan como tales.

Ejemplo:

Uber-Geek-R4(config-if)#do deb ppp pack PPP packet display debugging is on Uber-Geek-R4(config-if)# *May *May *May *May *May *May *May *May *May *May *May *May 9 12:59:50.932: Se0/1/0 LCP-FS: I ECHOREQ [Open] id 30 len 12 magic 9 12:59:50.936: Se0/1/0 LCP-FS: O ECHOREP [Open] id 30 len 12 magic 9 12:59:50.948: Se0/1/0 LCP: O ECHOREQ [Open] id 30 len 12 magic 0x42345A4D 9 12:59:50.948: Se0/1/0 LCP-FS: I ECHOREP [Open] id 30 len 12 magic 9 12:59:50.948: Se0/1/0 LCP-FS: Received id 30, sent id 30, line up 9 13:00:01.172: Se0/1/0 LCP-FS: I ECHOREQ [Open] id 31 len 12 magic 9 13:00:01.172: Se0/1/0 LCP-FS: O ECHOREP [Open] id 31 len 12 magic 9 13:00:01.188: Se0/1/0 LCP: O ECHOREQ [Open] id 31 len 12 magic 0x42345A4D 9 13:00:01.188: Se0/1/0 LCP-FS: I ECHOREP [Open] id 31 len 12 magic 9 13:00:01.188: Se0/1/0 LCP-FS: Received id 31, sent id 31, line up 9 13:00:04.608: Se0/1/0 PPP: O pkt type 0x0207, datagramsize 335 9 13:00:11.412: Se0/1/0 LCP-FS: I ECHOREQ [Open] id 32 len 12 magic 0x4234E325 0x42345A4D

0x4234E325 Uber-Geek-R4(config-if)# 0x4234E325 0x42345A4D

0x4234E325 Uber-Geek-R4(config-if)# Uber-Geek-R4(config-if)# 0x4234E325

*May *May *May *May *May *May *May *May *May

9 13:00:11.412: Se0/1/0 LCP-FS: O ECHOREP [Open] id 32 len 12 magic 9 13:00:11.428: Se0/1/0 LCP: O ECHOREQ [Open] id 32 len 12 magic 0x42345A4D 9 13:00:11.428: Se0/1/0 LCP-FS: I ECHOREP [Open] id 32 len 12 magic 9 13:00:11.428: Se0/1/0 LCP-FS: Received id 32, sent id 32, line up 9 13:00:21.652: Se0/1/0 LCP-FS: I ECHOREQ [Open] id 33 len 12 magic 9 13:00:21.652: Se0/1/0 LCP-FS: O ECHOREP [Open] id 33 len 12 magic 9 13:00:21.668: Se0/1/0 LCP: O ECHOREQ [Open] id 33 len 12 magic 0x42345A4D 9 13:00:21.668: Se0/1/0 LCP-FS: I ECHOREP [Open] id 33 len 12 magic 9 13:00:21.668: Se0/1/0 LCP-FS: Received id 33, sent id 33, line up

0x42345A4D

0x4234E325 Uber-Geek-R4(config-if)#do un al 0x4234E325 0x42345A4D

0x4234E325 Uber-Geek-R4(config-if)#do un all All possible debugging has been turned off

Es importante notar que en algunas IOS recientes no se desactivan el enlace en capa 2 (Up - Down), aunque se hayan deshabilitado los Keepalives en uno de los extremos PPP, esto porque los mensajes LCP-FS: respondida LCP-FS:
I ECHOREQ

solicitan una respuesta de eco que es efectivamente

I ECHOREP

por el extremo donde los keepalives han sido deshabilitados,

o sea, en pocas palabras este lado no enva Keepalives pero si responde los que recibe y consecuencia de esto el enlace permanece UP-UP.

Pero esto es una falla segn lo informado por Wendell Odom's:

Wendell Odom's CCNA ICND2 Official Certification Guide (page 449): "It is a configuration mistake to enable keepalives on only one end of a point-to-point serial link. It appears that some very recent IOS versions notice when the keepalives are mistakenly disabled on one end of a link and prevent the link from going to an "up and down" state."

Los siguientes comandos de depuracin tambin pueden ayudarnos a detectar problemas en algunas de las fases del establecimiento del enlace en capa 2:

debug ppp packet debug ppp authentication debug ppp negotiation

Router#debug ppp negotiation PPP protocol negotiation debugging is on Router# %LINK-5-CHANGED: Interface Serial0/0, changed state to down Serial0/0 PPP: Phase is TERMINATING Serial0/0 LCP: State is Closed Serial0/0 PPP: Phase is DOWN %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down %LINK-5-CHANGED: Interface Serial0/0, changed state to up Serial0/0 PPP: Using default call direction Serial0/0 PPP: Treating connection as a dedicated line---> se trata como una conexin dedicada Serial0/0 PPP: Phase is ESTABLISHING, Active Open---> Se comienza abriendo o activando la fase de establecimiento del enlace. Serial0/0 LCP: State is Open---> Se activa LCP. Serial0/0 PPP: Phase is AUTHENTICATING---> Comienza la fase de autenticacin. Serial0/0 IPCP: O CONFREQ [Closed] id 1 len 10---> Paquetes para la configuracin y establecimiento del protocolo IP sobre PPP. Serial0/0 IPCP: I CONFACK [Closed] id 1 len 10 Serial0/0 IPCP: O CONFREQ [Closed] id 1 len 10 Serial0/0 IPCP: I CONFACK [REQsent] id 1 len 10 Serial0/0 IPCP: I CONFREQ [Closed] id 1 len 10 Serial0/0 IPCP: O CONFACK [Closed] id 1 len 10 Serial0/0 IPCP: I CONFREQ [REQsent] id 1 len 10 Serial0/0 IPCP: O CONFACK [REQsent] id 1 len 10 Serial0/0 PPP: Phase is FORWARDING, Attempting Forward---> Probando el enlace. Serial0/0 Phase is ESTABLISHING, Finish LCP---> Enlace ya establecido, se finaliza LCP. Serial0/0 Phase is UP %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up

El enlace en capa 2 solo sube cuando todos los procesos de configuracin, negociacin y pruebas han resultado exitosos y de acuerdo a la configuracin determinada por el administrador.

Show logging: Muestra una lista de errores o cambios de estado de enlaces y conexiones.

Tambin podran darse otras situaciones, como que el extremo no responda a tramas de control por a veces configuracin inconclusa o errnea.

Es notorio que aqu no se han expuesto problemas de capa 3 por ser estos los ms comunes, tomando en cuenta Adems que este es un enlace WAN Point-to-Point, los problemas capa 3 deberan ser prcticamente de configuracin IP.

Despus de hechas todas estas pruebas deberamos encontrar el problema y ser capaces de solucionarlo ya sea directamente o por nuestra gestin. Un simple Ping podra confirmar el retorno de la conectividad en capa 3.

BIBLIOGRAFA
Troubleshooting interfaces seriales. http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1915.html Problema IOS Keepalives PPP https://learningnetwork.cisco.com/thread/13137 Odom W. - Cisco CCNA ICND2 640-816 Official Cert Guide, 3rd Edition - 2011 Understanding debug ppp negotiation Output http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800ae945. shtml