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 comment lire et comprendre correctement les différentes phases de la trace NSO NED.
Cisco® Crosswork Network Service Orchestrator (NSO) peut générer des traces détaillées de la communication entre NSO et les périphériques gérés par les pilotes d'éléments de réseau (NED) de NSO. Dans le cas des terminaux de traitement de l'information Java, ces fichiers de suivi sont structurés selon un cadre partagé. Ce document vous aide à comprendre ce cadre partagé et les détails de ces journaux.
Ce document suppose que vous utilisez un NED Java développé par Cisco. Cela inclut les NED CLI, Generic et 3PY. Les phases et le cadre expliqués dans ce document s'appliquent aux NED Netconf, mais les journaux de suivi générés pour les NED Netconf ne les étiquettent pas de la même manière que dans ce document.
Bien que les phases décrites dans ce document soient partagées entre tous les NED Java, des opérations spécifiques exécutées dans le cadre de cette phase diffèrent pour chaque NED en raison des besoins de chaque périphérique.
Les données d'un fichier de suivi NED peuvent être affichées dans 3 catégories différentes.
NSO demande au NED de commencer des phases spécifiques. Chaque opération dans NSO produit les mêmes séquences de phases, mais chaque NED exécute des instructions uniques vers un périphérique réseau. Le fichier de suivi NED ne consigne pas les données exactes circulant entre NSO et NED, mais il consigne l'instruction de démarrage d'une phase et la réponse NED indiquant qu'une phase est terminée. Les lignes commençant par >> indiquent comment démarrer une phase. Les lignes commençant par << indiquent que le NED informe l'ONS que la phase est terminée.
>> 20-Mar-2025::23:23:17.277 user: admin/56 thandle 86091 hostname ncs device xr-netsim0 trace-id=1ee09d76-4415-4bb8-bd39-05f99072bd54 CLI CONNECT to xr-netsim0-127.0.0.1:10025 as admin (Trace=raw)<< CONNECTED
<< 20-Mar-2025::23:23:17.623 user: admin/56 thandle 86091 hostname ncs device xr-netsim0 trace-id=1ee09d76-4415-4bb8-bd39-05f99072bd54 CONNECTED 0
>> 20-Mar-2025::23:24:41.703 user: admin/56 thandle 86213 hostname ncs device xr-netsim0 trace-id=1ee09d76-4415-4bb8-bd39-05f99072bd54 SHOW 0:
<< 20-Mar-2025::23:24:41.879 user: admin/56 thandle 86213 hostname ncs device xr-netsim0 trace-id=1ee09d76-4415-4bb8-bd39-05f99072bd54 SHOW
Au cours de chaque phase, le NED exécutera des commandes vers le périphérique réseau pour atteindre les objectifs de chaque phase. La communication entre le terminal terminal et le périphérique est marquée comme *** output
, la communication que le terminal reçoit du périphérique est marquée comme *** input
.
*** output 20-Mar-2025::13:08:31.955 user: admin/316551 thandle 18978916 hostname ncs device xr-netsim0 trace-id=- ***
show running-config
*** input 20-Mar-2025::13:08:31.987 user: admin/316551 thandle 18978916 hostname ncs device xr-netsim0 trace-id=- ***
show running-config
Thu Jan 5 13:08:37.274 BRT
Building configuration...
!! IOS XR Configuration 7.2.1
...
Dans les NED CLI, l'entrée est constituée de toutes les informations qui apparaissent sur l'interface de ligne de commande du périphérique, y compris les commandes envoyées par NSO.
Le NED consigne une certaine quantité d'informations qui ne sont pas relayées au périphérique ou au NSO. Cela inclut les paramètres finaux, le traitement des données et les modifications attendues dans la base de données NSO (CDB).
Ce type d'informations commence--
souvent par mais cela ne s'applique pas à toutes les informations de ce type.
*** output 20-Mar-2025::13:08:31.955 user: admin/316551 thandle 18978916 hostname ncs device xr-netsim0 trace-id=- ***
-- BEGIN SHOW
-- [20-Mar-2025::13:08:31.956] progress: show: reading config...
-- Reading running config...
show running-config
Cette section passe en revue une liste d'opérations courantes et documente la séquence prévue des phases initiées par l'ONS pour chaque opération. Pour plus de détails sur chaque phase, reportez-vous à la section Phases de ce document.
Remarque : Les phases IS_ALIVE, SET_TIMEOUT et CLOSE sont omises dans chaque séquence car elles ont peu de valeur de dépannage
>> CLI CONNECT
<< CONNECTED
OU
>> GENERIC CONNECT
<< CONNECTED
Bien que les phases CLI et GENERIC CONNECT soient pratiquement identiques sur le plan fonctionnel, les NED de type CLI et GENERIC utilisent des phases CONNECT différentes.
>> CLI CONNECT
<< CONNECTED
>> GET_TRANS_ID
<< TRANS_ID
>> CLI CONNECT
<< CONNECTED
>> SHOW
<< SHOW
>> GET_TRANS_ID
<< TRANS_ID
OU
>> CLI CONNECT
<< CONNECTED
>> SHOW
<< SHOW
<< PROVISIONAL TRANS_ID
Certains NED ont été optimisés pour être utilisés à la PROVISIONAL TRANS_ID
place de GET_TRANS_ID
.
>> CLI CONNECT
<< CONNECTED
>> SHOW
<< SHOW
L'opération compare-config est très similaire à sync-from, mais elle ne met pas à jour le CDB. Lorsque compare-config détecte une différence de configuration, il n'appelle pas GET_TRANS_ID pour mettre à jour la somme de contrôle. En l'absence de différence de configuration, il appelle GET_TRANS_ID et met à jour la somme de contrôle.
>> CLI CONNECT
<< CONNECTED
>> INITIALIZE
<< INITIALIZED
>> PREPARE
<< PREPARE OK
>> COMMIT
<< COMMIT OK
>> PERSIST
<< PERSIST OK
>> GET_TRANS_ID
<< TRANS_ID
Ces opérations n'engagent pas la logique NED et n'entraînent pas la génération de journaux dans le fichier de trace NED.
Cette opération n'envoie aucune donnée aux périphériques réseau, mais elle engage la logique NED.
>> CLI CONNECT
<< CONNECTED
>> PREPARE DRY
<< PREPARE DRY
>> CLI CONNECT
<< CONNECTED
>> INITIALIZE
<< INITIALIZED
>> SHOW_PARTIAL
<< SHOW
>> PREPARE
<< PREPARE OK
>> COMMIT
<< COMMIT OK
>> PERSIST
<< PERSIST OK
>> GET_TRANS_ID
<< TRANS_ID
Cette séquence est trompeuse. Il prétend inclure la phase INITIALIZE, mais le NED ne déclenchera aucune commande pendant cette phase et l'ignorera effectivement. En effet, l'indicateur no-overwrite ne vérifie pas la somme de contrôle, mais vérifie la configuration à l'aide de SHOW_PARTIAL.
>> CLI CONNECT
<< CONNECTED
>> INITIALIZE
<< INITIALIZED
>> PREPARE
>> CLOSE
<< CLOSED
>> CLI CONNECT
<< CONNECTED
>> SHOW_PARTIAL
<< SHOW
>> ABORT
<< ABORT OK
>> GET_TRANS_ID
<< TRANS_ID
En cas de problème lors d'une validation, NSO met fin à la connexion, se reconnecte et tente de restaurer le système. Pour ce faire, NSO vérifie la configuration du périphérique à l'aide de SHOW_PARTIAL et envoie une séquence de commandes pour rétablir la configuration actuelle avant le début de la validation pendant la phase ABORT. Les périphériques avec une configuration candidate disposent d'autres méthodes de récupération que NSO peut utiliser, en fonction du moment où l'erreur s'est produite.
>> CLI CONNECT
<< CONNECTED
>> COMMAND
<< COMMAND
Tous les NED basés sur Java utilisent les mêmes phases, mais chaque NED ajuste l'exécution exacte de la phase au périphérique spécifique qu'il gère.
Au cours de la phase CONNECT, le module NED imprime des informations sur lui-même, établit une connexion, désactive la pagination (pour les modules NED CLI) et collecte des informations sur les périphériques. Cela inclut la version NSO et NED, les paramètres NED, les algorithmes SSH, ainsi que le modèle et la version du périphérique. Il n'enregistre pas l'échange de mot de passe.
En cas d'échec de la connexion d'un NSO à un périphérique, n'importe quelle partie de cette phase peut être responsable. Il est possible que NSO ait pu établir la session SSH mais n'ait pas pu récupérer le modèle et la version du périphérique.
Les NED maintiennent une session avec un périphérique pendant plusieurs secondes après la fin d'une opération. Si une autre opération est nécessaire pour le même périphérique dans ce laps de temps, le NED consigne une phase RECONNECT au lieu de CLI/GENERIC CONNECT et réutilise les informations.
La phase GET_TRANS_ID collecte des informations pour calculer une somme de contrôle. Cette somme de contrôle peut être vérifiée pour déterminer si un périphérique est désynchronisé lors d'une opération de validation ou de synchronisation de contrôle, ou elle peut être stockée pour une vérification ultérieure. Cisco sélectionne l'option la plus légère disponible pour chaque périphérique. Le NED cisco-ios-cli collecte la configuration complète du périphérique pour générer une somme de contrôle. La commande cisco-iosxr NED utilise la liste de validation et vérifie si l'ID de validation a changé depuis la dernière synchronisation.
Les NED impriment la somme de contrôle qu'ils ont calculée à la fin de la phase GET_TRANS_ID.
>> 15-Mar-2025::10:29:41.410 user: admin/205 thandle 1559 hostname ncs device alu0 GET_TRANS_ID
*** output 15-Mar-2025::10:29:41.411 user: admin/205 thandle 1559 hostname ncs device alu0 ***
-- get config method: cli dump
admin display-config
*** input 15-Mar-2025::10:29:41.415 user: admin/205 thandle 1559 hostname ncs device alu0 ***
admin display-config
...
<< 15-Mar-2025::10:29:42.045 user: admin/205 thandle 1559 hostname ncs device alu0 TRANS_ID 8f42fe893c448f47c155710bb909800b
GET_TRANS_ID est appelé pendant la synchronisation de contrôle, à la fin de la synchronisation depuis, à la fin de la validation ou à la fin de la comparaison-config si aucune différence n'a été détectée. La somme de contrôle n'est pas mise à jour dans GET_TRANS_ID uniquement lors de la synchronisation des contrôles. Au début d'une opération de validation, NSO vérifie également la somme de contrôle mais utilise INITIALIZE au lieu de GET_TRANS_ID.
Au cours de la phase SHOW, un module NED collecte la configuration actuelle sur le périphérique et l'analyse afin de la mettre à jour ou de la comparer à CDB. Une phase SHOW peut consister en une ou plusieurs commandes pour collecter les données pertinentes. Certains NED invitent plusieurs phases SHOW dans une ligne pour différentes sections de la configuration.
<< 15-Mar-2025::14:17:07.190 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c CONNECTED 0
>> 15-Mar-2025::14:17:07.210 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW 0:
<< 15-Mar-2025::14:17:07.211 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW
>> 15-Mar-2025::14:17:07.211 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW 0:
<< 15-Mar-2025::14:17:07.212 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW
>> 15-Mar-2025::14:17:07.212 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW 0:
<< 15-Mar-2025::14:17:07.212 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW
>> 15-Mar-2025::14:17:07.213 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW 0:
<< 15-Mar-2025::14:17:07.213 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW
>> 15-Mar-2025::14:17:07.214 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW 0: <'vlan-configuration'>
<< 15-Mar-2025::14:17:07.214 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW
>> 15-Mar-2025::14:17:07.214 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW 0: <'switchvlan-configuration'>
<< 15-Mar-2025::14:17:07.215 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW
>> 15-Mar-2025::14:17:07.215 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW 0:
<< 15-Mar-2025::14:17:08.672 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c SHOW
<< 15-Mar-2025::14:17:08.672 user: admin/17279 thandle 7896374 hostname ncs device zte0 trace-id=438b8c PROVISIONAL TRANS_ID 8bb56df1e125549b62f96e8007866
Une fois les données collectées, le NED les analyse et les prépare pour le NSO. Dans les NED CLI, ce processus est marqué par un turbo-analyseur. Toutes les données que NSO ne comprend pas et ne peut pas mapper au modèle yang actuel sont enregistrées comme une ligne ignorée.
-- turbo-mode parsing (setvalues) :: performance numbers :
-- --------------------------------------------------------------------------------
-- number of lines parsed : 469
-- number of lines skipped : 2
-- time to parse config (ms) : 20
-- time to transfer xml to nso (ms) : 531
-- --------------------------------------------------------------------------------
-- skipped 2 lines in context '/' :
-- (line 16) : 'platform sslvpn use-pd'
-- (line 74) : 'pae'
-- --------------------------------------------------------------------------------
-- [15-Mar-2025::17:00:07.906] progress: show: populating cdb ok [531 ms]
-- transformed >= sorted 8 'neighbor ' lines for hash checksum
-- show trans_id = 12b6f28a48520ca4b5c6ebdfe3d333ee
-- done show [5055 ms]
<< 15-Mar-2025::17:00:07.912 user: nsoadmin/23219 thandle 3068964 hostname ncs device ios0 SHOW
PROVISIONAL TRANS_ID est une optimisation implémentée dans certains NED pour remplacer GET_TRANS_ID à la fin d'une opération de synchronisation. Sans cette optimisation, les NED qui sont nécessaires pour collecter la configuration complète d'un périphérique afin de calculer une somme de contrôle collectent ces données deux fois pendant la synchronisation. Une fois pendant la phase SHOW et une autre fois pendant la phase GET_TRANS_ID. PROVISIONAL TRANS_ID remplace GET_TRANS_ID dans ces situations pour réutiliser les données de l'opération SHOW.
Une implémentation spéciale de cette optimisation existe dans le NED cisco-iosxr-cli. Ce NED ne nécessite pas la configuration complète, mais la configuration peut être si grande que l'analyse prend suffisamment de temps pour que la session SSH expire avant le début de GET_TRANS_ID. Pour éviter cela, le NED collecte les informations nécessaires dans le cadre de SHOW et utilise PROVISIONAL TRANS_ID à la place.
La phase INITIALIZE est similaire à GET_TRANS_ID. Il collecte les mêmes données et calcule une somme de contrôle, mais n'est utilisé qu'au début d'une opération de validation pour vérifier si un périphérique est synchronisé. Si un périphérique n'est pas synchronisé, la phase INITIALIZE est suivie d'une phase UNINITIALIZE et une erreur est renvoyée à NSO. INITIALIZE ne met jamais à jour la somme de contrôle.
Remarque : La commande Commit no-overwrite comporte une phase INITIALIZE, mais aucune commande n'est exécutée pendant cette phase, car la désynchronisation n'est pas pertinente.
La phase PREPARE est la phase la plus importante d'une opération de validation. Au cours de la phase de PRÉPARATION, le NED traduit les modifications prévues dans la CDB NSO en commandes que le périphérique comprendra. Il envoie ensuite ces commandes au périphérique, y compris toutes les commandes permettant de naviguer dans l'interface utilisateur, telles que l'entrée en mode de configuration.
Pour les périphériques sans configuration candidate, l’envoi de commandes a un impact immédiat sur la configuration et le fonctionnement du réseau.
Au cours de la phase COMMIT, le NED applique la configuration au périphérique. La phase COMMIT est vide pour les périphériques sans configuration candidate, tels que les périphériques gérés par le NED cisco-ios-cli. Si le périphérique dispose de capacités confirmées par validation, NSO les exploite au cours de cette phase.
>> 8-Mar-2025::14:06:54.238 user: admin/397910 thandle 18935883 hostname ncs device xr0 trace-id=c9c7a91b-dfd2-45bd-bbe4-71a0ddb1039a COMMIT 1: (Timeout 30)
*** output 8-Mar-2025::14:06:54.239 user: admin/397910 thandle 18935883 hostname ncs device xr0 trace-id=c9c7a91b-dfd2-45bd-bbe4-71a0ddb1039a ***
-- BEGIN COMMIT
-- [08-Mar-2025::14:06:54.239] progress: commit: committing config...
-- Committing (confirmed) [num-commit 0 0a delayed=0]
commit confirmed 30 show-error
*** input 8-Mar-2025::14:06:54.268 user: admin/397910 thandle 18935883 hostname ncs device xr0 trace-id=c9c7a91b-dfd2-45bd-bbe4-71a0ddb1039a ***
commit confirmed 30 show-error
Wed Mar 8 14:06:54.354 BRT
RP/0/RP0/CPU0:RNCOBSA0101(config)#
*** output 8-Mar-2025::14:06:58.377 user: admin/397910 thandle 18935883 hostname ncs device xr0 trace-id=c9c7a91b-dfd2-45bd-bbe4-71a0ddb1039a ***
commit show-error
*** input 8-Mar-2025::14:06:58.404 user: admin/397910 thandle 18935883 hostname ncs device xr0 trace-id=c9c7a91b-dfd2-45bd-bbe4-71a0ddb1039a ***
commit show-error
Wed Mar 8 14:06:58.493 BRT
% Confirming commit for trial session.
RP/0/RP0/CPU0:RNCOBSA0101(config)#
*** output 8-Mar-2025::14:06:58.734 user: admin/397910 thandle 18935883 hostname ncs device xr0 trace-id=c9c7a91b-dfd2-45bd-bbe4-71a0ddb1039a ***
end
*** input 8-Mar-2025::14:06:58.763 user: admin/397910 thandle 18935883 hostname ncs device xr0 trace-id=c9c7a91b-dfd2-45bd-bbe4-71a0ddb1039a ***
end
RP/0/RP0/CPU0:RNCOBSA0101#
*** output 8-Mar-2025::14:06:58.832 user: admin/397910 thandle 18935883 hostname ncs device xr0 trace-id=c9c7a91b-dfd2-45bd-bbe4-71a0ddb1039a ***
-- [08-Mar-2025::14:06:58.832] progress: commit: committing config ok [4593 ms]
-- DONE COMMIT [4594 ms]
<< 8-Mar-2025::14:06:58.832 user: admin/397910 thandle 18935883 hostname ncs device xr0 trace-id=c9c7a91b-dfd2-45bd-bbe4-71a0ddb1039a COMMIT OK
Certains périphériques nécessitent des instructions supplémentaires pour s'assurer que la configuration est conservée même lorsqu'un périphérique redémarre. Ces commandes sont envoyées pendant la phase PERSIST.
La phase PREPARE DRY est propre aux commit dry-run outformat native
opérations. À l'instar de la phase PREPARE, elle traduit l'intention NSO en commandes de périphérique, mais n'envoie pas ces commandes au périphérique.
La phase SHOW_PARTIAL peut être appelée par l'instruction de la carte, ou elle est utilisée pendant commit no-overwite
et rollback during commit error
.
Cette phase est similaire à la phase SHOW en ce sens qu'elle collecte les données de configuration du périphérique et les analyse. Il collecte un ensemble plus spécifique de données relatives à l'opération de validation en cours plutôt que la configuration complète. Tous les périphériques ne prennent pas en charge la collecte de plus petits ensembles de données.
La phase ABORT est similaire à la phase PREPARE, mais elle est réservée à la restauration. NSO envoie des commandes pour rétablir la configuration des périphériques telle qu'elle était avant la validation.
La phase REVERT est utilisée dans les situations où un commit a rencontré une erreur, mais où NSO peut simplement demander à un périphérique de revenir à une configuration précédente. Dans ce cas, les phases SHOW_PARTIAL et ABORT ne sont pas requises.
La phase COMMAND est propre aux opérations à état actif. Au cours de la phase COMMAND, NSO transmet des instructions aux périphériques qui ne sont pas concernés par les opérations de validation standard.
La phase IS_ALIVE est un contrôle d'intégrité visant à vérifier si les sessions entre le terminal, le périphérique et le NSO sont toujours en bon état. Si vous rencontrez IS_ALIVE false, il est probable que vous ayez rencontré un délai d'attente dans l'une des sessions.
Pendant la phase CLOSE, le terminal ferme la session SSH au périphérique final.
La phase SET_TIMEOUT indique une actualisation des différents délais d'attente gérés par NSO et NED.
Après une phase SHOW, le NED imprime une liste des changements attendus à apporter dans la BDC des ONS.
created /ios:line/vty[first='5'][last='15']/login
created /ios:line/vty[first='5'][last='15']/login/local
modified /ios:interface/Loopback[name='2']
created /ios:interface/Loopback[name='2']/shutdown
created /ios:username[name='cisco']
value_set /ios:username[name='cisco']/privilege 15
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
24-Mar-2025
|
Première publication |