Dépannage des erreurs externes NSO NED

Introduction

Ce document décrit comment analyser les traces NED de type générique et CLI et identifier la cause des erreurs externes dans Cisco Crosswork NSO.

Conditions préalables

Exigences

• L'aspect dépannage de ce document s'applique à toutes les versions NED (Network Element Driver) et NSO (Crosswork Network Service Orchestrator) de Cisco® actuellement prises en charge.
• Afin de dépanner les erreurs externes de NED, vous devez pouvoir activer les journaux de suivi de NED et avoir accès à ces journaux.
• Afin d'évaluer avec précision les erreurs externes du NED, il est recommandé de connaître le périphérique réseau géré par NSO et son API.

Composants utilisés

- Crosswork NSO 6.4.3

- NED cisco-iosxr-7.64.1

Types d'erreurs externes

Les erreurs externes NED sont le signe d'une panne de communication entre le NED et le périphérique. Elles se répartissent en trois grandes catégories :

• Le périphérique réseau auquel il ne s’attendait pas reçoit une réponse du périphérique réseau auquel il s’attendait.
• Le périphérique réseau reçoit une réponse du périphérique réseau qui viole le modèle yang dans le périphérique.
• Le NED ne reçoit pas de réponse dans le délai imparti.

La catégorie de réponses inattendues est de loin la plus courante, à savoir les erreurs externes que votre NED peut rencontrer. Il s'agit du périphérique qui renvoie un message d'erreur, un message d'information ou tout autre type d'information qui ne correspond pas à ce que NSO s'attendait à voir renvoyé. Les NED sont conçus pour traiter les messages d'information ou les avertissements qui peuvent être ignorés en toute sécurité. De nombreux NED disposent de paramètres de terminaison permettant de personnaliser les messages à ignorer ou à traiter comme une erreur externe.

Vous pouvez voir une erreur externe déclenchée par le NED lorsque le NED reçoit des informations qui ne correspondent pas au modèle yang lors d'une opération sync-from oucompare-config. Un exemple typique est un modèle yang qui accepte une valeur de 0 à 8 pour une feuille donnée, mais dans la version la plus récente de ce système d'exploitation, la plage a été augmentée à 0 à 16. Le NED n'accepte pas une valeur de 16 car elle se trouve en dehors de la plage modélisée. L'erreur peut également être déclenchée lorsqu'un leaf est marqué obligatoire dans le modèle yang mais non fourni par le périphérique ou lorsque le périphérique fournit une chaîne lorsque NSO attend un entier.

Pour les terminaux à interface de ligne de commande et les terminaux génériques, aucune erreur externe n'est générée si le terminal reçoit une configuration qui n'est pas modélisée dans le modèle NED yang. Au lieu de cela, il est consigné en tant que skipped line dans le fichier de trace.

Enfin, lorsqu'un terminal d'extrémité de réseau ne reçoit pas la réponse attendue du périphérique dans le délai imparti, une erreur externe est générée. Cela peut se produire parce que le périphérique ne répond pas et n'a pas envoyé de réponse, mais cela peut également se produire lorsque la réponse du périphérique n'a pas été reconnue par le NED.

Lecture des journaux de suivi NED

Les journaux de suivi sont les meilleurs journaux disponibles pour dépanner les erreurs externes. 

Activation des journaux de suivi NED

Les journaux de suivi NED sont activés à partir de l'interface de ligne de commande NSO.

ncs_cli -C -u admin
admin@ncs# configure
admin@ncs(config)# devices device dev-1 ned-settings [ned-id] logging level debug
admin@ncs(config)# devices device dev-1 trace raw
admin@ncs(config)# commit
admin@ncs(config)# devices device dev-1 disconnect
admin@ncs(config)# devices clear-trace
admin@ncs(config)# devices device dev-1 compare-config

Pour [ned-id] , utilisez l'id de fin du périphérique que vous ciblez à l'aide de la commande .

