Mes: octubre 2008

Nombre NetBIOS o de Host inalcanzable

Ya dijimos que W2k3 permite la comunicación en red entre equipos usando tres tipos de destinos:

• Dirección IP
• Nombre de equipo (Host Name)
• Nombre NetBIOS (NetBIOS Name)

Veamos como podemos intentar dar soluciones a problemas en las dos últimas.

El primer paso es ver que aplicaciones están produciendo errores. Normalmente, en estas aplicaciones se incluyen IExplorer, NET USE, TELNET y FTP. Una vez sabemos cuales fallan, el siguiente paso es determinar si el error se debe a un problema de resolución de nombre de equipo o nombre NetBIOS.

La forma más fácil de distinguir los problemas entre ambas resoluciones es comprobar si la aplicación usa NetBIOS o Sockets. Si usa sockets el problema está relacionado con resolución de nombre de equipo. Las aplicaciones NetBIOS son de largo, las más comunes, incluyendo diversos comandos NET, Windows Explorer, y la superconocida Mis Sitios de Red. Las aplicaciones sockets incluyen IExplorer, otros navegadores, TELNET y FTP.

Error 53

El síntoma más común de un problema de NetBIOS es cuando el comando ping devuelve un mensaje de error 53. Este error generalmente es devuelto cuando falla la resolución a un nombre de equipo particular. También puede ocurrir cuando hay un problema estableciendo una sesión NetBIOS. Para distinguir entre estos dos casos:

• Desde la línea de comandos, escribimos

net view \nombre_equipo

*nombre_equipo es un recurso de red que sabemos que está activo.

Si esto funciona, la resolución de nombres no es probablemente el origen del problema. Con un ping al nombre de equipo podemos confirmarlo, ya que algunas veces la resolución de nombres puede funcionar correctamente cuando net use devuelve un error 53 (como cuando un DNS o WINS tiene una entrada errónea). Si el ping muestra que la resolución falla (con un error de host desconocido), comprobaremos el estado de la sesión NetBIOS.

Para comprobarla:

• Desde la línea de comandos, escribimos

net view \dirección_IP

*La dirección IP del mismo recurso que usamos para identificar la causa del error 53.

Si esto también falla, el problema se encuentra en el establecimiento de una sesión.

Si el equipo está en una subred local, confirmad que el nombre se ha escrito correctamente y que el equipo está ejecutando TCP/IP. Si el equipo no está en una subred local, asegúrenomos de que su nombre y su IP están debidamente relacionados en un DNS, o en los archivos HOSTS o LmHOSTS, o en WINS.

Si todos los elementos TCP/IP parecen bien instalados, con ping comprobaremos que en el equipo remoto TCP/IP funciona.

No podemos conectar con sistemas remotos mediante nombre de equipo

Si el problema no es de NetBIOS, es de sockets, el problema está relacionado con alguna entrada del archivo Hosts o un error en DNS. Para comprobar que sólo funciona correctamente con IPs y no con nombres de equipo, remotamente, comprobaremos ambos: Hosts y DNS en cuanto al equipo que nos da problemas.

Comprobar archivos Hosts

Las entradas del archivo Hosts se usan para crear entradas en la caché de resolución de cliente de DNS, que podemos ver con el comando ipconfig /displaydns. Comprobad los contenidos de la caché de resolución de cliente DNS y las entradas del archivo Hosts.

Comprobar configuración DNS

Si usamos DNS, comprobaremos que las direcciones IP de los mismos están perfectamente configuradas en las propiedades de TCP/IP y en el orden correcto.

Panel de control -> doble-clic en Conexiones de red -> Clic derecho en la conexión, clic en propiedades -> Clic en Protocolo TCP/IP y clic en propiedades -> En las propiedades clic en Avanzadas -> Pestaña DNS -> Comprobamos los DNS.

                                                  

