Solución de problemas de errores externos NSO NED

Introducción

Este documento describe cómo analizar los seguimientos NED de tipo genérico y CLI e identificar la causa de los errores externos en Cisco Crosswork NSO.

Prerequisites

Requirements

• El aspecto de solución de problemas de este documento se aplica a todas las versiones de Network Element Driver (NED) compatibles actualmente y a las versiones de Cisco® Crosswork Network Service Orchestrator (NSO).
• Para solucionar los errores externos NED, necesita la capacidad de habilitar los registros de seguimiento NED y tener acceso a estos registros.
• Para evaluar con precisión los errores externos NED, se recomienda conocer el dispositivo de red administrado por NSO y su API.

Componentes Utilizados

- Crosswork NSO 6.4.3

- NED cisco-iosxr-7.64.1

Tipos de errores externos

Los errores externos NED son un signo de una interrupción de la comunicación entre el NED y el dispositivo. Se dividen en tres grandes categorías:

• El NED recibe una respuesta del dispositivo de red que no esperaba.
• El NED recibe una respuesta del dispositivo de red que viola el modelo Yang en el NED.
• El NED no recibe una respuesta dentro del tiempo asignado.

La categoría de respuestas inesperadas es con diferencia la categoría más común de errores externos que su NED puede encontrar. Incluye el dispositivo que devuelve un mensaje de error, un mensaje informativo o cualquier otro tipo de información que no coincida con lo que NSO esperaba ver devuelto. Los NED están diseñados para manejar mensajes informativos o advertencias que pueden ser ignorados de manera segura. Muchos NED tienen configuraciones de extremo disponibles para personalizar qué mensajes ignorar o qué mensajes tratar como un error externo.

Puede ver un error externo provocado por el NED cuando éste recibe información que no coincide con el modelo yang durante una operación sync-from o compare-config . Un ejemplo típico es un modelo Yang que acepta un valor de 0 a 8 para una hoja determinada, pero en la versión más reciente de este sistema operativo, el intervalo se ha aumentado de 0 a 16. El NED no acepta un valor de 16 porque está fuera del intervalo modelado. Alternativamente, el error puede producirse cuando una hoja se marca como obligatoria en el modelo yang pero no la proporciona el dispositivo o cuando el dispositivo proporciona una cadena cuando NSO espera un entero.

Para CLI y NED genéricos, no se genera ningún error externo si el NED recibe una configuración que no se modela en el modelo de NED yang. En su lugar, se registra como una skipped line en el archivo de seguimiento.

Finalmente, cuando un NED no recibe la respuesta esperada del dispositivo dentro del tiempo asignado, se genera un error externo. Esto puede suceder porque el dispositivo no responde y no envió una respuesta, pero también puede suceder cuando el NED no reconoció la respuesta del dispositivo.

Lectura de registros de seguimiento NED

Los registros de seguimiento son los mejores registros disponibles para solucionar errores externos. 

Habilitación de Registros de Seguimiento NED

Los registros de seguimiento NED se habilitan desde la CLI de 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] , utilice el end-id para el dispositivo al que se dirige con el comando.

Precaución: El comando clear-trace borra los datos de todos los registros de seguimiento NED que se encuentran actualmente en el directorio de registro. Si tiene registros de seguimiento que desea conservar para este dispositivo o para cualquier otro dispositivo, debe archivarlos antes de ejecutar este comando. En las versiones actuales de NSO, puede ejecutar clear-trace para un único dispositivo.

Nota: En caso de que no encuentre "end-settings [ned-id] logging level debug", puede saltarse este comando.

Estos comandos borran todos los datos antiguos del archivo de seguimiento y los preparan con la configuración actual del dispositivo. En este momento, reproducirá el problema encontrado utilizando ncs_cli o su servicio NSO. Si encontró el error durante una operación de confirmación, debe capturar los resultados de CLI para commit dry-run y commit dry-run outformat native para referencia futura.

En el archivo NED README puede encontrar un capítulo titulado "Cómo informar sobre problemas NED y solicitudes de funciones" para obtener instrucciones más detalladas.

CLI y NED genéricos

Los seguimientos NED para CLI y NED genéricos se seccionan en fases distintas que son útiles para la solución de problemas. Las fases más importantes que se deben comprender para solucionar los errores externos son las fases SHOW y PREPARE.

