Manuales para la línea de comandos

Man » Manual de ping en línea: documentación detallada en línea para la página de manual de ping

🌍
ping - envía un datagrama ICMP ECHO_REQUEST a los hosts de la red

SINTAXIS

ping [-aAbBdCDfhHLnOqrRUvV346] [-c count] [-e identifier] [-F flowlabel] [-i interval]
[-I interface] [-l preload] [-m mark] [-M pmtudisc_option] [-N nodeinfo_option]
[-w deadline] [-W timeout] [-p pattern] [-Q tos] [-s packetsize] [-S sndbuf] [-t ttl]
[-T timestamp option] [hop...] {destino}

DESCRIPCIÓN

ping utiliza el datagrama ICMP ECHO_REQUEST obligatorio del protocolo ICMP para obtener una respuesta ICMP ECHO_RESPONSE
de un host o puerta de enlace. Los datagramas ECHO_REQUEST ("pings") tienen una cabecera IP e ICMP, seguida de
una estructura timeval y luego un número arbitrario de bytes de "relleno" utilizados para completar el paquete.

ping funciona tanto con IPv4 como con IPv6. Se puede forzar el uso de solo uno de ellos
especificando -4 o -6.

ping también puede enviar consultas de información de nodo IPv6 (RFC4620). Los saltos intermedios pueden no estar permitidos,
porque el enrutamiento de origen IPv6 quedó en desuso (RFC5095).

OPCIONES

-3
Precisión de RTT (no redondear el resultado del tiempo).

-4
Usar solo IPv4.

-6
Usar solo IPv6.

-a
Ping audible.

-A
Ping adaptativo. El intervalo entre paquetes se adapta al tiempo de ida y vuelta, de modo que efectivamente no haya más de uno (o más, si se establece preload)
paquete sin respuesta en la red. El intervalo predeterminado es de 2 ms; para obtener más información, consulte la opción -i. En las redes con baja latencia, este modo es
esencialmente equivalente al modo de inundación.

-b
Permitir hacer ping a una dirección de transmisión.

-B
No permitir que ping cambie la dirección de origen de los paquetes. La dirección se vincula a una seleccionada
cuando ping se inicia.

-c count
Dejar de enviar después de enviar count paquetes ECHO_REQUEST. Con la opción de tiempo máximo, ping espera count
paquetes ECHO_REPLY, hasta que expira el tiempo de espera.

-C
Llamar a la llamada al sistema connect() al crear el socket.

-d
Establecer la opción SO_DEBUG en el socket que se está utilizando. Básicamente, esta opción de socket no se usa
por el kernel de Linux.

-D
Imprimir la marca de tiempo (tiempo Unix + microsegundos como en gettimeofday) antes de cada línea.

-e identifier
Establecer el campo de identificación de ECHO_REQUEST. El valor 0 implica el uso de un socket sin procesar (no es compatible
en el socket de datagrama ICMP). El valor del campo se puede imprimir con la opción -v.

-f
Ping de inundación. Por cada paquete ECHO_REQUEST enviado, se imprime un punto "; mientras que por cada paquete ECHO_REPLY
recibido, se imprime un retroceso. Esto proporciona una visualización rápida de cuántos paquetes se están
perdiendo. Si no se especifica el intervalo, establece el intervalo en cero y envía paquetes tan rápido como
se reciben o cien veces por segundo, lo que sea más. Solo el superusuario puede
usar esta opción con un intervalo de cero.

-F etiqueta-flujo
Solo IPv6. Asigna y establece la etiqueta de flujo de 20 bits (en hexadecimal) en los paquetes de solicitud de eco. Si el valor es cero, el kernel asigna una etiqueta de flujo aleatoria.

-h

Muestra la ayuda.

-H

Fuerza la resolución de nombres DNS para la salida. Útil para destinos numéricos, o la opción -f, que por defecto no realizan esta operación. También puede ayudar a solucionar problemas de resolución de DNS. Anula la opción -n definida anteriormente. Consulte también la variable de entorno IPUTILS_PING_PTR_LOOKUP.

-i intervalo

Establece el intervalo de tiempo en segundos que se debe esperar entre el envío de cada paquete. Se permite un número real con un punto como separador decimal (independientemente de la configuración regional). El valor predeterminado es esperar un segundo entre cada paquete, o no esperar en modo de inundación. Solo el superusuario puede establecer el intervalo en valores inferiores a 2 ms. Las pruebas ping de difusión y multidifusión tienen una limitación aún mayor para el usuario normal: el mínimo es de 1 segundo.

