Utilice el juniper.device.config módulo de Ansible para recuperar o comparar configuraciones de Junos OS

Cuando utilice el juniper.device.config módulo para recuperar la configuración, debe incluir el retrieve parámetro en la lista de argumentos del módulo. El retrieve parámetro especifica la base de datos de configuración de la que se van a recuperar los datos. Puede establecer retrieve los siguientes valores para devolver los datos de configuración de la base de datos correspondiente:

• candidate: recupere datos de la configuración candidata.

• committed: recupere los datos de la configuración confirmada.

Base de datos de configuración confirmada

En el siguiente manual, se recupera la configuración completa confirmada en formato de texto para cada dispositivo del grupo de inventario:

Base de datos de configuración del candidato

En el siguiente manual, se recupera la configuración completa del candidato en formato de texto para cada dispositivo del grupo de inventario. El módulo devuelve un error si la base de datos está bloqueada o modificada.

Además de recuperar la configuración completa de Junos OS, puede recuperar partes específicas de la configuración mediante el filter parámetro. El filter valor del parámetro es una cadena que contiene el filtro de subárbol que selecciona las instrucciones de configuración que se van a devolver. El filtro de subárbol devuelve los datos de configuración que coinciden con los criterios de selección. Si solicita varias jerarquías, el valor de filter debe representar todos los niveles de la jerarquía de configuración, empezando por la raíz (representada por el <configuration> elemento) hasta cada elemento que se va a mostrar.

El siguiente manual recupera e imprime la configuración en los [edit interfaces] niveles y [edit protocols] jerarquía de la base de datos de configuración confirmada para cada dispositivo:

El siguiente manual recupera e imprime la configuración de la interfaz ge-1/0/1:

El siguiente manual recupera e imprime la configuración confirmada en el [edit system services] nivel de jerarquía:

Cuando se usa el juniper.device.config módulo para recuperar la configuración, el módulo invoca la operación del protocolo <get-configuration> XML de Junos, la cual puede devolver datos de configuración en diferentes formatos. De forma predeterminada, el módulo devuelve los datos de configuración como texto con formato. El formato de texto utiliza nuevas líneas, tabulaciones y otros espacios en blanco, llaves y corchetes para indicar las relaciones jerárquicas entre las instrucciones.

Para especificar el formato en el que se devolverán los datos de configuración, establezca el parámetro del format módulo igual al formato requerido. Los valores aceptables incluyen:

• json—Notación de objetos JavaScript (JSON)

• set—Comandos de Junos OS set

• text—Texto con formato (predeterminado)

• xml—Elementos XML de Junos

En la salida del manual de estrategias, las config claves y config_lines contienen la configuración en el formato solicitado. Si solicita el formato XML o JSON de Junos, la config_parsed clave contiene la configuración equivalente en formato JSON.

En el siguiente manual, se recupera la configuración completa confirmada para cada dispositivo del grupo de inventario en formato XML:

Los dispositivos Junos devuelven respuestas RPC en formato XML. Incluso cuando solicita datos en formato JSON, set o de texto, la respuesta del servidor NETCONF envuelve los datos en etiquetas XML. Por lo tanto, los módulos de Ansible deben usar un analizador XML para manejar la respuesta RPC. Los analizadores XML a menudo imponen límites de seguridad en la profundidad del documento y el tamaño de los nodos de texto individuales. Estos límites son una medida de seguridad integrada para evitar ataques maliciosos, agotamiento de la memoria y problemas generales de rendimiento.

Los dispositivos de red pueden tener configuraciones grandes y complejas y una amplia salida de comandos y RPC. De forma predeterminada, el analizador XML impone un límite de tamaño para los nodos de texto, que generalmente es de alrededor de 10 MB. Cuando un solo nodo de texto supera el límite de tamaño, el analizador genera un error. Por ejemplo:

Por lo general, si solicita datos de configuración, comando o RPC en formato XML, el documento contiene muchos nodos XML pequeños y el analizador no encuentra este límite, excepto en casos excepcionales. Sin embargo, si solicita los mismos datos en formato JSON, set o de texto, el dispositivo devuelve los datos envueltos en una o varias etiquetas XML. Por ejemplo, además de la <rpc-reply> etiqueta, el dispositivo encapsula, ensambla y textúa los datos de configuración en una <configuration-set> etiqueta o una <configuration-text> etiqueta, según corresponda. Del mismo modo, el dispositivo encierra la salida de comandos en formato de texto en un <output> elemento. Para datos extensos, la respuesta puede dar como resultado un único nodo de texto XML que supere los límites predeterminados del analizador.

