¿Qué proceso de Linux es responsable de responder a los pings?

Tengo un controlador de proceso basado en Linux que ocasionalmente se bloquea hasta el punto en el que no puede hacer ping (es decir, puedo hacer ping, luego ya no se puede hacer ping sin modificaciones en la configuración de la red).

Tengo curiosidad, ¿qué proceso / sistema es responsable de responder realmente a los pings? Parece que este proceso se está bloqueando.

network-interface ping icmp

— Izzo
fuente

¿Todavía puedes atravesarlo mientras no responde a los pings? ¿O se bloquean las sesiones SSH existentes?

— Peter Cordes

@PeterCordes Todo el sistema se bloquea y es esencialmente un ladrillo hasta forzar un reinicio.

— Izzo

Ok, esa es normalmente la única forma en que una máquina deja de responder a los pings. Sería extraño si los pings dejaran de funcionar pero otras cosas siguieran funcionando, porque el manejo del ping funciona incluso si el espacio del usuario está regado y todo está bloqueado en la E / S del disco a un disco muerto o montaje NFS o lo que sea. Intente conectar un monitor a su sistema y vea si hay un mensaje de consola mientras se bloquea. (Y si puede usar las secuencias mágicas del teclado SysRQ para volcar información, o volver a montar solo, forzar la sincronización de los discos + reiniciar.

— Peter Cordes

Si bien su pregunta es interesante, el ping no es la fuente de los problemas de su sistema, sino más bien una consecuencia de un sistema inestable. Verifique los registros para comprender qué está mal.

— Pedro Lobito

@PedroLobito ¿Qué registros específicamente?

— Izzo

Respuestas:

La pila de red del núcleo maneja los mensajes ICMP, que son los que envía el pingcomando.

Si no recibe respuestas, además de problemas de red o filtrado, y filtrado basado en host / limitación de velocidad / black-holing / etc. significa que la máquina probablemente esté sobrecargada por algo, que puede ser transitorio, o que el kernel se bloquee, lo cual es raro pero puede suceder (hardware defectuoso, etc.), no necesariamente por el tráfico ICMP (sino por tratar de sobrecargarlo con dicho tráfico) puede ser una buena prueba al comienzo de la vida de un servidor para ver cómo sostiene las cosas). En el último caso de bloqueo del kernel, debe tener amplia información en los archivos de registro o en la consola.

También tenga en cuenta que pingcasi siempre es la herramienta incorrecta para verificar si un servicio está en línea o no. Por varias razones, pero principalmente porque no imita el tráfico real de las aplicaciones, por definición. Por ejemplo, si necesita verificar que un servidor web aún esté activo, debe realizarle una consulta HTTP (puerto TCP 80 o 443), si necesita verificar un servidor de correo, debe realizar una consulta SMTP (puerto TCP 25), si un servidor DNS, una consulta UDP y TCP al puerto 53, etc.

— Patrick Mevzek
fuente

@Outurnate cualquier otra prueba de servicio de la aplicación fallará o quedará en un tiempo de espera, por lo que el resultado final observado será el mismo. Nunca pierdo la oportunidad de dar una conferencia contra el uso, pingya que esto crea demasiados falsos positivos en la resolución de problemas, por lo que creo que los usuarios que no saben exactamente qué hace el ping y cómo puede dar resultados engañosos deberían apegarse a otra cosa.

— Patrick Mevzek

En la mayoría de las situaciones de sobrecarga, las únicas cosas que aún responden son las realizadas por el núcleo. Eso significa que una máquina generalmente responderá al ping independientemente de cuán sobrecargada esté. Los intentos de llegar a un puerto cerrado responderán con RST para TCP y un error ICMP en caso de UDP. Y los primeros intentos de llegar a un puerto TCP abierto completarán un apretón de manos. Una falla de disco puede conducir a los mismos síntomas.

— kasperd

@kasperd He visto (muy) servidores sobrecargados (intercambiando los específicamente) que tampoco responden a las solicitudes ICMP. Y por supuesto a nada más también. El kernel no se bloqueó, solo estaba ocupado en cosas de E / S de disco.

— Patrick Mevzek

@Nacht Yup. Una interfaz de red es un dispositivo HW; Como tal, hay un controlador de kernel para interactuar con él. Una segunda capa proporciona API de gestión / comunicación genéricas. (Esto no es exclusivo de las redes: hay ALSA para desarrolladores de audio, las salidas de video usan la API KMS, USB tiene {U, E, X} HCI, luego usb_storage, usbhid, etc.) Tablas de enrutamiento de red, reglas de firewall (a través de iptables ), el protocolo de enlace, el ensamblaje de paquetes, las retransmisiones, etc. están todos en el núcleo. Dado que ICMP es un protocolo en sí mismo, sin carga útil y sin procesamiento más allá de "responder o no", el núcleo maneja las respuestas ICMP directamente para una sobrecarga mínima.

— FeRD

@Nacht: No se trata realmente de una arquitectura informática fundamental; Es una opción de implementación. Los microkernels manejarán ICMP en un proceso del sistema operativo.

— MSalters

No hay un proceso de usuario responsable de responder a los pings. Ping es solo una utilidad para enviar paquetes de eco ICMP. Estos son recibidos y procesados por la pila de red del núcleo

— Outurnate
fuente

El propio núcleo (no cualquier proceso de usuario) es responsable de enviar ICMP Echo Reply mensajes en respuesta a la solicitud de eco ICMP mensajes. Entonces, si un host deja de responder a pings, generalmente se debe a algunas de las siguientes razones:

la conectividad de red entre usted y el host que se está haciendo ping podría haberse cortado. Podría deberse a toneladas de razones en sí: daños físicos a los cables, ruido en el caso de la conexión inalámbrica, tablas de rutas rotas, estar bajo ataque DDoS, enrutadores / conmutadores problemáticos entre etc. Comenzaría a solucionar problemas en este caso al usando ethtool(8), iwconfig(8), route(8), ping(8)su router, tcpdump(8)etc. en el host de destino.
La configuración del firewall en el host de destino (o cualquier enrutador / firewall entre usted y el host de destino) puede estar limitando la cantidad de pings (o la cantidad de tráfico). También podría deberse a herramientas como fail2ban(8)cortafuegos bajo demanda. Ver iptables(8)para verificar.
ha habido un mal funcionamiento del software / hardware en el host de destino El módulo del kernel de red en el host de destino podría haber OOPSed y / o confundirse, o incluso el kernel completo podría haber PANICked. Verá mensajes sobre en dmesg(8)el host de destino, o como salida de pantalla en la consola física (si el acceso físico no es práctico, otra máquina con consola serie puede ayudar). Si el kernel OOPS / PANIC es el problema, un kernel más nuevo con mejores controladores podría ayuda, o podría analizar los bloqueos del sistema con watchdog(8)controladores auxiliares. O puede cambiar partes de hardware.

— Matija Nalis
fuente

Para los interesados, aquí está el código de kernel relevante para manejar solicitudes de eco ICMP.

— Ruslan

También debe mencionar la carga muy alta (especialmente CPU)

— Guilherme Bernal

@GuilhermeBernal no, incluso una carga de usuario de CPU extremadamente alta (en miles) no conducirá a la pérdida de ICMP (porque se sirve en el núcleo, antes de que los procesos del usuario tengan la oportunidad de ejecutarse). La tasa PPS de red extremadamente alta en combinación con hardware de gama baja puede causar la pérdida de paquetes, pero dicho DDoS cae en la categoría de "conectividad de red"

— Matija Nalis