Introducción a la Resolución de Problemas de conectividad

Dado que los pasos para que dos equipos puedan comunicarse involucra tanto la resolución del nombre del equipo destino, como la conectividad a nivel IP, es necesario conocer previamente tanto los métodos de resolución de nombres, como el orden en que se utilizan. En caso de dudas se aconseja leer la nota Resolución de Nombres publicada en este mismo sitio y del mismo autor.

Introducción

Previo a que dos equipos puedan conectarse se producen varios pasos intermedios. Tomemos por ejemplo que desde el Servidor-A, se ejecuta \\Servidor-B o que se ejecute PING servidor-b.dominio.sufijo para usar ambos tipos de nombre, tanto el nombre NetBIOS como el FQDN o nombre DNS.

Los pasos son:

Resolución del nombre de destino
Resolución de la Dirección MAC (MAC Address) del salto de destino, que puede ser el propio destino, o el Router que se encargará de hacer el transporte a otra subred
Establecimiento de una Sesión TCP, en caso que sea necesario
Establecimiento de la Sesión NetBIOS de ser necesario
Negociación del Dialecto SMB (Server Message Block) en redes Microsoft
Proceso de autenticación del usuario
Conexión

En el ejemplo de PING, no son necesarios los pasos 3 a 6, ya que este comando utiliza protocolo ICMP y no establece sesión, ni autenticación.

Para esta nota, nos centraremos en los pasos 1 y 2, esto es, la resolución de nombres y la conectividad a nivel IP

Paso 1 – Resolución de Nombre

