Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Usar el administrador de instantáneas de Junos en Python (JSNAPy) en los manuales de estrategia de Ansible

Ejecute pruebas de JSNAPy como parte de un manual de estrategias de Ansible para capturar y auditar instantáneas del entorno de ejecución de los dispositivos Junos.

® El administrador de instantáneas de Junos en Python (JSNAPy) le permite capturar y auditar instantáneas del entorno de ejecución de sus dispositivos Junos. Puede capturar y verificar la configuración y el estado operativo de un dispositivo y verificar los cambios en un dispositivo. Juniper Networks proporciona un módulo de Ansible que puede utilizar para ejecutar pruebas de JSNAPy en dispositivos Junos como parte de un manual de estrategias de Ansible. En la Tabla 1 se describe el módulo disponible.

Tabla 1: Módulo JSNAPy

Colección

Conjunto de módulos

Nombre del módulo

juniper.device

juniper.device

juniper.device.jsnapy

Debe instalar Junos Snapshot Administrator en Python en el nodo de control de Ansible para poder utilizar el juniper.device.jsnapy módulo. Para obtener instrucciones de instalación e información sobre cómo crear archivos de configuración y prueba de JSNAPy, consulte el Administrador de instantáneas de Junos en la documentación de Python.

En las siguientes secciones se describe cómo utilizar el módulo en los juniper.device.jsnapy manuales de Ansible.

Descripción general del módulo

El juniper.device.jsnapy módulo le permite ejecutar funciones de JSNAPy desde un manual de estrategias de Ansible, que incluye:

  • Captura y guardado de una instantánea del entorno de ejecución

  • Comparación de dos instantáneas

  • Captura de una instantánea y evaluación inmediata

El módulo requiere especificar el action argumento y el o el config_file test_files argumento. El action argumento especifica la acción JSNAPy que se va a realizar. En la tabla 2 se describen los valores válidos action y los comandos JSNAPy equivalentes.

Tabla 2: Valores de argumento de acción jsnapy

action Valor

Descripción

Comando JSNAPy equivalente

check

Compare dos instantáneas existentes basadas en los casos de prueba dados o, si no se proporciona ningún caso de prueba, compare las instantáneas nodo por nodo.

jsnapy --check

snap_post

Tome instantáneas de los comandos o RPC especificados en los archivos de prueba después de realizar cambios en los dispositivos especificados.

jsnapy --snap

snap_pre

Tome instantáneas de los comandos o RPC especificados en los archivos de prueba antes de realizar cambios en los dispositivos especificados.

jsnapy --snap

snapcheck

Tome instantáneas de los comandos o RPC especificados en los archivos de prueba y evalúe inmediatamente las instantáneas con respecto a criterios predefinidos en los casos de prueba.

jsnapy --snapcheck

Cuando ejecuta JSNAPy en la línea de comandos, JSNAPy realiza la acción solicitada en los hosts especificados en la sección del archivo de hosts configuración. El módulo de Ansible, por otro lado, ejecuta la acción solicitada en los hosts especificados en el manual de estrategias de Ansible. Como resultado, el módulo puede hacer referencia a un archivo de configuración, ignorando la hosts sección, o puede hacer referencia directamente a uno o varios archivos de prueba.

Por lo tanto, además del action argumento, el juniper.device.jsnapy módulo también requiere que el config_file argumento o el test_files argumento especifiquen el archivo de configuración JSNAPy o los archivos de prueba JSNAPy que se utilizarán para la acción dada. La Tabla 3 describe los config_file argumentos y test_files .

Tabla 3: Argumentos de archivo jsnapy

Argumento de módulo

Valor

Información adicional

config_file

Ruta de archivo absoluta o relativa a un archivo de configuración JSNAPy.

Si la ruta es relativa, el módulo comprueba el archivo de configuración en las siguientes ubicaciones y en el orden indicado:

  • Directorio del manual de estrategias de Ansible

  • dir directorio de argumentos, si se proporciona

  • /etc/jsnapy/testfiles (solo si se omite el dir argumento)

