Table of Contents Link to heading

Foundational Playbooks
Production-Grade Playbooks

Foundational Playbooks Link to heading

Gathering Device Facts Link to heading

Gathering device facts is often the first playbook written in a new automation environment — and one of the most immediately useful. Running ios_facts across your inventory gives you a structured snapshot of platform, version, interface state, and IP configuration without logging into a single device manually. The output can feed dashboards, validation checks, or change pre-conditions.

- name: Collect device facts
  hosts: all
  gather_facts: no
  tasks:
    - name: Gather network facts
      cisco.ios.ios_facts:

Run the playbook:

ansible-playbook get_facts.yml -i inventory.ini

Tip

Add register: device_facts and pipe the output to a structured log file per host using copy. Facts gathered this way become a baseline you can diff against after changes — useful for detecting configuration drift without a dedicated CMDB.

Deploying VLANs Across Switches Link to heading

Manual VLAN provisioning across a large switch fleet is error-prone and inconsistent. A single typo in a VLAN name or ID creates silent inconsistencies that are difficult to trace during troubleshooting. Ansible enforces idempotent VLAN state — running the playbook twice produces the same result as running it once, with no risk of duplicate entries.

- name: Configure VLANs
  hosts: switches
  tasks:
    - name: Create VLAN
      arista.eos.eos_vlan:
        vlan_id: 100
        name: Management_VLAN
        state: present

Run the playbook:

ansible-playbook configure_vlan.yml -i inventory.ini

Note

Use state: absent to clean up decommissioned VLANs with the same playbook structure. Documenting VLAN intent in the playbook itself (rather than a separate spreadsheet) keeps your automation and your network documentation in sync.

Backing Up Network Configurations Link to heading

Configuration backups have operational value only if they run reliably and the output is accessible when needed. Automating backups removes the dependency on someone remembering, and storing them in a consistent path per device makes retrieval straightforward during incident response.

- name: Backup Router Configurations
  hosts: routers
  tasks:
    - name: Save running config
      cisco.ios.ios_command:
        commands:
          - show running-config
      register: output

    - name: Write to file
      copy:
        content: "{{ output.stdout_lines }}"
        dest: "/backup/router_config_{{ inventory_hostname }}.txt"

Run the playbook:

ansible-playbook backup_configs.yml -i inventory.ini

Tip

Append a datestamp to the filename ({{ inventory_hostname }}_{{ ansible_date_time.date }}.txt) to retain a version history rather than overwriting the previous backup on each run. Push the backup directory to a Git repository for change tracking and rollback capability.

Production-Grade Playbooks Link to heading

Automating Router Firmware Upgrades Link to heading

Firmware upgrades across a fleet of routers are one of the highest-risk manual operations in network management — copying the wrong file, missing a verification step, or rebooting at the wrong time can take devices offline. Automating the process enforces consistency and gives you a verifiable audit trail.

- name: Upgrade Router Firmware
  hosts: routers
  tasks:
    - name: Upload firmware file
      cisco.ios.ios_command:
        commands:
          - copy tftp://192.168.1.100/cisco_fw.bin flash:cisco_fw.bin

    - name: Verify firmware version
      cisco.ios.ios_command:
        commands:
          - show version
      register: firmware_output

    - name: Display firmware version
      debug:
        msg: "{{ firmware_output.stdout_lines }}"

Run the playbook:

ansible-playbook upgrade_firmware.yml -i inventory.ini

Warning

Always add a pre-upgrade check that validates the MD5/SHA hash of the firmware file on flash before rebooting. Copying a corrupted image and rebooting into it is significantly worse than not upgrading. Add verify /md5 flash:cisco_fw.bin <expected_hash> as a task with failed_when to abort if the hash doesn’t match.

Monitoring Network Performance Link to heading

Polling interface status and basic counters via Ansible is a low-overhead way to get operational visibility without deploying a full monitoring stack. It’s particularly useful for ad hoc health checks before and after maintenance windows.

- name: Monitor Network Devices
  hosts: all
  tasks:
    - name: Check Interface Status
      cisco.ios.ios_command:
        commands:
          - show ip interface brief
      register: interfaces

    - name: Display Interface Status
      debug:
        msg: "{{ interfaces.stdout_lines }}"

Run the playbook:

ansible-playbook monitor_network.yml -i inventory.ini

Note

For continuous monitoring, a dedicated tool (Zabbix, Prometheus with SNMP exporter, Grafana) will scale better than Ansible polling. Ansible monitoring is most useful for point-in-time checks — before a change, during an incident, or as part of a post-change validation playbook.

Automating Security Policy Deployment Link to heading

ACL changes are among the most consequential configurations you can push to a network device — a misconfigured rule can block legitimate traffic or leave a gap in security policy. Defining ACLs in a playbook means the intended state is explicit, version-controlled, and reproducible.

- name: Apply Firewall Rules
  hosts: firewalls
  tasks:
    - name: Configure ACL
      cisco.ios.ios_acl:
        name: BLOCK_EXTERNAL_ACCESS
        entries:
          - sequence: 10
            action: deny
            protocol: tcp
            src: any
            dest: 192.168.1.0/24
            dport: 22

Run the playbook:

ansible-playbook firewall_rules.yml -i inventory.ini

Warning

Test ACL playbooks in a lab environment before production deployment. Include an explicit permit ip any any as the final ACL entry during testing — remove it only after validating that all required traffic is explicitly permitted. Accidentally locking yourself out of a device via SSH mid-playbook is a recoverable but avoidable situation.

Troubleshooting Network Issues Link to heading

A troubleshooting playbook that gathers routing table state and CPU metrics in a single run is significantly faster than logging into each device individually, particularly when investigating issues across multiple devices simultaneously.

- name: Troubleshoot Network Devices
  hosts: all
  tasks:
    - name: Check Routing Table
      cisco.ios.ios_command:
        commands:
          - show ip route
      register: routing_table

    - name: Check CPU Utilisation
      cisco.ios.ios_command:
        commands:
          - show processes cpu sorted
      register: cpu_usage

    - name: Display Troubleshooting Output
      debug:
        msg:
          - "Routing Table: {{ routing_table.stdout_lines }}"
          - "CPU Usage: {{ cpu_usage.stdout_lines }}"

Run the playbook:

ansible-playbook troubleshoot_network.yml -i inventory.ini

Automating Network Backup & Recovery Link to heading

Backup playbooks in production should include both the capture and storage steps, and ideally validate that the destination file was written successfully. A backup job that ran but wrote an empty file is worse than no backup — it creates a false sense of coverage.

- name: Backup Network Configuration
  hosts: routers
  tasks:
    - name: Retrieve Running Config
      cisco.ios.ios_command:
        commands:
          - show running-config
      register: running_config

    - name: Store Config in Backup Directory
      copy:
        content: "{{ running_config.stdout_lines }}"
        dest: "/backups/{{ inventory_hostname }}-config.txt"

Run the playbook:

ansible-playbook backup_configs.yml -i inventory.ini

Tip

Add a post-task that checks the file size of the backup and fails the play if it’s below a minimum threshold. An empty or truncated backup is worse than a failed backup — it’s silent data loss that only surfaces when you try to restore.