-I interfaz

La interfaz es una dirección, un nombre de interfaz o un nombre de VRF. Si la interfaz es una dirección, establece la dirección de origen en la dirección de la interfaz especificada. Si la interfaz es un nombre de interfaz, establece la interfaz de origen en la interfaz especificada. Si la interfaz es un nombre de VRF, cada paquete se enruta utilizando la tabla de enrutamiento correspondiente; en este caso, la opción -I se puede repetir para especificar una dirección de origen. NOTA: Para IPv6, al realizar un ping a una dirección de ámbito de enlace local, se puede utilizar la especificación de enlace (mediante la notación "%" en el destino o mediante esta opción), pero ya no es obligatorio.

-l precarga

Si se especifica precarga, ping envía ese número de paquetes sin esperar una respuesta. Solo el superusuario puede seleccionar una precarga mayor a 3.

-L

Suprime el bucle de los paquetes de multidifusión. Esta opción solo se aplica si el destino de ping es una dirección de multidifusión.

-m marca

Utiliza la marca para etiquetar los paquetes que se envían. Esto es útil para diversas razones dentro del kernel, como el uso del enrutamiento basado en políticas para seleccionar un procesamiento de salida específico. Se requiere la capacidad CAP_NET_ADMIN o CAP_NET_RAW (a partir de Linux 5.17), consulte socket(7).

-M pmtudisc_opt

Selecciona la estrategia de descubrimiento de MTU de ruta. La opción pmtudisc_option puede ser do (establece la marca DF, pero está sujeta a las comprobaciones de PMTU del kernel; los paquetes demasiado grandes se rechazarán), want (realiza el descubrimiento de PMTU, fragmenta localmente cuando el tamaño del paquete es grande), probe (establece la marca DF y omite las comprobaciones de PMTU, útil para la comprobación) o dont (no establece la marca DF).

-N nodeinfo_option

Solo IPv6. Envía consultas de información de nodo IPv6 (RFC4620) en lugar de solicitudes de eco. Se requiere la capacidad CAP_NET_RAW.

ayuda

Muestra la ayuda para el soporte de NI.

nombre

Realiza consultas para obtener nombres de nodo.

ipv6

Realiza consultas para obtener direcciones IPv6. Existen varias opciones específicas de IPv6.

ipv6-global

Solicita direcciones IPv6 de ámbito global.

ipv6-sitelocal

Solicita direcciones IPv6 de ámbito local del sitio.

ipv6-linklocal

Solicita direcciones IPv6 de ámbito de enlace local.

ipv6-all

Solicita direcciones IPv6 en otras interfaces.

ipv4

Realiza consultas para obtener direcciones IPv4. Existe una opción específica de IPv4.

ipv4-all

Solicita direcciones IPv4 en otras interfaces.

subject-ipv6=ipv6addr

Dirección de sujeto IPv6.

subject-ipv4=ipv4addr

Dirección de sujeto IPv4.


subject-name=nodename

Nombre del sujeto. Si contiene más de un punto, se asume que es un nombre de dominio completamente cualificado.

subject-fqdn=nodename

Nombre del sujeto. Siempre se asume que es un nombre de dominio completamente cualificado.

-n

Salida numérica únicamente. No se intentará buscar nombres simbólicos para las direcciones de host (no se realizará la resolución DNS inversa). Esta es la opción predeterminada para la salida numérica o la opción -f. Anula la opción -H definida previamente. Consulte también la variable de entorno IPUTILS_PING_PTR_LOOKUP.

-O

Informe sobre el ICMP ECHO pendiente antes de enviar el siguiente paquete. Esto es útil junto con la opción de marca de tiempo -D para registrar la salida en un archivo de diagnóstico y buscar respuestas faltantes.

-p pattern

Puede especificar hasta 16 bytes de "relleno" para completar el paquete que envía. Esto es útil para diagnosticar problemas dependientes de los datos en una red. Por ejemplo, -p ff hará que el paquete enviado se complete con unos.

-q

Salida silenciosa. No se muestra nada excepto las líneas de resumen al inicio y al final.

-Q tos