Si el archivo de configuración hace referencia a archivos de prueba mediante una ruta de acceso de archivo relativa, el módulo comprueba primero los archivos de prueba en el directorio del cuaderno de estrategias. A continuación, comprueba los archivos de prueba en el directorio predeterminado testfiles , que variará en función de la versión de JSNAPy y de su entorno.

test_files

Ruta de archivo absoluta o relativa a un archivo de prueba JSNAPy. Este valor puede ser una ruta de un solo archivo o una lista de rutas de archivo.

Para cada archivo de prueba que especifica una ruta relativa, el módulo comprueba el archivo en las siguientes ubicaciones y en el orden indicado:

  • Directorio del manual de estrategias de Ansible

  • dir directorio de argumentos, si se proporciona

  • /etc/jsnapy/testfiles (solo si se omite el dir argumento)

Los config_file argumentos and test_files pueden tomar una ruta de archivo absoluta o relativa. Cuando utilice una ruta de acceso de archivo relativa, puede incluir opcionalmente el argumento module dir para especificar el directorio en el que residen los archivos. Si un config_file argumento or test_files utiliza una ruta de archivo relativa, el módulo primero comprueba el archivo en el directorio del manual de estrategias de Ansible, incluso si el dir argumento está presente. Si el archivo no existe en el directorio del libro de jugadas, el módulo se verifica en el directorio de dir argumentos, si se especifica, o en el directorio /etc/jsnapy/testfiles , si se omite el dir argumento. El manual genera un mensaje de error si no se encuentra el archivo.

Es importante tener en cuenta que cuando se incluye el dir parámetro, el módulo comprueba esa ubicación solo para el argumento especificado config_file test_files . Por lo tanto, cuando se especifica un archivo de configuración, el módulo no comprueba el dir directorio de los archivos de prueba que se especifican en el archivo de configuración. Si el archivo de configuración hace referencia a rutas relativas para los archivos de prueba, el módulo comprueba los archivos de prueba solo en el directorio del manual y en el directorio predeterminado testfiles .

Supongamos que tiene el siguiente archivo de configuración JSNAPy, jsnapy_config_base_tests.yaml, que reside en el directorio ~/jsnapy/testfiles y hace referencia a varios archivos de prueba JSNAPy:

En el siguiente manual de estrategia de ejemplo, se realiza la snap_pre acción para cada uno de los archivos de prueba del archivo de configuración jsnapy_config_base_tests.yaml . Si el archivo de configuración no existe en el directorio del libro de jugadas, el módulo busca el archivo en el dir directorio, que en este caso es ~/jsnapy/testfiles. El archivo de configuración utiliza rutas relativas para los archivos de prueba. Como resultado, el módulo primero busca los archivos de prueba en el directorio del libro de estrategias y, a continuación, comprueba los archivos de prueba en el directorio predeterminado testfiles .

Como alternativa, el jsnapy módulo puede utilizar el test_files parámetro para especificar los archivos de prueba individuales que se van a utilizar. El siguiente manual ejecuta las mismas pruebas que en el ejemplo del manual anterior. En este caso, el módulo primero busca los archivos de prueba en el directorio del libro de estrategias y, a continuación, comprueba los archivos de prueba en el dir directorio.

Nota:

A partir de Junos Snapshot Administrator en la versión 1.3.0 de Python, la ubicación predeterminada para la configuración y los archivos de prueba es ~/jsnapy/testfiles. Sin embargo, la ubicación predeterminada dentro de un entorno virtual o para versiones anteriores es /etc/jsnapy/testfiles.

El módulo realiza la acción solicitada en los hosts especificados en el manual de estrategias de Ansible, incluso si el módulo hace referencia a un archivo de configuración que incluye una hosts sección. El módulo informa de que falló si encuentra un error y no puede ejecutar las pruebas de JSNAPy. No informa si falla una o más de las pruebas de JSNAPy. Para verificar los resultados de la prueba JSNAPy, registre la respuesta del módulo y use el ansible.builtin.assert módulo para verificar el resultado esperado en la respuesta.

