Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
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.
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
Remarque : le service d'inventaire peut également se composer de deux pod en cours d'exécution. Vous devez donc spécifier un pod unique dans les commandes en utilisant le nom complet du pod d'inventaire, y compris l'ID du pod.
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 :
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.
Remarque : pour plus d'informations sur les fonctions d'inventaire dans Cisco DNA Center, consultez le guide officiel de la version 2.3.5.x : Gérer votre inventaire
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 :
Conseil : le retrait du périphérique réseau et sa redécouverte à l'aide de l'interface de ligne de commande (CLI), des identifiants SNMP et NETCONF corrects peuvent aider à supprimer les entrées de base de données obsolètes qui pourraient être à l'origine de l'erreur interne.
Conseil : l'examen des journaux du service d'inventaire et le filtrage par adresse IP ou nom d'hôte du périphérique peuvent être utiles pour identifier la cause première de l'erreur interne.
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 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 :
(config)#netconf-yang
(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.
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.
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.
Conseil : si vous souhaitez apprendre à utiliser Grafana, consultez le guide officiel : Execute Postgres Queries in Cisco DNA Center GUI
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 :
Avertissement : seul le TAC Cisco est autorisé à exécuter des requêtes show dans l'interpréteur de commandes Postgres et seules les équipes BU/DE sont autorisées à apporter des modifications aux tables DB.
Remarque : les problèmes de base de données peuvent également entraîner le message d'erreur interne pour les périphériques, ce qui peut empêcher la collecte de données et le provisionnement des périphériques.
Conseil : vous pouvez consulter les journaux Postgres à l'aide de Kibana dans la page Cisco DNA Center System 360 et rechercher des violations de contraintes lorsque le service d'inventaire tente d'enregistrer ou de mettre à jour des entrées dans les tables de base de données Postgres.
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.
Remarque : ce type de boucles de synchronisation en raison de déroutements massifs peut entraîner l'authentification de Cisco DNA Center plusieurs fois en un court laps de temps aux périphériques qui envoient les déroutements en raison des modifications détectées.
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.
Conseil : vous pouvez obtenir l'uuid du périphérique à partir de l'URL du navigateur (deviceid ou id) à partir de la page Cisco DNA Center Inventory Device Details ou de la page Device View 360.
Remarque : pour plus d'informations sur les API dans Cisco DNA Center, consultez le guide Cisco DevNet API Guide
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.
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
Remarque : si aucun fichier de vidage de mémoire n'a été trouvé dans le répertoire du conteneur, aucun état de blocage n'est présent dans le conteneur.
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.
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.
Conseil : vous pouvez obtenir l'uuid du périphérique à partir de l'URL du navigateur (deviceid ou id) à partir de la page Cisco DNA Center Inventory Device Details ou de la page Device View 360.
Remarque : pour plus d'informations sur les API dans Cisco DNA Center, consultez le guide Cisco DevNet API Guide
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
24-Jul-2023 |
Première publication |