Comprensión de los registros de seguimiento NSO NED

Introducción

Este documento describe cómo leer y comprender correctamente las diversas fases del seguimiento de NSO NED.

Background

Cisco® Crosswork Network Service Orchestrator (NSO) puede generar seguimientos detallados de la comunicación entre NSO y los dispositivos gestionados por los controladores de elementos de red (NED) de NSO. Para los NED basados en Java, estos archivos de seguimiento se estructuran según un marco compartido. Este documento le ayuda a comprender este marco de trabajo compartido y los detalles de estos registros.

Prerequisites

Componentes Utilizados

• NSO 6.4
• NED cisco-iosxr-cli
• NED cisco-ios-cli
• NED cisco-nx-cli
• NED zte-zxros-cli
• NED alu-sr-cli
• NED juniper-junos_nc-gen

Descargo

Este documento asume que está utilizando un NED Java desarrollado por Cisco. Esto incluye CLI, Generic y 3PY NED. Las fases y el marco explicado en este documento se aplican a los NEDs de Netconf, pero los logs de seguimiento generados para los NEDs de Netconf no los etiquetan de la misma manera que se muestra en este documento.

Aunque las fases descritas en este documento se comparten entre todos los NED de Java, las operaciones específicas que se ejecutan como parte de esa fase difieren para cada NED debido a las necesidades de cada dispositivo individual.

Tipos de datos

Los datos de un archivo de seguimiento NED se pueden ver en 3 categorías diferentes.

Comunicación entre Core NSO y NED

NSO indica al NED que inicie fases específicas. Cada operación de NSO da lugar a las mismas secuencias de fases, pero cada NED ejecuta instrucciones únicas para un dispositivo de red. El archivo de seguimiento NED no registra los datos exactos que fluyen entre NSO y NED, pero sí registra la instrucción para iniciar una fase y la respuesta NED que indica que una fase ha finalizado. Las líneas que comienzan por >> indican instrucciones para iniciar una fase. Las líneas que comienzan por << indican el NED que informa a NSO de que la fase ha finalizado.

>> 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

Comunicación entre el NED y un dispositivo descendente

Dentro de cada fase, el NED ejecutará comandos hacia el dispositivo de red para lograr los objetivos de cada fase. La comunicación del NED al dispositivo se marca como *** output, la comunicación que el NED recibe del dispositivo se marca como *** 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
...

En los NED de CLI, la entrada consta de toda la información que aparece en la CLI del dispositivo, incluidos los comandos enviados por NSO.

Registro interno del propio NED

El NED registra una cierta cantidad de información que no se transmite al dispositivo ni a NSO. Esto incluye la configuración final, el procesamiento de datos y los cambios esperados en la base de datos de NSO (CDB).

Este tipo de información suele comenzar con--, pero no se aplica a toda la información de este tipo.

*** 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

Secuencias por operación

En esta sección se incluye una lista de operaciones comunes y se documenta la secuencia esperada de fases que NSO inicia para cada operación. En la sección Fases de este documento encontrará más información sobre cada fase.

Nota: Las fases IS_ALIVE, SET_TIMEOUT y CLOSE se omiten de cada secuencia, ya que tienen poco valor de resolución de problemas

CONNECT(conectar)

>> CLI CONNECT
<< CONNECTED

O bien

>> GENERIC CONNECT
<< CONNECTED

Aunque funcionalmente, las fases CLI y GENERIC CONNECT son casi idénticas, los NED de tipo CLI y GENERIC utilizan fases CONNECT diferentes.

Check-Sync

>> CLI CONNECT
<< CONNECTED
>> GET_TRANS_ID
<< TRANS_ID

Sync-From

>> CLI CONNECT
<< CONNECTED
>> SHOW
<< SHOW
>> GET_TRANS_ID
<< TRANS_ID

O bien

>> CLI CONNECT
<< CONNECTED
>> SHOW
<< SHOW
<< PROVISIONAL TRANS_ID

Algunos NED se han optimizado para su uso PROVISIONAL TRANS_ID en lugar de GET_TRANS_ID.

Compare-Config

>> CLI CONNECT
<< CONNECTED
>> SHOW
<< SHOW

La operación compare-config es muy similar a sync-from, pero no actualiza el CDB. Cuando compare-config detecta una diferencia de configuración, no invoca GET_TRANS_ID para actualizar la suma de comprobación. Cuando no hay diferencia de configuración, invoca GET_TRANS_ID y actualiza la suma de comprobación.

Commit

>> CLI CONNECT
<< CONNECTED
>> INITIALIZE
<< INITIALIZED
>> PREPARE
<< PREPARE OK
>> COMMIT
<< COMMIT OK
>> PERSIST
<< PERSIST OK
>> GET_TRANS_ID
<< TRANS_ID