JSNAPy registra información sobre sus operaciones en el archivo /var/log/jsnapy/jsnapy.log de forma predeterminada. Opcionalmente, juniper.device.jsnapy el módulo puede incluir el logfile argumento. Su valor especifica la ruta a un archivo grabable en el nodo de control de Ansible. El nivel de detalle y las opciones de depuración de Ansible determinan el nivel de información registrado en el archivo. De forma predeterminada, solo se registran los mensajes de nivel de gravedad WARNING o superior. Para registrar mensajes iguales o superiores al nivel de gravedad INFO o al nivel de gravedad DEBUG, ejecute el manual con la -v opción de línea de comandos o -vv , respectivamente.

Cuando ejecuta pruebas de JSNAPy en un libro de jugadas de Ansible, puede guardar o resumir la información de las pruebas de JSNAPy fallidas. Para obtener más información, consulte Revisión de pruebas JSNAPy fallidas.

Tomar y comparar instantáneas

JSNAPy le permite capturar instantáneas del entorno de ejecución de sus dispositivos Junos antes y después de un cambio y luego comparar las instantáneas para verificar los cambios esperados o identificar problemas inesperados. El juniper.device.jsnapy módulo le permite tomar y comparar instantáneas de JSNAPy como parte de un manual de Ansible. El módulo guarda cada instantánea de cada host en un archivo separado en el directorio de instantáneas predeterminado de JSNAPy utilizando un nombre de archivo predeterminado. Para obtener más información sobre los archivos de salida, consulte Descripción de la salida del módulo jsnapy.

Para tomar instantáneas de línea base de uno o más dispositivos antes de realizar cambios:

  • Establezca el argumento del action módulo en snap_pre.

  • Especifique un archivo de configuración o uno o varios archivos de prueba.

En el siguiente manual se guardan las instantáneas de PRE para cada dispositivo del grupo de inventario de Ansible. La tarea hace referencia al archivo de configuración jsnapy_config_base_tests.yaml en el directorio ~/jsnapy/testfiles y registra los mensajes en el archivo jsnapy_tests.log en el directorio playbook.

Para tomar una instantánea de uno o más dispositivos después de realizar cambios:

  • Establezca el argumento del action módulo en snap_post.

  • Especifique un archivo de configuración o uno o varios archivos de prueba.

En el siguiente manual se guardan instantáneas POST para cada dispositivo del grupo de inventario de Ansible. La tarea hace referencia al mismo archivo de configuración jsnapy_config_base_tests.yaml en el directorio ~/jsnapy/testfiles y registra los mensajes en el archivo jsnapy_tests.log en el directorio playbook.

Cuando el juniper.device.jsnapy módulo realiza una snap_pre acción o una snap_post acción, guarda cada instantánea de cada host en un archivo separado utilizando nombres de archivo generados automáticamente que contienen una etiqueta 'PRE' o 'POST', respectivamente. Puede realizar una check acción para comparar las PRE instantáneas y POST para comprobar rápidamente las actualizaciones o identificar cualquier problema que pueda haber resultado de los cambios.

Cuando el módulo realiza una check acción, JSNAPy compara las instantáneas PRE y POST de cada prueba en cada dispositivo y las evalúa en función de los criterios definidos en la tests: sección de los archivos de prueba. Si los archivos de prueba no definen ningún caso de prueba, JSNAPy compara las instantáneas nodo por nodo.

Para comparar instantáneas PRE y POST:

  • Establezca el argumento del action módulo en check.

  • Especifique el mismo archivo de configuración o archivos de prueba que se usaron para tomar las instantáneas.

  • Para comprobar los resultados de la prueba, registre la respuesta del módulo y utilice el ansible.builtin.assert módulo para verificar el resultado esperado en la respuesta.

En el siguiente manual se comparan las instantáneas realizadas para las acciones ejecutadas snap_pre anteriormente y snap_post para cada dispositivo del grupo de inventario de Ansible. Los resultados se evalúan utilizando los criterios de los archivos de prueba a los que se hace referencia en el archivo de configuración. El manual registra la respuesta del módulo como 'test_result' y lo utiliza ansible.builtin.assert para verificar que todas las pruebas se aprobaron en el dispositivo dado.