La fase SHOW se invoca cuando NSO lee información del dispositivo de red. Forma parte de la sync-from política y las compare-config operaciones. Durante este paso, NSO envía un mensaje al dispositivo con un comando como, por ejemplo, show running-config antes de leer y analizar la respuesta del dispositivo. Los mensajes salientes, enviados desde NSO al dispositivo, se dirigen con *** output mientras que los mensajes entrantes, enviados por el dispositivo a NSO, comienzan con *** input.

Nota: Los errores externos durante una operación SHOW incluyen valores que no se aceptan bajo el modelo yang actual y problemas de tiempo de espera.

La fase PREPARE se invoca como parte de las commit operaciones. Durante esta fase, NSO envía instrucciones al dispositivo. Al inicio de la fase PREPARAR, el NED imprime una lista de los cambios que NSO pretende realizar en el archivo de seguimiento. Tras este resumen inicial, NSO envía las instrucciones al dispositivo. Para determinados dispositivos, NSO envía los comandos de forma masiva, mientras que para otros dispositivos estos comandos se envían uno por uno. Este comportamiento se puede alterar usando la configuración de extremo relevante para los NED que lo soportan. Por ejemplo, cisco-iosxr-cli NED tiene la configuración NED "write number-of-lines-to-send-in-chunk <1-1000> (default 100)"

Para los NED de CLI, es común ver los comandos enviados por NSO como resultado devuelto como entrada. Esto se debe a que el comando aparece en la interfaz de usuario basada en texto del dispositivo y NSO considera todo el texto que aparece en esta interfaz de usuario como entrada. Un ejemplo en el que NSO envía comandos uno por uno puede ser similar 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

Nota: Los errores externos durante una operación de PREPARACIÓN incluyen cualquier mensaje devuelto por el dispositivo que no se ajuste a las expectativas de NSO, como errores, advertencias o mensajes informativos.

Solucionar errores externos

Al solucionar problemas de errores externos para CLI y NED genéricos: habilite el seguimiento, reproduzca el problema y examine la última fase SHOW o PREPARE, en función de las operaciones que activaron el error.

Para un problema en el que NSO se queja de un valor específico proporcionado por el dispositivo:

• ¿De qué parte de la configuración se quejó NSO?
• ¿Es correcta la configuración compartida por el dispositivo para este modelo y versión del dispositivo?
• ¿Conoce algún otro modelo o versión de dispositivo que utilice este NED y que tenga requisitos de entrada más restrictivos?

Para un problema en el que NSO genera un error externo que implica un tiempo de espera:

• ¿Cuál es el último comando enviado por NSO antes del tiempo de espera?
• ¿A qué espera NSO antes de continuar?

Puede resultar difícil determinar qué espera NSO. Algunos NED con mayor verbosidad imprimen la expresión regex que están buscando. En algunos casos, el mensaje que NSO estaba buscando no aparece en el archivo de seguimiento, pero NSO no lo reconoció y continúa esperando.

Para un problema en el que NSO genera un error externo debido a una respuesta inesperada:

• ¿Cuál es la respuesta específica que proporciona el dispositivo?
• ¿Qué comando enviado por NSO activó la respuesta?
• ¿Se espera la respuesta en función de lo que envió NSO?
• ¿Se puede ignorar la respuesta del dispositivo de forma segura o debe abortar la confirmación?
• ¿Ha enviado NSO los comandos correctos en el orden correcto?

Cuestiones Específicas Comunes:

Problema de traducción

Se produce un problema de traducción cuando NSO tiene la intención correcta, pero los comandos que envía al dispositivo no son del todo correctos. Esto puede suceder cuando una versión o modelo de dispositivo diferente que utiliza el mismo NED tiene una sintaxis ligeramente diferente. Si está utilizando una versión anterior del NED, verifique si el mismo comportamiento sigue existiendo en la última versión del NED. Además, compruebe si hay alguna configuración de extremo disponible en el archivo README-end-settings.md incluido en el NED para ver si alguna configuración le permite personalizar este comportamiento. Si el último NED todavía tiene el problema y los parámetros de extremo no tienen ningún método para resolverlo, abra un caso con TAC. Proporcionar:

