Identificar e Solucionar Erros Externos NSO NED

Introdução

Este documento descreve como analisar rastreamentos NED do tipo genérico e CLI e identificar a causa de erros externos no Cisco Crosswork NSO.

Pré-requisitos

Requisitos

• O aspecto de solução de problemas deste documento aplica-se a todas as versões de Network Element Driver (NED) e Cisco® Crosswork Network Service Orchestrator (NSO) suportadas atualmente.
• Para solucionar problemas de erros externos de NED, você precisa habilitar os logs de rastreamento de NED, bem como ter acesso a esses logs.
• Para avaliar com precisão os erros externos de NED, recomenda-se o conhecimento do dispositivo de rede gerenciado pelo NSO e sua API.

Componentes Utilizados

Crosswork NSO 6.4.3

- NED cisco-iosxr-7.64.1

Tipos de erros externos

Os erros externos de NED são um sinal de uma falha de comunicação entre a NED e o dispositivo. Eles ocorrem em três categorias amplas:

• O NED recebe uma resposta do dispositivo de rede que não esperava.
• O NED recebe uma resposta do dispositivo de rede que viola o modelo yang no NED.
• O NED não recebe uma resposta dentro do tempo alocado.

A categoria de respostas inesperadas é, de longe, a categoria mais comum de erros externos que sua NED pode encontrar. Ele inclui o dispositivo que retorna uma mensagem de erro, uma mensagem informativa ou qualquer outro tipo de informação que não corresponde ao que o NSO esperava ver retornado. Os NEDs são projetados para lidar com mensagens informativas ou avisos que podem ser ignorados com segurança. Muitos NEDs têm configurações de extremidade disponíveis para personalizar quais mensagens ignorar ou quais mensagens tratar como um erro externo.

Você pode ver um erro externo gerado pelo NED quando o NED recebe informações que não correspondem ao modelo yang durante uma operação sync-from ou compare-config . Um exemplo típico é um modelo yang que aceita um valor de 0 a 8 para uma determinada folha, mas na versão mais recente deste sistema operacional, o intervalo foi aumentado para 0 a 16. O NED não aceita um valor de 16, pois está fora do intervalo modelado. Alternativamente, o erro pode ser levantado quando uma folha é marcada como obrigatória no modelo yang, mas não fornecida pelo dispositivo ou quando o dispositivo fornece uma cadeia quando NSO espera um inteiro.

Para CLI e NEDs genéricos, nenhum erro externo será gerado se o NED receber a configuração que não é modelada no modelo NED yang. Em vez disso, isso é registrado como um skipped line no arquivo de rastreamento.

Finalmente, quando um NED não recebe a resposta esperada do dispositivo dentro do tempo alocado, um erro externo é gerado. Isso pode ocorrer porque o dispositivo não responde e não enviou uma resposta, mas também pode ocorrer quando a resposta do dispositivo não foi reconhecida pelo NED.

Lendo logs de rastreamento NED

Os registros de rastreamento são os melhores registros disponíveis para solucionar erros externos. 

Ativando registros de rastreamento NED

Os logs de rastreamento NED são ativados a partir da CLI do 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

Para [ned-id] , use o end-id para o dispositivo que você está buscando com o comando.

Caution: O comando clear-trace limpa os dados de todos os logs de rastreamento NED atualmente no diretório de log. Se você tiver logs de rastreamento que deseja manter para este dispositivo ou qualquer outro dispositivo, deverá arquivá-los antes de executar este comando. Nas versões atuais do NSO, você pode executar clear-trace para um único dispositivo.

Note: Caso você não encontre "end-settings [end-id] logging level debug", você pode ignorar esse comando.

Esses comandos limpam todos os dados antigos do arquivo de rastreamento e os preparam com a configuração atual no dispositivo. Neste ponto, você reproduz o problema encontrado usando o ncs_cli ou o serviço NSO. Se você encontrou o erro durante uma operação de confirmação, deve capturar saídas CLI para commit dry-run e commit dry-run outformat native para referência futura.

No arquivo LEIAME NED, você pode encontrar um capítulo chamado "Como reportar problemas NED e solicitações de recursos" para obter instruções mais detalhadas.

CLI e NEDs genéricos

Os rastreamentos de NED para CLI e NEDs genéricos são secionados em fases distintas que são úteis para a solução de problemas. As fases mais importantes a serem compreendidas para fins de solução de problemas de erros externos são as fases SHOW e PREPARE.

A fase SHOW é chamada quando o NSO está lendo informações do dispositivo de rede. Faz parte das operações do sync-from e do compare-config . Durante esta etapa, o NSO solicita ao dispositivo um comando como show running-config antes de ler e analisar a resposta do dispositivo. As mensagens de saída, enviadas do NSO para o dispositivo, são encaminhadas com *** output enquanto as mensagens de entrada, enviadas pelo dispositivo para o NSO, começam com *** input.

Note: Os erros externos durante uma operação SHOW incluem valores que não são aceitos no modelo yang atual e problemas de tempo limite.

A fase PREPARE é chamada como parte das commit operações. Durante essa fase, o NSO envia instruções ao dispositivo. No início de uma fase PREPARE, o NED imprime uma lista das alterações que o NSO pretende fazer no arquivo de rastreamento. Após esse resumo inicial, o NSO envia as instruções ao dispositivo. Para determinados dispositivos, o NSO envia os comandos em massa, enquanto para outros dispositivos esses comandos são enviados um por um. Esse comportamento pode ser alterado usando as configurações de extremidade relevantes para NEDs que o suportam. Por exemplo, o NED cisco-iosxr-cli tem a configuração NED "write number-of-lines-to-send-in-chunk <1-1000> (default 100)"

Para NEDs CLI, é comum ver os comandos enviados por NSO como saída retornada como entrada. Isso ocorre porque o comando aparece na interface do usuário baseada em texto do dispositivo e o NSO considera todo o texto que aparece nessa interface como entrada. Um exemplo em que o NSO envia comandos, um por um, pode ser semelhante a:

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

Note: Os erros externos durante uma operação PREPARE incluem todas as mensagens retornadas pelo dispositivo que não se encaixam nas expectativas do NSO, como erros, avisos ou mensagens informativas.

Solucionar erros externos

Ao Troubleshoot erros externos para CLI e NEDs Genéricos: ative o rastreamento, reproduza o problema e examine a fase SHOW ou PREPARE mais recente, dependendo de quais operações acionaram o erro.

Para um problema em que NSO reclama sobre um valor específico fornecido pelo dispositivo:

• De que parte da configuração o NSO reclamou?
• A configuração compartilhada pelo dispositivo está correta para este modelo e versão do dispositivo?
• Você conhece algum outro modelo ou versão de dispositivo que use este NED e que tenha requisitos de entrada mais restritivos?

Para um problema em que NSO levanta um erro externo envolvendo um timeout:

• Qual é o último comando enviado pelo NSO antes do timeout?
• O que o NSO está esperando antes de continuar?

Pode ser difícil determinar o que o NSO está esperando. Alguns NEDs com maior verbosidade imprimem a expressão regex que estão procurando. Em alguns casos, a mensagem que o NSO estava procurando não aparece no arquivo de rastreamento, mas o NSO não a reconheceu e continua a aguardar.

Para um problema em que NSO levanta um erro externo devido a uma resposta inesperada:

• Qual é a resposta específica fornecida pelo dispositivo?
• Que comando enviado pelo NSO disparou a resposta?
• A resposta é esperada com base no que o NSO enviou?
• A resposta do dispositivo pode ser ignorada com segurança ou deve abortar a confirmação?
• O NSO enviou os comandos corretos na ordem correta?

Problemas específicos comuns:

Problema de Tradução

Um problema de conversão ocorre quando o NSO tem a intenção correta, mas os comandos que ele envia ao dispositivo não estão totalmente corretos. Isso pode acontecer quando uma versão diferente do dispositivo ou um modelo que usa o mesmo NED tem uma sintaxe ligeiramente diferente. Se você estiver usando uma versão mais antiga do NED, verifique se o mesmo comportamento ainda existe na versão mais recente do NED. Além disso, verifique se há configurações finais disponíveis no arquivo README-end-settings.md incluído no NED para ver se alguma configuração permite personalizar esse comportamento. Se o problema persistir no NED mais recente e as configurações finais não tiverem nenhum método para resolvê-lo, abra um caso no TAC. Fornecer:

• versão NSO
• Usando o NED mais recente, um rastreamento de NED capturando uma compare-config operação seguida por uma commit operação enviando o comando incorreto.
• O comando que o NED está enviando no momento
• O comando correto, de preferência mostrado como um exemplo na CLI do dispositivo real
• A versão e o modelo do dispositivo que apresenta o problema
• Qualquer outra versão e modelo de dispositivos em sua rede usando esse NED em que o comportamento atual do NED esteja correto.

Problema com o pedido

Ocorre um problema de ordenação quando o NED está enviando os comandos corretos na ordem errada. Para alguns dispositivos e payloads de configuração específicos, o pedido é importante. Se você estiver usando uma versão mais antiga do NED, verifique se o mesmo comportamento ainda existe na versão mais recente do NED. Além disso, verifique se há configurações finais disponíveis no arquivo README-end-settings.md incluído no NED para ver se alguma configuração permite personalizar esse comportamento. Se o problema persistir no NED mais recente e as configurações finais não tiverem nenhum método para resolvê-lo, abra um caso no TAC. Fornecer:

• versão NSO
• Usando o NED mais recente e sem usar um serviço: Um rastreamento NED que captura uma compare-config operação seguida por uma commit operação que envia a ordem incorreta.
• A saída de commit dry-run outformat native  para a confirmação com falha. Isso mostra a ordem na qual o NED está enviando os comandos.
• A ordem correta, de preferência exibida como exemplo na CLI do dispositivo real
• Quaisquer outros pré-requisitos que sejam relevantes para este requisito de pedido

Note: Em raros casos, a Cisco não consegue atender a um requisito de pedidos através do NED, caso em que você pode implementar um fluxo de trabalho de várias confirmações ou gerar um relatório de erros com o fornecedor relevante.

Problema de Valor Inválido

Um problema de valor inválido acontece quando o NSO permite que um intervalo de valores diferente seja definido do que o dispositivo aceita ou que o NSO não permita o intervalo completo permitido pelo dispositivo. Por exemplo, o NSO permite que você defina um valor entre 0 e 15, mas o dispositivo aceita apenas valores de 0 a 8. Isso pode acontecer quando o NED é modelado com um modelo de dispositivo específico e versão em mente, mas outros dispositivos carregam expectativas diferentes. Se você estiver usando uma versão mais antiga do NED, verifique se o mesmo comportamento ainda existe na versão mais recente do NED. Além disso, verifique se há configurações finais disponíveis no arquivo README-end-settings.md incluído no NED para ver se alguma configuração permite personalizar esse comportamento. Se o problema persistir no NED mais recente e as configurações finais não tiverem nenhum método para resolvê-lo, abra um caso no TAC. Fornecer:

• versão NSO
• Para NSO que permite dados que não são aceitos pelo dispositivo, usando o NED mais recente: Um rastreamento NED que captura uma compare-config operação seguida de um commit envio de um valor que é rejeitado pelo dispositivo.
• Para NSO com uma interpretação dos dados mais rigorosa do que a permitida pelo dispositivo, utilizando a NED mais recente: Um rastreamento NED que captura uma sync-from operação após a configuração de dados no dispositivo que não é aceito atualmente pelo NSO.
• O intervalo de valores correto
• A versão e o modelo do dispositivo que apresenta o problema
• Qualquer outra versão e modelo de dispositivos em sua rede usando esse NED em que o comportamento atual do NED esteja correto.

Erros, Avisos e Mensagens Informativas do dispositivo:

Quando um dispositivo responde a comandos NSO com uma mensagem de erro ou outra mensagem, isso pode disparar um erro externo em NSO. Os NEDs NSO têm uma lista interna de expressões regex que podem ser ignoradas com segurança, bem como expressões que disparam um erro. Vários NEDs têm configurações de extremidade que permitem personalizar essas listas sem a necessidade de um aprimoramento de NED. Por exemplo: O cisco-iosxr-cli NED ned-setting write config-warning.

Se o NED mais recente não tiver essa opção, abra um caso no TAC. Fornecer:

• versão NSO
• Um rastreamento NED que captura uma compare-config operação seguida pela operação, resultando no erro
• Uma solicitação para alterar as listas internas e/ou uma solicitação para adicionar suporte a uma opção de configuração final para personalizar a lista você mesmo
• A mensagem específica que o dispositivo está enviando, causando o problema

Resoluções

Erro do usuário

