Entender logs de rastreamento NED NSO

Introdução

Este documento descreve como ler e entender corretamente várias fases do rastreamento NED do NSO.

Background

O Cisco® Crosswork Network Service Orchestrator (NSO) pode gerar rastreamentos detalhados da comunicação entre o NSO e os dispositivos gerenciados pelos Network Element Drivers (NEDs) do NSO. Para NEDs baseados em Java, esses arquivos de rastreamento incluem arquivos estruturados de acordo com uma estrutura compartilhada. Este documento ajuda você a entender essa estrutura compartilhada e os detalhes nesses logs.

Pré-requisitos

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

Ressalva

Este documento pressupõe que você esteja usando um NED Java desenvolvido pela Cisco. Isso inclui NEDs CLI, Genéricos e 3PY. As fases e a estrutura explicadas neste documento se aplicam aos NEDs da Netconf, mas os logs de rastreamento gerados para os NEDs da Netconf não os rotulam da mesma forma como mostrado neste documento.

Enquanto as fases descritas neste documento são compartilhadas em todos os NEDs Java, as operações específicas executadas como parte dessa fase diferem para cada NED devido às necessidades individuais do dispositivo.

Tipos de dados

Os dados em um arquivo de rastreamento NED podem ser exibidos em 3 categorias diferentes.

Comunicação entre NSO central e NED

O NSO instrui a NED a iniciar fases específicas. Cada operação em NSO resulta nas mesmas sequências de fases, mas cada NED executa instruções exclusivas em direção a um dispositivo de rede. O arquivo de rastreamento NED não registra o fluxo exato de dados entre o NSO e o NED, mas registra a instrução para iniciar uma fase e a resposta NED indicando que uma fase foi concluída. As linhas que começam com >> indicam instruções para iniciar uma fase. As linhas que começam com << indicam o NED informando ao NSO que a fase foi concluída.

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

Comunicação entre a NED e um dispositivo de saída

Dentro de cada fase, o NED executará comandos em direção ao dispositivo de rede para atingir os objetivos de cada fase. A comunicação da NED com o dispositivo é marcada como *** output, a comunicação que a NED recebe do dispositivo é marcada 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
...

Nos NEDs de CLI, a entrada consiste em todas as informações que aparecem no CLI do dispositivo, incluindo os comandos enviados pelo NSO.

Registro interno pelo próprio NED

O NED registra uma certa quantidade de informações que não são retransmitidas para o dispositivo ou para o NSO. Isso inclui configurações finais, o processamento de dados e as alterações esperadas no banco de dados NSO (CDB).

Esse tipo de informação geralmente começa com--, mas não se aplica a todas as informações desse 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

Sequências por Operação

Esta seção apresenta uma lista de operações comuns e documenta a sequência esperada de fases que o NSO inicia para cada operação. Mais detalhes sobre cada fase podem ser encontrados na seção Fases deste documento.

Note: As fases IS_ALIVE, SET_TIMEOUT e CLOSE são omitidas de cada sequência, pois têm pouco valor de solução de problemas

CONNECT

>> CLI CONNECT
<< CONNECTED

Ou

>> GENERIC CONNECT
<< CONNECTED

Embora funcionalmente, as fases CLI e GENERIC CONNECT são quase idênticas, as fases CLI e GENERIC tipo NEDs usam diferentes fases CONNECT.

Verificar-Sincronizar

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

Sincronizar - De

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

Ou

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

Alguns NEDs foram otimizados para serem usados em PROVISIONAL TRANS_ID vez de GET_TRANS_ID.

Compare-Config

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

A operação compare-config é muito semelhante à sync-from, mas não atualiza o CDB. Quando compare-config detecta uma diferença de configuração, não chama GET_TRANS_ID para atualizar a soma de verificação. Quando não há diferença de configuração, ele chama GET_TRANS_ID e atualiza o checksum.

Consolidação

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

Commit dry-run e Commit no-networking

Essas operações não envolvem a lógica NED e não fazem com que nenhum log seja gerado no arquivo de rastreamento NED.

Confirmar Formatação de Saída de Execução Seca Nativa

