Free tech learning for everyone, from basics to pro

AnsibleProgramming and Application SecurityIntermediate

Ansible network modules and collections for Cisco, Arista and Juniper

In short: Vendor collections such as cisco.ios, arista.eos and junipernetworks.junos provide modules for network devices. Resource modules manage features such as VLANs and interfaces as structured data with consistent states, while config and command modules handle anything else.

Collections for network vendors

Network support in Ansible lives in collections, one per platform. Common ones include cisco.ios, cisco.nxos, cisco.iosxr, arista.eos, junipernetworks.junos and vyos.vyos, all built on the shared ansible.netcommon collection. Install or update them with ansible-galaxy collection install cisco.ios arista.eos junipernetworks.junos, and pin versions in a requirements.yml file so every engineer uses the same code.

Network module typesNetwork collectionscisco.ios, arista.eos,junipernetworks.junosFactsread stateResource modulesvlans, interfacesConfigraw linesCommandshow output
Figure 1. Network collections offer facts, structured resource modules, line-based config modules and command modules.

Connection settings per platform

Platformansible_network_osTypical ansible_connection
Cisco IOS / IOS XEcisco.ios.iosansible.netcommon.network_cli
Cisco NX-OScisco.nxos.nxosnetwork_cli or httpapi (NX-API)
Arista EOSarista.eos.eosnetwork_cli or httpapi (eAPI)
Juniper Junosjunipernetworks.junos.junosansible.netcommon.netconf (most modules)

Put these in group_vars for each platform group. For enable mode on IOS and EOS, set ansible_become: true and ansible_become_method: enable. Junos devices need NETCONF over SSH enabled (set system services netconf ssh) before the netconf connection works.

Resource modules

Resource module statesmergedadd, keep othersreplacedreplace one itemoverriddenreplace all itemsdeletedremove itemsgatheredread as datarenderedshow commands offline
Figure 2. Resource modules share the same set of states across vendors, which makes playbooks predictable.

Resource modules manage one feature as structured data, for example cisco.ios.ios_vlans, arista.eos.eos_interfaces or junipernetworks.junos.junos_vlans. The same data shape and states work across vendors, so the playbook reads like a description of intent.

- name: Standard VLANs on all access switches
  hosts: access
  gather_facts: false
  vars:
    vlans:
      - { vlan_id: 10, name: STAFF }
      - { vlan_id: 20, name: STUDENTS }
      - { vlan_id: 30, name: CCTV }
  tasks:
    - name: Ensure VLANs exist (IOS)
      cisco.ios.ios_vlans:
        config: "{{ vlans }}"
        state: merged
      when: ansible_network_os == 'cisco.ios.ios'

    - name: Ensure VLANs exist (EOS)
      arista.eos.eos_vlans:
        config: "{{ vlans }}"
        state: merged
      when: ansible_network_os == 'arista.eos.eos'

Be careful with overridden: it removes every item not in your list, so an override of VLANs could delete VLANs that other teams rely on. Use merged while you are learning and move to replaced or overridden only when your data is the trusted source of truth. The gathered state is a safe way to read current configuration as data, and rendered shows the commands a task would send without connecting to a device.

Config, command and facts modules

- name: Login banner via raw config lines
  cisco.ios.ios_config:
    lines:
      - banner motd ^Authorised access only^
    save_when: modified

- name: Read a show command
  arista.eos.eos_command:
    commands: show version
  register: ver

The *_config modules push configuration lines and check the running config to stay roughly idempotent; save_when: modified writes to startup config only when something changed. The *_command modules run show commands and never change configuration. The *_facts modules gather model, version, serial number and interfaces into variables such as ansible_net_model.

Tip: always run against a lab or a single device with --check --diff first, and confirm you have out-of-band access before changing management interfaces or ACLs remotely.

Practice

What is the risk of state: overridden on a VLAN resource module?
It removes any VLAN not listed in your data, which can delete VLANs still in use if your data is incomplete.
Which connection is normally used for Junos modules?
ansible.netcommon.netconf, which requires NETCONF over SSH to be enabled on the device.
How do you avoid saving the config when nothing changed?
Use save_when: modified on the config module, or a handler that only runs on change.

Key takeaways

  • Each vendor platform has its own collection built on ansible.netcommon.
  • Set ansible_network_os and ansible_connection per platform group.
  • Resource modules manage features as data with shared states.
  • Start with merged; use overridden only with a trusted source of truth.
  • Config modules push lines, command modules read, facts modules collect inventory data.
Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author

Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.

Stay up to date by email

New notes, tools and security news from FM TecHub, explained simply. Free.

We only use your email to send these updates. See our privacy policy.