Este procedimiento nos servirá en los equipos que están configurados estáticamente, ya que si son clientes DHCP no tendrán DNS en la lista.

Ping al equipo remoto mediante nombre de equipo y con su dirección IP para ver si la resolución es correcta. Si al nombre falla pero no a la IP, el problema es la resolución. Comprobad los DNS, un ping a sus IP para ver si están en marcha, o abrid una sesión Telnet al puerto 53: si la conexión se establece con éxito el DNS está funcionando. Después de ver que funciona el DNS, con NSlookup podemos enviar solicitudes al DNS y verificar el estado de los registros que estamos comprobando.

Si fallan ambos, el problema debe ser la conectividad de red, sea la conectividad básica o el enrutamiento.

Resolución de nombres mediante servidor DNS

DNS es una base de datos distribuida que relaciona nombres de dominio a datos. Un usuario puede consultar DNS usando nombres conocidos y jerárquicamente, para localizar equipos y otros recursos en una red IP. Esto ha supuesto el reemplazo de lo que una vez realizaba el archivo Hosts. DNS resuelve nombres conocidos a direcciones IP, de una forma transparente y como podemos observar, como ejemplo:

• Un cliente contacta con el servidor DNS con una solicitud recursiva para www.juansa.net. El servidor debe devolver una respuesta o un mensaje de error.
• El DNS comprueba sus archivos de zona y caché para la respuesta, pero no la encuentra. Entonces contacta con un servidor raíz para realizar una consulta iterativa respecto a la solicitud recibida.
• El servidor raíz no conoce la respuesta, y responde con una referencia a un servidor autoritativo del dominio .net.
• El servidor DNS contacta con un servidor en el dominio .net con una consulta iterativa respecto a la solicitud original.
• El servidor DNS en el dominio .net no conoce la respuesta exacta, así que responde con una referencia a un servidor autoritativo en el dominio juansa.net.
• El servidor DNS contacta con el servidor en juansa.net con una consulta iterativa de la solicitud original.
• El servidor en juansa.net conoce la respuesta y responde con la IP correspondiente al nombre solicitado.
• El servidor DNS responde a la solicitud del cliente con la dirección IP para www.juansa.net.

(Esto no es más que un ejemplo que podría darse en internet, hay más info sobre consultas recursivas e iterativas, podemos encontrarla por ejemplo en nuestro propio w2k3, ejecutando hh DNSconcepts.chm desde ejecutar)

Mensajes de error DNS

Los errores en la resolución de nombres pueden ocurrir si las entradas en un servidor o cliente DNS no están correctamente configuradas, sí el servidor no está activo, o si hay un problema con la conectividad de red. Para determinar la causa de cualquier problema de resolución podemos usar la herramienta Nslookup.

Las solicitudes falladas devolverán una variedad de mensajes, dependiendo de la naturaleza del fallo. Por ejemplo, si usamos el siguiente comando:

nslookup equipo_destino

y el servidor no puede resolver el nombre, se mostrará lo siguiente:

Server: Nombre cualificado completo de dominio
Address: Dirección IP del servidor
*** Nombre completo de dominio cualificado no puede encontrar equipo_destino: dominio no existe

En otros casos, las solicitudes sin respuesta:

nslookup equipo_válido
Servidor: IP Address: w.x.y.z
DNS request timed out.
timeout was 2 seconds.

Si el servidor falla en responder a la solicitud, Nslookup devuelve:

*** Can’t find server name for address dirección_ip: No response from server
*** Default servers are not available.

Este mensaje indica que el servidor DNS es inalcanzable, aunque no indica el porqué. El servidor puede estar apagado, el equipo no tener el servicio DNS activo o existir un problema de hardware o enrutamiento.

Resolución de nombre de equipo mediante archivo Hosts

Un equipo que usa el archivo Hosts para llevar a cabo la resolución de nombres sigue unos pasos:

