Ce playbook décrit les étapes pour résoudre les problèmes lorsque la surveillance LAN est configurée et que le cloud Cato n'arrive pas à atteindre un hôte derrière un site.
La fonction de surveillance LAN permet de définir des hôtes derrière un site par leur adresse IP, et le seuil de défaillance pour l'hôte (le nombre maximum de tests ICMP consécutifs échoués). Un PoP dans le cloud Cato envoie des tests ICMP à l'hôte, si l'hôte ne répond pas au nombre spécifié de tests ICMP, il est considéré comme hors service et un événement est automatiquement généré. Vous pouvez également choisir d'envoyer une notification par e-mail lorsqu'un hôte est inaccessible.
Lorsque la connectivité entre l'hôte et le PoP est rétablie, un nouvel événement est généré indiquant que l'hôte est accessible.
Pour plus d'informations, consultez Travailler avec la surveillance LAN pour un site.
Voici les différentes manières pour un administrateur de l'application de gestion Cato de vérifier qu'un hôte surveillé est devenu inaccessible au PoP de surveillance :
-
Accédez à la page Stories Workbench et utilisez le préréglage Network XDR pour trouver les histoires LAN surveillance hôte inaccessible.
L'histoire fournit des informations sur l'état actuel du site, une chronologie de l'incident, et plus encore.
-
Événement de surveillance LAN avec l'action Hôte Inaccessible
-
Utilisez le filtre préréglé Hôtes LAN inaccessibles et ajustez la plage de temps si nécessaire
-
-
Notification par e-mail de la surveillance LAN
-
Lorsque les notifications par email sont activées pour une règle de surveillance LAN, des emails sont envoyés à la liste de diffusion (peut inclure des non-administrateurs)
-
Lorsque vous répondez aux histoires des opérations de site, il est important d'aborder le problème en vérifiant d'abord que le problème est en cours, puis en le défiant et enfin vérifier que le problème est résolu.
Cette section aborde différents outils Cato que vous pouvez utiliser pour vérifier la raison pour laquelle l'hôte est inaccessible.
Utilisation du préréglage des événements de surveillance LAN
L'utilisation du filtre d'événements préréglé de surveillance LAN nous permet de vérifier le dernier événement lié à l'hôte en question. Si cet événement n'est pas suivi d'un événement indiquant que la connectivité est revenue, cela suggère que l'hôte est toujours inaccessible.
Afficher l'histoire pour l'état actuel
L'histoire elle-même peut également être utilisée pour déterminer l'inaccessibilité continue d'un hôte. L'état actuel de l'histoire est répertorié sur le tableau de bord. Un statut d'histoire ouvert montre que cet événement est toujours en cours.
Étape 2 - Dépannage de la connectivité de l'hôte
Cette section aborde des outils au sein de Cato qui peuvent être utilisés pour suivre une approche de dépannage structurée pour ce type d'incident. Ces étapes doivent être suivies généralement dans l'ordre, mais les résultats de ces vérifications peuvent déterminer quelle pourrait être la prochaine étape.
Examinez les modifications dans la page de journal d'audit de l'application de gestion Cato, et voyez s'il y a une configuration liée à ce problème. Si une configuration a directement conduit au changement de statut de l'hôte, envisagez d'annuler le changement.
Hôtes connus
La page Hôtes Connus dans le CMA (Réseau > Sites > {nom du site} > Surveillance du site > Hôtes Connus) peut être utilisée pour recueillir des informations sur les points de terminaison individuels vus dans un site. Cette information inclut l'ancienneté des derniers paquets vus provenant de cet hôte.
En général, les hôtes surveillés répondant aux paquets ICMP dans le cadre de la surveillance LAN actualiseront toujours ce minuteur. Un exemple comme celui ci-dessus suggère le timing de la perte de l'accessibilité de l'hôte. Cela peut fournir un contexte supplémentaire. Cette fenêtre temporelle correspond-elle à des périodes de maintenance prévues ou à des événements de courant qui peuvent avoir affecté la connectivité de l'hôte, ou à des changements de réseau dans l'environnement local, par exemple.
Vous pouvez utiliser le Socket WebUI pour pinger l'hôte depuis l'interface LAN. Pour plus d'informations, voir Utilisation des outils Socket WebUI.
-
Depuis le Socket WebUI, pinguez l'hôte avec ces paramètres :
-
Route via - LAN
-
Nom de l'hôte/IP - Adresse IP de l'hôte inaccessible
S'il n'y a pas de réponse au ping, le problème pourrait être lié au routage, ou l'hôte pourrait être généralement inaccessible, éteint ou non configuré pour répondre aux pings, par exemple.
-
-
-
Utilisez les outils Socket WebUI pour prendre un PCAP de l'interface LAN pendant qu'un ping vers l'hôte en question est en cours. Voyez s'il y a un ping bidirectionnel entre la socket et l'hôte.
L'exemple ci-dessus montre qu'il n'y a aucune réponse de la socket lorsqu'un ARPing pour l'adresse physique de l'hôte en question est effectué. Ceci implique que l'hôte est sur le même réseau local que la socket LAN, mais que l'hôte ne répond pas au niveau 2. Pour ce résultat, vérifiez que l'hôte est sous tension et prêt à répondre aux requêtes ARP.
L'exemple ci-dessus montre que la socket et les requêtes ICMP configurées par le PoP pour le suivi LAN à l'hôte surveillé. Notez l'adresse source 10.254.254.1 et le delta temps (10 secondes) entre les requêtes de surveillance LAN ICMP envoyées par le PoP. Le fait que la requête ICMP soit envoyée montre que l'adresse MAC soit du prochain sauteur soit de l'hôte final est utilisée pour envoyer ces requêtes. Vérifiez si cette adresse MAC suggère que l'hôte surveillé se trouve derrière une frontière de couche 3, ou est local au réseau LAN de la socket.
- Si l'hôte surveillé se trouve derrière une frontière de couche 3, commencez par enquêter sur la façon dont les requêtes ICMP sont gérées à cet endroit. Si la réponse ICMP de l'hôte atteint cet appareil de frontière de couche 3, il est probable qu'il s'agit d'un problème de routage à cette frontière de couche 3.
- Si l'hôte surveillé est sur le réseau LAN de la socket, il est probable que l'appareil soit éteint ou n'est pas configuré ou capable de répondre aux ICMP.
-
Après avoir remédié au problème avec l'hôte, vérifiez qu'il est accessible et dispose de la connectivité avec le cloud Cato.
Depuis la page des Hôtes Connus, affichez l'hôte et vérifiez que l'Dernière Activité de l'Hôte affiche des données pour l'heure actuelle.
Utilisez le Socket WebUI pour pinger l'hôte, en utilisant l'interface LAN pour vérifier que l'hôte dispose de la connectivité au site.
Après la restauration de la connectivité entre l'hôte et le cloud Cato, un événement Hôte Accessible est généré. Vous pouvez configurer manuellement le filtre d'événements pour Action EST Hôte Accessible pour afficher l'événement.
Soumission de cas au Support Cato
Si après avoir suivi ce playbook vous n'êtes pas en mesure de rectifier le problème, vous pouvez envisager de soumettre un ticket au Support Cato. Lors de cette étape, pour une résolution la plus rapide possible, il est important que vous incluiez tous les aperçus rassemblés en suivant les étapes ci-dessus.
Veuillez voir Soumettre un ticket de support
0 commentaire
Vous devez vous connecter pour laisser un commentaire.