Se você determinou que os comandos enviados pelo NSO estavam incorretos, certifique-se de que sua entrada para o NSO e seus pacotes de serviço geraram as alterações corretas. commit dry-run Verifique se a saída de corresponde às alterações que você deseja fazer e se a saída de commit dry-run outformat native mostra os comandos e a ordem corretos para evocar essas alterações. Se o teste previr mudanças inesperadas, você deve verificar suas entradas para o NSO ou seu código de serviço. Se o dry-run estiver correto, mas os comandos que estão sendo enviados ao NSO estiverem incorretos, verifique a conversão e as soluções de problemas de pedido.

Dispositivo de rede

Em alguns casos, um erro externo é o resultado da configuração, das configurações ou até mesmo de um bug no próprio dispositivo de rede, como um usuário que não tem a autorização correta ou um dispositivo que restringe determinadas operações. Avalie se a configuração ou as configurações do dispositivo podem ser alteradas para permitir que o NSO funcione melhor com o dispositivo.

Configurações finais

Cada NED tem uma variedade de configurações de extremidade para ajudá-lo a personalizar a forma como o NSO interage com o dispositivo. As configurações de fim são documentadas no arquivo README-end-settings.md dentro do NED e tendem a diferir de NED para NED. O NED cisco-iosxr-cli tem opções para alterar a forma como o NSO calcula um checksum para o dispositivo, quantos comandos são enviados em massa, personalizar comandos adicionais para injetar com base em acionadores específicos ou se o NED deve coletar dados de configuração usando "show running-config"  ou gravando a configuração em um arquivo no dispositivo e transferindo o arquivo usando o sftp, que pode ser útil para configurações grandes.

Conflito de serviço final

Um conflito NED-Service acontece quando um comportamento problemático está presente quando a configuração é alterada ou excluída usando um pacote de serviços, mas não aparece quando as mesmas alterações de configuração são feitas sem o uso de um pacote de serviços. Esse tipo de comportamento pode aparecer como uma configuração inesperada sendo adicionada ou removida, resultando em erros externos do dispositivo. Normalmente, isso é o resultado da propriedade do serviço sobre partes da configuração. As alterações na configuração do NSO CDB resultantes de um pacote de serviços podem substituir a lógica NED que normalmente protegeria contra alterações incorretas. Se você suspeitar que encontrou esse comportamento, verifique tentando as mesmas alterações de configuração sem usar um pacote de serviços.

Consulte o artigo Compreender a propriedade do serviço NSO para saber mais sobre a propriedade do serviço e as possíveis soluções.

Melhorias de NED e suporte TAC

Se nenhuma outra opção estiver disponível, você pode abrir um tíquete com o Cisco TAC e solicitar que o NED seja atualizado para atender às suas necessidades.

As NEDs NSO fornecidas pela Cisco são criadas com base em atualizações baseadas em seus casos de uso. A Cisco não tenta abordar proativamente todos os modelos e versões possíveis de dispositivos, mas a NED é constantemente atualizada para atender às necessidades de uma rede em evolução e de novos casos de uso. Você pode encontrar um resumo do escopo do suporte NED fornecido pelos desenvolvedores do Crosswork NSO aqui

Note: Embora a Cisco faça o melhor para manter um ambiente de teste interno amplo, não podemos manter um ambiente que abranja todos os modelos e versões para uma grande variedade de fornecedores. Como tal, podemos exigir sua ajuda para fornecer acesso a um dispositivo que descreve o comportamento em questão.

Ao abrir um caso no TAC da Cisco para um NED fornecido pela Cisco, forneça:

• Versão do NSO
• Rastreamento NED definido para depuração em nível de log
• O rastreamento NED deve capturar uma operação compare-config ou sync-from .
• O rastreamento NED deve capturar o problema específico para o qual você deseja assistência
• Qualquer informação sobre outros dispositivos ou NEDs que também mostrem um problema
• Qualquer informação sobre dispositivos semelhantes na mesma NED que não mostre um problema

Note: Os NEDs da Netconf criados com a ferramenta NSO NED Builder não são suportados pela Cisco fora de qualquer problema com a ferramenta em si.

Tip: Para NEDs fornecidos pelos desenvolvedores do Crosswork NSO, use a tecnologia: NMS (Network Management Services and Sub-Technology, Serviços de gerenciamento de rede e subtecnologia: Network Service Orchestrator (NSO) - NED