Cuando ejecuta el manual de estrategias, las aserciones identifican rápidamente qué dispositivos no pasaron las pruebas.

Realizar operaciones de Snapcheck

JSNAPy le permite tomar instantáneas de los comandos o RPC especificados en los archivos de prueba de JSNAPy y evaluar inmediatamente las instantáneas con respecto a criterios predefinidos en los casos de prueba. El juniper.device.jsnapy módulo le permite realizar una operación de comprobación instantánea de JSNAPy como parte de un manual de estrategias de Ansible.

Para tomar una instantánea y evaluarla inmediatamente en función del conjunto de criterios predefinidos en la tests: sección de los archivos de prueba:

  • Establezca el argumento del action módulo en snapcheck.

  • Especifique un archivo de configuración o uno o varios archivos de prueba.

  • Para comprobar los resultados de la prueba, registre la respuesta del módulo y utilice el ansible.builtin.assert módulo para verificar el resultado esperado en la respuesta.

Por ejemplo, para cada dispositivo del grupo de inventario de Ansible, el siguiente manual guarda una instantánea independiente para cada comando o RPC en los archivos de prueba. A continuación, registra la respuesta del módulo y lo utiliza ansible.builtin.assert para verificar que todas las pruebas definidas en los archivos de prueba pasaron a ese dispositivo.

Descripción de la salida del módulo jsnapy

Cuando el juniper.device.jsnapy módulo realiza un , snap_posto snapcheck una snap_preacción, guarda automáticamente las instantáneas en el directorio de instantáneas de JSNAPy. El módulo utiliza los directorios JSNAPy predeterminados a menos que modifique el archivo de configuración JSNAPy (jsnapy.cfg) para especificar una ubicación diferente. El módulo crea un archivo independiente para cada comando o RPC ejecutado en cada dispositivo del grupo de inventario de Ansible. En la tabla 4 se describen los nombres de archivo de los archivos de instantánea para cada valor del action argumento.

Nota:

A partir de Junos Snapshot Administrator en la versión 1.3.0 de Python, los directorios predeterminados para los archivos de prueba y las instantáneas de JSNAPy son ~/jsnapy/testfiles y ~/jsnapy/snapshots, respectivamente. Sin embargo, los directorios predeterminados dentro de un entorno virtual o para versiones anteriores son /etc/jsnapy/testfiles y /etc/jsnapy/snapshots.

Tabla 4: Nombres de archivo de salida de JSNAPy

action valor

Archivos de salida

snap_pre

hostname_PRE_hash_.commandformat

snap_post

hostname_POST_hash_.commandformat

snapcheck

hostname_snap_temp_hash_command.format
o bien
hostname_PRE_hash_.commandformat

donde:

  • hostname: nombre de host del dispositivo en el que se ejecuta el comando o RPC.

  • (PRE | PUBLICAR | snap_temp): etiqueta que identifica la acción. La snapcheck operación utiliza la etiqueta en las PRE versiones actuales; en versiones anteriores, la operación utiliza la snap_temp etiqueta.

  • hash—Hash generado a partir de los archivos de kwargs prueba que incluyen las rpc claves y kwargs .

    Si los archivos de prueba utilizan la misma RPC pero incluyen argumentos diferentes, y las RPC se ejecutan en el mismo host, el hash garantiza nombres de archivo de salida únicos en esos casos. Si un archivo de prueba define la command clave o si un archivo de prueba define la rpc clave pero no incluye la kwargs clave, se omite el hash.

  • command: comando o RPC ejecutado en el dispositivo administrado. El módulo reemplaza los espacios en blanco y los caracteres especiales en el comando o nombre RPC por guiones bajos ( _ ).

  • format—Formato de la salida, por ejemplo, xml.

Nota:

