El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo leer y comprender correctamente las diversas fases del seguimiento de NSO NED.
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.
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.
Los datos de un archivo de seguimiento NED se pueden ver en 3 categorías diferentes.
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
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.
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
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
>> 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.
>> CLI CONNECT
<< CONNECTED
>> GET_TRANS_ID
<< TRANS_ID
>> 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
.
>> 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.
>> CLI CONNECT
<< CONNECTED
>> INITIALIZE
<< INITIALIZED
>> PREPARE
<< PREPARE OK
>> COMMIT
<< COMMIT OK
>> PERSIST
<< PERSIST OK
>> GET_TRANS_ID
<< TRANS_ID
Estas operaciones no involucran la lógica NED y no hacen que se genere ningún registro en el archivo de seguimiento NED.
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
>> 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.
>> 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.
>> CLI CONNECT
<< CONNECTED
>> COMMAND
<< COMMAND
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
Durante la fase CLOSE, el NED cierra la sesión SSH al dispositivo final.
La fase SET_TIMEOUT indica una actualización de varios tiempos de espera administrados por NSO y NED.
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
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
24-Mar-2025
|
Versión inicial |