Essa operação não envia nenhum dado aos dispositivos de rede, mas envolve a lógica NED.

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

Confirmar sem substituição

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

Esta sequência é enganosa. Ele afirma incluir a fase INITIALIZE, mas o NED não acionará nenhum comando durante essa fase e efetivamente a ignorará. Isso ocorre porque o sinalizador no-overwrite não verifica o checksum, mas verifica a configuração usando SHOW_PARTIAL.

Confirmar com erro

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

Quando algo dá errado durante uma confirmação, o NSO encerra a conexão, reconecta e tenta restaurar o sistema. O NSO faz isso verificando a configuração do dispositivo usando SHOW_PARTIAL e enviando uma sequência de comandos para reverter a configuração atual para a configuração antes do início da confirmação durante a fase ABORT. Os dispositivos com configuração candidata têm métodos alternativos para recuperar qual NSO pode aproveitar, dependendo de quando o erro ocorreu.

Status ao vivo

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

Fases

Todos os NEDs baseados em java usam as mesmas fases, mas cada NED ajusta a execução exata da fase para o dispositivo específico que está sendo manipulado.

CONEXÃO CLI, CONEXÃO GENÉRICA e RECONEXÃO

Durante a fase CONNECT, o NED imprime informações sobre si mesmo, estabelece uma conexão, desativa a paginação (para NEDs CLI) e coleta informações do dispositivo. Isso inclui a versão NSO e NED, as configurações NED, os algoritmos SSH e o modelo e a versão do dispositivo. Ele não registra a troca de senha.

Ao encontrar uma falha para que o NSO se conecte a um dispositivo, qualquer parte dessa fase pode ser responsável. É possível que o NSO tenha conseguido estabelecer a sessão SSH, mas não tenha recuperado o modelo e a versão do dispositivo.

Os NEDs mantêm uma sessão com um dispositivo por vários segundos após a conclusão de uma operação. Se outra operação para o mesmo dispositivo for necessária dentro desse período de tempo, o NED registrará uma fase RECONNECT em vez de CLI/GENERIC CONNECT e reutilizará as informações.

GET_TRANS_ID

A fase GET_TRANS_ID coleta informações para calcular um checksum. Essa soma de verificação pode ser verificada para determinar se um dispositivo está fora de sincronia durante uma operação de confirmação ou de sincronização de verificação, ou pode ser armazenada para uma verificação futura. A Cisco seleciona a opção mais leve disponível para cada dispositivo. O NED do cisco-ios-cli coleta a configuração completa do dispositivo para gerar um checksum. O NED cisco-iosxr usa a lista de confirmação e verifica se o ID de confirmação foi alterado desde a última sincronização.

Os NEDs imprimem o checksum calculado no final da 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 é invocado durante o check-sync, no final de sync-from, no final de commit ou no final de compare-config se nenhuma diferença foi detectada. Somente durante a sincronização de verificação a soma de verificação não é atualizada como parte de GET_TRANS_ID. No início de uma operação de commit, o NSO também verifica o checksum, mas usa INITIALIZE em vez de GET_TRANS_ID.

SHOW

Durante a fase SHOW, um NED coleta a configuração atual no dispositivo e a analisa para que possa ser atualizada ou comparada com o CDB. Uma fase SHOW pode consistir em um ou mais comandos para coletar os dados relevantes. Algumas NEDs solicitam várias fases SHOW em uma linha para diferentes seções da configuração.

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

Uma vez coletados os dados, o NED os analisa e prepara para o NSO. Em NEDs de CLI, esse processo é marcado por um turbo-parser. Qualquer dado que o NSO não entenda e não possa mapear para o modelo yang atual é registrado como uma linha ignorada.

-- 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 PROVISÓRIO

PROVISIONAL TRANS_ID é uma otimização implementada em alguns NEDs para substituir GET_TRANS_ID no final de uma operação de sincronização. Sem essa otimização, os NEDs, que são necessários para coletar a configuração completa de um dispositivo para calcular uma soma de verificação, coletam esses dados duas vezes durante a sincronização. Uma vez durante a fase SHOW e novamente durante a fase GET_TRANS_ID. PROVISIONAL TRANS_ID substitui GET_TRANS_ID nessas situações para reutilizar os dados da operação SHOW.

