table of contents
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.25.0-1
PING(8) | iputils | PING(8) |
NOMBRE¶
ping: envía ICMP ECHO_REQUEST a los equipos de la red
SINOPSIS¶
ping [-aAbBdCDfhHLnOqrRUvV46] [-c cuenta] [-e identificador] [-F etiqueta de flujo] [-i intervalo] [-I interfaz] [-l precarga] [-m marca] [-M opción_pmtudisc] [-N opción_nodeinfo] [-w fecha límite] [-W tiempo de espera] [-p patrón] [-Q tos] [-s tamaño de paquete] [-S sndbuf] [-t ttl] [-T marca de tiempo opción] [salto...] {destino}
DESCRIPCIÓN¶
ping utiliza el protocolo ICMP's datagrama ECHO_REQUEST obligatorio para obtener un ICMP ECHO_RESPONSE de otro equipo o puerta de enlace. Los datagramas ECHO_REQUEST (“pings”) tienen un encabezado IP e ICMP, seguido de una estructura timeval y un número aleatorio de “pad” bytes utilizados para completar el paquete.
ping funciona tanto con IPv4 como con IPv6. Sólo Se puede imponer de manera explícita uno de ellos mediante las opciones -4 o -6.
ping también puede enviar consultas de información de nodo IPv6 (RFC4620). Es posible que no se permitan saltos intermedios porque el enrutamiento de origen IPv6 está ya obsoleto (RFC5095).
OPCIONES¶
-4
-6
-a
-A
-b
-B
-c cuenta
-C
-d
-D
-e identificador
-f
-F etiqueta de flujo
-h
-H
-i intervalo
-I interfaz
-l precarga
-L
-m marca
-M opción_pmtudisc
-N opción_nodeinfo
help
nombre
ipv6
ipv6-global
ipv6-sitelocal
ipv6-linklocal
ipv6-all
ipv4
ipv4-all
subject-ipv6=dirección ipv6
subject-ipv4=ipv4addr
nombre-sujeto=nombre de nodo
subject-fqdn=nombre de nodo
-n
-O
-p patrón
-q
-Q tos
En RFC2474, estos campos se interpretan como servicios diferenciados (DS) de 8 bits, que constan de: bits 0-1 (los 2 bits más bajos) de datos separados y bits 2-7 (los 6 bits más altos) de punto de código de servicios diferenciados (DSCP). . Según los RFC2481 y RFC3168, los bits 0-1 se utilizan para ECN.
Históricamente (RFC1349, actualizado por RFC2474), estos se interpretaban del siguiente modo: el bit 0 (bit más bajo) estaba reservado (actualmente redefinido como control de congestión), 1-4 eran para el tipo de servicio y los bits 5-7 (bits más altos) para indicar la precedencia.
-r
-R
-s tamaño de paquete
-S sndbuf
-t ttl
-T opción de marca de tiempo
-U
-v
-V
-w fecha límite
-W tiempo de espera
Cuando se utilice ping para identificar errores, primero se debe ejecutar en el equipo local para verificar que la interfaz de red local esté activa y funcionando. Luego deberá ejecutarse “ping” en equipos y puertas de enlace cada vez más distantes. 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 pérdida, aunque el tiempo de ida y vuelta de estos paquetes se utiliza para calcular los números de tiempo de ida y vuelta mínimo/promedio/máximo/mdev.
Desviación estándar de la población (mdev), promedio de la distancia entre cada RTT de ping y el RTT promedio. Cuanto mayor es mdev, más variable es el RTT (con el tiempo). Con una alta variabilidad de RTT, tendrá problemas de velocidad con las transferencias masivas (tomarán más tiempo de lo estrictamente necesario, ya que la variabilidad hará que el remitente espere los ACK) y tendrá una calidad de VoIP mediocre o mala. .
Se mostraráun breve resumen cuando se ha enviado (y recibido) la cantidad definida de paquetes o si el programa finaliza con un SIGINT.. Con las señal SIGQUIT, se pueden obtener estadísticas actualizadas más resumidas sin finalizar el proceso.
La finalidad de este programa es el de ser utilizado en la comprobación, medición y mantenimiento de redes. Debido a la sobrecarga de la red que supone su uso, no resulta muy adecuado usar ping durante las operaciones normales o en scripts automáticos.
ESTADO DE SALIDA¶
Si ping no recibe ningún paquete de respuesta, finalizará con el código 1. Si se especifican un paquete cuenta y límite de tiempo, y se reciben menos de cuenta paquetes cuando finaliza el tiempo de espera, también saldrá con el código 1. En caso de otro error, sale con el código 2. Si todo sale bien, finaliza con el código 0. Esto hace que se pueda saber si un equipo está vivo o no mediante el código de salida.
ENLACE IPV6-DESTINOS LOCALES¶
Para IPv6, cuando la dirección de destino tiene un alcance de enlace local y ping utiliza sockets de datagramas ICMP, se debe definir la interfaz de salida. Cuando ping utiliza raw sockets, no es estrictamente necesario especificar la interfaz de salida, pero debería hacerse para evitar ambigüedades cuando podrían confundirse múltiples interfaces de salida.
Hay dos formas de definir la interfaz de salida:
• mediante el símbolo %
ping fe80::5054:ff:fe70:67bc%eth0
ping fe80::5054:ff:fe70:67bc%2
• mediante la opción -I
DETALLES DE LOS PAQUETES ICMP¶
Un encabezado IP sin ninguna opción tiene 20 bytes. Un paquete ICMP ECHO_REQUEST contiene 8 bytes adicionales de encabezado ICMP seguidos de una cantidad arbitraria de datos. Cuando se proporciona un tamaño_de_paquete, se referirá al tamaño de estos datos adicionales (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 mayor que el espacio de datos solicitado (por el encabezado ICMP).
Si los datos ocupan al menos el tamaño de struct timeval ping emplea los bytes iniciales de este espacio para incluir una marca de tiempo que se usará en el cálculo de los tiempos de ida y vuelta. Si el espacio de datos es más corto, no se dan tiempos de ida y vuelta.
PAQUETES DUPLICADOS Y DAÑADOS¶
ping informará de los paquetes duplicados y dañados. Nunca debe de aparecer ningún paquete duplicado. Éstos aparecen por retransmisiones inapropiadas a nivel de conexión. Los paquetes duplicados pueden aparecer en muchas situaciones y rara vez (por no decir nunca) son buena señal, aunque la aparición de unos pocos duplicados no ha de considerarse siempre una señal de alarma.
Los paquetes dañados constituyen obviamente una causa de alarma y normalmente indican que hay hardware dañado en alguna lugar de la ruta seguida por el paquete ping, bien sea en la red o en los equipos.
COLISIONES DE IDENTIFICACIÓN¶
A diferencia de TCP y UDP, que utilizan el puerto para identificar de forma única al destinatario para entregar los datos, ICMP utiliza el campo de identificador (ID) para dicha identificación. Por lo tanto, si en el mismo equipo, al mismo tiempo, dos procesos de ping utilizan el mismo ID, la respuesta de eco puede entregarse a un destinatario equivocado. Este es un problema conocido debido al tamaño limitado del campo ID de 16 bits. Esa es una limitación original del protocolo que no es posible solucionar salvo que se codifique una identificación en la carga útil del paquete de ping. ping mostrará el error DIRECCIÓN DIFERENTE y la pérdida de paquetes saldrá con valor negativo.
ping usa PID para obtener un número único. El valor predeterminado de /proc/sys/kernel/pid_max es 32768. Si se utiliza mucho ping y con pid_max superior a 65535, es probable que se produzcan colisiones.
PRUEBAS CON DIFERENTES PATRONES DE DATOS¶
La capa de red nunca debe tratar los paquetes de manera diferente dependiendo del contenido de la porción de datos. Desafortunadamente, se sabe que los problemas dependientes de los datos se cuelan en las redes y suelen pasar desapercibidos durante mucho tiempo. En muchos casos, el patrón particular que tendrá problemas es algo que no tiene suficientes “transiciones”, por ejemplo todos unos o todos ceros, o un patrón similar como por ejemplo casi todos zeros. NO es necesariamente es suficiente definir un patrón de datos de todos ceros (por ejemplo) en la línea de órdenes porque el patrón que es de interés está en el nivel de enlace de datos y la relación entre lo que se teclea y lo que realmente transmiten los controladores puede ser complicada.
Esto significa que si existe un problema relacionado con los datos puede ser necesario hacer muchas pruebas para detectarlo. Con suerte, se encontrará un archivo que, o bien no se puede transmitir por la red, o que tarda mucho más en enviarse que otros archivos de tamaño similar. En ese caso, deberia examinarse este archivo en busca de patrones repetidos que se pueden comprobar con la opción -p.
DETALLES DEL TTL¶
El valor TTL de un paquete IP representa el número máximo de routers IP que un paquete puede atravesar antes de ser deshechado. En el trabajo diario, lo normal es que cada router en internet reste exactamente uno del campo TTL.
El campo TTL para paquetes TCP puede tener varios valores. El valor máximo posible es de 255. Un valor inicial recomendado sería el 64. Para obtener más información, consulte la sección TCP/Interfaz de nivel inferior de RFC9293.
ping muestra el valor TTL del paquete que recibe. Cuando un sistema remoto recibe un paquete ping, tiene tres posibles opciones para actuar sobre el campo TTL en su respuesta:
ERRORES¶
VÉASE TAMBIÉN¶
HISTORIAL¶
La orden ping apareció en 4.3BSD.
La versión descrita aquí es su descendiente específico para Linux.
A partir de la versión s20150815, el binario ping6 ya NO EXISTE como tal, sino que se ha fusionado con ping. Si se crea un enlace simbólico llamado ping6 que apunte a ping tendrá la misma funcionalidad que antes.
SEGURIDAD¶
ping requiere que se ejecute la capacidad CAP_NET_RAW 1) Si el programa se usa para consultas sin eco (ver opción -N) o cuando el campo de identificación está definido en 0 para ECHO_REQUEST (ver -e). 2) Si el kernel no soporta sockets de datagramas ICMP. 3) Si el usuario no tiene permiso para crear un socket de eco ICMP. El programa se puede utilizar como set-uid root.
DISPONIBILIDAD¶
ping es parte del paquete iputils.
TRADUCCIÓN¶
La traducción al español de esta página del manual fue creada por Antonio Aneiros <aneiros@ctv.es> y Marcos Fouces <marcos@debian.org>
Esta traducción es documentación libre; lea la GNU General Public License Version 3 o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD.
Si encuentra algún error en la traducción de esta página del manual, envíe un correo electrónico a debian-l10n-spanish@lists.debian.org.
iputils 20240117 |