• Equipo A introduce un comando usando el nombre de equipo de Equipo B.
• Equipo A comprueba el contenido de la caché de resolución DNS, que contiene las entradas del archivo Hosts. Cuando el nombre de equipo de Equipo B se encuentra, se resuelve a una dirección IP. Entonces el paquete es envíado usando los procesos de resolución de dirección y determinación de ruta normales.

Los errores del archivo Hosts pueden causar errores de red, como:

• No contenga un nombre de equipo concreto.
• El nombre de equipo en el archivo o en el comando está mal escrito.
• La dirección IP para el nombre de equipo es inválida o incorrecta.
• Hay múltiples entradas para el mismo equipo en distintas líneas. El archivo se usa desde el inicio, así que la primera entrada es la que se propagará a la caché de resolución de cliente DNS.

El archivo Hosts no se actualiza dinámicamente; todas sus entradas son agregadas manualmente, y la IP y el nombre de equipo son siempre separados por uno o más espacios o tabulación. Un ejemplo:

Si estamos teniendo problemas conectando a un equipo remoto mediante su nombre de equipo y usamos el archivo Hosts para la resolución, el problema podría estar en el contenido del archivo. Busquemos el nombre del equipo remoto correctamente escrito en el archivo y por la aplicación que lo usa.

Comprobar el archivo LmHosts

El problema en la  resolución de nombres podría estar en nuestro archivo LmHosts, que se comprueba para direcciones para nombres NetBIOS de forma secuencial de arriba a abajo. Si hay más de una dirección listada para el mismo nombre, se devuelve el primer valor encontrado, tanto si es bueno como si no.

El archivo podemos buscarlo en ruta_del_sistemaSystem32DriversEtc. No existe de forma predeterminada; un ejemplo existe como LmHosts.SAM. Este archivo debe ser renombrado o copiado como LmHosts antes de usarlo.

Aunque el directorio mencionado es el predeterminado, su consulta dependerá del valor en la entrada DataBasePath de la sub-clave del registro HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters.

Esta entrada le dice al equipo local donde debe mirar para el archivo LmHosts.

Tiempo excesivo para conectar usando Lmhosts

Para comprobar la causa de un tiempo excesivo en conectar al añadir una entrada en el archivo, hay que ver el orden de las entradas.

Este problema puede ocurrir cuando un archivo grande tiene la entrada especificada al final del mismo. Para mejorar la resolución de la entrada, marcarla como una entrada precargada mediante el uso de la etiqueta #PRE. Entonces usaremos el comando nbstat -R para actualizar la caché de nombres NetBIOS local inmediatamente.

Alternativamente, podemos emplazarla más alto en el archivo. El archivo se lee desde arriba para la localización de entradas sin la etiqueta #PRE. Por lo tanto, las entradas que sabemos que son utilizadas más frecuentemente deben ir cerca del inicio del archivo y las que llevan la etiqueta al final del mismo archivo.

Comprobar la configuración WINS

Comprobar que la configuración WINS es correcta y en particular que la dirección del servidor WINS es la adecuada.

El procedimiento es el mismo que más arriba hemos utilizado para comprobar la configuración DNS, sólo que esta vez pulsaremos la pestaña WINS y comprobaremos la configuración:

– Añadir la ip del servidor WINS, si no lo está y existe.

– Verificar que Lmhosts lookup esta habilitado.

– También si NetBIOS sobre TCP/IP se asigna desde DHCP si está habilitado o deshabilitado. Sino, habilitar NetBIOS sobre TCP/IP.

Usemos Tracert y Pathping

Si la tabla de rutas es correcta, el problema puede halarse en algún enrutador o enlace en cualquier punto a lo largo de la ruta. Podemos rastrear la ruta hacia el destino con Tracert y Pathping para señalar el problema.

A menos que haya una sola ruta hacia el equipo destino, asegurarse de usar estas herramientas para trazar la ruta más de una vez, especialmente si notamos pérdidas intermitentes de paquetes. El datagrama puede enviarse por distintos caminos, y un enrutador defectuoso puede ser el problema.

