Examiner le service d'inventaire du centre DNA et les problèmes courants

Introduction

Ce document décrit les concepts de base du service d'inventaire Cisco DNA Center et les problèmes courants rencontrés lors de la production.

Composants utilisés

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Détails du service d'inventaire

Le service d'inventaire Cisco DNA Center est basé sur un pod Kubernetes (K8s) qui s'exécute dans l'espace de noms « fusion » avec le nom « apic-em-inventory-manager-service-<id> » comme type d'environnement de déploiement.

À l'intérieur de la zone K8s, vous pouvez trouver un conteneur Docker appelé "apic-em-inventory-manager-service".

Les tâches principales de la zone "apic-em-inventory-manager-service" sont : Détection des périphériques et gestion du cycle de vie des périphériques.

Cela garantit que les données des périphériques sont disponibles dans Postgres SQL (base de données utilisée par les services de fusion).

L'espace de noms « fusion » (Appstack) également appelé NCP (Network Controller Platform) fournit les services SPF (Service Provisioning Framework) pour toutes les exigences d'automatisation du réseau.

Il s'agit notamment de la découverte, de l'inventaire, de la topologie, de la politique, de la gestion des images logicielles (SWIM), de l'archivage de la configuration, du programmeur réseau, des sites, du regroupement, de la télémétrie, de l'intégration Tesseract, du programmeur de modèles, des cartes, de l'IPAM, des capteurs, de l'orchestration/du workflow/de la planification, de l'intégration ISE, etc.

L'état du pod d'inventaire peut être vérifié en exécutant la commande : 

$ magctl appstack status | grep inventory

L'état du service d'inventaire peut être vérifié avec la commande :

$ magctl service status

Les journaux de service d'inventaire peuvent être vérifiés à l'aide de la commande :

$ magctl service logs -r

Dans ce document, nous pouvons nous concentrer sur l'état de gestion et de dernière synchronisation des périphériques d'inventaire pour examiner les problèmes courants :

État de gérabilité

• Géré avec une coche verte : le périphérique est accessible et entièrement géré.
• Géré avec l'icône d'erreur orange : Le périphérique est géré avec une erreur telle que inaccessible, échec d'authentification, ports Netconf manquants, erreur interne, etc. Vous pouvez placer le curseur sur le message d'erreur pour afficher plus de détails sur l'erreur et les applications affectées.
• Non géré : le périphérique est inaccessible et aucune information d'inventaire n'a été collectée en raison de problèmes de connectivité du périphérique.

Dernier état de synchronisation

• Géré : le périphérique est dans un état entièrement géré.

• Échec de la collecte partielle : le périphérique est dans un état de collecte partielle et toutes les informations d'inventaire n'ont pas été collectées. Placez le curseur sur l'icône Informations (i) pour afficher des informations supplémentaires sur l'échec.

• Inaccessible : le périphérique est inaccessible et aucune information d'inventaire n'a été collectée en raison de problèmes de connectivité du périphérique. Cette condition se produit lorsque la collecte périodique a lieu.

• Informations d'identification incorrectes : si les informations d'identification du périphérique sont modifiées après l'ajout du périphérique à l'inventaire, cette condition est notée.

• En cours : Collecte d'inventaire en cours.

Problèmes

Internal Error

La page d'inventaire de Cisco DNA Center peut afficher un message d'avertissement dans l'état de gérabilité pour les périphériques présentant un type de conflit empêchant la collecte de données : 

"Erreur interne : NCIM12024 : toutes les informations du périphérique n'ont pas pu être collectées correctement ou la collecte d'inventaire pour ce périphérique n'a pas encore commencé. Il peut s'agir d'un problème temporaire pouvant être résolu automatiquement. Resynchronisez le périphérique. Si cela ne résout pas le problème, contactez le TAC Cisco."

Si l'erreur ne se résout pas automatiquement ou après une resynchronisation du périphérique, nous pouvons commencer par le dépannage initial. Cette erreur peut être due à plusieurs raisons, mais ici, nous énumérons quelques-unes des plus courantes : 

