Troubleshooting de Redes Básico

NOTA: Este post fue publicado originalmente en mi anterior blog el
10/08/2007

Cuando se está tratando de resolver un problema de comunicación, por ejemplo de flujo de correos entre servidores, lo segundo que hay que revisar (lo primero, todos sabemos: verificar que el servidor esté “encendido y con todos sus cables bien conectados” 😉 ), es probar que se pueda establecer comunicación con éste. Para realizar las pruebas utilizaremos herramientas que ya vienen incorporadas en Windows.

1. Lo primero es lo Primero: Ping

Abrimos una ventana de Símbolo de Sistema (o D.O.S., o consola, o línea de comando, o shell) y escribimos:

ping <IP_Destino> -N 10

El comando ping, realiza una solicitud de echo ICMP (echo-Request) al servidor que queremos verificar. Por defecto se realizan 4  solicitudes, pero yo prefiero usando el parámetro -N <número>, darle un múltiplo de 10. Esto tiene 2 razones bastante simples: 

  • Si hay problemas de intermitencia en el enlace (me ha pasado con enlaces de microondas), sólo 4 ping no siempre detectan esta situación.
  • Si se realiza una cantidad múltiplo de 10 es inmediato el cálculo del porcentaje de pérdida de paquetes 😉

image

El ejemplo anterior corresponde a un cliente que perdía la conexión con el servidor de Escritorio Remoto dónde estaba el ERP de la empresa. Este era un enlace de microondas que tenía “mal apuntada” la antena y gracias a éste (y otros muchos reportes, con más paquetes) pudimos identificar el problema.

Otra información importante que se puede sacar desde este ping es que tan rápida o lenta está la red, viendo el tiempo de recorrido redondo (roundtrip). Claramente no hay un tiempo óptimo, pues depende de las características de la red, la congestión y el ancho de banda. Aún así este valor no debiese superar los 20 ms (en el ejemplo: un mínimo de 80 y un máximo de 841 no fueron buenos números).

Finalmente se puede determinar qué tan “lejos” está el emisor del receptor del mensaje, comparando los valores del TTL.

IMPORTANTE: En el ejemplo anterior se hace ping desde el equipo cliente en la ubicación a un servidor web de una muy conocida y prestigiosa Universidad 😉 . Por qué?, porque yo sé que ese servidor “SI responde PING”. Es posible que el “destino” del Ping no esté configurado para responder Ping, o que haya un firewall bloqueando las peticiones de echo, por lo que si como respuesta a un ping “no hay respuesta” esto no necesariamente indica problemas en la red o en el servidor.

2. NSLookup

En el ejemplo anterior en realidad hicimos una pequeña trampa: asumimos que el servidor DNS estaba funcionando 😉

El servidor DNS es el encargado de hacer la traducción <nombres> = <dirección IP>. En este caso: www.uc.cl = 146.155.99.60, pues en realidad, la petición de eco se hace a la IP de destino, no al <nombre>.

La herramienta más básica para revisar que el servidor DNS al cual estamos consultando esté respondiendo es nslookup, que en su forma más simple puede invocarse de la siguiente forma:

nslookup <IP_Destino>

Una posible respuesta a esta solicitud es la del siguiente ejemplo:

image 

Las primeras líneas identifican al servidor que me está respondiendo la consulta: 192.168.8.1 y el puerto 53 (estándar para DNS)

La tercera línea indica que el servidor no es “dueño” ni “parte” de la zona DNS, por lo que su respuesta no es “de primera mano”, sino que responde “lo que sabe”.

Finalmente las últimas líneas identifican el nombre con su dirección IP. Una respuesta distinta a ésta implicaría problemas con el servidor DNS o con su capacidad para resolver (por sí mismo o preguntando a otros servidores) las consultas que se le realizan. En este caso (y como regla general), es mejor ejecutar los comandos con la dirección IP en vez del nombre.

3. Tracert

OK. Ya sabemos si tenemos, o no, pérdida de paquetes, y sabemos encontrar la dirección IP de nuestro destino. Otra herramienta muy útil en la resolución de problemas es Tracert (traceroute en sistemas basados en Unix), pues nos permite saber por dónde (por cuáles routers) pasan los paquetes mientras viajan entre el origen y el destino.

tracert <IP_Destino>

Una ejecución se muestra en el siguiente ejemplo:

image 

La Primera columna indica el número de salto. Las siguientes 3 muestran el tiempo de respuesta del router frente a los paquetes enviados, si el resultado es un (*) simplemente indica que no se obtuvo respuesta. La cuarta columna muestra el router: nombre, si es capaz de resolverlo, o su dirección IP.

La primera línea (primer salto), si tiene el número 0, es el equipo local, si tiene el número 1 es el Default Gateway o puerta de enlace del equipo desde el cual se está ejecutando el Tracert. La última línea debiese ser el Servidor o Equipo de destino. (no siempre es alcanzable).

Una variante súper interesante de Tracert es VisualRoute, que muestra visualmente en un mapa del mundo la ubicación (aproximada, por cierto) de los routers por dónde pasa un paquete en su recorrido por la súper carretera de la información. (Se requiere JAVA)

3. PathPing

Una de mis favoritas, pues combina en una sólo herramienta las 3 anteriores :D.

pathping <IP_Destino>

El funcionamiento de pathping es más o menos el siguiente:

  • Primero resuelve el nombre del destino a su dirección IP. (Nslookup)
  • Luego obtiene el camino por dónde viajan los paquetes (Tracert)
  • Finalmente, realiza una prueba de conectividad enviando una ráfaga de solicitudes de eco ICMP, es decir, hace ping muchas veces a cada router en el camino recién obtenido.
  • Y lo mejor, despliega estadísticas sobre pérdidas de paquetes al final de la ejecución 🙂

En nuestro ejemplo del enlace vía microondas:

image 
image 

Notas:

  • BORRADA corresponde a IP’s públicas reales, borradas para proteger la identidad de los implicados 😉
  • Los saltos (routers) 7 y 8, destacados en otro color, presentaban pérdidas de paquetes.
  • Pathping tarda un rato, alrededor de 5 minutos, en terminar de ejecutarse, debido a la cantidad de paquetes (100) que envía a cada salto, pero vale la pena esperar.

4. Notas Finales

Muchas de estas herramientas (si no todas) poseen una versión en entorno gráfico, tal vez más amigables y tal vez hasta gratis. De todas formas creo importante saber que existen y vienen junto al sistema operativo, pues a veces es a lo único a lo cual podemos echar mano.

Tip: para quienes den exámenes de certificación sobre networking, el uso de estas herramientas son preguntas seguras 😉

Otra consideración importante es que en este artículo revisamos las herramientas con sus opciones más elementales (o las que eran mis favoritas), pero todas éstas poseen muchas otras funcionalidades que son interesantes y útiles. Sólo basta con escribir el nombre de la herramienta seguido de un “/?” para descubrirlas 😉

Espero que esto les haya resultado de utilidad y que NO tengan que usarlo para resolver problemas en sus redes 😉

Gonzalo

2 comentarios en “Troubleshooting de Redes Básico”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *