Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Using Ansible to Retrieve or Compare Junos OS Configurations

 

Juniper Networks provides support for using Ansible to manage the configuration of devices running Junos OS. The juniper_junos_config module in the Juniper.junos role enables you to retrieve or compare Junos OS configurations. You can use the module to request the complete configuration or selected configuration hierarchies of devices running Junos OS, and you can compare the active configuration with previously committed configurations.

Note

Starting in Ansible for Junos OS Release 2.0.0, the juniper_junos_config module combines and replaces the functionality of the junos_commit, junos_get_config, junos_install_config, and junos_rollback modules.

To retrieve the configuration from a device running Junos OS, execute the juniper_junos_config module with the retrieve parameter. The module’s response includes the configuration in text format in the config, config_lines, and config_parsed keys, unless the return_output option is set to false.

The following sections discuss how to use the juniper_junos_config module to retrieve or compare Junos OS configurations.

Specifying the Source of the Configuration Data to Return

When you use the juniper_junos_config module to retrieve the configuration, you must include the retrieve parameter in the module argument list and specify the configuration database from which to retrieve the data. You can retrieve data from the candidate configuration database or from the committed configuration database by setting retrieve to 'candidate' or 'committed', respectively.

For example, the following playbook retrieves the complete committed configuration for each device in the inventory group:

Specifying the Format of the Configuration Data to Return

When you use the juniper_junos_config module to retrieve the configuration, the module invokes the Junos XML protocol <get-configuration> operation, which can return Junos OS configuration data as CLI configuration statements, Junos XML elements, Junos OS set commands, or JavaScript Object Notation (JSON). By default, the juniper_junos_config module returns configuration data as CLI configuration statements, or text format, which uses newlines, tabs and other white space, braces, and square brackets to indicate the hierarchical relationships between the statements.

To specify the format in which to return the configuration data, include the format parameter in the module argument list and set the value equal to the desired format. To explicitly request text format, or to request Junos XML elements, Junos OS set commands, or JSON format, set the format value to 'text', 'xml', 'set', or 'json', respectively.

The following playbook retrieves the complete committed configuration for each device in the inventory group in XML:

Specifying the Scope of the Configuration Data to Return

In addition to retrieving the complete Junos OS configuration, the juniper_junos_config module can retrieve specific portions of the configuration by including the filter parameter in the module argument list. The filter parameter takes a string containing the subtree filter that selects the configuration statements to return. The subtree filter returns the configuration data that matches the selection criteria. When multiple hierarchies are requested, the value of filter must represent all levels of the configuration hierarchy starting at the root (represented by the <configuration> element) down to each element to display.

The following playbook retrieves and prints the configuration at the [edit interfaces] and [edit protocols] hierarchy levels in the committed configuration database:

The following playbook retrieves and prints the configuration for the ge-1/0/1 interface:

The following playbook retrieves and prints the configuration committed at the [edit system services] hierarchy level:

Specifying Options That Do Not Have an Equivalent Module Argument

When you use the juniper_junos_config module to retrieve the configuration, the module invokes the Junos XML protocol <get-configuration> operation. The module supports explicit arguments for many of the <get-configuration> attributes, for example, the format attribute. The module also supports the options argument, which enables you to include any additional <get-configuration> attributes that do not have an equivalent juniper_junos_config argument. The options argument takes a dictionary of key/value pairs of any attributes supported by the <get-configuration> operation.

For the complete list of attributes supported by the Junos XML protocol <get-configuration> operation, see https://www.juniper.net/documentation/en_US/junos/topics/reference/tag-summary/junos-xml-protocol-get-configuration.html.

For example, the juniper_junos_config module retrieves data from the pre-inheritance configuration, in which the <groups>, <apply-groups>, <apply-groups-except>, and <interface-range> tags are separate elements in the configuration output. To retrieve data from the post-inheritance configuration, which displays statements that are inherited from user-defined groups and ranges as children of the inheriting statements, you can include the options argument with inherit: "inherit".

For example, the following playbook retrieves the configuration committed at the [edit system services] hierarchy level from the post-inheritance committed configuration. In this case, if the configuration also contains statements configured at the [edit groups global system services] hierarchy level, those statements would be inherited under [edit system services] in the post-inheritance configuration and returned in the retrieved configuration data.

Saving Retrieved Configuration Data To a File

When you use the juniper_junos_config module to retrieve the configuration, you can save the returned configuration data in a file on the local Ansible control machine by including the dest or dest_dir module arguments. To specify the directory on the local Ansible control machine where the retrieved configurations are saved, include the dest_dir argument, and define the path to the target directory. The configuration for each device is stored in a separate file named hostname.config.

The following playbook retrieves the [edit system services] hierarchy from the committed configuration database on all devices in the inventory group and saves each device configuration to a separate file in the playbook directory on the Ansible control machine:

To specify the path and filenames to which the retrieved configurations are saved on the local Ansible control machine, include the dest argument, and define the filename or the full path of the file. If you include the dest argument, but omit the directory, the files are saved in the playbook directory. If you retrieve the configuration for multiple devices, the dest argument must include a variable such as {{ inventory_hostname }} to differentiate the filename for each device. If you do not differentiate the filenames, the configuration file for each device will overwrite the configuration file of the other devices.

The following playbook retrieves the [edit system services] hierarchy from the committed configuration database on all devices in the inventory group and saves each device configuration to a separate file in the playbook directory on the Ansible control machine. Each file is uniquely identified by the device hostname.

If you are saving the configuration data to files and do not want to duplicate the configuration data in the module’s response, you can you can optionally include return_output: false in the juniper_junos_config argument list. Setting return_output to false causes the module to omit the config, config_lines, and config_parsed keys in the module’s response. Doing this might be necessary if the devices return a significant amount of configuration data.

Comparing the Active Configuration to a Previous Configuration

The juniper_junos_config module enables you to compare the active configuration to a previously committed configuration, or rollback configuration. To compare the active configuration to a previous configuration, include the diff: true and rollback: id arguments in the module’s argument list. By default, when you include the rollback: id argument, the module reverts the candidate configuration to the specified configuration and commits the changes. To only compare the configurations and prevent the module from loading and committing the rollback configuration, you must also include the commit: false argument.

The module returns the diff and diff_lines keys, which contain the configuration differences between the active and previous configuration. diff is a multi-line string and diff_lines is a list of single line strings, both in diff or patch format.

To save the differences to a file on the local Ansible control machine, include the diffs_file argument, and define the filename or the full path of the output file. If you include the diffs_file argument but omit the directory, the files are saved in the playbook directory. If you compare the configurations on multiple devices, the diffs_file argument must include a variable such as {{ inventory_hostname }} to differentiate the filename for each device. If you do not differentiate the filenames, the output file for each device will overwrite the output file of the other devices.

The following playbook prompts for the rollback ID of a previously committed configuration, compares the committed configuration to the specified rollback configuration, saves the comparison to a uniquely-named file, and also prints the response to standard output:

user@ansible-cm:~$ ansible-playbook configuration-compare-to-rollback.yaml
user@ansible-cm:~$ cat dc1a.example.net-diff-rollback-2
Release History Table
Release
Description
Starting in Ansible for Junos OS Release 2.0.0, the juniper_junos_config module combines and replaces the functionality of the junos_commit, junos_get_config, junos_install_config, and junos_rollback modules.