Ejecución de simulacro y confirmación de ausencia de conexión en red

Estas operaciones no involucran la lógica NED y no hacen que se genere ningún registro en el archivo de seguimiento NED.

Commit Dry-Run Outformat Native

Esta operación no envía ningún dato a los dispositivos de red, pero interactúa con la lógica NED.

>> CLI CONNECT
<< CONNECTED
>> PREPARE DRY
<< PREPARE DRY

Commit No-Overwrite

>> CLI CONNECT
<< CONNECTED
>> INITIALIZE
<< INITIALIZED
>> SHOW_PARTIAL
<< SHOW
>> PREPARE
<< PREPARE OK
>> COMMIT
<< COMMIT OK
>> PERSIST
<< PERSIST OK
>> GET_TRANS_ID
<< TRANS_ID

Esta secuencia es engañosa. Afirma incluir la fase INITIALIZE, pero el NED no activará ningún comando durante esta fase y lo salta de forma efectiva. Esto se debe a que el indicador de no sobrescritura no verifica la suma de comprobación, sino que verifica la configuración mediante SHOW_PARTIAL.

Confirmar con error

>> CLI CONNECT
<< CONNECTED
>> INITIALIZE
<< INITIALIZED
>> PREPARE
>> CLOSE
<< CLOSED
>> CLI CONNECT
<< CONNECTED
>> SHOW_PARTIAL
<< SHOW
>> ABORT
<< ABORT OK
>> GET_TRANS_ID
<< TRANS_ID

Cuando algo falla durante una confirmación, NSO finaliza la conexión, se vuelve a conectar e intenta restaurar el sistema. NSO lo hace comprobando la configuración del dispositivo mediante SHOW_PARTIAL y enviando una secuencia de comandos para revertir la configuración actual a la configuración antes del inicio de la confirmación durante la fase ABORT. Los dispositivos con configuración candidata tienen métodos alternativos para recuperar los que NSO puede aprovechar, en función de cuándo se produjo el error.

Live-Status

>> CLI CONNECT
<< CONNECTED
>> COMMAND
<< COMMAND

Fases

Todos los NED basados en Java utilizan las mismas fases, pero cada NED ajusta la ejecución exacta de la fase al dispositivo específico que está manejando.

CLI CONNECT, GENERIC CONNECT y RECONNECT

Durante la fase CONNECT, el NED imprime información sobre sí mismo, establece una conexión, inhabilita la paginación (para los NED CLI) y recopila información del dispositivo. Esto incluye la versión de NSO y NED, la configuración de NED, los algoritmos SSH y el modelo y la versión del dispositivo. No registra el intercambio de contraseñas.

Al producirse un fallo de conexión de NSO a un dispositivo, cualquier parte de esta fase puede ser responsable. Es posible que NSO haya podido establecer la sesión SSH pero no haya podido recuperar el modelo y la versión del dispositivo.

Los NED mantienen una sesión con un dispositivo durante varios segundos después de que una operación haya finalizado. Si se requiere otra operación para el mismo dispositivo dentro de ese marco de tiempo, el NED registrará una fase de RECONEXIÓN en lugar de CLI/GENERIC CONNECT y reutilizará la información.

GET_TRANS_ID

La fase GET_TRANS_ID recopila información para calcular una suma de comprobación. Esta suma de comprobación se puede verificar para determinar si un dispositivo no está sincronizado durante una operación de confirmación o sincronización de comprobación, o se puede almacenar para una comprobación futura. Cisco selecciona la opción más ligera disponible para cada dispositivo. El NED de Cisco-IOS-CLI recopila la configuración completa del dispositivo para generar una suma de comprobación. El NED cisco-iosxr utiliza la lista de confirmación y verifica si el commit-id ha cambiado desde la última sincronización.

Los NED imprimen la suma de comprobación que calcularon al final de la fase 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 se invoca durante la sincronización de comprobación, al final de la sincronización desde, al final de la confirmación o al final de compare-config si no se detectó ninguna diferencia. Sólo durante la sincronización de comprobación la suma de comprobación no se actualiza como parte de GET_TRANS_ID. Al inicio de una operación de confirmación, NSO también verifica la suma de comprobación, pero utiliza INITIALIZE en lugar de GET_TRANS_ID.

SHOW

Durante la fase SHOW, un NED recopila la configuración actual en el dispositivo y la analiza para que se pueda actualizar o comparar con CDB. Una fase SHOW puede consistir en uno o más comandos para recopilar los datos relevantes. Algunos NED solicitan varias fases SHOW en una fila para diferentes secciones de la configuración.

<< 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

Una vez recopilados los datos, el NED los analiza y los prepara para NSO. En los CLI NEDs, este proceso se marca con turbo-parser. Los datos que NSO no comprende y no puede asignar al modelo yang actual se registran como una línea omitida.