El juniper.device.jsnapy módulo diferencia los nombres de archivo de instantánea para una acción determinada basándose únicamente en el nombre de host y el comando o RPC. Como resultado, si el módulo toma instantáneas en el mismo dispositivo para la misma acción utilizando archivos de prueba que definen el mismo comando o RPC, el módulo generará instantáneas con el mismo nombre de archivo y el nuevo archivo sobrescribirá el archivo anterior.

Por ejemplo, si el módulo incluye action: "snap_pre" y hace referencia a archivos de prueba que ejecutan los show chassis fpc comandos y show interfaces terse en dispositivos dc1a.example.net y dc1b.example.net, los archivos resultantes son:

Si el módulo incluye action: "snap_post" y hace referencia a un archivo de prueba que ejecuta la RPC con kwargs un elemento interface_name: lo0 en el get-interface-information dispositivo dc1a.example.net, el archivo resultante es:

Además de generar los archivos de instantánea, el juniper.device.jsnapy módulo también puede devolver las siguientes claves en la respuesta del módulo:

  • action—JSNAPy acción realizada por el módulo.

  • changed: indica si el estado del dispositivo cambió. Dado que JSNAPy solo informa sobre el estado, el valor siempre falsees .

  • failed: indica si se produjo un error en la tarea del manual.

  • msg—Resultados de la prueba JSNAPy.

Revise las pruebas de JSNAPy fallidas

Cuando ejecuta pruebas de JSNAPy en dispositivos Junos, puede verificar rápidamente si todas las pruebas de JSNAPy pasaron. Registre la respuesta del juniper.device.jsnapy módulo y use el ansible.builtin.assert módulo para verificar que sea passPercentage 100. Sin embargo, si una o más pruebas fallan, puede ser difícil identificar y extraer las pruebas fallidas si el resultado es extenso.

El juniper.device.jsnapy módulo proporciona las siguientes opciones para ver las pruebas de JSNAPy fallidas:

  • juniper.device.jsnapy complemento de devolución de llamada: imprima un resumen de las pruebas JSNAPy fallidas después de la salida del libro de estrategias.

  • dest_dir argumento de módulo: escriba las pruebas de JSNAPy fallidas en los archivos del directorio especificado.

El jsnapy complemento de devolución de llamada le permite extraer y resumir fácilmente la información de las pruebas de JSNAPy fallidas. Cuando habilita el complemento de devolución de jsnapy llamada y ejecuta un libro de jugadas que incluye pruebas de JSNAPy, el complemento resume la información de las pruebas de JSNAPy fallidas después del libro PLAY RECAPde jugadas.

El complemento de jsnapy devolución de llamada está deshabilitado de forma predeterminada. Para habilitar el complemento de devolución de jsnapy llamada, agregue la callbacks_enabled = juniper.device.jsnapy instrucción al archivo de configuración de Ansible.

Cuando habilita el complemento de devolución de jsnapy llamada y ejecuta un libro de jugadas, el complemento resume las pruebas de JSNAPy fallidas en un formato legible por humanos. Por ejemplo:

A partir de juniper.device la versión 1.0.6, el juniper.device.jsnapy módulo también admite el dest_dir argumento. Puede incluir el argumento a check favor y snapcheck las dest_dir operaciones que evalúan las instantáneas con respecto a los criterios de prueba. Cuando realiza una check operación o snapcheck e incluye el dest_dir argumento, el módulo escribe cada prueba JSNAPy fallida para un host determinado en un archivo en el directorio de salida especificado.

Por ejemplo, considere el siguiente manual de estrategias:

Cuando ejecuta el libro de estrategias, el módulo genera un archivo en el dest_dir directorio para cada prueba fallida en el host dado. Por ejemplo, el módulo generó los siguientes archivos para pruebas fallidas bgp_neighbor y bgp_summary en hosts r1 y r3.

Ejemplo: Utilice Ansible para realizar una operación de comprobación instantánea de JSNAPy