Cuando no tenemos conectividad con un lugar concreto usaremos Tracert, ya que nos dice en qué lugar se detiene la comunicación. Pathping es más útil cuando sí hay conectividad a un lugar, pero se pierden paquetes o la espera es alta. En estos casos, pathping nos dice exactamente donde se están perdiendo los paquetes.

Comprobar los servicios de servidor en el equipo remoto

Algunas veces un sistema configurado como puerta de enlace remota o enrutador no está funcionando como debería. Para poder confirmar que el equipo remoto está reenviando los paquetes debemos usar alguna herramienta de administración remota (siempre que seamos administradores de dicha máquina) o contactar con el responsable y que lo compruebe.

Hay una serie de bases de datos en InterNIC que nos servirán en algunos casos para saber quien es el responsable. También nos puede servir la herramienta Whois desde : ARIN, AFRINIC, APNIC, LACNIC, RIPE, INTERNIC u otros.

Comprobar IPSec

IPSec puede incrementar la seguridad de una red, pero también cambia la configuración y hace más difícil resolver un problema. En algunos casos, IPSec se ejecuta donde tenemos al equipo problemático y ello puede crearle dificultades para conectar con otro equipo. Para ver si este es el origen del problema, temporalmente deshabilitaremos IPSec con el comando net stop policyagent, comprobando si el servicio o funcionalidad de red se ejecutan con normalidad.

Si el problema desaparece con IPSec detenido, puede que sea por su filtrado de paquetes, entonces es el responsable del problema. Volveremos a iniciar el servicio con net start policyagent y seguiremos el siguiente procedimiento:

netdiag /test:ipsec /debug > archivo.txt

Con lo que veremos los filtros activos.

Para asignar o desasignar una directiva IPSec para directivas Active Directory

1. Abrimos el complemento de Usuarios y equipos de AD: Inicio, herramientas administrativas, doble clic en el complemento.
2. En el árbol de la consola, expandimos el controlador de dominio, el dominio, y la OU u OU hija al que queremos aplicar la directiva.
3. Clic en propiedades y luego en la pestaña directiva de grupo.
4. Clic en Editar para abrir la directiva, o Nueva para crear una nueva y luego editarla.
5. En el árbol de la consola de directiva, expandimos la directiva para el equipo, Configuración de equipo, Configuración de Windows, Configuración de seguridad y clic en Directivas de seguridad IP en Active Directory (dominio)
6. En el panel detalles, clic en la directiva IPSec que queremos asignar o negar, y hacemos una de dos:

• Para asignarla, en el menú Acción, clic en asignar.
• Para desasignarla, en el menú Acción, clic en desasignar

 

Para asignar o desasignar una directiva IPSec para directivas de equipo local

1. Inicio, Ejecutar, escribimos MMC y pulsamos ENTER.
2. Clic en File, Add/Remove Snap-in, OK.
3. Clic en Editor de objetos de directivas de grupo, Add.
4. Finalizar, Cerrar, Aceptar.
5. En el árbol de la consola de directiva, expandimos la directiva para el equipo, Configuración de equipo, Configuración de Windows, Configuración de seguridad y clic en Directivas de seguridad IP en Equipo Local
6. En el panel detalles, clic en la directiva IPSec que queremos asignar o negar, y hacemos una de dos:

• Para asignarla, en el menú Acción, clic en asignar.
• Para desasignarla, en el menú Acción, clic en desasignar

 

 

IMPORTANTE: Una directiva IPSec puede permanecer activa incluso después de que la directiva IPSec o el objeto de Directiva de Grupo a la que se asignó ha sido borrada. Por lo tanto, debemos desasignar la directiva IPSec antes de eliminar la directiva o el objeto de directiva de grupo. En evitación de problemas, deasignamos la directiva IPSec en el objeto de Directiva de Grupo. Esperamos 24 horas para asegurarnos que el cambio se ha propagado, y entonces podemos eliminar la directiva o el objeto de directiva de grupo.

