Estudio de caso: ping a un host desconectado (o inexistente)

Fecha: 29 de octubre del 2015

 

Escenario

 

Este escenario se planteó con algunos colegas administradores de sistemas. La imagen mental que se tiene cuando uno “tira un ping”

a una IP sin utilizar en nuestra red, para verificar que realmente no esté en uso, es tiempo de espera agotado, pero por lo visto no es así…

 

 

Tuvimos cierta confusión con el ping de Windows 7, lo verificamos con Linux y pulimos algunos conceptos sobre ICMP.

Siempre el modelo OSI es el que manda, aguante CCNA 1.

 

Verificación inicial en Windows 7:

 

 

Microsoft Windows [Versión 6.1.7601]

Copyright (c) 2009 Microsoft Corporation. Reservados todos los derechos.

 

C:\>ping 10.0.0.100 (esta IP no existe en la red local, nuestra IP es la 10.0.0.18)

 

Haciendo ping a 10.0.0.100 con 32 bytes de datos:

Respuesta desde 10.0.0.18: Host de destino inaccesible.

Respuesta desde 10.0.0.18: Host de destino inaccesible.

Respuesta desde 10.0.0.18: Host de destino inaccesible.

Respuesta desde 10.0.0.18: Host de destino inaccesible.

 

Estadísticas de ping para 10.0.0.100:

    Paquetes: enviados = 4, recibidos = 4, perdidos = 0

    (0% perdidos),

 

Vemos que la respuesta viene desde nuestra propia IP, por lo tanto nuestro propio sistema operativo nos dice que el host es inalcanzable.

Ahora bien, esta respuesta a simple vista es de layer 3, pero podemos observar que enviamos 4 paquetes y recibimos 4 paquetes, aunque

no sean tiempo de espera agotado (en realidad ese mensaje no existe), sino que recibimos host de destino inaccesible. Recibir recibimos,

lo que confunde es el perdidos=0.

 

La verdad es que, desde nuestro host nunca se enviaron 4 paquetes ICMP sino 4 consultas ARP, el tráfico ICMP nunca salió de la placa de red

porque no había MAC de destino a quién enviar.

 

 

 ---resumido---

 

 

Verificamos la tabla ARP para comprobar la existencia de alguna entrada:

 

C:\>arp –a (no existen entradas para la IP 10.0.0.100, no se pudo resolver)

 

Interfaz: 10.0.0.18 --- 0xc

  Dirección de Internet    Dirección física           Tipo

  10.0.0.1                           d4-ca-6d-a4-2e-26     dinámico (gateway por defecto)

  255.255.255.255            ff-ff-ff-ff-ff-ff               estático   (broadcast)

 

C:\>

 

Verificamos si salió algún paquete de la placa de red:

 

 

Solamente se transmitieron los ARP correspondientes, pero nunca llegaron a destino, y por lo tanto nunca se respondieron, y por lo tanto

 nunca se resolvió la dirección de destino de layer 2, por lo tanto nunca salieron los ping de nuestra máquina…por lo tanto…definitivamente

 todos los mensajes ICMP recibidos son de nuestro sistema operativo.

 

Ahora, porqué Windows 7 nos dice 4 enviados, 4 recibidos, 0 perdidos ? les dejo la inquietud.

 

 

 

Veamos que pasa en Windows XP:

 

Generalmente, uno tiene la imagen mental de que (en lenguaje vulgar) si tira un ping a una IP que no está activa en nuestra red local, recibe

un tiempo de espera agotado. En mi caso esto era por tantos años de Windows XP:

 

