El primer día que hicimos algo práctico en ASIR, cuando nadie en clase sabía todavía casi nada de redes, fue lanzar pings entre nuestros propios equipos y trazar rutas hacia servidores como Google. En ese momento parecía casi magia: escribes un comando y te dice si el otro equipo “está ahí” o no. Lo que hay detrás es un protocolo concreto, y entender qué hace de verdad cambia bastante cómo interpretas los resultados.
Qué es ICMP
ICMP (Internet Control Message Protocol) no transporta datos de usuario como HTTP o FTP — es un protocolo de control y diagnóstico. Su trabajo es enviar mensajes cortos sobre el estado de la red: “este host no responde”, “esta ruta no existe”, “el paquete ha tardado demasiado y se ha descartado”. Cuando ejecutas ping o tracert/traceroute, en realidad estás usando ICMP por debajo.
Qué pasa exactamente cuando haces ping
Un ping manda un mensaje ICMP llamado Echo Request al equipo de destino. Si ese equipo está accesible y no tiene el ICMP bloqueado, responde con un Echo Reply. El comando mide el tiempo que tarda ese viaje de ida y vuelta (la latencia, en milisegundos) y te dice si se ha perdido algún paquete por el camino.
PS C:\> ping 8.8.8.8
Haciendo ping a 8.8.8.8 con 32 bytes de datos:
Respuesta desde 8.8.8.8: bytes=32 tiempo=14ms TTL=118
Respuesta desde 8.8.8.8: bytes=32 tiempo=13ms TTL=118
Estadísticas de ping para 8.8.8.8:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos)Cuatro peticiones, cuatro respuestas, cero pérdida. Eso significa que hay conectividad completa entre tu equipo y el destino — no dice nada sobre si un servicio concreto (una web, un servidor) funciona, solo que la red entre los dos puntos está bien.
El campo TTL que casi nadie mira
Fíjate en el TTL=118 de la respuesta anterior. TTL (Time To Live) no es un tiempo, es un contador de saltos: cada vez que un paquete pasa por un router, ese router le resta 1 al TTL. Si el TTL llega a 0 antes de alcanzar el destino, el router que lo descarta manda de vuelta un mensaje ICMP de tipo “tiempo excedido” — y esto, aunque no lo parezca, es la base exacta de cómo funciona traceroute.
Cómo traceroute usa el TTL para “ver” la ruta completa
tracert (Windows) o traceroute (Linux) no es un comando distinto de ping por casualidad — usa el mismo truco del TTL de forma deliberada. Manda un primer paquete con TTL=1: el primer router de la ruta lo descarta (porque llega a 0) y responde con el ICMP de “tiempo excedido”, revelando su propia IP. Luego manda otro con TTL=2, que llega un salto más allá antes de agotarse, y así sucesivamente, aumentando el TTL en cada intento hasta llegar al destino final.
Traza a la dirección google.com [142.250.184.14]
sobre un máximo de 30 saltos:
1 2 ms 1 ms 1 ms 192.168.1.1
2 12 ms 11 ms 12 ms 10.45.0.1
3 14 ms 13 ms 14 ms 142.250.x.x
4 14 ms 13 ms 13 ms 142.250.184.14Cada línea es un router distinto por el que pasa tu tráfico antes de llegar al destino, descubierto exactamente gracias a que cada uno “se queja” con ICMP cuando el TTL le llega a cero.
ICMP no es solo Echo Request/Reply
Aunque el ping es el uso más conocido, ICMP define varios tipos de mensajes distintos, cada uno con su propio significado. Los más habituales que te vas a encontrar analizando una red son:
| Tipo de mensaje ICMP | Qué indica |
|---|---|
| Echo Request / Echo Reply | El ping normal: “¿estás ahí?” / “sí, aquí estoy” |
| Time Exceeded | El TTL ha llegado a 0 (la base de traceroute) |
| Destination Unreachable | El destino, o la ruta hacia él, no es alcanzable |
| Redirect | Un router le dice a un equipo que use una ruta más directa |
Cuando ves en Windows un ping que responde “Host de destino inaccesible” en vez de un simple “tiempo de espera agotado”, esas son dos cosas distintas aunque ambas parezcan un fallo: la primera es un mensaje ICMP explícito de tipo Destination Unreachable (algún router en la ruta sabe activamente que no puede llegar), mientras que la segunda es simplemente que no ha llegado ninguna respuesta en el tiempo esperado, sin que nadie te lo confirme.
Por qué a veces un ping falla aunque el equipo esté encendido
Esto es lo que más confunde al principio: que un ping no responda no significa necesariamente que el equipo esté apagado o inaccesible. Los motivos más habituales son:
- El firewall del destino bloquea ICMP a propósito. Muchos servidores en Internet (y muchos equipos con Windows Defender activo) descartan los Echo Request por seguridad, para no revelar que están ahí. El equipo puede estar perfectamente operativo y con sus servicios funcionando, simplemente no responde a ping.
- Algún router intermedio filtra ICMP, sin que tenga nada que ver con el destino final.
- La red de verdad está caída, que es el caso que sí indica un problema real.
Por eso en redes reales nunca se usa solo el ping para decidir si un servidor “está mal” — un servidor puede no responder a ping y tener su web funcionando perfectamente en el navegador, o al revés.
Pon a prueba lo que has entendido
Haces ping a un servidor y no responde, pero cuando abres su web en el navegador, carga perfectamente. ¿Qué explicación es la más probable?
Resumen rápido
ICMP es el protocolo de control y diagnóstico detrás del ping (Echo Request/Reply) y del traceroute (que aprovecha el contador TTL para descubrir cada router de la ruta). Un ping sin respuesta no siempre significa que el equipo esté caído — a menudo es solo que ICMP está bloqueado por seguridad. Una vez que confirmas que un equipo responde en tu red local, el siguiente paso lógico suele ser mirar cómo ese equipo consigue conectividad en primer lugar — algo que empieza con DHCP y cómo ver la IP asignada con ipconfig /all.