Comprobar el filtrado de paquetes

Cualquier error en el filtrado de paquetes en TCP/IP, enrutador, servidor proxy, Enrutamiento y acceso remoto, o a nivel de IPSec pueden provocar errores de resolución o de conectividad. Para averiguar si el origen del problema de red es el filtrado de paquetes, podemos deshabilitarlo.

1. Panel de control, conexiones de red.
2. Clic derecho en la conexión, seleccionamos propiedades.
3. Seleccionamos Protocolo Internet (TCP/IP) y pulsamos en la pestaña propiedades.
4. Clic en Avanzadas, y clic en la pestaña Opciones.
5. Bajo Configuración opcional, clic en Filtrado TCP/IP y luego en el botón propiedades.
6. Desmarcar la casilla de verificación Habilitar filtrado TCP/IP (en todos los adaptadores) y pulsar en Aceptar.

Intentar pings a una dirección mediante su nombre DNS, su nombre NetBIOS o su IP. Si el intento tiene éxito, las opciones del filtrado de paquetes puede estar configurada incorrectamente o ser demasiado restrictivas. Puede que esté permitiendo al equipo actuar como web server pero, en el proceso, estar deshabilitadas herramientas como el ping o administración remota. Restaurar el rango de filtrado permisivo, cambiando los puertos permitidos TCP, UDP e IP.

Si el intento falla, otra tipo de filtrado puede estar interfiriendo en la red.

Comprobando la resolución de IP a MAC con ARP

TCP/IP en Windows Server 2003 permite a las aplicaciones comunicarse en red con otros equipos mediante la IP, nombre de host o nombre NetBIOS. Sin embargo, a pesar de utilizarse una convención de nombres, la dirección de próximo salto para el destino debe al final resolverse a una dirección hardware -conocida como media access control, o sea la MAC address- para el acceso compartido a los medios como ethernet o token ring.

ARP permite a un equipo encontrar la dirección MAC del próximo salto de IP en la misma red física. Para un ARP eficiente, cada equipo guarda en su caché la dirección IP-a-MAC para eliminar solicitudes broadcast de ARP repetitivas.

La utilidad ARP permite al usuario ver y modificar las entradas de la tabla ARP en el equipo local. El comando arp es útil para ver la caché ARP y resolver problemas de resolución de direcciones.

Una entrada estática puede añadirse a un archivo ARP con arp -s dirección_IP dirección_MAC. Sin embargo, hay que tener cuidado cuando añadimos entradas estáticas ya que es fácil de equivocarse. (Que se lo digan al envenenamiento de ARP, :-))). Cuando se reinicia un equipo, todas las entradas estáticas son eliminadas.

Detección de direcciones IP duplicadas con ARP

Cuando iniciamos, Windows realiza un ARP de regalo para detectar cualquier duplicación de su propia IP. Consiste en una solicitud ARP para la IP propia del nodo, o sea para sí mismo. Si un equipo envía una solicitud ARP para sí mismo y no hay respuesta, el equipo determina que nadie está usando dicha IP. Aunque esto detecta en la mayoría de casos IPs duplicadas, en muy pocas situaciones dos equipos (sean MS o no MS) pueden estar configurados con la misma IP en la misma red.

La relación entre las direcciones MAC e IP se realiza por el módulo ARP, que utiliza la primera respuesta ARP que recibe. Por lo tanto, la respuesta desde un equipo impostor puede algunas veces enmascarar la respuesta del equipo previsto.

Usaremos arp -a para mostrar por la pantalla la relaciones MAC-IP de la caché de ARP. Si sabemos la MAC de un equipo remoto que deseamos usar, podemos determinar fácilmente si ambas coinciden. Si no lo hacen, usaremos arp -d para eliminar la entrada, realizaremos un ping a la dirección (forzar un ARP), y entonces comprobamos la MAC en la caché de nuevo con arp -a.