-- 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

TRANS_ID PROVISIONAL

PROVISIONAL TRANS_ID es una optimización implementada en algunos NED para reemplazar GET_TRANS_ID al final de una operación de sincronización desde. Sin esta optimización, los NED que son necesarios para recopilar la configuración completa de un dispositivo para calcular una suma de comprobación recopilan estos datos dos veces durante la sincronización desde. Una vez durante la fase SHOW y otra vez durante la fase GET_TRANS_ID. PROVISIONAL TRANS_ID reemplaza a GET_TRANS_ID en estas situaciones para reutilizar los datos de la operación SHOW.

Existe una implementación especial de esta optimización en el NED cisco-iosxr-cli. Este NED no requiere la configuración completa, pero la configuración puede ser tan grande que el análisis tarda el tiempo suficiente para que la sesión SSH se agote en el momento en que se inicia GET_TRANS_ID. Para evitar esto, el NED recopila la información necesaria como parte de SHOW y utiliza PROVISIONAL TRANS_ID en su lugar.

INICIALIZACIÓN

La fase INITIALIZE es similar a GET_TRANS_ID. Recopila los mismos datos y calcula una suma de comprobación, pero sólo se utiliza al inicio de una operación de confirmación para comprobar si un dispositivo está sincronizado. Si se detecta que un dispositivo no está sincronizado, la fase INITIALIZE va seguida de una fase UNINITIALIZE y se devuelve un error a NSO. INITIALIZE nunca actualiza la suma de comprobación.

Nota: La confirmación de no-overwrite tiene una fase INITIALIZE pero no se ejecutan comandos durante la misma ya que out-of-sync no es relevante.

PREPARAR

La fase PREPARAR es la fase más importante de una operación de confirmación. Durante la fase PREPARACIÓN, el NED traduce los cambios previstos en la CDB de NSO en comandos que el dispositivo comprenderá. A continuación, envía esos comandos al dispositivo, incluidos los comandos para navegar por la interfaz de usuario, como entrar en el modo de configuración.

En el caso de dispositivos sin configuración candidata, el envío de comandos causa un impacto inmediato en la configuración en ejecución y el funcionamiento de la red.

COMMIT

Durante la fase COMMIT, el NED aplica la configuración al dispositivo. La fase COMMIT está vacía para los dispositivos sin configuración candidata, como los dispositivos administrados por el NED cisco-ios-cli. Si el dispositivo tiene capacidades confirmadas por confirmación de compromiso, NSO las aprovecha durante esta fase.

>> 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

PERSISTIR

Algunos dispositivos requieren instrucciones adicionales para garantizar que la configuración se mantiene incluso cuando se reinicia un dispositivo. Estos comandos se envían durante la fase PERSIST.

PREPARAR EN SECO

La fase PREPARAR EN SECO es exclusiva para las commit dry-run outformat native operaciones. De forma similar a la fase PREPARE, traduce la intención de NSO en comandos de dispositivo, pero no los envía al dispositivo.

SHOW_PARTIAL

La fase SHOW_PARTIAL se puede invocar mediante una instrucción de correspondencia o se utiliza durante commit no-overwite y rollback during commit error.

Esta fase es similar a la fase SHOW, ya que recopila los datos de configuración del dispositivo y los analiza. Recopila un conjunto más específico de datos relevantes para la operación de confirmación actual en lugar de la configuración completa. No todos los dispositivos admiten la recopilación de conjuntos de datos más pequeños.

ABORT

La fase ABORT es similar a la fase PREPARE pero exclusiva para la recuperación de reversión. NSO envía comandos para revertir la configuración de los dispositivos a la forma en que estaba antes de la confirmación.

REVERTIR

La fase REVERT se utiliza en situaciones en las que un commit encuentra un error pero NSO simplemente puede indicar a un dispositivo que vuelva a una configuración anterior. En este caso, las fases SHOW_PARTIAL y ABORT no son necesarias.

COMANDO

La fase COMMAND es exclusiva de las operaciones de estado activo. Durante la fase COMMAND, NSO pasa instrucciones a los dispositivos fuera del alcance de las operaciones de confirmación típicas.

IS_ALIVE

La fase IS_ALIVE es una comprobación de estado para verificar si las sesiones entre el NED, el dispositivo y NSO siguen en buen estado. Si encuentra IS_ALIVE false es probable que haya encontrado un tiempo de espera en una de las sesiones.

CERRAR

Durante la fase CLOSE, el NED cierra la sesión SSH al dispositivo final.

SET_TIMEOUT

La fase SET_TIMEOUT indica una actualización de varios tiempos de espera administrados por NSO y NED.

Otra información en el seguimiento

Modificaciones

Después de una fase SHOW, el NED imprime una lista de los cambios esperados que se van a realizar en la CDB de NSO.

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