ON THIS PAGE
Use the juniper.device.junos_config Ansible Module to Configure Junos
Devices
Use the juniper.device.junos_config Ansible module and related
network resource modules to manage the configuration on devices running Junos OS and devices
running Junos OS Evolved.
Juniper Networks provides Ansible modules that enable you to manage the configuration on
Junos devices. Table 1
outlines the available modules. If you are already using a given set of modules from the
juniper.device collection, use the module for that set.
|
Collection |
Module Set |
Module Name |
|---|---|---|
|
|
||
|
|
|
In addition to the juniper.device.junos_config module, you can also use
the juniper.device.junos_* network resource modules to manage the
configuration of Junos devices. The network resource modules are standardized templates
that you can use to configure common statements and options for specific network
resources. The following sections discuss how to use the
juniper.device.junos_config module and the network resource modules
to manage the configuration on Junos devices.
Module Overview
The juniper.device.junos_config module enables you to perform
the following operations on Junos devices:
-
Archive the configuration
-
Load configuration data
-
Commit the configuration
-
Roll back the configuration
-
Reset the device to its factory-default state
The juniper.device.junos_config module enables you to back up
the configuration before applying any changes. This feature enables you to
easily archive the configuration every time you modify it. For more information,
see Back Up the Configuration.
The basic process for making configuration changes is to lock the configuration,
load the configuration changes, commit the configuration to make it active, and
then unlock the configuration. The juniper.device.junos_config
module makes changes to the candidate configuration database using
configure exclusive mode. This mode automatically locks and
unlocks the candidate global configuration. The user account that is used to
make configuration changes must have permissions to change the relevant portions
of the configuration on each device.
The juniper.device.junos_config module enables you to load
configuration data from a local file on the Ansible control node or from a list
of strings containing configuration mode commands. For more information about
specifying the source of the configuration data, see the following sections:
When loading configuration data from a local file, you can specify the load operation and the format of the changes.
-
Load operation—The load operation determines how the configuration data is loaded into the candidate configuration. You can select from many of the same load operations that are available in the Junos OS CLI.
-
Format—You can configure Junos devices using one of the standard, supported formats: text, Junos XML elements, Junos OS
setcommands, or JSON.
The juniper.device.junos_config module also enables you to roll
the configuration back to a previously committed configuration or reset a device
to factory-default configuration settings. For more information, see:
After modifying the configuration, you must commit the configuration to make it
the active configuration on the device. By default, the
juniper.device.junos_config module commits the changes to
the configuration. To alter this behavior or supply additional commit options,
see How to Commit the Configuration.
The juniper.device collection provides a number of network
resource modules. The modules are standardized templates that you can use to
configure common configuration statements and options for many network resources
on Junos devices. To determine the available network resources and use the
templates to configure resources on a device, see:
Back Up the Configuration
The juniper.device.junos_config module enables you to back up
your active configuration before you make any configuration changes. You can
execute the backup as a standalone operation or when you modify the
configuration. The module does not back up the configuration by default.
To back up the configuration, set the module's backup argument
to true. The module saves the configuration in
set format in a backup directory. The
module creates the target directory in the playbook root directory or in the
role root directory, when the playbook is part of a role. The default filename
is:
hostname_config.current-date@current-time
You can include the backup_options dictionary to change the
backup operation's default directory, filename, or configuration format.
-
To change the directory, set
dir_pathto the target directory. -
To specify the format, set
backup_formattojson,set,text, orxml. -
To change the filename, set
filenameto the destination filename. The value must include a variable such as{{ inventory_hostname }}to ensure a unique filename for each device.
The following playbook uses the juniper.device.junos_config
module to back up the configurations for the hosts in the specified inventory
group. The module saves the files in JSON format in the playbook's
config_archives subdirectory.
---
- name: Back up configuration
hosts: dc1
gather_facts: false
tasks:
- name: Back up configuration
juniper.device.junos_config:
backup: true
backup_options:
backup_format: json
dir_path: config_archives
When you run the playbook, it retrieves the configuration in JSON format and saves it to the specified directory.
user@ansible-cn:~/ansible$ ansible-playbook configuration-backup.yaml PLAY [Back up configuration] ******************************************************** TASK [Back up configuration] ******************************************************** changed: [dc1a.example.com] PLAY RECAP ************************************************************************** dc1a.example.com : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
In this example, the module uses the default filename for backup operations.
user@ansible-cn:~/ansible$ ls config_archives dc1a.example.com_config.2026-02-11@14:22:22
How to Load Configuration Data as a String
The juniper.device.junos_config module enables you to load
configuration data from a list of strings. The only supported format for loading
configuration data as a string is the set format. To load the
data, include the lines argument with a list of configuration
mode commands. You can include the following types of commands:
-
delete -
set
The following playbook configures and commits two op scripts. The module first
takes a backup of the active configuration. The module then loads the commands
in the lines argument and commits the configuration.
---
- name: Load and commit configuration
hosts: junos
gather_facts: no
tasks:
- name: Load configuration data using strings and commit
juniper.device.junos_config:
backup: true
lines:
- "set system scripts op file bgp.slax"
- "set system scripts op file bgp-neighbor.slax"
register: response
- name: Print the response
ansible.builtin.debug:
var: responseHow to Load Configuration Data from a Local File
The juniper.device.junos_config module enables you to load
configuration data from a local file on the Ansible control node. To specify the
file location, set the src argument to the absolute or relative
path of the file.
The module attempts to auto-detect the format of the configuration data in the
file. However, you can explicitly specify the format by including the
src_format argument. Supported configuration data formats
include text, Junos XML elements, Junos OS configuration mode commands, and
JSON. If you include the src_format argument, it overrides the
auto-detect format.
Table 2 outlines the module parameters that you can include to specify the location and format of the file.
|
Module Parameter |
Description |
|---|---|
|
|
Absolute or relative path to a file on the Ansible control node. Paths are relative to the root of the implemented role or playbook. |
|
|
Format of the data, specified as:
|
You can load the configuration data using many of the same load operations that
the Junos OS CLI supports. You specify the load operation by setting the
module's update argument to the value of the corresponding load
operation. Table 3 summarizes the argument values for the different load operations.
|
Load Operation |
|
Description |
|---|---|---|
|
|
|
(Default) Merge the loaded configuration with the existing configuration. |
|
|
|
Replace the entire configuration with the loaded configuration. All system processes parse the configuration. |
|
|
|
Merge the loaded configuration with the existing
configuration, but replace statements in the existing
configuration with statements in the loaded configuration
that specify the |
|
|
|
Load a complete configuration and compare it against the existing configuration. Replace only those parts of the candidate configuration that have changed. During the commit operation, only affected system processes parse the new configuration. |
The override and update load operations do
not support using Junos OS set command format.
Example: Load Configuration Data from a Local File
In the following playbook, the juniper.device.junos_config
module first takes a backup of the active configuration file. The module then
merges configuration data from the junos.conf file
referenced in the src argument. The src_format
argument explicitly defines the configuration data as text format.
---
- name: Load and commit configuration
hosts: dc1
gather_facts: no
tasks:
- name: Load configuration from a local file and commit
juniper.device.junos_config:
backup: true
update: merge
src: "build_conf/{{ inventory_hostname }}/junos.conf"
src_format: text
comment: updating config using Ansible
register: response
- name: Print the response
ansible.builtin.debug:
var: response
The playbook output confirms that the module backed up the active configuration and successfully modified the configuration.
PLAY [Load and commit configuration] ************************************************
TASK [Load configuration from a local file and commit] ******************************
changed: [dc1a.example.com]
TASK [Print the response] ***********************************************************
ok: [dc1a.example.com] => {
"response": {
"backup_path": "/home/user/ansible-project/backup/dc1a.example.com_config.2026-02-11@17:42:52",
"changed": true,
"date": "2026-02-11",
"failed": false,
"filename": "dc1a.example.com_config.2026-02-11@17:42:52",
"shortname": "/home/user/ansible-project/backup/dc1a.example.com_config",
"time": "17:42:52"
}
}
PLAY RECAP **************************************************************************
dc1a.example.com : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
How to Roll Back the Configuration
Junos devices store a copy of the most recently committed configuration and up to 49 previous configurations, depending on the platform. You can roll back to any of the stored configurations. This feature is useful when configuration changes cause undesirable results, and you want to revert back to a known working configuration. Rolling back the configuration is similar to the process for making configuration changes on the device. However, instead of loading configuration data, you perform a rollback, which replaces the entire candidate configuration with a previously committed configuration.
The juniper.device.junos_config module enables you to roll back
to a previously committed configuration on Junos devices. To roll back the
configuration and commit it, include the module’s rollback
argument, and specify the ID of the rollback configuration. Valid ID values are
0 (zero, for the most recently committed configuration) through one less than
the number of stored previous configurations (maximum is 49).
The following playbook first prompts for the rollback ID of the configuration to restore. The module then rolls back the configuration to the requested version and commits it.
---
- name: Roll back the configuration
hosts: dc1a
gather_facts: no
vars_prompt:
- name: "ROLLBACK"
prompt: "Rollback ID of the configuration to restore"
private: no
tasks:
- name: Roll back the configuration and commit
juniper.device.junos_config:
rollback: "{{ ROLLBACK }}"
comment: use Ansible to roll back configuration
register: responseuser@ansible-cn:~/ansible$ ansible-playbook configuration-rollback.yaml Rollback ID of the configuration to restore: 1 PLAY [Roll back the configuration] ************************************************** TASK [Roll back the configuration and commit] *************************************** changed: [dc1a.example.com] PLAY RECAP ************************************************************************** dc1a.example.com : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
How to Commit the Configuration
By default, when you use the juniper.device.junos_config module
to modify the configuration, the module automatically performs a commit check
and commits the changes. To perform a commit check but not commit the changes,
set check_commit: true.
You can also customize the commit operation with some of the same options that are available in the Junos OS CLI. Table 4 outlines the module arguments that you can use to specify different commit options.
|
Module Argument |
Description |
Default value |
|---|---|---|
|
|
Perform a commit check only; do not apply the changes. Confirm a previous confirmed commit operation. |
|
|
|
Log a comment for that commit operation in the system log file and in the device’s commit history. |
"configured by junos_config" |
|
|
Require that a commit operation be confirmed within a specified amount of time after the initial commit. If you do not confirm the commit in the specified time, roll back to the previously committed configuration. If you set the value to 0, the device immediately confirms the commit, which is the default behavior. Confirm the commit using either the
|
0 |
|
|
Confirm a previous confirmed commit operation. |
|
Commit Comment
When you commit the configuration, you can include a comment to describe the
purpose of the committed changes. By default, the
juniper.device.junos_config module logs the comment
"configured by junos_config". To log a custom comment
describing the changes, include the
comment: "comment string" argument
with the message string.
Commit Check
By default, the juniper.device.junos_config module executes both
a commit check and a commit operation. To perform a commit check but not commit
the changes, set check_commit to true.
Commit Confirm
To require that a commit operation be confirmed within a specified amount of time
after the initial commit, include the
confirm: minutes argument. If you do
not confirm the commit within the given time limit, the configuration
automatically rolls back to the previously committed configuration. The allowed
range is 1 through 65,535 minutes. The confirmed commit operation is useful for
verifying that a configuration change works correctly and does not prevent
management access to the device. If the change prevents access or causes other
errors, the automatic rollback to the previous configuration enables access to
the device after the rollback deadline passes. To confirm the commit operation,
invoke the juniper.device.junos_config module with the
check_commit: true argument or the
confirm_commit: true argument.
In this example, the playbook performs the following operations:
-
Backs up the configuration
-
Merges the configuration data from a local file into the candidate configuration
-
Commits the configuration with a comment. The commit requires confirmation within 10 minutes. Otherwise the device rolls back the configuration.
---
- name: Load configuration and confirm within 10 minutes
hosts: dc1
gather_facts: no
tasks:
- name: Load configuration. Confirm within 10 min.
juniper.device.junos_config:
backup: true
src: "build_conf/{{ inventory_hostname }}/junos.conf"
src_format: text
update: merge
confirm: 10
comment: "updated using Ansible"
register: response
- name: Print the response
ansible.builtin.debug:
var: response
The following playbook confirms the previous confirmed commit operation. The
playbook executes the juniper.device.junos_config module with
confirm_commit: true. In a real-world scenario, you might
perform validation tasks after the initial commit and only execute the commit
confirmation if the tasks pass certain validation criteria.
---
- name: Confirm commit
hosts: dc1
gather_facts: no
tasks:
- name: Confirm the pending commit
juniper.device.junos_config:
confirm_commit: trueRestore a Device to Factory-Default Configuration Settings
The juniper.device.junos_config module enables you to restore
Junos devices to their factory-default configuration settings. To reset devices,
set the module's zeroize argument to true.
After you restore a device to the factory-default configuration settings, you
must log in through the console as root in order to access the device.
The zeroize: true argument causes the module to execute the
request system zeroize operational command on the target
hosts. This command removes all configuration information on the specified
Routing Engines, resets all key values on the device, and then reboots the
device and resets it to the factory-default configuration settings. The zeroize
operation removes all data files, including customized configuration and log
files, by unlinking the files from their directories. It also removes all
user-created files from the system including all plaintext passwords, secrets,
and private keys for SSH, local encryption, local authentication, IPsec, RADIUS,
TACACS+, and SNMP.
The following playbook resets the hosts in the inventory group to factory-default settings. The playbook first prompts for confirmation. The user must enter 'yes' to proceed. For each device in the inventory group, the playbook takes a backup of the configuration and then resets the device.
---
- name: Restore Junos devices to factory-default configuration settings
hosts: dc1a
gather_facts: no
vars_prompt:
- name: reset_confirmation
prompt: >
This playbook resets hosts to factory-default settings!
Enter 'yes' to continue.
default: "no"
private: no
tasks:
- name: Confirmation check
fail: msg="Playbook run confirmation failed"
when: reset_confirmation != "yes"
- name: Back up configuration and reset device
juniper.device.junos_config:
backup: true
zeroize: trueUnderstanding Ansible Network Resources
Network Resources Overview
Ansible network resource modules are standardized configuration templates. They enable you to manage the configuration of network devices in a consistent, repeatable way, even in a multi-vendor environment.
For each resource, you define simple key-value pairs to specify configuration values. You also assign a state to indicate what the module should do. Network resource modules can:
-
Merge, replace, override, or delete configuration data
-
Retrieve resource details from a device
-
Render the provided configuration data into device-native format, which is useful for validating the data against a schema.
This design provides significant value because it simplifies the configuration and enables multi-vendor consistency. You do not need to memorize or look up the specific command syntax required for different devices. You can configure common networking protocols and services consistently across all supported devices in your environment.
You can find the available network resources in the following ways:
-
juniper.devicecollection documentation—The module list includes the network resource modules. -
juniper.device.junos_facts—Include theavailable_network_resources: Trueargument to retrieve a list of network resources.
The list of network resources corresponds to all of the available configuration
template modules that you can use to configure Junos devices. You can use the
configuration templates to configure common statements and options for the
available resources. For example, you can use the junos_ospfv2
module to configure the ospfv2 network resource.
For detailed information about network modules and supported states, see Network Resource Modules in the Ansible documentation
Example: Retrieve Available Network Resources
The following playbook uses the juniper.device.junos_facts
module to retrieve the available network resources for Junos devices.
---
- name: Get network resources
hosts: junos
gather_facts: false
tasks:
- name: Get available network resources
juniper.device.junos_facts:
available_network_resources: true
register: response
- name: Print available network resources
ansible.builtin.debug:
var: ansible_facts.available_network_resources
run_once: trueThe output displays the available network resources.
user@ansible-cn:~$ ansible-playbook get-network-resources.yaml
PLAY [Get network resources] ********************************************************
TASK [Get available network resources] **********************************************
ok: [router1.example.com]
TASK [Print available network resources] ********************************************
ok: [router1.example.com] => {
"ansible_facts.available_network_resources": [
"acl_interfaces",
"acls",
"bgp_address_family",
"bgp_global",
"hostname",
"interfaces",
"l2_interfaces",
"l3_interfaces",
"lacp",
"lacp_interfaces",
"lag_interfaces",
"lldp_global",
"lldp_interfaces",
"logging_global",
"ntp_global",
"ospf_interfaces",
"ospfv2",
"ospfv3",
"prefix_lists",
"routing_instances",
"routing_options",
"security_policies",
"security_policies_global",
"security_zones",
"snmp_server",
"static_routes",
"vlans"
]
}
PLAY RECAP **************************************************************************
router1.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Use the Network Resource Modules to Configure Resources
You can use the
juniper.device.junos_network-resource
modules to manage the configuration of Junos devices.
To preview the configuration in the device-native format, you can set the module
state to rendered. For example, the following playbook renders
a simple OSPFv2 configuration that configures the backbone area 0.0.0.0 with two
interfaces.
---
- name: manage OSPFv2
hosts: junos
gather_facts: false
tasks:
- name: OSPFv2 configuration
juniper.device.junos_ospfv2:
config:
- areas:
- area_id: 0.0.0.0
interfaces:
- name: ge-0/0/0.0
- name: ge-0/0/1.0
state: rendered
register: response
- name: Print response
ansible.builtin.debug:
var: response.renderedBecause the module arguments include state: rendered, the module
returns the configuration in the device-native format. It does not apply the
configuration on the devices in the Ansible inventory group.
user@ansible-cn:~$ ansible-playbook ospfv2-config.yaml
PLAY [manage OSPFv2] ****************************************************************
TASK [OSPFv2 configuration] *********************************************************
ok: [router1.example.com]
TASK [Print response] ***************************************************************
ok: [router1.example.com] => {
"config.rendered": "<nc:protocols xmlns:nc=\"urn:ietf:params:xml:ns:netconf:base:1.0\"><nc:ospf><nc:area><nc:name>0.0.0.0</nc:name><nc:interface><nc:name>ge-0/0/0.0</nc:name></nc:interface><nc:interface><nc:name>ge-0/0/1.0</nc:name></nc:interface></nc:area></nc:ospf></nc:protocols>"
}
PLAY RECAP **************************************************************************
router1.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 To apply the configuration, set the state to the appropriate
value. The following playbook merges the configuration on the devices in the
Ansible inventory group.
---
- name: manage OSPFv2
hosts: junos
gather_facts: false
tasks:
- name: OSPFv2 configuration
juniper.device.junos_ospfv2:
config:
- areas:
- area_id: 0.0.0.0
interfaces:
- name: ge-0/0/0.0
- name: ge-0/0/1.0
state: merged
register: response
- name: Print response
ansible.builtin.debug:
var: response
When you configure the device using a network resource module, the playbook output shows the before and after state. In this example, the device does not initially include any OSPF configuration.
user@ansible-cn:~$ ansible-playbook ospfv2-config.yaml
PLAY [manage OSPFv2] ****************************************************************
TASK [OSPFv2 configuration] ****************************************************
changed: [router1.example.com]
TASK [Print response] ***************************************************
ok: [router1.example.com] => {
"response": {
"after": [
{
"areas": [
{
"area_id": "0.0.0.0",
"interfaces": [
{
"name": "ge-0/0/0.0"
},
{
"name": "ge-0/0/1.0"
}
]
}
]
}
],
"before": [],
"changed": true,
"commands": [
"<nc:protocols xmlns:nc=\"urn:ietf:params:xml:ns:netconf:base:1.0\"><nc:ospf><nc:area><nc:name>0.0.0.0</nc:name><nc:interface><nc:name>ge-0/0/0.0</nc:name></nc:interface><nc:interface><nc:name>ge-0/0/1.0</nc:name></nc:interface></nc:area></nc:ospf></nc:protocols>"
],
"failed": false
}
}
PLAY RECAP **************************************************************************
router1.example.com : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0