• Identifiants de périphérique incorrects pour SNMP, SSH et Netconf.
• Problèmes de connectivité réseau liés à SNMP, SSH et Netconf.
• Des problèmes de configuration Netconf dans le périphérique provoquent un dysfonctionnement de Netconf.
• Déclenchez la resynchronisation d'un périphérique alors qu'elle est déjà en cours. 
• Plusieurs déroutements ont été reçus du périphérique, entraînant plusieurs déclencheurs de resynchronisation en peu de temps.
• Problèmes de back-end avec les entrées de la base de données d'inventaire dans plusieurs tables liées au périphérique.

Identifiants des périphériques

Pour vérifier les informations d'identification des périphériques, accédez au menu Cisco DNA Center -> Provisionner -> Inventaire -> Sélectionner un périphérique -> Actions -> Inventaire -> Modifier un périphérique et cliquez sur "Valider" et vérifiez que les informations d'identification obligatoires (CLI et SNMP) sont validées par une coche verte (y compris netconf si elle s'applique).

Si la validation échoue, vérifiez que le nom d'utilisateur et le mot de passe que Cisco DNA Center utilise pour gérer le périphérique réseau sont valides directement dans la ligne de commande du périphérique.

S'ils sont configurés localement ou s'ils sont configurés dans un serveur AAA (TACACS ou RADIUS), vérifiez que le nom d'utilisateur et le mot de passe sont correctement configurés dans le serveur AAA.

Vérifiez également si le privilège de nom d'utilisateur nécessite la configuration du mot de passe "Enable" dans les paramètres d'identification du périphérique dans Cisco DNA Csaisissez Stock.

Les erreurs dans les informations d'identification CLI peuvent entraîner un message d'erreur de gérabilité dans Inventory : CLI Authentication Failure.

Netconf

Netconf est un protocole permettant de gérer à distance un périphérique réseau compatible via les appels de procédure distante (RPC).

Cisco DNA Center utilise les fonctionnalités Netconf pour pousser ou supprimer la configuration sur les périphériques réseau afin d'activer des fonctionnalités telles que la surveillance via Assurance.

L'inventaire Cisco DNA Center peut également valider que les exigences Netconf sont correctes, ce qui inclut :

• Le port par défaut 830 de la commande Netconf doit être ouvert et fonctionnel sur le réseau.
• Utilisateur disposant du privilège 15 avec accès SSH au périphérique réseau (configuré localement ou AAA).
• Activez Netconf dans le périphérique réseau :

(config)#netconf-yang

• Si aaa new-model est activé, vous devez également configurer les exigences des paramètres AAA par défaut :

(config)#aaa authorization exec default 
     
(config)#aaa authentication login default 
     

Des erreurs dans les informations d'identification Netconf peuvent provoquer un message d'erreur de gérabilité dans Inventory : Netconf Connection Failure.

Contrôles réseau

Nous pouvons également valider les paramètres de connectivité réseau et de protocoles, tels que les paramètres SNMP, en fonction de la version.

Par exemple, nous pouvons vérifier les paramètres de communauté, d'utilisateur, de groupe, d'ID de moteur, d'authentification et de cryptage, etc. en fonction de la version SNMP. 

Nous pouvons également examiner la connectivité SSH et SNMP en utilisant les commandes ping et traceroute dans la ligne de commande du périphérique et les ports pour SSH (22) et SNMP (161 et 162) dans le pare-feu, le proxy ou les listes d'accès.

À partir de Cisco DNA Center, maglev CLI, nous utilisons les commandes ip route pour valider la connectivité au périphérique réseau.

La marche SNMP peut également être utilisée pour le dépannage.

Les erreurs dans les informations d'identification SNMP peuvent entraîner un message d'erreur de gérabilité dans l'inventaire : Échec d'authentification SNMP ou Périphérique inaccessible.

Tables de base de données

En tant qu'utilisateur final, vous pouvez utiliser l'interface graphique de Cisco DNA Center avec Grafana pour exécuter des requêtes SQL afin de ne pas avoir besoin d'accéder à l'interpréteur de commandes Postgres via maglev CLI.

Voici quelques tables de base de données postgres à consulter en cas de problèmes avec les périphériques réseau dans l'inventaire :

• périphérique réseau
• interface d'élément géré
• élément de réseau
• ressource du réseau
• appareil
• adresse IP

Boucle et déroutements de synchronisation

Cisco DNA Center est conçu pour exécuter un périphérique Resycn chaque fois qu'il reçoit un piège du périphérique après qu'une modification majeure a été effectuée sur le périphérique lui-même afin de maintenir l'inventaire Cisco DNA Center à jour. Parfois, la page d'inventaire de Cisco DNA Center maintient vos périphériques réseau à l'état "Synchronisation" dans la section Facilité de gestion pendant une longue période ou pour toujours.

API pour forcer la synchronisation des périphériques

Si votre périphérique réseau conserve l'état Synchronisation trop longtemps, voire plusieurs jours, vérifiez d'abord les vérifications de base de l'accessibilité et de la connectivité. Forcez ensuite la resynchronisation du périphérique via l'appel API :

1.- Ouvrez la session Cisco DNA Center maglev CLI.

2.- Obtenez le jeton d'authentification Cisco DNA Center via l'API :

curl -s -X POST -u admin  https://kong-frontend.maglev-system.svc.cluster.local/api/system/v1/identitymgmt/token

3.- Utilisez le jeton de l'étape précédente pour exécuter l'API pour forcer la synchronisation du périphérique :

curl -X PUT -H "X-AUTH-TOKEN: 
     
       " -H "content-type: application/json" -d ' 
      
        ' https:// 
       
         /api/v1/network-device/sync-with-cleanup?forceSync=true --insecure 
        
       
     

4.- Vous pouvez voir le périphérique dans Synchronisation une fois de plus, mais cette fois avec une option Force Sync via l'API.

Vérifier les déroutements

Si le problème persiste après avoir forcé la tâche de synchronisation dans le périphérique, nous pouvons vérifier si le "service d'événements" Cisco DNA Center reçoit trop de déroutements et vérifier quel type de déroutements en lisant les journaux de service d'événements :

1.- Avant de lire les journaux, il suffit de vérifier le nombre total de déroutements à l’aide de la commande :

$ echo;echo;eventsId=$(docker ps | awk '/k8s_apic-em-event/ {print $1}'); docker cp $eventsId:/opt/CSCOlumos/logs/ /tmp/;for ip in $(awk -F\: '/ipAddress / {print $4}' /tmp/logs/ncs* | sort | uniq);do for trap in $(grep -A10 $ip /tmp/logs/ncs* | awk -F\= '/trapType/ {print $2}');do tStamp=$(grep -A10 $ip /tmp/logs/ncs* | awk '/trapType/ {print $2,$3}'); echo "$ip - $trap "| grep -E "^([0-9]{1,3}[\.]){3}[0-9]{1,3}" | awk -F\. '{print $1,$2,$3,$4}';done;done | sort | uniq -c | grep -v address| sort -bgr > /home/maglev/trapCounter.log &

2.- Ensuite, nous attachons au conteneur event-service :

$ magctl service attach -D event-service

3.- Une fois que vous êtes entré dans le conteneur event-service, changez de répertoire pour le dossier logs :

 $ cd /opt/CSCOlumos/logs/

4.- Si vous examinez les fichiers à l'intérieur du répertoire, vous pouvez voir certains fichiers journaux dont le nom commence par "ncs".

Exemple :

root@apic-em-event-service-586df7d4b8-f9c74:/opt/CSCOlumos/logs# ls -l
total 90852
drwxr-xr-x 1 maglev maglev     4096 May  9 21:33 ./
drwxr-xr-x 1 maglev maglev     4096 Apr 29 17:56 ../
-rw-r--r-- 1 root root 2937478 May 9 21:37 ncs-0-0.log -rw-r--r-- 1 root root 0 Apr 29 23:59 ncs-0-0.log.lck -rw-r--r-- 1 root root 10002771 May 9 21:33 ncs-1-0.log -rw-r--r-- 1 root root 10001432 May 9 21:16 ncs-2-0.log -rw-r--r-- 1 root root 10005631 May 9 21:01 ncs-3-0.log -rw-r--r-- 1 root root 10000445 May 9 20:47 ncs-4-0.log -rw-r--r-- 1 root root 10000507 May 9 20:33 ncs-5-0.log -rw-r--r-- 1 root root 10003091 May 9 20:21 ncs-6-0.log -rw-r--r-- 1 root root 10001058 May 9 20:06 ncs-7-0.log -rw-r--r-- 1 root root 10001064 May 9 19:53 ncs-8-0.log -rw-r--r-- 1 root root 10000572 May 9 19:39 ncs-9-0.log
-rw-r--r-- 1 root   root        424 Apr 30 00:01 nms_launchout.log
-rw-r--r-- 1 root   root        104 Apr 30 00:01 serverStatus.log

5.- Ces fichiers "ncs" sont ceux dont nous avons besoin pour analyser le type de pièges que nous recevons et combien. Nous pouvons examiner les fichiers journaux en les filtrant par nom d'hôte du périphérique ou par le mot clé « trapType » :

root@apic-em-event-service-586df7d4b8-f9c74:/opt/CSCOlumos/logs# grep trapType ncs*.log
root@apic-em-event-service-586df7d4b8-f9c74:/opt/CSCOlumos/logs# grep 
     
       ncs*.log 
     

Il y a trop de types d'interruptions, certaines peuvent déclencher la resynchronisation du périphérique et si elles arrivent trop souvent, elles peuvent provoquer la boucle de synchronisation.

En analysant les déroutements, nous pouvons identifier la cause première et faire en sorte que les déroutements s'arrêtent, par exemple un AP dans un cycle de redémarrage.

Vous pouvez enregistrer le résultat des déroutements dans un fichier et les partager avec l'équipe de remontée si nécessaire. 

État de blocage du service

Si vous pensez que le pod d'inventaire tombe en panne en raison d'un comportement étrange dans la page d'inventaire de Cisco DNA Center lors de la gestion des périphériques réseau, vous pouvez d'abord valider l'état du pod :

$ magctl appstack status | grep inventory

$ magctl service status 
     
         
     

En examinant le résultat de l'état de la zone, si vous voyez un nombre élevé de redémarrages ou un état d'erreur, vous pouvez attacher au conteneur d'inventaire et collecter le fichier de vidage de la pile qui peut avoir les données qui peuvent aider l'équipe de remontée d'urgence à analyser et définir la cause première de l'état de blocage :

$ magctl service attach -D 
     

root@apic-em-inventory-manager-service-76f7f8d7f5-427m5:/# ll /opt/maglev/srv/diagnostics/ | grep heapdump
-rw-r--r-- 1 root root 1804109 Jul 20 21:16 apic-em-inventory-manager-service-76f7f8d7f5-427m5.heapdump

Impossible de supprimer un périphérique

Dans certaines situations, Cisco DNA Center peut ne pas être en mesure de supprimer un périphérique réseau de l'interface utilisateur d'inventaire en raison d'un problème de back-end.

API pour forcer la suppression du périphérique

Si vous ne parvenez pas à supprimer le périphérique de l'inventaire à l'aide de l'interface utilisateur graphique de Cisco DNA Center, vous pouvez utiliser l'API pour supprimer le périphérique par ID :

1.- Accédez au menu Cisco DNA Center -> Plate-forme -> Developer Toolkit -> onglet API et recherchez Devices dans la barre de recherche. À partir des résultats, cliquez sur Devices dans la section Know your network et recherchez l'API DELETE by Device Id.

2.- Cliquez dans l'API DELETE by Device Id, cliquez sur Try et fournissez l'ID du périphérique souhaité à supprimer de l'inventaire.

3.- Attendez que l'API s'exécute et obtenez une réponse 200 OK, puis vérifiez que le périphérique réseau n'est plus présent dans la page d'inventaire.