Establezca los bits relacionados con la calidad de servicio (QoS) en los datagramas ICMP. tos puede ser un número decimal (solo ping) o hexadecimal.

En RFC2474, estos campos se interpretan como DS (Differentiated Services) de 8 bits, que consisten en: bits 0-1 (los 2 bits más bajos) de datos separados y bits 2-7 (los 6 bits más altos) del punto de código de servicios diferenciados (DSCP). En RFC2481 y RFC3168, los bits 0-1 se utilizan para ECN.

Históricamente (RFC1349, obsoleto por RFC2474), se interpretaban de la siguiente manera: bit 0 (el bit más bajo) para reservado (actualmente se está redefiniendo como control de congestión), 1-4 para el tipo de servicio y los bits 5-7 (los bits más altos) para la precedencia.

-r

Omita las tablas de enrutamiento normales y envíe directamente a un host en una interfaz adjunta. Si el host no está en una red directamente adjunta, se devuelve un error. Esta opción se puede utilizar para hacer ping a un host local a través de una interfaz que no tiene una ruta a través de ella, siempre que también se utilice la opción -I.

-R

solo ping. Registrar ruta. Incluye la opción RECORD_ROUTE en el paquete ECHO_REQUEST y muestra el búfer de ruta en los paquetes devueltos. Tenga en cuenta que la cabecera IP solo tiene suficiente tamaño para nueve rutas. Muchos hosts ignoran o descartan esta opción.

-s packetsize

Especifica el número de bytes de datos que se enviarán. El valor predeterminado es 56, lo que se traduce en 64 bytes de datos ICMP cuando se combina con los 8 bytes de la cabecera de datos ICMP. El valor máximo permitido es 65507 para IPv4 (65467 cuando se utiliza -R, -T o saltos intermedios) o 65527 para IPv6, pero la mayoría de los sistemas limitan esto a un número dependiente del sistema más pequeño.

-S sndbuf

Establecer sndbuf del socket. Si no se especifica, se selecciona para almacenar en búfer no más de un paquete.

-t ttl

solo ping. Establecer el tiempo de vida (TTL) de IP.

-T timestamp option

Establecer opciones de marca de tiempo IP especiales. La opción de marca de tiempo puede ser tsonly (solo marcas de tiempo), tsandaddr (marcas de tiempo y direcciones) o tsprespec host1 [host2 [host3 [host4]]] (marca de tiempo para saltos preespecificados).

-U

Imprimir la latencia completa de usuario a usuario (el comportamiento anterior). Normalmente, ping imprime el tiempo de ida y vuelta de la red, que puede ser diferente, por ejemplo, debido a fallas de DNS.


-v

Salida detallada. No suprima las respuestas DUP al hacer ping a una dirección multicast.

-V

Mostrar la versión y salir.

-w tiempo_limite

Especifica un tiempo de espera, en segundos, antes de que ping salga sin importar cuántos paquetes se hayan enviado o recibido. En este caso, ping no se detiene después de que se envían la cantidad de paquetes, espera ya sea que expire el tiempo de espera o hasta que se respondan la cantidad de pruebas o que se reciba alguna notificación de error de la red.

-W tiempo_de_espera

Tiempo para esperar una respuesta, en segundos. La opción afecta solo el tiempo de espera en ausencia de cualquier respuesta; de lo contrario, ping espera durante dos RTT. Se permite un número real con un punto como separador decimal (independientemente de la configuración regional). 0 significa tiempo de espera infinito.

Cuando se utiliza ping para el aislamiento de fallos, primero debe ejecutarse en el host local para verificar que la interfaz de red local esté activa y funcionando. Luego, se deben "hacer ping" a los hosts y las puertas de enlace que estén cada vez más lejos. Se calculan los tiempos de ida y vuelta y las estadísticas de pérdida de paquetes. Si se reciben paquetes duplicados, no se incluyen en el cálculo de la pérdida de paquetes, aunque el tiempo de ida y vuelta de estos paquetes se utiliza para calcular los números mínimos/promedios/máximos/desviación estándar del tiempo de ida y vuelta.

La desviación estándar de la población (mdev) es esencialmente un promedio de qué tan lejos está cada RTT de ping de la media de RTT. Cuanto mayor sea la mdev, más variable será el RTT (con el tiempo). Con una alta variabilidad de RTT, tendrá problemas de velocidad con las transferencias masivas (tardarán más de lo estrictamente necesario, ya que la variabilidad eventualmente hará que el remitente espere las confirmaciones) y tendrá una calidad de VoIP de mala a mediocre.