Mise en garde : La commande clear-trace efface les données de tous les journaux de suivi NED actuellement dans le répertoire des journaux. Si vous souhaitez conserver des journaux de suivi pour ce périphérique ou tout autre périphérique, vous devez les archiver avant d'exécuter cette commande. Dans les versions actuelles de NSO, vous pouvez exécuter clear-trace pour un seul périphérique.

Remarque : Si vous ne trouvez pas « end-settings [end-id] logging level debug », vous pouvez ignorer cette commande.

Ces commandes effacent toutes les anciennes données du fichier de trace et les préparent avec la configuration actuelle sur le périphérique. À ce stade, vous reproduisez le problème détecté à l'aide de ncs_cli ou de votre service NSO. Si vous avez rencontré l'erreur au cours d'une opération de validation, vous devez capturer les sorties CLI pour commit dry-run et commit dry-run outformat native pour référence ultérieure.

Dans le fichier NED README, vous trouverez un chapitre intitulé « How to report NED issues and feature requests » pour obtenir des instructions plus détaillées.

CLI et NED génériques

Les suivis NED pour CLI et les NED génériques sont divisés en phases distinctes, utiles pour le dépannage. Les phases les plus importantes à comprendre pour le dépannage des erreurs externes sont les phases SHOW et PREPARE.

La phase SHOW est appelée lorsque NSO lit des informations à partir du périphérique réseau. Il fait partie de la sync-from et des compare-config opérations. Au cours de cette étape, NSO invite le périphérique à exécuter une commande, par exemple, show running-config avant de lire et d'analyser la réponse du périphérique. Les messages sortants, envoyés par le NSO au périphérique, sont dirigés par, *** output tandis que les messages entrants, envoyés par le périphérique au NSO, commencent par *** input.

Remarque : Les erreurs externes lors d'une opération SHOW incluent des valeurs qui ne sont pas acceptées dans le cadre du modèle yang actuel, ainsi que des problèmes de délai d'attente.

La phase PREPARE est appelée dans le cadre des commit opérations. Au cours de cette phase, NSO envoie des instructions au périphérique. Au début d'une phase de PRÉPARATION, le NED imprime une liste des modifications que NSO a l'intention d'apporter au fichier de suivi. Après ce résumé initial, NSO envoie les instructions au périphérique. Pour certains périphériques, NSO envoie les commandes en masse, tandis que pour d'autres périphériques, ces commandes sont envoyées une par une. Ce comportement peut être modifié à l'aide des paramètres finaux appropriés pour les terminaux qui le prennent en charge. Par exemple, le NED de cisco-iosxr-cli comporte un paramètre NED "write number-of-lines-to-send-in-chunk <1-1000> (default 100)"

Pour les terminaux à interface de ligne de commande (CLI), il est courant de voir les commandes envoyées par NSO sous forme de résultats renvoyés en entrée. En effet, la commande apparaît dans l'interface utilisateur textuelle du périphérique et NSO considère tout le texte qui apparaît dans cette interface comme une entrée. Un exemple où NSO envoie des commandes une par une peut ressembler à ceci :

  *** output 1-Jan-2024::09:56:00.928 user: admin/425 thandle 7428 hostname NSO1 device test-device ***
interface GigabitEthernet 0/0/0/2.34280485 l2transport
  *** input 1-Jan-2024::09:56:00.929 user: admin/425 thandle 7428 hostname NSO1 device test-device ***
 interface GigabitEthernet 0/0/0/2.34280485 l2transport

Remarque : Les erreurs externes lors d'une opération de PRÉPARATION incluent tous les messages renvoyés par le périphérique qui ne correspondent pas aux attentes de l'ONS, tels que les erreurs, les avertissements ou les messages d'information.

Dépannage des erreurs externes

Lors du dépannage d'erreurs externes pour CLI et NED génériques : activez le suivi, reproduisez le problème et examinez la dernière phase SHOW ou PREPARE, selon les opérations qui ont déclenché l'erreur.

