Comment puis-je définir un court délai d'attente avec la commande ping ?

Si tous vos hôtes se trouvent sur le réseau local physique, vous pouvez utiliser l'outil arp ping, qui fait la même chose mais utilise des paquets arp de couche 2 pour effectuer le "ping". Vous pouvez utiliser une combinaison de arp et icmp ping, ou en fait tcp ping, pour déterminer la cause de la panne. Par exemple, un plantage de la pile tcp, bien que rare de nos jours, nous pourrions trouver si la pile tcp d'une machine s'est plantée, car la machine ne répondrait pas à ping, mais elle répondrait à arp (qui est un morceau de code différent sur l'hôte).

en utilisant une combinaison de arpping, tcpping, et icmp ping vous pouvez découvrir si le service sur la machine a planté, la pile tcp a planté, ou la machine s'est complètement bloquée. Si vous avez des commutateurs Ethernet gérés, vous pouvez obtenir des données de liaison physique, révélant si la machine est réellement allumée ou si elle a été physiquement débranchée. Nous avons eu une situation où des machines (des clients dans des salles publiques) étaient éteintes, nous avons recueilli ces données et envoyé des paquets de réveil en lan, pour rallumer les machines. :-)

Quelles que soient les solutions que vous mettez en place, si votre réseau est occupé, pensez à implémenter une sorte de qos, afin que vos paquets de surveillance soient prioritaires sur le réseau, la perte de paquets de mesure due à la congestion du réseau peut donner de fausses alarmes. Si vous utilisez la qualité de service pour les paquets de surveillance, vous devrez alors penser à collecter des données sur l'utilisation du réseau.

Ainsi, vous pouvez rendre votre solution de surveillance aussi complexe ou aussi simple que vous le souhaitez. Nous trouvons que même le système de surveillance le plus élémentaire est un pas dans la bonne direction, au moins un administrateur garde un œil sur les machines :-).

Bonne chance !

@jordon-bedwell a une super suggestion.

@laszlo-valko https://stackoverflow.com/questions/20359487/why-does-ping-not-timeout-in-linux explique que les délais de ping ne commencent qu'après la détermination de l'adresse IP. Si vous utilisez un dns et que votre station de travail est hors ligne, ping ne peut pas déterminer l'adresse IP et semble donc attendre environ 20+secs par défaut avant de renvoyer un faux.

L'utilisation de l'outil linux 'timeout' permet de mieux contrôler l'exécution de ping avec un nom de domaine.

Merci les gars

Sous macOS, pour définir le temps que ping attend pour une réponse du serveur avant de décider qu'il s'agit d'une non-réponse (délai d'attente), il suffit de -t :

ping -t 1 -c 1 host

Si vous pouvez scanner votre sous-réseau (ou une partie de celui-ci) sans déclencher d'alarmes de sécurité, et si vous n'êtes pas contre un peu de données supplémentaires, Scanner IP en colère est rapide, gratuit, vous permet de cliquer pour trier par statut, et peut fournir des informations plus détaillées.

Pourquoi ne pas lancer ping en arrière-plan, avec sortie dans un fichier temporaire, en parallèle pour chaque hôte ? Ensuite, il suffit de dormir pendant une seconde, de tuer tous les processus ping qui sont encore en cours d'exécution, et de lire les fichiers pour recueillir les résultats.