El juniper.device.jsnapy módulo le permite ejecutar pruebas de JSNAPy en dispositivos Junos como parte de un manual de estrategias de Ansible. En este ejemplo, se utiliza el jsnapy módulo para realizar una snapcheck acción para verificar el estado operativo de los dispositivos Junos después de aplicar cambios de configuración específicos.

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Nodo de control de Ansible en ejecución:

    • Python 3.10 o posterior

    • Ansible 2.17 o posterior con la juniper.device colección instalada

    • Junos PyEZ versión 2.7.3 o posterior

    • Administrador de instantáneas de Junos en Python versión 1.3.7 o posterior

Antes de ejecutar el manual de estrategias de Ansible, asegúrese de contar con lo siguiente:

  • Dispositivos Junos con NETCONF a través de SSH habilitado y una cuenta de usuario configurada con los permisos adecuados

  • Par de claves pública/privada SSH configurado para el usuario adecuado en el nodo de control de Ansible y en el dispositivo de Junos

  • Archivo de inventario de Ansible existente con los hosts necesarios definidos

Descripción general

En este ejemplo, el manual de estrategias de Ansible configura las sesiones de emparejamiento del BGP en tres dispositivos Junos y utiliza el jsnapy módulo para comprobar que la sesión del BGP está establecida para cada dirección de vecino. Si el manual verifica que las sesiones se establecieron en un dispositivo, confirma la confirmación de la nueva configuración. Si el manual no confirma la confirmación, el dispositivo Junos revierte automáticamente a la configuración confirmada anteriormente. El proyecto de Ansible define las variables de grupo y host para el manual en los group_vars directorios y host_vars , respectivamente.

El libro de jugadas tiene dos jugadas. La primera reproducción, Load and commit BGP configuration, genera y ensambla la configuración, carga la configuración en el dispositivo y la confirma mediante una operación de confirmación de confirmación. Si se actualiza la configuración, se notifica a un controlador. La obra ejecuta las siguientes tareas:

Remove build directory

Elimina el directorio de compilación existente para el dispositivo dado, si está presente.

Create build directory

Crea un nuevo directorio de compilación vacío para el dispositivo dado.

Build BGP configuration

Usa el template módulo con la plantilla Jinja2 y las variables de host para representar la configuración del BGP para el dispositivo dado y guardarla en un archivo en el directorio de compilación del dispositivo.

Assemble configuration parts

Usa el assemble módulo para ensamblar el archivo de configuración del dispositivo a partir de los archivos del directorio de compilación de ese dispositivo.

En este ejemplo, solo estará presente el archivo de configuración del BGP y, por lo tanto, el archivo de configuración resultante es idéntico al archivo de configuración del BGP representado en la tarea anterior. Si más adelante agrega nuevas tareas para generar archivos de configuración adicionales a partir de otras plantillas, el assemble módulo combinará todos los archivos en una sola configuración.

Load and commit config, require confirmation

Carga la configuración en el dispositivo Junos y confirma la configuración mediante una operación que requiere confirmación commit confirmed explícita para que la confirmación se convierta en permanente. Si esta tarea realiza un cambio en la configuración, también notifica a un controlador que detiene la ejecución del libro de estrategias durante un período de tiempo especificado. Pausar la ejecución del libro de estrategias permite a los pares del BGP establecer conexiones antes de ejecutar la segunda reproducción.

Si la configuración solicitada ya está presente en el dispositivo, el config módulo no se carga ni confirma la configuración. En este caso, el módulo devuelve changed: false, y por lo tanto no notifica al controlador.

La segunda reproducción, Verify BGP, realiza una operación JSNAPy snapcheck en cada dispositivo utilizando las pruebas de los archivos de prueba JSNAPy. Si todas las pruebas pasan, la jugada también confirma la confirmación. La obra ejecuta las siguientes tareas:

Execute snapcheck

Realiza una operación JSNAPy snapcheck , que valida que la sesión BGP esté establecida para cada uno de los vecinos del dispositivo y que no haya pares inactivos.

En este ejemplo, el libro de jugadas hace referencia directamente a los archivos de prueba JSNAPy estableciendo el test_files argumento igual a la lista de archivos de prueba JSNAPy. El dir argumento especifica el directorio que contiene los archivos de prueba.

Confirm commit