Microsoft Windows XP [Versión 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.

 

C:\>ping 10.0.0.100

 

Haciendo ping a 10.0.0.100 con 32 bytes de datos:

 

Tiempo de espera agotado para esta solicitud.

Tiempo de espera agotado para esta solicitud.

Tiempo de espera agotado para esta solicitud.

Tiempo de espera agotado para esta solicitud.

 

Estadísticas de ping para 10.0.0.100:

    Paquetes: enviados = 4, recibidos = 0, perdidos = 4

    (100% perdidos),

 

C:\>

 

Esto es mas cercano a la realidad desde el punto de vista de los pings perdidos, aunque salieron de la capa 3, “entraron en la capa 2” pero

nunca salieron de la máquina por no tener la MAC destino. Pero es sólo una cuestión de gramática.

 

Y con Linux ?

 

Linux devuelve x errors, eso es tan digerible como los “perdidos” de Windows XP, y mucho mas que lo de Windows 7.

 

PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.

From 10.0.0.18 icmp_seq=1 Destination Host Unreachable

From 10.0.0.18 icmp_seq=2 Destination Host Unreachable

From 10.0.0.18 icmp_seq=3 Destination Host Unreachable

From 10.0.0.18 icmp_seq=4 Destination Host Unreachable

From 10.0.0.18 icmp_seq=5 Destination Host Unreachable

From 10.0.0.18 icmp_seq=6 Destination Host Unreachable

^C

--- 10.0.0.100 ping statistics ---

7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6031ms

pipe 3

 

Y con un escenario mas complejo ?

 

Enviamos pings a una IP fuera de la red local, ahora interviene nuestro Gateway por defecto.

 

 

En este caso recibimos una respuesta ICMP desde nuestro router (10.0.0.1), que es quien debe resolver el problema de reenviar el tráfico.

 

 

El router no tiene una ruta específica ni una ruta por defecto, por lo tanto nos informa que no puede alcanzar el destino, en cierta manera

reproducimos el caso anterior.

 

C:\>ping 10.0.1.100

 

Haciendo ping a 10.0.1.100 con 32 bytes de datos:

Respuesta desde 10.0.0.1: Host de destino inaccesible. (estos sí son mensajes ICMP de layer 3)

Respuesta desde 10.0.0.1: Host de destino inaccesible.

Respuesta desde 10.0.0.1: Host de destino inaccesible.

Respuesta desde 10.0.0.1: Host de destino inaccesible.

 

Estadísticas de ping para 10.0.1.100:

    Paquetes: enviados = 4, recibidos = 4, perdidos = 0

    (0% perdidos),

 

C:\>

 

Se agrega una ruta por defecto a un next-hop inexistente:

 

En este caso el router hará lo posible para reenviar nuestro tráfico, mientra lo hace, nuestro TCP/IP llega al timeout y vemos el (ahora) lógico

mensaje tiempo de espera agotado.

 

Gateway(config)#ip route 0.0.0.0 0.0.0.0 172.16.145.162

 

 

Del “otro lado” del router tenemos esto:

 

El router intenta localizar su próximo salto para poder reenviar nuestros paquetes.

 

 

El resultado final es este:

 

C:\>ping 10.0.1.100

 

Haciendo ping a 10.0.1.100 con 32 bytes de datos:

Tiempo de espera agotado para esta solicitud.

Tiempo de espera agotado para esta solicitud.

Tiempo de espera agotado para esta solicitud.

Tiempo de espera agotado para esta solicitud.

 

Estadísticas de ping para 10.0.1.100:

    Paquetes: enviados = 4, recibidos = 0, perdidos = 4

    (100% perdidos),

 

C:\>

 

Ahora sí el resultado 4-0-4 tiene sentido, los pings salen, se reenvían pero nunca llegan a ningún lado, si esto sale a internet puede ser que el paquete

con IP de destino privada se muera en nuestro propio ISP (ver RFC 1918).

 

Se puede ir mas lejos con este tema ? por supuesto que sí, pero habrá que depurar los mensajes que recibimos si no llegamos.

Es una cuestión de tiempo (agotado, o expirado en tránsito, etc…).

 

(2015) Sensei,  St Claus can deliver IP packets too ?

Rosario, Argentina