• versión de NSO
• Utilizando el último NED, un seguimiento NED captura una compare-config operación seguida de una commit operación que envía el comando incorrecto.
• El comando que el NED está enviando actualmente
• El comando correcto, de preferencia mostrado como ejemplo en la CLI del dispositivo real
• La versión y el modelo del dispositivo que tiene el problema
• Cualquier otra versión y modelo de dispositivos de la red que utilice este NED y cuyo comportamiento NED actual sea correcto.

Problema de pedidos

Un problema de orden ocurre cuando el NED está enviando los comandos correctos en el orden incorrecto. Para algunos dispositivos y cargas de configuración específicas, el orden es importante. Si está utilizando una versión anterior del NED, verifique si el mismo comportamiento sigue existiendo en la última versión del NED. Además, compruebe si hay alguna configuración de extremo disponible en el archivo README-end-settings.md incluido en el NED para ver si alguna configuración le permite personalizar este comportamiento. Si el último NED todavía tiene el problema y los parámetros de extremo no tienen ningún método para resolverlo, abra un caso con TAC. Proporcionar:

• versión de NSO
• Uso del último NED y sin utilizar un servicio: Un seguimiento NED que captura una compare-config operación seguida de una commit operación que envía el orden incorrecto.
• El resultado de commit dry-run outformat native  para la confirmación defectuosa. Muestra el orden en que el NED está enviando actualmente los comandos.
• El orden correcto, de preferencia mostrado como ejemplo en la CLI del dispositivo real
• Cualquier otro requisito previo relevante para este requisito de pedido

Nota: En casos excepcionales, Cisco no puede hacer frente a un requisito de pedido a través del NED, en cuyo caso puede implementar un flujo de trabajo de varias confirmaciones o generar un informe de errores con el proveedor relevante.

Problema de valor no válido

Se produce un problema de valor no válido cuando NSO permite que se establezca un intervalo de valores distinto del que acepta el dispositivo o cuando NSO no permite el intervalo completo que permite el dispositivo. Por ejemplo, NSO permite definir un valor entre 0-15, pero el dispositivo sólo acepta valores del 0 al 8. Esto puede suceder cuando el NED se modela teniendo en cuenta un modelo y una versión de dispositivo específicos, pero otros dispositivos tienen expectativas diferentes. Si está utilizando una versión anterior del NED, verifique si el mismo comportamiento sigue existiendo en la última versión del NED. Además, compruebe si hay alguna configuración de extremo disponible en el archivo README-end-settings.md incluido en el NED para ver si alguna configuración le permite personalizar este comportamiento. Si el último NED todavía tiene el problema y los parámetros de extremo no tienen ningún método para resolverlo, abra un caso con TAC. Proporcionar:

• versión de NSO
• En el caso de que NSO permita datos que no sean aceptados por el dispositivo, utilizando el último NED: Un seguimiento NED que captura una compare-config operación seguida de un commit envío de un valor que el dispositivo rechaza.
• Para que NSO tenga una interpretación de los datos más estricta que la permitida por el dispositivo, utilice el último NED: Un seguimiento NED que captura una sync-from operación después de configurar datos en el dispositivo que actualmente NSO no acepta.
• El rango de valores correcto
• La versión y el modelo del dispositivo que tiene el problema
• Cualquier otra versión y modelo de dispositivos de la red que utilice este NED y cuyo comportamiento NED actual sea correcto.

Errores, advertencias y mensajes informativos del dispositivo:

Cuando un dispositivo responde a los comandos de NSO con un mensaje de error o de otro tipo, puede producirse un error externo en NSO. Los NSO NED tienen una lista interna de expresiones de expresiones regulares que pueden ignorarse de forma segura, así como expresiones que activan un error. Varios NED tienen configuraciones de extremo que le permiten personalizar estas listas sin la necesidad de una mejora NED. Por ejemplo: cisco-iosxr-cli NED ned-setting write config-warning.

Si el último NED no dispone de esta opción, abra un caso con el TAC. Proporcionar:

• versión de NSO
• Un seguimiento NED que captura una compare-config operación seguida de la operación que produce el error
• Una solicitud para modificar las listas internas y/o una solicitud para agregar soporte para una opción de configuración de extremo para personalizar la lista usted mismo
• El mensaje específico que el dispositivo está enviando y que causa el problema

Resoluciones

Error de usuario