Ejecuta una operación de verificación de confirmación, que confirma la operación de confirmación anterior, siempre que la primera reproducción del libro de jugadas haya actualizado la configuración y que todas las pruebas de JSNAPy hayan pasado. Si el manual actualiza la configuración, pero no confirma la confirmación, el dispositivo Junos revierte automáticamente la configuración a la configuración confirmada anteriormente.

Nota:

Puede confirmar la operación de confirmación anterior con una commit check operación or commit en el dispositivo, que corresponde al check: true argumento or commit: true , respectivamente, en el config módulo.

Verify BGP configuration

(Opcional) Indica explícitamente si las pruebas de JSNAPy pasaron o fallaron en el dispositivo dado. Esta tarea no es un requisito específico, pero identifica más fácilmente cuándo fallan las pruebas de JSNAPy y en qué dispositivos.

Configuración

Definir las variables de grupo

Procedimiento paso a paso

Para definir las variables de grupo:

  • En el archivo group_vars/all , defina variables para el directorio de compilación y para los nombres de archivo de los archivos de configuración y registro.

Defina la plantilla de Jinja2 y las variables de host

Definir la plantilla de Jinja2

Para crear la plantilla Jinja2 que se utiliza para generar la configuración del BGP:

  1. Cree un archivo llamado bgp-template.j2 en el directorio del libro de estrategias del proyecto.

  2. Agregue la plantilla de configuración de BGP al archivo.

Defina las variables de host

Para definir las variables de host que se utilizan con la plantilla Jinja2 para generar la configuración del BGP:

  1. En el directorio host_vars del proyecto, cree un archivo independiente llamado hostname.yaml para cada host.

  2. Defina las variables para el host r1 en el archivo r1.yaml .

  3. Defina las variables para el host r2 en el archivo r2.yaml .

  4. Defina las variables para el host r3 en el archivo r3.yaml .

Crear los archivos de prueba de JSNAPy

Procedimiento paso a paso

El jsnapy módulo hace referencia a los archivos de prueba JSNAPy en el directorio ~/jsnapy/testfiles . Para crear los archivos de prueba JSNAPy:

  1. Cree el archivo jsnapy_test_file_bgp_states.yaml , el cual ejecuta el show bgp neighbor comando y comprueba que se ha establecido el estado par BGP.

  2. Cree el archivo jsnapy_test_file_bgp_summary.yaml en el que se ejecuta el show bgp summary comando y se afirma que el recuento de pares inactivos del BGP debe ser 0.

Crear el manual de estrategias de Ansible

Defina la primera jugada para configurar el dispositivo

Para crear la primera reproducción, que representa la configuración, la carga en el dispositivo y confirma la configuración como una operación confirmada de confirmación:

  1. Incluya el texto repetitivo para el libro de jugadas y la primera jugada, que ejecuta los módulos localmente.

  2. Cree las tareas que reemplacen el directorio de compilación existente con un directorio vacío, que almacenará los nuevos archivos de configuración.

  3. Cree la tarea que representa la configuración del BGP a partir del archivo de plantilla Jinja2 y las variables de host y guárdela en el archivo bgp.conf en el directorio de compilación de ese host.

  4. Cree una tarea para ensamblar los archivos de configuración en el directorio build en el archivo de configuración junos.conf final.

  5. Cree la tarea que carga la configuración en el dispositivo, realiza una operación de confirmación que requiere confirmación y notifica al controlador dado, siempre que se haya cambiado la configuración.

  6. Cree un controlador que detenga la ejecución del libro de estrategias si se actualiza la configuración del dispositivo. Establezca el tiempo de pausa en un valor adecuado para su entorno.

Defina la segunda jugada para realizar las operaciones de JSNAPy

Para crear la segunda reproducción, que realiza una operación de comprobación instantánea de JSNAPy y confirma la configuración confirmada, siempre que la configuración haya cambiado y las pruebas de JSNAPy hayan pasado:

  1. Incluya el texto repetitivo para la segunda obra, que ejecuta los módulos localmente.

  2. Cree una tarea para realizar una operación de comprobación instantánea de JSNAPy basada en las pruebas de los archivos de prueba de JSNAPy dados y registre la respuesta del módulo.

  3. Cree la tarea para confirmar la confirmación, siempre que se cumplan las condiciones dadas.

  4. (Opcional) Cree una tarea que utilice el ansible.builtin.assert módulo para afirmar que las pruebas de JSNAPy pasaron.

