Uso de PING para solucionar problemas de red

Diagnóstico de problemas con Ping

Por Steve Waddington

Los dos más utilizados herramientas, y casi siempre el primero para diagnosticar un problema de red son traceroute y ping. Los resultados que devuelven son, sin embargo lo más a menudo mal entendida o interpretada de una manera que conduce a una conclusión incorrecta.

Vamos a tomar la utilidad ping específicamente. Los errores más comunes que se hace es que sea cual sea el resultado de ping es decir, se debe a que el objetivo de la mesa de ping. Por ejemplo, si no hay respuesta de ping; la conclusión de que el sitio está desactivado. O si hay pérdida de paquetes o largos tiempos de retorno, la conclusión de que es debido a algún problema con la dirección de destino. Mientras tanto esos resultados podría ser el caso, mucho más a menudo que no, que estén completamente las conclusiones erróneas a dibujar.

Las causas comunes de este error de interpretación son las siguientes:

1. Ping envía un paquete a la dirección de destino que por lo general recorrerá varios puntos de la red de otros para llegar allí. Un problema en cualquiera de estos puntos provocará una respuesta no a la consulta de ping
2. En muchos casos los sitios web y otros servidores se sientan detrás de un cortafuegos, y muchos, si no la mayoría de los firewalls de paquetes de ping bloque. Así, mientras que el tráfico puede llegar al lugar, los paquetes de ping no.
3. El paquete de ping tiene una fuente (el sistema de iniciar el ping), así como un destino, puede ser que la fuente no tiene una trayectoria de la ruta correcta para el destino, o que el destino no tiene una vía de retorno a la ruta correcta fuente. Esto podría ser debido a determinadas firewall reglas, un error en las tablas de rutas "algún lugar" a lo largo de la ruta de datos, o de una política deliberada de enrutamiento específico puesto en marcha para bloquear el acceso.

El comando traceroute se puede utilizar para ayudar a detectar si 1. o 3. son la causa del problema, que tiene sus propios problemas, pero más sobre esto más adelante. Un resultado positivo en cualquiera de telnet y tcptraceroute de manera concluyente que descartar 2. como un caso posible.

Telnet se puede utilizar para abrir una conexión de cualquier de cualquier puerto, no sólo el puerto por defecto de telnet. Una conexión Telnet exitosa en mesa de ping no ha logrado es una prueba positiva de que un servidor de seguridad impide el acceso a los paquetes de ping. Aquí está un ejemplo:

  $ Ping cisco.com PING Cisco.com (198.133.219.25) 56 (84) bytes of data. 

  --- Cisco.com mesa de ping estadísticas --- 

  6 paquetes transmitidos, 0 recibidas, 100% de pérdida de paquetes, tiempo 5008ms 

  $ Telnet cisco.com 80 

  Tratando de 198.133.219.25 ... 

 Conectado a cisco.com. 

  Carácter de escape es '^]'. 

Se puede ver que el paquete de ping falló, pero que telnet al puerto 80 logró conectar con el servidor.

Lo mismo sucede con tcptraceroute en el puerto 80:

  $ 80 tcptraceroute cisco.com 

  traceroute para cisco.com (198.133.219.25), 30 hops max, 40 byte packets 

  1 192.168.6.254 (192.168.6.254) 8,557 ms 10.624 ms * 

  .... 

  15 cisco.com (198.133.219.25) 289.162 ms 237.972 ms 242.171 ms 

Otro error común utilizar ping es que los resultados de sólo unos pocos ensayos ping son indicativos de la condición de una ruta de datos. Puede que sea cierto, pero tal conclusión sólo puede ser invocado por un tamaño de muestra estadísticamente significativa. Además, para ser verdaderamente exacta, la distribución de las respuestas paquetes fuera del nivel aceptable necesita ser conocida.

Por ejemplo, como prueba de ping soltera de cuatro paquetes en los que se deja caer un paquete, no se puede, de ninguna manera significativa, se utiliza para concluir que existe un 25% la pérdida de paquetes en ese circuito. Diez mil pruebas de ping, a lo largo de varias horas donde hay digamos 5% de pérdidas tiene un significado mucho más, sin embargo tener en cuenta si la prueba se llevó a cabo más de 24 horas, y durante una hora el sitio de destino se redujo. La pérdida del 100% durante esa hora se parece a una pérdida de paquetes en general un 5% durante 24 horas.

Por tanto, es importante revisar el registro de la prueba de ping y ver si la distribución de cualquier pérdida de paquetes es regular o limitada a un período determinado, antes de una verdadera conclusión se puede extraer.