Si determinó que los comandos enviados por NSO eran incorrectos, asegúrese de que los datos introducidos en NSO y en los paquetes de servicio generaron los cambios correctos. Compruebe si el resultado de commit dry-run coincide con los cambios que desea realizar y si el resultado de commit dry-run outformat native muestra los comandos y el orden correctos para provocar dichos cambios. Si el simulacro predice cambios inesperados, debe verificar las entradas en NSO o el código de servicio. Si el simulacro es correcto pero los comandos que se envían a NSO son incorrectos, verifique las resoluciones de problemas de traducción y pedido.

Dispositivo de red

En algunos casos, un error externo es el resultado de la configuración, la configuración o incluso un error en el dispositivo de red en sí, como un usuario que no tiene la autorización correcta o un dispositivo que restringe ciertas operaciones. Evalúe si la configuración o los ajustes del dispositivo se pueden modificar para permitir que NSO funcione mejor con el dispositivo.

Ned-settings

Cada NED dispone de una serie de parámetros de extremo para ayudarle a personalizar la forma en que NSO interactúa con el dispositivo. Los ajustes necesarios se documentan en el archivo README-end-settings.md dentro del NED y tienden a diferir de NED a NED. El NED cisco-iosxr-cli tiene opciones para cambiar la forma en que NSO calcula una suma de comprobación para el dispositivo, cuántos comandos se envían de forma masiva, personalizar comandos adicionales para inyectarlos según desencadenadores específicos o si el NED debe recopilar datos de configuración mediante "show running-config"  o escribiendo la configuración en un archivo del dispositivo y transfiriendo el archivo mediante sftp, lo que puede ser útil para grandes configuraciones.

Conflicto de servicio NED

Un conflicto NED-Service ocurre cuando un comportamiento problemático está presente cuando la configuración se cambia o se elimina usando un paquete de servicio pero no aparece cuando se realizan los mismos cambios de configuración sin el uso de un paquete de servicio. Este tipo de comportamiento puede aparecer como una configuración inesperada que se agrega o quita, lo que provoca errores externos en el dispositivo. Esto es típicamente el resultado de la propiedad del servicio sobre partes de la configuración. Los cambios en la configuración de CDB de NSO resultantes de un paquete de servicio pueden invalidar la lógica NED, que normalmente protegería contra cambios incorrectos. Si sospecha que encontró este comportamiento, verifíquelo intentando realizar los mismos cambios de configuración sin utilizar un paquete de servicio.

Consulte el artículo Comprender la propiedad de los servicios de NSO para obtener más información sobre la propiedad de los servicios y las posibles soluciones.

Mejoras de NED y soporte de TAC

Si no hay otras opciones disponibles, puede abrir un ticket con Cisco TAC y solicitar que se actualice el NED para que se ajuste a sus necesidades.

Las NSO NED proporcionadas por Cisco se basan en las actualizaciones basadas en sus casos prácticos. Cisco no intenta cubrir de forma proactiva todos los modelos y versiones de dispositivos posibles, pero la NED se actualiza constantemente para satisfacer las necesidades de una red en evolución y nuevos casos prácticos. Puede encontrar un resumen del alcance de la asistencia NED proporcionada por los desarrolladores de Crosswork NSO aquí

Nota: Aunque Cisco hace todo lo posible para mantener un amplio entorno de pruebas interno, no podemos mantener un entorno que cubra todos los modelos y versiones para una amplia gama de proveedores. Por lo tanto, podemos solicitar su ayuda para proporcionar acceso a un dispositivo que represente el comportamiento en cuestión.

Al abrir un caso con Cisco TAC para un NED proporcionado por Cisco, proporcione:

• Versión de NSO
• Seguimiento NED establecido en debug de nivel de registro
• El seguimiento NED debe capturar una operación compare-config o sync-from o
• El seguimiento NED debe capturar el problema concreto con el que desea ayuda
• Cualquier información sobre otros dispositivos o NED que también muestre un problema
• Cualquier información sobre dispositivos similares en el mismo NED que no muestre un problema

Nota: Cisco no admite los Netconf NED creados con la herramienta NSO NED Builder, salvo por cualquier problema que pueda surgir con la propia herramienta.

Consejo: Para los NED proporcionados por los desarrolladores de Crosswork NSO, utilice la tecnología: NMS (subtecnología y servicios de administración de redes): Network Service Orchestrator (NSO) - NED