Esta primera etapa se realiza de acuerdo al tipo de nombre utilizado (NetBIOS o FQDN) y de acuerdo a los parámetros configurados en el equipo (Dirección de servidores WINS y/o DNS, utilización de LMHOSTS, HOSTS, etc.

Si tiene dudas, por favor consulte la nota Resolución de Nombres

Al finalizar este paso, si la resolución de nombres es correcta, el equipo que inica la conexión dispone de la dirección IP del equipo destino.

Paso 2 – Resolución de la dirección MAC

Durante esta etapa, IP debe determinar si la Dirección IP de destino es Local, está en la misma subred; o si por el contrario es una dirección Remota, está en otra subred.

Si el destino es Local, entonces el Protocolo ARP, verá si tiene la información requerida en memoria, y de no ser así envía un Broadcast de ARP solicitando la Dirección MAC de la máquina destino, individualizándola por la correspondiente Dirección IP

Si la dirección de destino es remota, IP consultará la Tabla de Rutas en el propio equipo para determinar por cuál Router debe enviar el pedido, y si no existe una ruta más específica usará el que tenga configurado como Puerta de Enlace.

Luego se repite el procedimiento anterior, pero esta vez buscando la Dirección MAC correspondiente a la Dirección IP del Router.

En ambos casos, la información es enviada a quien corresponda, ya sea la máquina destino, o el Router; quien se hará cargo de hacer llegar la información a destino.

IMPORTANTE: se debe notar que para obtener una respuesta positiva, no sólo se debe enviar la información, sino además el equipo destino debe poder responder al pedido, por lo que éste debe saber como dirigir la respuesta al iniciador

Resumiendo en un gráfico:

Acotando el Problema

A fin de acotar el problema, lo dividiremos en partes. Primero debemos verificar que esté correcta la configuración desde el punto de vista IP.

Si lo anterior está correcto, entonces el problema está en la resolución de nombres, el cual dividiremos de acuerdo a que se trate de problemas de resolución de nombres NetBIOS o FQDNs

1 – Conectividad IP

Como primer paso debemos verificar que no tengamos localmente problemas con TCP/IP. Para esto se puede utilizar varios comandos.

Primero ejecutar un comando IPCONFIG /ALL, y obtendremos una salida similar a la que sigue:

Windows IP Configuration

Host Name . . . . . . . . . . . . : P5

Primary Dns Suffix . . . . . . . :

Node Type . . . . . . . . . . . . : Broadcast

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connection

Physical Address. . . . . . . . . : 00-20-ED-83-96-F7

Dhcp Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 192.168.200.200

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 192.168.200.1

DNS Servers . . . . . . . . . . . : 192.168.200.1

En la misma podremos verificar si la Dirección IP es la correcta, como así también la Máscara de Subred y los demás parámetros.

El paso siguiente es verificar la conectividad a través del comando PING usando Dirección IP.

Es importante comenzar con PING Dir_IP pues de esta forma se puede comenzar a acotar el problema. Si usando la Dirección IP no obtenemos respuesta positiva, sabemos que el problema no está relacionado con la resolución de nombres.

También es importante interpretar la respuesta en caso de ser negativa. Las dos más comunes son: Tiempo de Espera Agotado, o que el destino es inalcanzable.

Si el error es que el destino es inalcanzable, entonces el problema seguramente está en nuestra máquina: no sabe cómo llegar al destino

Si el error es Tiempo de Espera Agotado, nuestro equipo cree saber cómo llegar al destino, y envía el requerimiento. En este caso hay dos posibilidades: lo enviamos por el camino incorrecto, o el destino no sabe o puede respondernos

Normalmente se hace un PING a la dirección 127.0.0.1 (Loopback) esto nos asegura que el protocolo TCP/IP está funcionando. Y si lo anterior responde, entonces probar un PING a la propia dirección IP, con lo cual nos aseguraremos que además responde.

Si en los dos casos responde, se puede probar con PING a una dirección local, que bien puede ser otra máquina en la misma red, o lo que tengamos configurado como Puerta de Enlace. Si esto es satisfactorio se puede probar hacer el PING a un equipo externo, del cual sabemos positivamente que está online, correctamente configurado, y que no hay filtrado de protocolo ICMP.

Si las respuestas positivas fueran sólo las locales, es para pensar que el problema puede estar en el Router, debemos verificar su funcionamiento correcto.

Si aún en los PINGs a máquinas locales no hay respuesta positiva, debemos verificar estar usando la Dirección IP y Máscara de Subred adecuadas para la red en la que estamos conectados.

En prácticamente la mayoría de los casos, una respuesta positiva a un PING a una dirección remota, nos asegura que podemos llegar a todas las direcciones locales, como así también al Router

Se deben tener en cuenta otros factores también, como puede ser el hardware involucrado, que incluye, placas de red, cables, hub/switches, etc.

También debemos asegurarnos que el equipo contra el que estamos probando esté correctamente configurado y que no esté protegido por un Cortafuegos que filtre ICMP.

Las Tablas de Rutas las podemos verificar con el comando ROUTE PRINT. Una respuesta podría ser:

=======================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x2 ...00 20 ed 83 96 f7 ...... Intel(R) PRO/100 VE Network Connection - Packet Scheduler Miniport

=======================================================================

Active Routes:

Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 192.168.200.1 192.168.200.200 1

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

131.107.2.0 255.255.255.0 192.168.200.2 192.168.200.200 1

192.168.200.0 255.255.255.0 192.168.200.200 192.168.200.200 20

192.168.200.200 255.255.255.255 127.0.0.1 127.0.0.1 20

192.168.200.255 255.255.255.255 192.168.200.200 192.168.200.200 20

224.0.0.0 240.0.0.0 192.168.200.1 192.168.200.1 20

255.255.255.255 255.255.255.255 192.168.200.200 192.168.200.200 1

Default Gateway: 192.168.200.1

===========================================================================

Persistent Routes:

Network Address Netmask Gateway Address Metric

131.107.2.0 255.255.255.0 192.168.200.2 1

Un comando casi desconocido, y con muchísimas opciones sobre todo para los que usen Windows XP – SP2 es el comando NETSH. Un buen consejo es que cuando disponga de un tiempo, comience por NETSH /? y va a ver cúantas cosas se pueden hacer con este comando.

Otro comando que puede ayudar mucho cuando el problema es de conectividad con una máquina remota, es TRACERT. Se utiliza en forma similar a PING, pero TRACERT además de informar si hay respuesta o no, mostrará el camino recorrido, por cuáles Routers pasa, o sea hasta dónde llega el pedido. Debemos tener en cuenta cuando el destino es remoto que puede ser que ni nuestra máquina, ni el destino tengan probles, sino que éstos se producen en los dispositvos intermedios.

Otro comando que también puede ser útil es PATHPING. Éste es similar a TRACERT, pero además nos brindará estadísticas de los diferentes tramos del camino. Podremos averiguar, por ejemplo, cuál es el Router que hace que nuestra conexión sea lenta.

Una posibilidad de falla, aunque no muy común, es que el Cache ARP tuviera entradas incorrectas. Con ARP –a podemos visualizar el mismo, y con ARP –d podemos eliminar entradas incorrectas, si existieran.

Resumiendo, si tenemos conectividad a nivel IP, ya es un paso positivo, sabemos que en cuanto a configuración IP está todo correcto. Luego, si no podemos conectarnos el problema tiene que estar en la resolución de nombres

2A – Resolución de Nombres NetBIOS

La correcta resolución de un nombre NetBIOS a su correspondiente dirección IP la podemos verificar a través de varios comandos. Puede ser por ejemplo a través de Inicio \ Ejecutar: \\nombreNB-servidor o desde línea de comando con, por ejemplo, NET VIEW \\nombreNB-servidor En cualquiera de los casos deberá mostrar la lista de recursos compartidos

Si los comandos anteriores no fueran exitosos, o si demorara demasiado tiempo en mostrar los recursos compartidos, es para pensar que tenemos problemas en la resolución de nombres NetBIOS

Si no puede resolver el sistema informará con un error, y si demora demasiado es para pensar el orden en que se prueban los métodos de resolución de nombres NetBIOS (Ver la nota Resolución de Nombres publicada en este mismo sitio y del mismo autor).

Comandos disponibles para ayudar a solucionar el problema son, por ejemplo:

NBTSTAT –c Para ver el cache de nombres NetBIOS

NBTSTAT –n Para listar los nombres locales

NBTSTAT –R Para purgar el cache de nombres NetBIOS, y recargargar las entradas marcadas con #PRE en el archivo LMHOSTS

NBTSTAT –RR Para des-registrar y registrar nuevamente los nombres NetBIOS

2B – Resolución de Nombres FQDN

La correcta resolución de nombres FQDN (o hostnames o nombres DNS) tiene fundamental importancia en dominios Windows 2000 o posteriores, ya que los clientes encuentran los servicios de red utilizando este tipo de nombre, no nombres NetBIOS. Si existe una mala configuración de este tipo en ambientes de dominio, es común que los clientes demoren en mostrar el cuadro de inicio de sesión varios minutos (a veces hasta 15), que los servidores controladores de dominio demoren hasta una hora en levantar, que servicios no arranquen, no tener conectividad con Internet, etc.

Para verificar la correcta resolución de nombres de este tipo podemos usar fundamentalmente dos comandos: PING y NSLOOKUP.

Ejecutando un PING hostname.dominio.sufijo nos permite ver si la resolución se hace correctamente, siempre que lo ejecutemos contra un equipo que pueda responder al comando

Pero si utilizamos, como en la mayoría de los casos, servidor DNS, es mucho mejor utilizar el comando NSLOOKUP, ya que con éste verificamos la resolución de nombre a dirección IP, o la inversa, sin tener en cuenta si el destino está en condiciones de responder, sólo si la resolución es correcta.

El uso más sencillo es NSLOOKUP hostname.dominio.sufijo si necesitamos opciones más avanzadas, basta teclear NSLOOKUP, y entraremos a la línea de comandos del utilitario. Podremos ver todas las opciones diponibles ingresando HELP.

Existe además un utilitario muy poderoso para detectar problemas de resolución de este tipo de nombres que se puede bajar junto con la correspondiente documentación del sitio de Microsoft: DNSLINT. Recomiendo mucho que lo vean anque no tengan problemas

Y tampoco debemos olvidarnos del conocido comando IPCONFIG ya que tiene varios modificadores apropiado, por ejemplo:

IPCONFIG /ALL Para visualizar completa información

IPCONFIG /DISPLAYDNS Para visualizar el contenido del cache de hosts

IPCONFIG /FLUSHDNS Para purgar el cache de hosts

IPCONFIG /REGISTERDNS Para refrescar las registraciones dinámicas en DNS

Recordemos que para forzar la registración en DNS de los servicios debemos reinicializar los mismos. Por ejemplo para forzar la registración de los servicios que anota un controlador de dominio, se debe reiniciar el servicio NETLOGON

Resumiendo

Cuando no podemos hacer una conexión, debemos acotar el problema para facilitar la resolución. Como primera medida es conveniente revisar si hay conexión a nivel IP. Pues si esta no fuera correcta, nada se puede hacer con resolución de nombres. Estamos en la parte inferior del gráfico.

Si tenemos conectividad por IP, pero no hay conectividad usando nombres, o el tiempo de acceso es excesivo, entonces debemos investigar por los métodos de resolución de los mismos. Es muy importante conocer cuáles son los métodos usados para resolver cada tipo de nombre y en que orden se utilizan.

Desde ya que hay métodos más avanzados para resolver problemas de conectividad, y otros caminos, pero en mi experiencia es común que alguno de los métodos expuestos no ayude o resuelva el problema. También es de hacer notar que con toda la intención he dejado algunos comandos con poca explicación para que el lector investigue por su cuenta. Recomiendo especialmente NETSH para los que tengan Windows XP, y que vean DNSLINT.