Ansible with Juniper

Speaking of centralized management of network devices would be a great idea to demonstrate some possibilities to use NETCONF and open-source software.
Under the hood, we are going to use Ansible and “Juniper.junos” library to manage Juniper vMX 14.1 and SRX 12.1 from GNU/Linux Debian CLI.

I’m not a first who wrote an article about Ansible usage with JunosOS and there is nothing really new, but count this as a leaf for “Software-driven network” – a try to meet with practical NETCONF usage as a transport to deliver data.

Why Ansible

The most important reason to use Ansible as a clientless – no agents are supposed to be on end systems.
Agile methodology allows push in production a raw and partially functioning product and so do I follow these instructions and will fill the article somehow in the future (or not).


  1. Create a VM with any convenient virtualization software
  2. Ensure the VM will have access to the Internet
  3. Install Debian from Network-installer image (247MB), with SSH server and standard system utils
  4. Make a snapshot of VM
  5. Prepare an environment (connect via SSH as a user created while setup and switch to root for the sake of brevity):

It might seem like not an optimal way to install Ansible, but that way guarantees to get the latest Ansible version, avoid debugging and thus allows to play with Ansible instead of Linux.
By the way, the official way to install has failed on some platforms and not deserve a consideration.

After all, prepare to use SSH keys for authentication to Junos.

Generate SSH keys in Linux, do not enter passphrase:

ssh-keygen -t dsa


The installation had created default Ansible directory thus all we need is to define end hosts.
List of configurable devices contains 2 items: Juniper vMX and SRX. Those hostnames should be defined in /etc/ansible/hosts file

cat /etc/ansible/hosts

As you see, devices had separated in different groups. This allows an administrator to execute an action to a single group strictly or to both of them as JUNIPER group.

Ensure hostnames “fw1” and “mx1” are resolvable – ping the names.
Add hosts in system ‘/etc/hosts’ file or mention them in ‘/etc/ansible/hosts’ as IP-addresses.


Installation of Juniper.junos open library:

Preparation of end devices:

  • Linux: get public SSH key:
  • Juniper: create a user with ssh-key authentication:
  • Juniper: enable NETCONF port:
At now we may check that end devices support NETCONF and accessible to user “ansible” without a password request:

check access and NETCONF capability


In Ansible terms, any action is called “task” and any file that defines a task or list of tasks is called “playbook”.
Administrator could follow a few tactics:

  • one playbook – one task
    That means a separate file for any kind of task. An example: playbook “set-domain.yml” to change hostname and playbook “shutdown.yml” to shut down an end system;
  • one playbook – many tasks
    That means in a single playbook file a lot of tasks are defined and by specific tag only distinct task performed.

Version 1.3.1 of Juniper.junos Ansible library supports following actions:

We’ll follow the 2nd tactic and I’ve prepared separate playbooks for “GET” tasks and “SET” tasks:

  • GET task is informational and uses to gather some information from end devices, like hostname, software version, a configuration or part of it or enter a command and save an output;
  • SET task is operational and uses to configure, reboot, shutdown, zeroise and other potentially dangerous action.

Insert them in /etc/ansible/roles/Juniper.junos/tasks directory:


Don’t be scared. A classic playbook easy to read – contains environment options and a task in a pretty understandable YAML structure:

The Games

Tags that are defined in a playbook will be used to start an explicit task or a subset of tasks.


1. Check if end devices are available to manipulations via NETCONF
SRX group onlyJUNIPER group (both SRX and MX)
2. Gather a set of data from SRX group devices - model, active software version, serial number
3. Get configuration stanza 'system', save an output


1. Input and commit set commands from file '/opt/juniper/set/set-domain.set' file. Log all steps and provide diff file

2. Replace section of configuration defined in file '/opt/juniper/set/set-section.conf' and commit for 10 minutes. If 2nd commit is not executed within that time, then rollback.

Additional information

Yes, it is still vendor-specific at the end. Ansible by itself is not related with SDN and just a way to automation. But this is a start and community moves forward – check N.A.P.A.L.M (Network Automation and Programmability Abstraction Layer with Multi-vendor support).
I do not advertise Ansible or Juniper, but share an overview of Ansible applicability to network devices.