Cuando solicita configuraciones grandes o un comando extenso o salida RPC en cualquier formato, el analizador XML maneja la respuesta RPC. Por lo tanto, puede encontrar el error de límite de tamaño de nodo para todos los formatos, aunque es más raro para los datos XML. En estos casos, recomendamos devolver la respuesta como XML.

Si necesita uno de los otros formatos, puede anular los límites del analizador incluyendo el huge_tree: true argumento module. Cuando se usa huge_tree: true, se habilita la XML_PARSE_HUGE opción, que ignora los límites en el tamaño máximo del nodo de texto, el tamaño máximo de atributo y la profundidad máxima. Como resultado, el analizador puede procesar documentos XML grandes, árboles XML profundos y nodos de texto grandes.

En el siguiente manual, se recupera la configuración confirmada en set formato para los dispositivos del grupo de inventario. Los argumentos del juniper.device.config módulo incluyen huge_tree: true. Con esta opción, la tarea tiene éxito incluso si una respuesta específica supera el límite de tamaño de nodo predeterminado del analizador.

Puede cargar módulos YANG estandarizados o personalizados en dispositivos Junos para agregar modelos de datos que no son compatibles de forma nativa con Junos OS, pero que pueden ser compatibles con la traducción. Los modelos de datos no nativos se configuran en la configuración candidata con la sintaxis definida para esos modelos. Cuando confirma la configuración, los scripts de traducción del modelo de datos traducen esos datos y confirman la configuración de Junos OS correspondiente como un cambio transitorio en la configuración de checkout.

Las configuraciones candidatas y activas contienen los datos de configuración para modelos de datos YANG no nativos en la sintaxis definida por esos modelos. Puede utilizar el módulo para recuperar datos de juniper.device.config configuración para modelos de datos YANG estándar (GTI-I, OpenConfig) y personalizados, además de recuperar la configuración nativa de Junos OS. De forma predeterminada, la respuesta del módulo no incluye los datos de configuración de modelos de datos YANG de terceros.

Para recuperar los datos de configuración definidos por un modelo de datos YANG no nativo, además de recuperar la configuración de Junos OS, ejecute el módulo con el model parámetro e inclúyalo namespace cuando corresponda. El model argumento toma uno de los siguientes valores:

• custom: recupere datos de configuración definidos por modelos de datos YANG personalizados. Debe incluir el namespace argumento al recuperar datos para modelos de datos de YANG personalizados.

• ietf: recupere los datos de configuración definidos por los modelos de datos de YANG de GTI-I.

• openconfig: recupere los datos de configuración definidos por los modelos de datos YANG de OpenConfig.

• True: recupere todos los datos de configuración, incluida la configuración completa de Junos OS y los datos de cualquier modelo de datos de YANG.

Si el model argumento especifica ietf o openconfig, el módulo utiliza automáticamente el espacio de nombres adecuado. Si especifica model: custom que se recuperen datos para un modelo de datos YANG personalizado, también debe incluir el namespace argumento con el espacio de nombres correspondiente.

Si incluye el model argumento con el valor custom, o ietfopenconfig y también incluye el filter argumento para devolver un subárbol XML específico, Junos OS solo devuelve la jerarquía coincidente del modelo de datos no nativo. Si la configuración de Junos OS contiene una jerarquía del mismo nombre, por ejemplo, "interfaces", no se incluye en la respuesta. La filter opción no se admite cuando se usa model: True.

Cuando se utiliza el juniper.device.config módulo para recuperar datos de configuración no nativos, solo se puede especificar el formato de los datos devueltos si también se incluye el filter parámetro. Si omite el filter parámetro, debe especificar format: xml.

El siguiente manual recupera la jerarquía de configuración de OpenConfig interfaces de la configuración confirmada. Si omite el filter argumento, la RPC devuelve las configuraciones completas de Junos OS y OpenConfig.

La siguiente tarea recupera la l2vpn jerarquía de configuración de la configuración confirmada para un modelo de datos YANG personalizado con el espacio de nombres dado:

La siguiente tarea recupera la configuración completa confirmada de Junos OS, así como los datos de configuración de otros modelos de datos de YANG que se agregaron al dispositivo:

Cuando se usa el juniper.device.config módulo para recuperar la configuración, el módulo invoca la operación del protocolo <get-configuration> XML de Junos. El módulo admite argumentos explícitos para muchos de los <get-configuration> atributos, por ejemplo, el format atributo. El módulo también admite el options argumento, lo que le permite incluir cualquier atributo adicional <get-configuration> que no tenga un argumento de módulo equivalente. El options argumento toma un diccionario de pares clave/valor de cualquier atributo admitido por la <get-configuration> operación.

Para obtener la lista completa de atributos admitidos por la operación del protocolo <get-configuration> XML de Junos, consulte <get-configuration>.