Sí ambos equipos están en la misma red, recibiremos eventualmente una respuesta desde el equipo impostor. Si no, podemos tener que capturar el tráfico desde el equipo impostor con Network monitor (descarga) para determinar el propietario o ubicación del sistema.

Detección entradas inválidas en la caché de ARP

La resolución de problemas de la caché de ARP puede ser una de las tareas de mayor dificultad en la administración de redes ya que los problemas asociados con ello son frecuentemente intermitentes. La excepción a esta regla es cuando nos encontramos que el equipo con problemas responde a una solicitud ARP, creando una entrada inválida en la caché de ARP. Los síntomas de las entradas inválidas en la caché de ARP son difíciles de reproducir y se componen de problemas intermitentes que afectan solamente a un grupo pequeño de equipos. El problema subyacente es que dos equipos están usando la misma IP en la red. Vemos los problemas de forma intermitente ya que la mayoría de entradas de la tabla ARP recientes son siempre del primero de los equipos que responda más rápidamente a una solicitud ARP particular.

Ejemplo de salida del comando arp -a:

Ya que las IP asignadas por DHCP no causan los conflictos definidos aquí(Aconsejo DHCP en cuanto el número de equipos sea grande), el principal origen de los mismos suelen ser las direcciones IP estáticas. El mantener una lista de las direcciones IP estáticas (y sus correspondientes MAC) y como se han asignado nos servirán de ayuda para cualquier seguimiento de conflicto y su comparación con los pares de la tabla de ARP.

Si no tenemos un registro de todos los pares IP y MAC de nuestra red, podemos examinar los bytes del vendedor de la MAC en busca de inconsistencias. Los primeros tres bytes de cada MAC identifican al vendedor/fabricante de la tarjeta. Estos tres bytes se llaman OUI y están asignados por la IEEE. Conociendo el equipamiento instalado y comparando lo con los valores devueltos por un arp -a puede permitirnos determinar cuales direcciones estáticas se han introducido erronéamente.

Comprobar las rutas persistentes de la tabla de rutas

Lo siguiente a examinar son las entradas persistentes en las tablas de rutas. Podemos verlas mediante el comando route. Las entradas persistentes se agregan mediante el comando y parámetros route add -p o desde el servicio de enrutamiento y acceso remoto. Las entradas incorrectas pueden cambiarse mediante route change. Con enrutamiento y acceso remoto agregamos una ruta estática:

1. Abrimos Enrutamiento y acceso remoto
2. En el árbol de la consola, extendemos enrutamiento IP y clic derecho en rutas estáticas.
3. Clic Nueva ruta estática.
4. En el cuadro de diálogo de Ruta estática, introducimos el interfaz, destino, máscara de red. puerta de enlace y métrica. Si fuera una interfaz de llamada por demanda, el campo de puerta de enlace no está disponible.

Vaciar la caché ARP

Entradas incorrectas en la caché de ARP pueden impedir la conectividad a equipos locales y remotos (si la entrada correspondiente a la puerta de enlace es incorrecta). Para ver el contenido de la caché podemos usar los comandos:

arp -a o arp -g

Los resultados que se obtienen con estos parámetros del comando pueden enviarse hacia un archivo de texto o doc si tenemos word instalado, con la sintaxis de redirección.

arp -a > ruta_del archivo (la extensión debe ser txt o doc)

Antes de cualquier cambio en la caché es conveniente volcar su contenido a un archivos y mantenerlo para su revisión si fuese necesario.

El vaciado de la caché la realizamos con:

arp -d *

Comprobar la puerta de enlace predeterminada

Hay que comprobar la puerta de enlace predeterminada. La dirección IP de la puerta de enlace debe estar en la misma sub-red de la dirección del equipo local, si no ese el caso, los paquetes no podrán reenviarse a ningún lugar fuera de la sub-red local. Así que comprobemoslo.

