Cisco TDR Feature: Estado de los Pares del Cable UTP

 Thank to: https://learningnetwork.cisco.com/

Hace algunos años estuve en un proyecto donde estuve revisando diversos Switches Cisco y resolviendo problemas de conectividad en redes LAN en una empresa que tiene varias sucursales en provincias de mi país, Perú.

Es muy conocido por muchos administradores de red que cuando tenemos un problema de conectividad en una PC, teléfono u otro dispositivo final conectado a un puerto de un Switch LAN, la prueba más común es a través de los comandos ping y traceroute. Las acciones complementarias incluyen verificaciones de la tabla ARP y la tabla de direcciones MAC.

Como podemos darnos cuenta, la prueba más común en un problema de conectividad comienza con la capa 3 (ping), luego revisamos si hubo un registro de la dirección MAC del dispositivo final en el puerto del Switch, que corresponde a la capa 2 (tabla de direcciones mac). En caso de no obtener un resultado favorable en ambas pruebas, podríamos suponer que hay una desconexión física en la red, sin embargo lo que quiero exponer en este artículo es sobre un caso donde no obtuve ningún resultado en la prueba de ping, ningún registro de la dirección MAC en el puerto del Switch, pero, curiosamente el estado del puerto del Switch donde se conectó una PC (que utilizaba un aplicativo web muy importante donde los usuarios se conectaban de forma remota) estuvo en estado up/up. Esto sucedió en una sucursal ubicada en otra provincia, lejos de mi ubicación de trabajo.

Esto fue algo que llamó mi atención, ya que, aunque el problema está claramente en la capa 1, se hubiera tenido que realizar una medición del cableado con un equipo que prueba cables de red, sin embargo no se contaba con ese instrumento en dicha sucursal. Incluso, el único asistente de redes en la sucursal no estuvo presente en ese momento, por tanto, solo había personal administrativo que no tenía conocimiento en redes. La solución en ese instante de urgencia era realizar un diagnóstico del cableado de forma remota y tener un reporte que sustente ese diagnóstico.

Es cierto que vemos diversos probadores de cable de red de diferentes proveedores (en esa empresa se contaba con un Probador de cable de red de Fluke solo en la sede central), sin embargo, aunque Cisco no fabrica estos productos, siempre ha tenido en cuenta diversos métodos de probar la conectividad en un Switch LAN. Teniendo esto en mente, me puse a investigar al respecto y encontré que Cisco utiliza un instrumento electrónico virtual (tester) denominado: TDR (time-domain reflectometer), lo cual voy a describir a continuación.

 

TDR

Un time-domain reflectometer (TDR) es un instrumento electrónico virtual utilizado para testear cables, brindando una salida muy útil y así tener una información que nos permita sustentar por medio de un reporte sobre las fallas encontradas en los cables de cobre como el par trenzado (UTP), donde me voy a enfocar en esta oportunidad.

Consideraciones en equipos Cisco sobre TDR:

• Los Switches Cisco lo soportan desde el IOS versión 12.2 o posterior. TDR es compatible con IOS versión 15.0. Las anteriores versiones al IOS 12.2 no soportan TDR.
• Si estamos ejecutando el IOS versión 12.2, la prueba con TDR podría producir interrupciones súbitas. En otras palabras, la interfaz irá hacia abajo (down) y hacia arriba (up). Si hacemos pruebas en un puerto de switch que conecta a un PC que está funcionando correctamente, el dispositivo perderá conectividad de red por la prueba en dicho puerto.
• Si el dispositivo soporta PoE, la prueba hará que el dispositivo pierda potencia. Un ejemplo típico es la conexión de un teléfono IP y una PC conectados al mismo puerto del Switch, donde tanto el teléfono como la PC perderán la conectividad de red.
• Particularmente cuando ejecuta versiones antiguas de IOS, la prueba puede tomar entre cinco (5) y siete (7) segundos.
• TDR funciona en 10/100/1000BaseTX (ETHERNET). Los puertos de fibra óptica no pueden ser medidos por este tester (en Fibra, podemos usar un comando útil como: “show interface transceiver [detail]” que es soportado por Switches de alta gama).

 