Cuando se ha enviado (y recibido) el número especificado de paquetes, o si el programa se termina con una señal SIGINT, se muestra un breve resumen. Se pueden obtener estadísticas actuales más cortas sin la terminación del proceso con la señal SIGQUIT.

Este programa está diseñado para usarse en pruebas, mediciones y administración de redes. Debido a la carga que puede imponer en la red, no es aconsejable usar ping durante las operaciones normales o desde scripts automatizados.

ENTORNO

La variable de entorno IPUTILS_PING_PTR_LOOKUP establecida en 0 desactiva la resolución de DNS inversa (búsqueda de PTR)
por defecto. Se anulará mediante la opción -H o -n.

ESTADO DE SALIDA

Si ping no recibe ningún paquete de respuesta, saldrá con el código 1. Si se especifican tanto un recuento de paquetes como un tiempo de espera, y se reciben menos de la cantidad de paquetes cuando llega el tiempo de espera, también saldrá con el código 1. En cualquier otro error, sale con el código 2. De lo contrario, sale con el código 0. Esto hace posible utilizar el código de salida para ver si un host está activo o no.

DESTINOS DE ENLACE LOCAL DE IPV6

Para IPv6, cuando la dirección de destino tiene un alcance de enlace local y ping está utilizando sockets de datagramas ICMP, la interfaz de salida debe especificarse. Cuando ping está utilizando sockets brutos, no es estrictamente necesario especificar la interfaz de salida, pero se debe hacer para evitar ambigüedades cuando hay varias interfaces de salida posibles.


Hay dos formas de especificar la interfaz de salida:

usando la notación %

La dirección de destino se agrega con % y el nombre de la interfaz de salida o el ifindex, por ejemplo:

ping fe80::5054:ff:fe70:67bc%eth0

ping fe80::5054:ff:fe70:67bc%2

usando la opción -I

Cuando se utilizan sockets de datagramas ICMP, este método es compatible con las siguientes versiones del kernel: 5.17, 5.15.19, 5.10.96, 5.4.176, 4.19.228, 4.14.265. Además, no es compatible con musl libc.

DETALLES DEL PAQUETE ICMP

Una cabecera IP sin opciones tiene 20 bytes. Un paquete ICMP ECHO_REQUEST contiene 8 bytes adicionales de cabecera ICMP seguidos de una cantidad arbitraria de datos. Cuando se proporciona un tamaño de paquete, esto indica el tamaño de esta parte adicional de datos (el valor predeterminado es 56). Por lo tanto, la cantidad de datos recibidos dentro de un paquete IP de tipo ICMP ECHO_REPLY siempre será 8 bytes más que el espacio de datos solicitado (la cabecera ICMP).

Si el espacio de datos tiene al menos el tamaño de la estructura timeval, ping utiliza los bytes iniciales de este espacio para incluir una marca de tiempo que utiliza en el cálculo de los tiempos de ida y vuelta. Si el espacio de datos es más corto, no se proporcionan tiempos de ida y vuelta.

PAQUETES DUPLICADOS Y DAÑADOS

ping informará sobre paquetes duplicados y dañados. Los paquetes duplicados nunca deberían ocurrir y parecen ser causados por retransmisiones inapropiadas a nivel de enlace. Los duplicados pueden ocurrir en muchas situaciones y rara vez (si es que alguna vez) son una buena señal, aunque la presencia de bajos niveles de duplicados no siempre debe ser motivo de alarma.

Los paquetes dañados son obviamente motivo de gran preocupación y a menudo indican un hardware defectuoso en algún lugar de la ruta del paquete ping (en la red o en los hosts).

COLISIONES DE ID

A diferencia de TCP y UDP, que utilizan el puerto para identificar de forma única al destinatario para entregar datos, ICMP utiliza el campo de identificador (ID) para la identificación. Por lo tanto, si en la misma máquina, al mismo tiempo, dos procesos ping utilizan el mismo ID, el eco de respuesta puede entregarse a un destinatario incorrecto. Este es un problema conocido debido al tamaño limitado del campo ID de 16 bits. Esa es una limitación histórica del protocolo que no se puede solucionar en este momento a menos que codifiquemos un ID en la carga útil del paquete ping. ping imprime el error DIFERENTE DIRECCIÓN y la pérdida de paquetes es negativa.