Ping a un equipo remoto

Si la puerta de enlace responden correctamente, hagamos un ping a un equipo remoto para asegurarnos de que la comunicación existe y es operativa con normalidad. Si esto falla, con Tracert examinemos la ruta hacia el destino. Para enrutadores IP que sean equipos ejecutando NT, 2000 o Windows Server 2003, podemos ver la tabla de rutas con route print o con enrutamiento y acceso remoto. En caso de otros enrutadores usaremos la herramienta que le corresponda para ver su tabla de enrutamiento.

Un ping nos devuelve cuatro mensajes de error durante la búsqueda del error.

TTL expiración en tránsito El número de saltos requerido para alcanzar el destino excede el TTL establecido por el equipo que envía, para el reenvío de paquetes. El valor predeterminado de TTL en el caso de mensajes Echo de ICMP es 128. Si esto no es suficiente para el número necesario de enlaces hasta el destino, podemos incrementarlo mediante ping -i, hasta un máximo de 255. Si al aumentarlo nos falla para resolver el problema, los paquetes comenzarán a ser reenvíados en un loop de enrutamiento, esto es, una ruta circular entre enrutadores. Usaremos Tracert para localizar el conjunto de enrutadores del loop, que aparece como una serie repetida de direcciones IP iguales en el informe del Tracert. Después, cambiemos de forma correcta las tablas de enrutamiento de los enrutadores del Loop, o avisemos al administrador del enrutador remoto para solucionar el problema.

Equipo destino inalcanzable Esto indica una de dos: O no hay ruta entre el equipo y el destino deseado, o un enrutador remoto informa que no hay ruta al destino. La forma del mensaje puede distinguirlos:

• Si el mensaje es simple «Destination Host Unreachable» (equipo destino inalcanzable), no hay ruta desde el equipo local, y los paquetes a ser envíados nunca se pondrán en la red. Usaremos la herramienta route para comprobar la tabla de enrutamiento local para ver si la ruta al destino es equivocada o inexistente.
• Si el mensaje es en cambio «Reply From IP Address: Destination Host unreachable» (Respuesta desde dirección_IP: equipo destino inalcanzable), el problema de enrutamiento se encuentra en un enrutador remoto, cuya dirección IP es la indicada en IP Address. Comprobaremos la tabla de rutas del enrutador remoto correspondiente o avisaremos para ello.

Si hacemos un ping a una dirección IP, hagámoslo también al nombre de host y asegúremonos que la IP es la correcta.

Tiempo de espera agotado para esta solicitud Este mensaje indica que no se recibe respuesta dentro del tiempo predeterminado de cuatro segundos. Esto puede deberse a distintas causas; la más común es una congestión de la red, un fallo de ARP en la resolución del próximo salto de dirección MAC, filtrado de paquetes, error de enrutamiento o descarte por silencio. Frecuentemente significa que una ruta de retorno al equipo de envío ha fallado. Esto puede ser porque el equipo destino no conoce la ruta de regreso al de envío, uno de los enrutadores intermedios no tiene una ruta de regreso o incluso que la puerta de enlace del equipo destino no conoce la ruta de regreso. Antes de comprobar als tablas de rutas de los enrutadores, comprobar la tabla de rutas del equipo destino para ver si tiene una ruta para llevar al equipo de envío.

Si las tablas de rutas remotas son correctas y contienen rutas válidas de retorno para el equipo de envío, mirar si la caché ARP carece de la dirección procedente con arp -a. Tambié, comprobar la máscara de subred para estar seguro que la dirección remota no se interpreta como local.