Pour un problème où l'ONS se plaint d'une valeur spécifique fournie par le dispositif :

• De quelle partie de la configuration NSO s'est-il plaint ?
• La configuration partagée par le périphérique est-elle correcte pour ce modèle et cette version du périphérique ?
• Connaissez-vous d'autres modèles ou versions de périphériques utilisant ce NED qui ont des exigences d'entrée plus restrictives ?

Pour un problème où NSO soulève une erreur externe impliquant un délai d'attente :

• Quelle est la dernière commande envoyée par NSO avant le délai d’attente ?
• Qu'attend l'ONS avant de continuer ?

Il peut être difficile de déterminer ce que l'ONS attend. Certains NED à verbosity accrue impriment l'expression regex qu'ils recherchent. Dans certains cas, le message que l'ONS recherchait apparaît dans le fichier de suivi, mais l'ONS ne l'a pas reconnu et continue d'attendre.

Dans le cas d'un problème où l'ONS soulève une erreur externe en raison d'une réponse inattendue :

• Quelle est la réponse spécifique fournie par le périphérique ?
• Quelle commande envoyée par NSO a déclenché la réponse ?
• La réponse attendue est-elle basée sur ce que l'ONS a envoyé ?
• La réponse du périphérique peut-elle être ignorée en toute sécurité ou doit-elle abandonner la validation ?
• NSO a-t-il envoyé les commandes correctes dans le bon ordre ?

Problèmes spécifiques courants :

Problème de traduction

Un problème de traduction se produit lorsque NSO a l'intention correcte, mais que les commandes qu'il envoie au périphérique ne sont pas tout à fait correctes. Cela peut se produire lorsqu'une version ou un modèle de périphérique différent utilisant le même NED présente une syntaxe légèrement différente. Si vous utilisez une version antérieure de la NED, vérifiez si le même comportement existe toujours dans la dernière version de la NED. En outre, vérifiez si des paramètres de fin sont disponibles dans le fichier README-end-settings.md inclus dans le NED pour voir si des paramètres vous permettent de personnaliser ce comportement. Si le dernier NED présente toujours le problème et que les paramètres de fin ne disposent d'aucune méthode pour le résoudre, veuillez ouvrir un dossier auprès du TAC. Fournir :

• version NSO
• À l'aide de la dernière commande NED, une commande NED trace capture une compare-config opération suivie d'une commit opération envoyant la commande incorrecte.
• La commande que le NED envoie actuellement
• La commande correcte, représentée de préférence à titre d'exemple sur l'interface de ligne de commande du périphérique réel
• La version et le modèle du périphérique qui pose problème
• Toute autre version et tout autre modèle de périphériques de votre réseau utilisant ce NED dont le comportement NED actuel est correct.

Problème de commande

Un problème de classement se produit lorsque le NED envoie les commandes correctes dans le mauvais ordre. Pour certains périphériques et certaines charges utiles de configuration spécifiques, l'ordre est important. Si vous utilisez une version antérieure de la NED, vérifiez si le même comportement existe toujours dans la dernière version de la NED. En outre, vérifiez si des paramètres de fin sont disponibles dans le fichier README-end-settings.md inclus dans le NED pour voir si des paramètres vous permettent de personnaliser ce comportement. Si le dernier NED présente toujours le problème et que les paramètres de fin ne disposent d'aucune méthode pour le résoudre, veuillez ouvrir un dossier auprès du TAC. Fournir :

• version NSO
• Utilisation de la dernière NED et sans utilisation de service : Une trace NED capturant une compare-config opération suivie d'une commit opération envoyant l'ordre incorrect.
• Le résultat de commit dry-run outformat native  pour la validation défectueuse. Ceci vous montre l'ordre dans lequel le NED envoie actuellement les commandes.
• L'ordre correct, de préférence illustré à titre d'exemple sur l'interface de ligne de commande du périphérique réel
• Toute autre condition requise pertinente pour cette commande