ping utiliza el PID para obtener un número único. El valor predeterminado de /proc/sys/kernel/pid_max es 32768. En los sistemas que utilizan ping de forma intensiva y con pid_max mayor que 65535, las colisiones están destinadas a ocurrir.

PROBAR DIFERENTES PATRONES DE DATOS

La capa de red (inter)net no debería tratar los paquetes de forma diferente según los datos contenidos en la porción de datos. Desafortunadamente, se sabe que los problemas dependientes de los datos se introducen en las redes y permanecen sin detectar durante largos períodos de tiempo. En muchos casos, el patrón particular que causará problemas es algo que no tiene suficientes "transiciones", como todo unos o todo ceros, o un patrón justo al borde, como casi todo ceros. No es necesariamente suficiente especificar un patrón de datos de todo ceros (por ejemplo) en la línea de comandos porque el patrón que es de interés está en el nivel de enlace de datos, y la relación entre lo que escribe y lo que transmiten los controladores puede ser complicada.


Esto significa que si tiene un problema dependiente de los datos, probablemente tendrá que realizar muchas pruebas para encontrarlo. Si tiene suerte, puede encontrar un archivo que no se pueda enviar a través de su red o que tarde mucho más en transferirse que otros archivos de longitud similar. Luego, puede examinar este archivo en busca de patrones repetidos que pueda probar utilizando la opción -p de ping.

DETALLES DE TTL

El valor TTL de un paquete IP representa el número máximo de enrutadores IP por los que puede pasar el paquete antes de que se descarte. En la práctica actual, puede esperar que cada enrutador en Internet disminuya el campo TTL en exactamente uno.

El campo TTL para los paquetes TCP puede tener varios valores. El valor máximo posible de este campo es 255, y un valor inicial recomendado es 64. Para obtener más información, consulte la sección TCP/Interfaz de nivel inferior de RFC9293.

En el funcionamiento normal, ping imprime el valor TTL del paquete que recibe. Cuando un sistema remoto recibe un paquete ping, puede hacer una de las tres cosas con el campo TTL en su respuesta:

No cambiarlo; esto es lo que hacían los sistemas Berkeley Unix antes de la versión 4.3BSD Tahoe. En este caso, el valor TTL en el paquete recibido será 255 menos el número de enrutadores en la ruta de ida y vuelta.

Establecerlo en 255; esto es lo que hacen los sistemas Berkeley Unix actuales. En este caso, el valor TTL en el paquete recibido será 255 menos el número de enrutadores en la ruta desde el sistema remoto hasta el host que ejecuta ping.

Establecerlo en algún otro valor. Algunas máquinas utilizan el mismo valor para los paquetes ICMP que para los paquetes TCP, por ejemplo, 30 o 60. Otras pueden utilizar valores completamente aleatorios.

ERRORES

Muchos hosts y gateways ignoran la opción RECORD_ROUTE.

La longitud máxima del encabezado IP es demasiado pequeña para que opciones como RECORD_ROUTE sean completamente útiles. Sin embargo, no hay mucho que se pueda hacer al respecto.

No se recomienda el ping de inundación en general, y el ping de inundación a la dirección de transmisión solo debe realizarse en condiciones muy controladas.

VER TAMBIÉN

ip(8), ss(8).

HISTORIA

El comando ping apareció en 4.3BSD.

La versión descrita aquí es su descendiente específico de Linux.

A partir de la versión s20150815, el binario ping6 ya no existe. Se ha fusionado con ping. Crear un enlace simbólico llamado ping6 que apunte a ping dará como resultado la misma funcionalidad que antes.

SEGURIDAD

ping requiere la capacidad CAP_NET_RAW para ser ejecutado 1) si el programa se utiliza para consultas que no sean de eco (vea la opción -N) o cuando el campo de identificación se establece en 0 para ECHO_REQUEST (vea la opción -e), o 2) si el kernel no admite sockets de datagrama ICMP, o 3) si no se permite que el usuario cree un socket de eco ICMP. El programa se puede utilizar como set-uid root.

DISPONIBILIDAD

ping forma parte del paquete iputils.