Resultados

En el nodo de control de Ansible, revise el manual de estrategias completado. Si el manual no muestra el código deseado, repita las instrucciones de esta sección para corregirlo.

Ejecute el manual

Para ejecutar el manual de estrategias:

  • Emita el ansible-playbook comando en el nodo de control y proporcione la ruta del libro de estrategias y las opciones deseadas.

Verificación

Verificar los vecinos del BGP

Propósito

Verifique que la sesión BGP se haya establecido para cada dirección de vecino.

Los archivos de prueba de JSNAPy prueban que la sesión BGP se establece para cada dirección de vecino y que no hay pares inactivos. El Verify BGP configuration resultado de la tarea le permite verificar rápidamente que el dispositivo dado pasó todas las pruebas de JSNAPy. Si JSNAPy passPercentage es igual al 100 por ciento, la tarea se incluye "msg": "All assertions passed" en la salida de la tarea.

Acción

Revise el resultado de la Verify BGP configuration tarea y compruebe que cada dispositivo devuelve el All assertions passed mensaje.

Significado

El All assertions passed mensaje indica que los dispositivos establecieron correctamente las sesiones BGP.

Solución de errores del manual de estrategias de Ansible

Solucionar errores de carga de configuración

Problema

El manual de estrategias de Ansible genera un ConfigLoadError error que indica que no se pudo cargar la configuración en el dispositivo debido a un error de sintaxis.

Solución

El manual representa la configuración del Junos OS mediante la plantilla Jinja2 y las variables de host definidas para ese dispositivo en el directorio host_vars . El manual genera un error de sintaxis cuando la plantilla Jinja2 produce una configuración no válida. Para corregir este error, actualice la plantilla Jinja2 para corregir el elemento identificado por la bad_element clave en el mensaje de error.

Solución de problemas de pruebas JSNAPy fallidas

Problema

La Verify BGP configuration salida de la tarea indica que se produjo un error en la aserción, ya que JSNAPy passPercentage no era igual al 100 %.

La aserción falla cuando el dispositivo no ha establecido la sesión de BGP con su vecino o cuando la sesión deja de funcionar. Si se produce un error en la aserción y la configuración de ese dispositivo se actualizó en la primera reproducción, el manual no confirma la confirmación de la nueva configuración en el dispositivo y el dispositivo revierte la configuración a la configuración confirmada anteriormente.

Solución

Las pruebas de JSNAPy pueden fallar si la snapcheck operación se realiza antes de que los pares puedan establecer la sesión o porque los vecinos del BGP no están configurados correctamente. Si la salida del manual indica que la configuración se cargó y confirmó correctamente en el dispositivo, intente aumentar el intervalo de pausa del controlador a un valor adecuado para su entorno y vuelva a ejecutar el manual.

Si las pruebas siguen fallando, verifique que la plantilla Jinja2 y las variables de host de cada dispositivo contienen los datos correctos y que la configuración resultante para cada dispositivo es correcta.

Solución de problemas de confirmaciones de confirmaciones de confirmación fallidas

Problema

La configuración no se confirmó en uno o más dispositivos.

Solución

El manual solo confirma la configuración si cambió y las pruebas de JSNAPy pasan. Si el resultado de la Load and commit config, require confirmation tarea indica que la configuración no cambió, el manual no ejecuta la tarea para confirmar la confirmación. Si la configuración cambiaba pero no se confirmaba, entonces las pruebas de JSNAPy fallaban. Las pruebas de JSNAPy pueden fallar si los vecinos del BGP no están configurados correctamente o si el manual no proporciona suficiente tiempo entre las jugadas para que los dispositivos establezcan la sesión BGP. Para obtener más información, consulte Solución de problemas de pruebas JSNAPy fallidas.