Remarque : Dans de rares cas, Cisco n'est pas en mesure de répondre à un besoin de commande via le NED, auquel cas vous pouvez mettre en oeuvre un workflow de validation multiple ou générer un rapport de bogue avec le fournisseur concerné.

Problème de valeur non valide

Un problème de valeur non valide se produit lorsque NSO autorise la définition d'une plage de valeurs différente de celle acceptée par le périphérique ou lorsque NSO n'autorise pas la plage complète autorisée par le périphérique. Par exemple, NSO vous permet de définir une valeur comprise entre 0 et 15, mais le périphérique n'accepte que des valeurs comprises entre 0 et 8. Cela peut se produire lorsque le NED est modélisé en tenant compte d'un modèle et d'une version de périphérique spécifiques, mais que d'autres périphériques ont des attentes différentes. Si vous utilisez une version antérieure de la NED, vérifiez si le même comportement existe toujours dans la dernière version de la NED. En outre, vérifiez si des paramètres de fin sont disponibles dans le fichier README-end-settings.md inclus dans le NED pour voir si des paramètres vous permettent de personnaliser ce comportement. Si le dernier NED présente toujours le problème et que les paramètres de fin ne disposent d'aucune méthode pour le résoudre, veuillez ouvrir un dossier auprès du TAC. Fournir :

• version NSO
• Pour NSO permettant des données qui ne sont pas acceptées par le périphérique, à l'aide de la dernière NED : Une trace NED capturant une compare-config opération suivie d'un commit envoi d'une valeur qui est rejetée par le périphérique.
• Pour les ONS ayant une interprétation des données plus stricte que celle autorisée par le périphérique, en utilisant le dernier NED : Une trace NED capturant une sync-from opération après avoir configuré des données sur le périphérique qui ne sont actuellement pas acceptées par NSO.
• Plage de valeurs correcte
• La version et le modèle du périphérique qui pose problème
• Toute autre version et tout autre modèle de périphériques de votre réseau utilisant ce NED dont le comportement NED actuel est correct.

Erreurs, avertissements et messages d'information du périphérique :

Lorsqu'un périphérique répond aux commandes NSO avec un message d'erreur ou autre, cela peut déclencher une erreur externe dans NSO. Les NED NSO ont une liste interne d'expressions regex qu'ils peuvent ignorer en toute sécurité, ainsi que des expressions qui déclenchent une erreur. Plusieurs NED ont des paramètres de fin qui vous permettent de personnaliser ces listes sans avoir besoin d'une amélioration NED. Exemple : Les cisco-iosxr-cli NED ned-setting write config-warning.

Si la dernière NED ne dispose pas d'une telle option, veuillez ouvrir un dossier auprès du TAC. Fournir :

• version NSO
• Une trace NED capturant une compare-config opération suivie de l'opération ayant entraîné l'erreur
• Une demande de modification des listes internes et/ou une demande d'ajout de la prise en charge d'une option de définition de fin pour personnaliser la liste vous-même
• Le message spécifique envoyé par le périphérique à l'origine du problème

Résolutions

Erreur utilisateur

Si vous avez déterminé que les commandes envoyées par NSO étaient incorrectes, assurez-vous que votre entrée dans NSO et vos packages de services ont généré les modifications correctes. Vérifiez si le résultat de commit dry-run correspond aux modifications que vous souhaitez apporter et si le résultat de commit dry-run outformat native affiche les commandes et l'ordre corrects pour évoquer ces modifications. Si le tirage à sec prévoit des changements inattendus, vous devez vérifier vos entrées dans NSO ou votre code de service. Si le test à sec est correct mais que les commandes envoyées à NSO sont incorrectes, vérifiez la traduction et la commande de résolution des problèmes.

Périphérique réseau