Existe uma implementação especial dessa otimização no NED cisco-iosxr-cli. Esse NED não exige a configuração completa, mas a configuração pode ser tão grande que a análise demora um tempo suficiente para que a sessão SSH atinja o tempo limite quando GET_TRANS_ID for iniciado. Para evitar isso, o NED coleta as informações necessárias como parte de SHOW e usa PROVISIONAL TRANS_ID.

INICIALIZAR

A fase INITIALIZE é semelhante a GET_TRANS_ID. Ele coleta os mesmos dados e calcula uma soma de verificação, mas só é usado no início de uma operação de confirmação para verificar se um dispositivo está em sincronia. Se um dispositivo não estiver sincronizado, a fase INITIALIZE será seguida por uma fase UNINITIALIZE e um erro será retornado ao NSO. INITIALIZE nunca atualiza o checksum.

Note: Commit no-overwrite possui uma fase INITIALIZE, mas nenhum comando é executado durante ela, já que out-of-sync não é relevante.

PREPARAR

A fase PREPARAR é a fase mais importante de uma operação de confirmação. Durante a fase PREPARAR, o NED converte as alterações pretendidas no NSO CDB em comandos que o dispositivo entenderá. Em seguida, ele envia esses comandos para o dispositivo, incluindo todos os comandos para navegar na interface do usuário, como entrar no modo de configuração.

Para dispositivos sem configuração candidata, o envio de comandos causa impacto imediato na configuração atual e na operação da rede.

CONSOLIDAÇÃO

Durante a fase de COMMIT, o NED aplica a configuração ao dispositivo. A fase COMMIT está vazia para dispositivos sem configuração candidata, como dispositivos gerenciados pelo NED cisco-ios-cli. Se o dispositivo tiver recursos confirmados por confirmação, o NSO os utilizará durante essa 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

Alguns dispositivos exigem instruções adicionais para garantir que a configuração seja mantida mesmo quando um dispositivo for reiniciado. Esses comandos são enviados durante a fase PERSIST.

PREPARAR SECO

A fase PREPARE DRY é exclusiva das commit dry-run outformat native operações. Semelhante à fase PREPARE, ele converte a intenção de NSO em comandos de dispositivo, mas não envia esses comandos para o dispositivo.

SHOW_PARTIAL

A fase SHOW_PARTIAL pode ser chamada por instrução de mapa ou é usada durante commit no-overwite e rollback during commit error.

Essa fase é semelhante à fase SHOW, pois coleta dados de configuração do dispositivo e os analisa. Ele coleta um conjunto mais específico de dados relevantes para a operação de confirmação atual em vez da configuração completa. Nem todos os dispositivos suportam a coleta de conjuntos menores de dados.

ABORTAR

A fase ABORT é semelhante à fase PREPARE, mas exclusiva para recuperação de reversão. O NSO envia comandos para reverter a configuração dos dispositivos para a forma como estava antes da confirmação.

REVERTER

A fase REVERT é usada em situações em que uma confirmação encontrou um erro, mas o NSO pode simplesmente dizer a um dispositivo para reverter para uma configuração anterior. Nesse caso, as fases SHOW_PARTIAL e ABORT não são obrigatórias.

COMANDO

A fase COMMAND é exclusiva para operações de status dinâmico. Durante a fase de COMANDO, o NSO passa instruções aos dispositivos fora do escopo das operações de confirmação típicas.

IS_ALIVE

A fase IS_ALIVE é uma verificação de integridade para verificar se as sessões entre o NED, o dispositivo e o NSO ainda estão íntegras. Se você encontrar IS_ALIVE false, é provável que você tenha encontrado um tempo limite em uma das sessões.

FECHAR

Durante a fase de FECHAMENTO, o NED fecha a sessão SSH para o dispositivo final.

SET_TIMEOUT

A fase SET_TIMEOUT indica uma atualização de vários timeouts gerenciados pelo NSO e pelo NED.

Outras Informações no Rastreamento

Modificações

Após uma fase SHOW, o NED imprime uma lista de alterações esperadas a serem feitas no NSO CDB.

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