Un error común es que la tercera causa lo que se resultado se obtiene es debido al sitio de destino. Por ejemplo, digamos un 5% de pérdida de paquetes se encontró al hacer ping a 3com.com, esto de ninguna manera indica que el problema reside en ese sitio, más bien, el problema podría ser con cualquiera de los puntos a lo largo de la ruta de datos de ese sitio, inclusive la fuente (mi propio ordenador):

  $ Traceroute traceroute 3com.com de 3com.com (192.136.34.41), 30 hops max, 40 byte packets 

  1 192.168.6.254 (192.168.6.254) 10,285 13,316 ms ms 14.440 ms 

  2 129.1.233.220.exetel.com.au (220.233.1.129) 132,994 135,387 ms ms 136.312 ms 

  3 241.0.233.220.exetel.com.au (220.233.0.241) 137,192 141,296 ms ms 162.018 ms 

  4 10.0.1.1 (10.0.1.1) 168.530 ms 174.358 ms 176.908 ms 

  5 38.2.233.220.exetel.com.au (220.233.2.38) 177,729 188,233 ms ms 189.122 ms 

  6 359-GE-0-0-0.GW5.SYD2.ALTER.NET (203.166.92.57) 197.691 ms 85.598 ms 156.625 ms 

  7 0.so-0-2-0.XR3.SYD2.ALTER.NET (210.80.33.189) 158.108 ms 159.430 ms 160.260 ms 

  8 0.so-4-3-0.IR1.LAX12.ALTER.NET (210.80.50.249) 305.124 ms 305.952 ms 306.775 ms 

 9 0.so-5-0-0.IL1.LAX9.ALTER.NET (152.63.48.65) 313.518 ms 321.047 ms 321.868 ms 

  10 0.so-5-0-0.XT1.SAC1.ALTER.NET (152.63.0.98) 405.111 ms 406.359 ms 407.241 ms 

  11-0-GigabitEthernet6 0.GW9.SAC1.ALTER.NET (152.63.55.73) 331.091 ms 337.600 ms 341.527 ms 

  12-eds gw.customer.alter.net (63.114.61.154) 357.930 ms 287.765 ms 310.755 ms 

  13 205.141.209.3 (205.141.209.3) 311,606 312,502 ms ms 313.587 ms 

  14 10.231.1.2 (10.231.1.2) 341,277 342,101 ms ms 342.931 ms 

  15 205.141.209.133 (205.141.209.133) 344,380 345,861 ms ms 346.689 ms 

  16 ip-192-136-34-41.ip.3com.com (192.136.34.41) 261.317 ms 266.998 ms 346.689 ms 

Se puede ver claramente el número de saltos que los datos deben atravesar. En este caso no hay evidencia de cualquier problema a lo largo de la ruta de datos. Pero si el traceroute se veía así:

  $ Traceroute traceroute 3com.com de 3com.com (192.136.34.41), 30 hops max, 40 byte packets 

  1 192.168.6.254 (192.168.6.254) 10,285 13,316 ms ms 14.440 ms 

  2 129.1.233.220.exetel.com.au (220.233.1.129) 132,994 135,387 ms ms 136.312 ms 

  3 241.0.233.220.exetel.com.au (220.233.0.241) 137,192 141,296 ms ms 162.018 ms 

  4 10.0.1.1 (10.0.1.1) 168.530 ms 174.358 ms 176.908 ms 

  5 38.2.233.220.exetel.com.au (220.233.2.38) 177,729 188,233 ms ms 189.122 ms 

 6 359-GE-0-0-0.GW5.SYD2.ALTER.NET (203.166.92.57) 197.691 ms 85.598 ms 156.625 ms 

  7 0.so-0-2-0.XR3.SYD2.ALTER.NET (210.80.33.189) 758.108 ms 759.430 ms * 

  8 0.so-4-3-0.IR1.LAX12.ALTER.NET (210.80.50.249) ** 806,775 ms 

  9 0.so-5-0-0.IL1.LAX9.ALTER.NET (152.63.48.65) 813.518 ms 721.868 ms * 

  10 0.so-5-0-0.XT1.SAC1.ALTER.NET (152.63.0.98) * 1406.359 ms 1007.241 ms 

  11-0-GigabitEthernet6 0.GW9.SAC1.ALTER.NET (152.63.55.73) 731.091 ms 737.600 ms 1341.527 ms 

  12-eds gw.customer.alter.net (63.114.61.154) 357.930 ms ** 

  13 205.141.209.3 (205.141.209.3) 811,606 812,502 ms ms 813.587 ms 

  14 10.231.1.2 (10.231.1.2) 741,277 742,101 ms ms 1342.931 ms 

  15 205.141.209.133 (205.141.209.133) 746.689 ms ** 

  16 ip-192-136-34-41.ip.3com.com (192.136.34.41) 761.317 ms 866.998 ms * 

Sería razonable llegar a la conclusión de que había algún problema serio entre el hip hop 6 y 7, que está causando la prueba de ping para devolver su resultado con pérdidas.

Para concluir, podemos ver que el ping:

1. es una herramienta útil para indicar donde un problema puede ser
2. se debe utilizar en combinación con otras pruebas para eliminar los falsos positivos
3. no debe utilizarse para las pruebas pequeñas y aisladas 4. es un buen indicador de los problemas más significativos tamaños de las muestras sádicamente

http://steve.blogs.exetel.com.au

Fuente del artículo: http://EzineArticles.com/?expert=Steve_Waddington
http://EzineArticles.com/?Problem-Diagnosis-With-Ping&id=1021226

Puestos relacionados con:

1. Cómo configurar HSRP en un router Cisco