Use the juniper.device.junos_command and
juniper.device.junos_rpc Ansible Modules to Execute Commands and
RPCs
You can use the juniper.device.junos_command and
juniper.device.junos_rpc Ansible modules to execute operational mode
commands and RPCs on devices running Junos OS and devices running Junos OS
Evolved.
Juniper Networks provides Ansible modules that you can use to execute operational mode
commands and remote procedure calls (RPCs) on Junos devcies. Table 1 outlines the modules. If you are already using a given set of modules from the
juniper.device collection, use the modules for that set.
|
Collection |
Module Set |
Module Name |
|---|---|---|
|
|
|
|
|
|
The following sections discuss how to the use the
juniper.device.junos_command and
juniper.device.junos_rpc modules and what to expect in the module
response. Table 2 briefly summarizes the modules' supported actions.
| Module | Action | Module Arguments |
Supported Ansible Connections |
|---|---|---|---|
|
|
Execute one or more CLI commands |
|
|
|
Execute one or more RPCs and optionally include RPC arguments |
|
|
|
| Evaluate command or RPC output |
|
|
|
|
|
Execute an RPC and optionally include RPC arguments and attributes |
|
|
Execute Commands with the junos_command Module
The juniper.device.junos_command module enables you to execute
operational mode commands on Junos devices. The module requires one argument,
commands, which can be a single command or a list of one or
more commands to execute on the device.
The following playbook executes two commands on each device in the inventory group. The playbook displays the module response in standard output (stdout).
---
- name: Get device information
hosts: junos
gather_facts: no
tasks:
- name: Get version and uptime information
juniper.device.junos_command:
commands:
- show version
- show system uptime
register: junos_result
- name: Print response
ansible.builtin.debug:
var: junos_result
For information about the module’s response and output format, see Understanding the Module Response and Specify the Format for Command or RPC Output.
Execute RPCs with the junos_command or junos_rpc
Module
The Junos XML API is an XML representation of Junos OS configuration statements and operational mode commands. It defines an XML equivalent for all statements in the Junos OS configuration hierarchy and many of the operational mode commands that you issue in the Junos OS CLI. Each operational mode command with a Junos XML counterpart maps to a request tag element and, if necessary, a response tag element. Request tags are used in RPCs within NETCONF or Junos XML protocol sessions to request information from a Junos device. The server returns the response using Junos XML elements enclosed within the corresponding response tag element.
For information about mapping CLI commands to RPC request tags, see the Junos XML API Explorer for operational tags.
The juniper.device.junos_command module and the
juniper.device.junos_rpc module enable you to execute RPCs
on Junos devices. The junos_command module enables you to
execute multiple RPCs in a single task with the option to include inline RPC
arguments. The junos_rpc module enables you to execute a single
RPC with the option to include RPC arguments and attributes. The following
sections show how to use the modules to execute RPCs.
junos_command Module
To use the junos_command module to execute RPCs, include the
rpcs parameter. The rpcs parameter can
be a single RPC request tag or a list of RPC request tags. You can
optionally include any number of RPC arguments that are supported by that
RPC. Specify the arguments inline as
key=value
pairs. The following playbook uses the junos_command module
to execute multiple RPCs:
---
- name: Execute multiple RPCs with junos_command
hosts: junos
gather_facts: no
tasks:
- name: Get version, uptime, and interface information
juniper.device.junos_command:
rpcs:
- get-software-information
- get-system-uptime-information
- get-interface-information interface-name=ge-0/0/1 terse=true
register: junos_result
- name: Print response
ansible.builtin.debug:
var: junos_resultjunos_rpc Module
To use the junos_rpc module to execute a single RPC, include
the rpc parameter and specify the RPC to execute. The
following playbook executes the get-software-information
RPC on each device in the inventory group and displays the module response
in stdout. The RPC is equivalent to the show version
operational mode command.
---
- name: Execute a single RPC with junos_rpc
hosts: junos
gather_facts: no
tasks:
- name: Get version information
juniper.device.junos_rpc:
rpc: get-software-information
register: junos_result
- name: Print response
ansible.builtin.debug:
var: junos_resultjunos_rpc Module with Arguments and Attributes
The junos_rpc module supports the args and
attrs options. Use the args option to
specify a dictionary of RPC arguments and values. If an individual RPC
argument does not require a value, set its value equal to
true. Use the attrs option to specify
a dictionary of attributes for the RPC.
You can use a hyphen or an underscore in RPC argument names. For example,
you can represent the interface-name argument as
interface-name or
interface_name.
The following playbook executes the
get-interface-information RPC on each device in the
inventory group and displays the module response in stdout. The module
arguments include the args option to request terse level
output for the lo0.0 interface only. The RPC is equivalent to the
show interfaces lo0.0 terse operational mode
command.
---
- name: Execute an RPC with arguments
hosts: junos
gather_facts: no
tasks:
- name: Get device information
juniper.device.junos_rpc:
rpc: get-interface-information
args:
interface_name: lo0.0
terse: true
register: junos_result
- name: Print response
ansible.builtin.debug:
var: junos_result
The following playbook executes the <get-configuration
database="candidate" inherit="inherit"/> RPC on each device
in the inventory group. The attrs option includes the
database and inherit RPC attributes.
The RPC returns the post-inheritance candidate configuration for each
device.
---
- name: Execute an RPC with attributes
hosts: junos
gather_facts: no
tasks:
- name: Get the post-inheritance candidate configuration
juniper.device.junos_rpc:
rpc: get-configuration
attrs:
database: candidate
inherit: inherit
register: junos_result
- name: Print response
ansible.builtin.debug:
var: junos_resultFor information about the module’s response and output format, see Understanding the Module Response and Specify the Format for Command or RPC Output.
Evaluate Command and RPC Output
The junos_command module enables you to evaluate output as part of
the task. If the specified conditions are false, the task fails, and the playbook
skips the remaining tasks for that device. A playbook might evaluate the output in
order to determine whether to perform the remaining tasks on a device. For example,
if the model or Junos OS version does not match a specified condition, the playbook
might skip subsequent installation or configuration tasks for that device.
You can use junos_command to evaluate command or RPC output.
However, the following requirements must be met:
-
The Ansible connection must be set to
ansible.netcommon.netconf. -
The match conditions must use the appropriate syntax for the requested format.
You use the wait_for argument to specify the conditions to evaluate.
If you define multiple conditions, you can include the match
argument to define the match policy. Set match to
all to indicate that all conditions must be satisfied.
Alternatively, set match to any if only one
condition must be satisfied.
You can evaluate conditions in the output of multiple commands. To define conditions
for different command output, reference the result for that command, for example,
result[0] for the first command, result[1] for
the second command, and so on.
You can also evaluate conditions using any output format. However, the conditions
must use the appropriate syntax for that format. For example, for text and set
formats, use string operators like contains or
matches. For XML and JSON output, specify the appropriate
dictionary path.
The following playbook executes the show version command and checks
for the model number and version number in the command output, which defaults to
text format.
---
- name: Validate text output
hosts: junos
gather_facts: no
tasks:
- name: Validate text output for model and version
juniper.device.junos_command:
commands: show version
wait_for:
- result[0] contains mx240
- result[0] contains 23.2R2.21
match: all
The task includes match: all. Thus, the task passes for a given
device if all of the conditions are true. If the conditions are not met, the task
fails with an error, and the playbook ignores any remaining tasks for that device.
In the following output, the first device matches all of the specified criteria and the task succeeds. The second device does not match one of the conditions and thus the task fails.
user@ansible-cn:~$ ansible-playbook junos-command-evaluate-output.yaml
PLAY [Validate text output] ********************************************************
TASK [Validate text output for model and version] **********************************
ok: [198.51.100.1]
[ERROR]: Task failed: Action failed: One or more conditional statements have not been satisfied
[...output omitted...]
fatal: [198.51.100.2]: FAILED! => {"changed": false, "failed_conditions": ["result[0] contains 23.2R2.21"], "msg": "One or more conditional statements have not been satisfied"}
PLAY RECAP *************************************************************************
198.51.100.2 : ok=0 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0
198.51.100.1 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Similarly, you can evaluate RPC output. The following playbook uses the
junos_command module with the equivalent RPC to perform the
same evaluation as in the previous example. The task requests text output instead of
the default RPC output format, which is XML.
---
- name: Validate text output
hosts: junos
gather_facts: no
tasks:
- name: Validate text output for model and version
juniper.device.junos_command:
rpcs: get-software-information
display: text
wait_for:
- result[0] contains mx240
- result[0] contains 23.2R2.21
match: allTo evaluate XML output, update the wait_for conditions to use the
appropriate dictionary paths.
---
- name: Validate XML output
hosts: junos
gather_facts: no
tasks:
- name: Validate XML output for model and version
juniper.device.junos_command:
commands:
- show version
display: xml
wait_for:
# XML is parsed into a dictionary
- result[0]['rpc-reply']['software-information']['product-model'] == 'mx240'
- result[0]['rpc-reply']['software-information']['junos-version'] == '23.2R2.21'
match: allSimilarly, for JSON output:
---
- name: Validate JSON output
hosts: junos
gather_facts: no
tasks:
- name: Validate JSON output for model and version
juniper.device.junos_command:
commands:
- show version
display: json
wait_for:
- result[0]['software-information'][0]['product-model'][0]['data'] == 'mx240'
- result[0]['software-information'][0]['junos-version'][0]['data'] == '23.2R2.21'
match: allUnderstanding the Module Response
The junos_command and junos_rpc modules store the
RPC reply from the device within several different keys in the module response.
Table 3 outlines the different fields. The output returns some fields only for certain
formats.
| Module | Output Field | Description |
|---|---|---|
junos_command |
output |
For XML format only, the XML responses transformed to JSON. |
stdout |
A list with the responses for the requested commands. |
|
stdout_lines |
The stdout value split into a list. |
|
junos_rpc |
output |
The RPC reply in the requested format. |
output_lines |
For text format only, the text output split into lines. | |
xml |
The XML RPC reply string. |
Specify the Format for Command or RPC Output
When you use the junos_command module to execute commands, the
default output format is text. When you use the junos_command
module or the junos_rpc module to execute RPCs, the default
format is XML.
To specify a different output format, include the parameter specific to that
module, and set the value equal to the required format. Table 4 outlines the parameters, supported formats, and default format for each
module. If you use the junos_command module to execute multiple
commands or RPCs, you can specify only a single format.
| Module |
Module |
Supported Values |
|---|---|---|
junos_command |
display |
|
junos_rpc |
output |
|
The following playbook uses the junos_command module to execute
two RPCs on each device in the inventory group. The playbook requests text
format for the output of all executed RPCs.
---
- name: Get device information
hosts: junos
gather_facts: no
tasks:
- name: Get version and system uptime information
juniper.device.junos_command:
rpcs:
- get-software-information
- get-system-uptime-information
display: text
register: junos_result
- name: Print response
ansible.builtin.debug:
var: junos_resultIn the module's response, the stdout and
stdout_lines keys contain the RPC reply in text format
instead of the default XML output.
The following playbook uses the junos_rpc module to execute an
RPC on each device in the inventory group. The playbook requests text format for
the RPC output.
---
- name: Get device information
hosts: evo
gather_facts: no
tasks:
- name: Get uptime information
juniper.device.junos_rpc:
rpc: get-system-uptime-information
output: text
register: junos_result
- name: Print response
ansible.builtin.debug:
var: junos_resultFor junos_rpc, the module's response includes the
output, output_lines, and
xml keys. In this case, the module returns
output_lines only when you request text format.
PLAY [Get device information] ******************************************************
TASK [Get uptime information] ******************************************************
ok: [router1.example.com]
TASK [Print response] **************************************************************
ok: [router1.example.com] => {
"junos_result": {
"changed": false,
"failed": false,
"output": "Current time: 2026-03-16 16:25:29 PDT\nTime Source: NTP CLOCK \nNode booted: 2026-01-05 10:18:33 PST (10w0d 05:06 ago)\nSystem booted: 2026-01-05 10:18:57 PST (10w0d 05:06 ago)\nProtocols started: 2026-01-05 10:21:14 PST (10w0d 05:04 ago)\nLast configured: 2026-02-23 17:07:17 PST (2w6d 22:18 ago) by admin\n 4:25PM up 70 days, 5:06, 1 user, load averages: 0.09, 0.09, 0.10",
"output_lines": [
"Current time: 2026-03-16 16:25:29 PDT",
"Time Source: NTP CLOCK ",
"Node booted: 2026-01-05 10:18:33 PST (10w0d 05:06 ago)",
"System booted: 2026-01-05 10:18:57 PST (10w0d 05:06 ago)",
"Protocols started: 2026-01-05 10:21:14 PST (10w0d 05:04 ago)",
"Last configured: 2026-02-23 17:07:17 PST (2w6d 22:18 ago) by admin",
" 4:25PM up 70 days, 5:06, 1 user, load averages: 0.09, 0.09, 0.10"
],
"xml": "<rpc-reply message-id=\"urn:uuid:81f492e2-bce2-4818-b6e7-4675eb4df442\"><output>\nCurrent time: 2026-03-16 16:25:29 PDT\nTime Source: NTP CLOCK \nNode booted: 2026-01-05 10:18:33 PST (10w0d 05:06 ago)\nSystem booted: 2026-01-05 10:18:57 PST (10w0d 05:06 ago)\nProtocols started: 2026-01-05 10:21:14 PST (10w0d 05:04 ago)\nLast configured: 2026-02-23 17:07:17 PST (2w6d 22:18 ago) by admin\n 4:25PM up 70 days, 5:06, 1 user, load averages: 0.09, 0.09, 0.10\n</output></rpc-reply>"
}
}
PLAY RECAP *************************************************************************
router1.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0