Por ejemplo, el juniper.device.config módulo recupera datos de la configuración anterior a la herencia, en la que , , y <interface-range> las <groups><apply-groups><apply-groups-except>etiquetas son elementos independientes en la salida de la configuración. Para recuperar datos de la configuración posterior a la herencia, puede incluir el argumento con inherit: inherit.options La configuración posterior a la herencia muestra las instrucciones heredadas de grupos y rangos definidos por el usuario como hijos de las instrucciones heredadas,

El siguiente manual recupera los datos de configuración en el nivel de jerarquía de la configuración confirmada posterior a la [edit system services] herencia. En la configuración posterior a la herencia, las instrucciones configuradas en niveles de jerarquía de grupo, como los que [edit groups global system services] se heredan y [edit system services] se devuelven en los datos de configuración recuperados.

Cuando utilice el juniper.device.config módulo para recuperar la configuración, puede guardar los datos de configuración devueltos en un archivo en el nodo de control de Ansible local. Para guardar los datos en un archivo, incluya el módulo dest_dir o dest el parámetro. La dest_dir opción especifica una ruta de directorio. La dest opción puede especificar una ruta y un nombre de archivo. Si ya existe un archivo de salida con el nombre de destino, el módulo sobrescribe el archivo.

Para especificar el directorio en el que se guardarán las configuraciones recuperadas, establezca el dest_dir argumento en la ruta del directorio de destino. La configuración de cada dispositivo se almacena en un archivo independiente llamado hostname.config.

En el siguiente manual, se recupera la configuración confirmada de todos los dispositivos del grupo de inventario. El manual guarda cada configuración de dispositivo en un archivo independiente en el directorio configs, en el directorio playbook del nodo de control de Ansible.

Para especificar la ruta y el nombre de archivo de los archivos de salida, establezca el dest argumento en la ruta absoluta o relativa del archivo. Si incluye el dest argumento, pero omite el directorio, los archivos se guardan en el directorio del libro de estrategias. Si recupera la configuración para varios dispositivos, el dest argumento debe incluir una variable como {{ inventory_hostname }} para diferenciar el nombre de archivo de cada dispositivo. Si no diferencia los nombres de archivo, el archivo de configuración de cada dispositivo sobrescribirá el archivo de configuración de los demás dispositivos.

El siguiente manual recupera la [edit system services] jerarquía de la base de datos de configuración confirmada en todos los dispositivos del grupo de inventario. El manual guarda cada configuración de dispositivo en un archivo independiente en el directorio del playbook en el nodo de control de Ansible. Cada archivo se identifica de forma única por su nombre de host.

Si está guardando los datos de configuración en archivos y no desea duplicar los datos de configuración en la respuesta del módulo, puede incluirlos return_output: false opcionalmente en la lista de argumentos del módulo. Establecer return_output en hace que false el módulo omita las configteclas , config_linesy en config_parsed su respuesta. Esto puede ser necesario si el dispositivo devuelve una cantidad significativa de datos de configuración.

El juniper.device.config módulo le permite comparar la configuración activa con una configuración previamente confirmada o una configuración de reversión. Para comparar la configuración activa con una configuración anterior, incluya los siguientes argumentos de módulo:

De forma predeterminada, cuando se incluye el rollback: id argumento, el módulo revierte la configuración, realiza una comprobación de confirmación y confirma los cambios. Debe incluir el commit: false argumento para comparar solo las configuraciones y evitar que el módulo cargue y confirme la configuración de reversión. Incluir el check: false argumento evita la operación de comprobación de confirmación innecesaria.

El módulo devuelve las diff claves y diff_lines . Las claves contienen las diferencias de configuración entre la configuración activa y la anterior en formato diff o patch.

• diff: diccionario que contiene una sola clave con nombre prepared y su valor, que es una sola cadena de varias líneas que contiene las diferencias.

• diff_lines—Lista de cadenas de una sola línea que contienen las diferencias.

Para guardar las diferencias en un archivo del nodo de control de Ansible local, incluya el diffs_file argumento y defina la ruta absoluta o relativa del archivo de salida. Si incluye el diffs_file argumento pero omite el directorio, los archivos se guardan en el directorio del libro de estrategias. Si compara las configuraciones en varios dispositivos, el diffs_file argumento debe incluir una variable como {{ inventory_hostname }} para diferenciar el nombre de archivo de cada dispositivo. Si no diferencia los nombres de archivo, el archivo de salida de cada dispositivo sobrescribirá el archivo de salida de los demás dispositivos.

En el siguiente cuaderno de estrategias, se solicita el ID de reversión de una configuración confirmada anteriormente. Luego, el manual compara la configuración confirmada con la configuración de reversión especificada, guarda la comparación en un archivo con un nombre único e imprime la respuesta a la salida estándar.