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.