Debido a que el protocolo IP no es fiable, los datagramas pueden perderse o llegar defectuosos a su destino. El protocolo ICMP (Internet Control Message Protocol, protocolo de mensajes de control y error) se encarga de informar al origen si se ha producido algún error durante la entrega de su mensaje. Pero no sólo se encarga de notificar los errores, sino que también transporta distintos mensajes de control.
El protocolo ICMP únicamente informa de incidencias en la red pero no toma ninguna decisión. Esto será responsabilidad de las capas superiores. Los mensajes ICMP viajan en el campo de datos de un datagrama IP, como se puede apreciar en el siguiente esquema:
Debido a que el protocolo IP no es fiable puede darse el caso de que un mensaje ICMP se pierda o se dañe. Si esto llega a ocurrir no se creará un nuevo mensaje ICMP sino que el primero se descartará sin más.
Los mensajes ICMP comienzan con un campo de 8 bits que contiene el tipo de mensaje, según se muestra en la tabla siguiente. El resto de campos son distintos para cada tipo de mensaje ICMP.
Nota
El formato y significado de cada mensaje ICMP está documentado en la RFC 792
| Campo de tipo | Tipo de mensaje ICMP |
|---|---|
| 0 | Respuesta de eco (Echo Reply) |
| 3 | Destino inaccesible (Destination Unreachable) |
| 4 | Disminución del tráfico desde el origen (Source Quench) |
| 5 | Redireccionar (cambio de ruta) (Redirect) |
| 8 | Solicitud de eco (Echo) |
| 11 | Tiempo excedido para un datagrama (Time Exceeded) |
| 12 | Problema de Parámetros (Parameter Problem) |
| 13 | Solicitud de marca de tiempo (Timestamp) |
| 14 | Respuesta de marca de tiempo (Timestamp Reply) |
| 15 | Solicitud de información (obsoleto) (Information Request) |
| 16 | Respuesta de información (obsoleto) (Information Reply) |
| 17 | Solicitud de máscara (Addressmask) |
| 18 | Respuesta de máscara (Addressmask Reply) |
3.2.3.1. Solicitud y respuesta de eco
Los mensajes de solicitud y respuesta de eco, tipos 8 y 0 respectivamente, se utilizan para comprobar si existe comunicación entre 2 hosts a nivel de la capa de red. Estos mensajes comprueban que las capas física (cableado), acceso al medio (tarjetas de red) y red (configuración IP) están correctas. Sin embargo, no dicen nada de las capas de transporte y de aplicación las cuales podrían estar mal configuradas; por ejemplo, la recepción de mensajes de correo electrónico puede fallar aunque exista comunicación IP con el servidor de correo.
La orden PING envía mensajes de solicitud de eco a un host remoto e informa de las respuestas. Veamos su funcionamiento, en caso de no producirse incidencias en el camino.
- A envía un mensaje ICMP de tipo 8 (Echo) a B
- B recibe el mensaje y devuelve un mensaje ICMP de tipo 0 (Echo Reply) a A
- A recibe el mensaje ICMP de B y muestra el resultado en pantalla
C:\>ping 172.20.9.7 -n 1
Haciendo ping a 172.20.9.7 con 32 bytes de datos:
Respuesta desde 172.20.9.7: bytes=32 tiempo<10ms TDV=128
En la orden anterior hemos utilizado el parámetro «-n 1» para que el host A únicamente envíe 1 mensaje de solicitud de eco. Si no se especifica este parámetro se enviarían 4 mensajes (y se recibirían 4 respuestas).
Si el host de destino no existiese o no estuviera correctamente configurado recibiríamos un mensaje ICMP de tipo 11 (Time Exceeded).
C:\>ping 192.168.0.6 -n 1
Haciendo ping a 192.168.0.6 con 32 bytes de datos:
Tiempo de espera agotado.
Si tratamos de acceder a un host de una red distinta a la nuestra y no existe un camino para llegar hasta él, es decir, los routers no están correctamente configurados o estamos intentando acceder a una red aislada o inexistente, recibiríamos un mensaje ICMP de tipo 3 (Destination Unreachable).
C:\>ping 1.1.1.1 -n 1
Haciendo ping a 1.1.1.1 con 32 bytes de datos:
Respuesta desde 192.168.0.1: Host de destino inaccesible.
3.2.3.2. Utilización de PING para diagnosticar errores en una red aislada
C:\>ping 192.168.1.12
- Respuesta. El cableado entre A y B, las tarjetas de red de A y B, y la configuración IP de A y B están correctos.
- Tiempo de espera agotado. Comprobar el host B y el cableado entre A y B.
- Host de destino inaccesible. Comprobar las direcciones IP y máscaras de subred de A y B porque no pertenecen a la misma red.
- Error. Probablemente estén mal instalados los protocolos TCP/IP del host A. Probar C:>ping 127.0.0.1 para asegurarse.
Nota
El comando ping 127.0.0.1 informa de si están correctamente instalados los protocolos TCP/IP en nuestro host. No informa de si la tarjeta de red de nuestro host está correcta.
3.2.3.3. Utilización de PING para diagnosticar errores en una red de redes
A continuación veremos un ejemplo para una red de redes formada por dos redes (1 solo router). La idea es la misma para un mayor número de redes y routers.
C:\>ping 10.100.5.1
- Respuesta. El cableado entre A y B, las tarjetas de red de A, R1 y B, y la configuración IP de A, R1 y B están correctos. El router R1 permite el tráfico de datagramas IP en los dos sentidos.
- Tiempo de espera agotado. Comprobar el host B y el cableado entre R1 y B. Para asegurarnos que el router R1 está funcionando correctamente haremos C:>ping 192.168.1.1
- Host de destino inaccesible. Comprobar el router R1 y la configuración IP de A (probablemente la puerta de salida no sea 192.168.1.1). Recordemos que la puerta de salida (gateway) de una red es un host de su propia red que se utiliza para salir a otras redes.
- Error. Probablemente estén mal instalados los protocolos TCP/IP del host A. Probar C:>ping 127.0.0.1 para asegurarse.
En el caso producirse errores de comunicación en una red de redes con más de un router (Internet es el mejor ejemplo), se suele utilizar el comando PING para ir diagnosticando los distintos routers desde el destino hasta el origen y descubrir así si el fallo es responsabilidad de la red de destino, de una red intermedia o de nuestra red.
Nota
Algunos hosts en Internet tienen deshabilitadas las respuestas de eco (mensajes ICMP tipo 0) como medida de seguridad. En estos casos hay que utilizar otros mecanismos para detectar si responde (por ejemplo, la apertura de conexión a un puerto)
3.2.3.4. Mensajes ICMP de tiempo excedido
Los datagramas IP tienen un campo TTL (tiempo de vida) que impide que un mensaje esté dando vueltas indefinidamente por la red de redes. El número contenido en este campo disminuye en una unidad cada vez que el datagrama atraviesa un router. Cuando el TTL de un datagrama llega a 0, éste se descarta y se envía un mensaje ICMP de tipo 11 (Time Exceeded) para informar al origen.
Los mensajes ICMP de tipo 11 se pueden utilizar para hacer una traza del camino que siguen los datagramas hasta llegar a su destino. ¿Cómo? Enviando una secuencia de datagramas con TTL=1, TTL=2, TTL=3, TTL=4, etc… hasta alcanzar el host o superar el límite de saltos (30 si no se indica lo contrario). El primer datagrama caducará al atravesar el primer router y se devolverá un mensaje ICMP de tipo 11 informando al origen del router que descartó el datagrama. El segundo datagrama hará lo propio con el segundo router y así sucesivamente. Los mensajes ICMP recibidos permiten definir la traza.
La orden TRACERT (traceroute en entornos Unix) hace una traza a un determinado host. TRACERT funciona enviando mensajes ICMP de solicitud de eco con distintos TTL; traceroute, en cambio, envía mensajes UDP. Si la comunicación extremo a extremo no es posible, la traza nos indicará en qué punto se ha producido la incidencia. Existen algunas utilidades en Internet, como Visual Route, que conocen la localización geográfica de los principales routers de Internet. Esto permite dibujar en un mapamundi el recorrido que siguen los datagramas hasta llegar a un host.
C:\>tracert 130.206.1.2
Traza a la dirección sun.rediris.es [130.206.1.2]
sobre un máximo de 30 saltos:
1 1 ms 1 ms 1 ms PROXY [192.168.0.1]
2 122 ms 118 ms 128 ms MADR-X27.red.retevision.es [62.81.1.102]
3 143 ms 232 ms 147 ms MADR-R2.red.retevision.es [62.81.1.92]
4 130 ms 124 ms 246 ms MADR-R16.red.retevision.es [62.81.3.8]
5 590 ms 589 ms 431 ms MADR-R12.red.retevision.es [62.81.4.101]
6 612 ms 640 ms 124 ms MADR-R10.red.retevision.es [62.81.8.130]
7 259 ms 242 ms 309 ms 193.149.1.28
8 627 ms 752 ms 643 ms 213.0.251.42
9 137 ms 117 ms 118 ms 213.0.251.142
10 109 ms 105 ms 110 ms A1-2-1.EB-Madrid00.red.rediris.es [130.206.224.81]
11 137 ms 119 ms 122 ms A0-0-0-1.EB-Madrid3.red.rediris.es [130.206.224.86]
12 109 ms 135 ms 115 ms sun.rediris.es [130.206.1.2]
Traza completa.
Ejemplo de Visual Route a una dirección IP de Taiwan (203.69.112.12):