Después usamos TRacert para determinar la ruta al destino. Aunque Tracert no grava la ruta que los mensajes de Echo siguen en su retorno, puede mostrar lo que el paquete hace en el destino. Si es este caso, el problema es probablemente un problema de enrutamiento de la ruta de retorno. Si la traza no consigue llegar al destino, puede deberse a que el equipo está detrás de un cortafuegos. Cuando hay un cortafuegos, el filtrado de paquetes ICMP impide a los ping -y cualesquiera otros mensajes ICMP- traspasarlo y por tanto alcanzar su destino.

Para comprobar la congestión de red, solamente necesitamos incrementar la latencia permitida aumentando el tiempo de espera, unos 5 milisegundos, mediante el comando ping -w. Probar el ping al destino otra vez. Si la solicitud excede el tiempo de respuesta, la congestión no es el problema.

Equipo desconocido Este mensaje de error indica que el nombre de equipo solicitado no puede resolverse a una dirección IP; comprobar si el nombre es correcto y si los DNS pueden resolverlo.

Comprobación de la conectividad con Ping y Pathping

Ping nos ayuda a verificar la conectividad a nivel de IP y Pathping detecta paquetes perdidos en intentos de múltiples saltos. El comando ping lanza una serie de mensajes echo de ICMP a un destino: nombre de host o dirección IP. Con ping verificamos que un equipo puede enviar paquetes IP a un destino, así como aislar problemas de hard o configuraciones incorrectas.

Si el comando ipconfig /all nos muestra la dirección IP adecuada no necesitamos hacer un ping a la dirección de loopback (127.0.0.1) o la dirección IP.

Para verificar que una ruta existe entre el equipo y un equipo de la red:

ping dirección_IP

Comprobamos que TCP/IP está instalado y configurado correctamente en el equipo:

ping 127.0.0.1

Comprobamos que el equipo se añadió correctamente a la red (si la tabla de rutas es correcta, esto solamente reenvía el paquete a 127.0.0.1)

ping dirección_IP_equipo_local

Comprobamos que la puerta de enlace predeterminada funciona y podemos comunicarnos con un host dentro de nuestra red:

ping dirección_IP_puerta_de_enlace

Comprobación de la ruta a un host remoto pasando por un enrutador:

ping dirección_IP_host_remoto

Comprobamos la resolución de nombre del host remoto:

ping nombre_equipo_remoto

Comprobamos que los enrutadores de la ruta al destino funcionan correctamente:

pathping dirección_IP_host_remoto

 

Notas:

• Sí la dirección IP local devuelta en cualquier comando es 169.254.y.z, significa que se ha asignado mediante APIPA (Automatic Private IP Adressing), una característica de Windows Server 2003. Lo cual nos indica que no hay servidor DHCP activo o que es inalcanzable por el equipo.
• Si la IP es 0.0.0.0, se ha detectado que el adaptador de red no está conectado a una red. Comprobar el cable y que el concentrador/conmutador (hub/switch) funciona. Podría también ser un mal funcionamiento de controladores e incluso de la propia tarjeta de red.

Ping utiliza resolución de host name para resolver el nombre de un euipo a una IP, así que si el ping a la IP se realiza con éxito y al nombre del equipo falla, el problema reside en la resolución de nombres y no en la conectividad de la red.

Si por cualquier motivo no logramos pings con éxito comprobaremos:

• Que el equipo dispone de una dirección IP válida y que se muestra correctamente en la pestaña General de las propiedades del protocolo TCP/IP de la conexión de red y también en la pestaña Soporte del Estado de la conexión de red (clic derecho conexión de red, Estado). Por supuesto si usamos ipconfig o netdiag también se nos muestra.
• La puerta de enlace está configurada y el enlace entre ambos funciona adecuadamente. Windows Server 2003 dispone de lo que se llama Dead Gateway Detection que en caso de múltiples puertas de enlace configuradas, intentará enviar paquetes mediante la puerta de enlace predeterminada un número de veces sin recibir respuesta, esta característica hará que se cambie la dirección de próximo salto de esa conexión TCP a la siguiente puerta de enlace de la lista.