Ejecución de la prueba con TDR:

El diagnóstico se realiza por puerto, donde en primer lugar se realiza la medición correspondiente, esto se hace con el comando:

Switch# test cable-diagnostics tdr interface interface-type interface-number

Después de un tiempo prudencial de unos cuantos segundos, ejecutamos el siguiente comando “show” donde nos mostrará el resultado de la medición realizada.

Switch# show cable-diagnostics tdr interface interface-type interface-number

Como ejemplo tenemos una prueba en el Switch WS-C2960-24LT-L que cuenta con puertos FastEthernet y GigabitEthernet. Tener en cuenta que cuando usamos la prueba en un puerto FastEthernet, TDR solo probará los dos primeros pares, los pares A y B, ya que en una conexión FastEthernet solo utilizamos dos pares en el cable UTP, por tanto, los pares C y D no van ser probados y obtendremos un resultado de “Not Supported” (No soportado). Por otro lado, cuando se realiza la medición en puertos GigabitEthernet, todos los pares serán probados, ya que en una conexión GigabitEthernet utilizamos los cuatro pares en el cable UTP.

 

Prueba en un Puerto FastEthernet – Puerto operativo

Prueba en un Puerto GigaEthernet – Puerto operativo

Estas salidas las podemos tomar como referencia al momento de realizar las pruebas, ya que cualquier estado del par que muestre una condición diferente a lo mostrado arriba, indicará absolutamente un estado de falla en el cableado UTP.

Con todo esto, volviendo al caso que tuve en ese momento en la oficina de ka sucursal, el Switch que estuve analizando en ese entonces era el modelo WS-C3560X-24P-S

Entonces, cuando realicé la medición en el puerto donde estuvo conectado esa PC (plenamente identificado gracias al registro encontrado en la documentación de la red), obtuve el siguiente resultado

La presencia de estados en los pares UTP como “Open” y “Short/ Crosstalk” indicaron claramente una falla en el cableado UTP desde el puerto del Switch al equipo, donde la conexión pasa por Patch panels donde utilizamos los patch cords UTP para las conexiones y el cableado horizontal correspondiente. Esto se entenderá mejor con el siguiente gráfico:

El estado “Open” indicaba una rotura en uno de los pares durante el recorrido del cableado UTP y el estado “Short/Crosstalk” ocurre cuando la señal de un cable se mezcla con la señal de otro cable. Esto puede suceder cuando los cables están deteriorados o se tiene un RJ45 plug desgastado o roto. Esto produce el efecto de "corto circuito" en la señal.

Con esta información, envíe el correo correspondiente informando este evento y la salida de este comando como sustento de mi diagnóstico. Después de eso, logré contactarme con el asistente de redes para que revise el recorrido del cableado y que comience cambiando el Patch cord que conecta a la PC. Y cuando realizó ese procedimiento, se tuvo nuevamente conectividad en esa PC y el acceso remoto de su aplicativo por parte de los usuarios. El asistente de redes me informó que había encontrado el RJ45 plug del Patch Cord muy dañado. El cableado de red en la sucursal no había sido cambiado en años.

Todo esto sirvió para que se pudieran iniciarse, después de algún tiempo, los proyectos de mantenimiento de todo el cableado en cada sucursal y también en los gabinetes de comunicaciones.

Aquí les comparto registros de otras pruebas de cableado realizado en otros Switches utilizando TDR

A modo de conclusión, la intención de lo expuesto es en primer lugar compartirles una experiencia que tuve como Ingeniero en proyectos de redes y telecomunicaciones donde se tuvo que realizar troubleshooting (soluciones de problemas), al mismo tiempo que compartirles una herramienta útil que podemos aplicar por medio de comandos en un Switch Cisco y en segundo lugar es para motivarles a seguir estudiando, investigando y practicando, ya que un amante de las tecnologías de redes no se conformará con lo presentado sino que investigará acerca de la infraestructura de redes que incluye el cableado estructurado y las otras características que debemos considerar al realizar un proyecto de redes y telecomunicaciones.