Dans certains cas, une erreur externe est le résultat d'une configuration, de paramètres ou même d'un bogue sur le périphérique réseau lui-même, tel qu'un utilisateur n'ayant pas l'autorisation correcte ou un périphérique limitant certaines opérations. Déterminez si la configuration ou les paramètres du périphérique peuvent être modifiés pour permettre à NSO de mieux fonctionner avec le périphérique.

Paramètres de besoins

Chaque NED dispose d'une gamme de paramètres d'extrémité pour vous aider à personnaliser la façon dont NSO interagit avec le périphérique. Les paramètres de fin sont documentés dans le fichier README-end-settings.md à l'intérieur du NED et ont tendance à différer d'un NED à l'autre. Le NED cisco-iosxr-cli propose des options permettant de modifier la façon dont NSO calcule une somme de contrôle pour le périphérique, le nombre de commandes envoyées en masse, la personnalisation de commandes supplémentaires à injecter en fonction de déclencheurs spécifiques ou si le NED doit collecter des données de configuration à l'aide de ou en écrivant la configuration dans un fichier sur le périphérique et en transférant le fichier à l'aide de sftp, "show running-config"  ce qui peut s'avérer utile pour les configurations volumineuses.

Conflit de service NED

Un conflit NED-Service se produit lorsqu'un comportement problématique est présent lorsque la configuration est modifiée ou supprimée à l'aide d'un service-package, mais n'apparaît pas lorsque les mêmes modifications de configuration sont effectuées sans l'utilisation d'un service-package. Ce type de comportement peut apparaître comme une configuration inattendue en cours d'ajout ou de suppression, entraînant des erreurs externes du périphérique. Ceci est généralement le résultat de la propriété de services sur des parties de la configuration. Les modifications apportées à la configuration NSO CDB suite à un service-package peuvent remplacer la logique NED, ce qui permet normalement de se prémunir contre les modifications incorrectes. Si vous pensez avoir rencontré ce comportement, vérifiez en essayant les mêmes modifications de configuration sans utiliser de service-package.

Reportez-vous à l'article Comprendre la propriété des services NSO pour en savoir plus sur la propriété des services et les solutions possibles.

Améliorations NED et assistance TAC

Si aucune autre option n'est disponible, vous pouvez ouvrir un ticket auprès du TAC Cisco et demander à ce que le NED soit mis à jour pour répondre à vos besoins.

Les NED NSO fournis par Cisco sont élaborés à partir de mises à jour basées sur vos cas d'utilisation. Cisco n'essaie pas de couvrir de manière proactive tous les modèles et toutes les versions de périphériques possibles, mais le NED est constamment mis à jour pour répondre aux besoins d'un réseau en constante évolution et aux nouveaux cas d'utilisation. Vous pouvez trouver un résumé de l'étendue de l'assistance NED fournie par les développeurs NSO Crosswork ici

Remarque : Bien que Cisco fasse de son mieux pour maintenir un vaste environnement de test interne, nous ne sommes pas en mesure de maintenir un environnement couvrant chaque modèle et chaque version pour un large éventail de fournisseurs. Ainsi, nous pouvons avoir besoin de votre aide pour fournir l'accès à un périphérique décrivant le comportement en question.

Lorsque vous ouvrez un dossier auprès du TAC Cisco pour un NED fourni par Cisco, fournissez :

• Version NSO
• Suivi NED défini sur le débogage du niveau de journalisation
• La trace NED doit capturer une opération compare-config ousync-from.
• Le suivi NED doit capturer le problème particulier pour lequel vous souhaitez obtenir de l'aide
• Toute information sur d'autres périphériques ou NED qui présentent également un problème
• Toute information sur des périphériques similaires sur le même NED qui ne présentent pas de problème

Remarque : Les NED Netconf construits à l'aide de l'outil NSO NED Builder ne sont pas pris en charge par Cisco en dehors de tout problème avec l'outil lui-même.

Conseil : Pour les NED fournis par les développeurs NSO Crosswork, utilisez Technology : NMS (Network Management Services and Sub-Technology : Network Service Orchestrator (NSO) - NED