Network Automation with Ansible and Python: Getting Started

Every network engineer has a story about a late-night change window where a typo in a VLAN configuration brought down a production link. Manual CLI configuration is inherently risky because humans make mistakes under pressure, and the blast radius of a misconfigured core switch can be catastrophic. Network automation addresses this by codifying configurations in version-controlled templates, applying them through repeatable playbooks, and validating the result with automated checks. The benefits compound quickly: what takes an engineer 20 minutes per switch across a 50-switch campus becomes a single playbook execution that completes in minutes and produces an identical, auditable result on every device.

For Australian IT resellers, network automation is also a competitive differentiator. Clients increasingly expect their managed service provider to deliver infrastructure-as-code practices, not just traditional break-fix support. Offering automated provisioning, compliance checking, and configuration backup as part of your managed network service justifies higher-margin contracts and reduces the operational burden on your engineering team — allowing you to manage more client networks with the same headcount.

Ansible is an open-source automation engine that uses agentless, SSH-based communication to manage devices. Unlike server automation where Ansible installs a Python interpreter on the target, network modules execute on the control node and communicate with devices over SSH or API calls. An Ansible inventory file lists your devices, grouped by role (core switches, access switches, routers, firewalls). A playbook is a YAML file that describes the desired tasks — for example, "configure VLAN 100 on all access switches" or "ensure NTP is set to 203.35.255.222 on all devices." Ansible ships with modules for Cisco IOS, NX-OS, Arista EOS, Juniper Junos, and many other platforms through collections available on Ansible Galaxy.

A simple playbook to configure an NTP server on Cisco IOS devices might look like this: you define the hosts group, set the connection type to network_cli, and use the cisco.ios.ios_ntp_global module to declare the desired NTP servers. When you run ansible-playbook ntp.yml, Ansible connects to each device in the group, compares the current NTP configuration against the desired state, and applies changes only where needed. This idempotent behaviour is a core Ansible principle — running the same playbook twice produces no unnecessary changes, making it safe to execute repeatedly.

While Ansible provides a declarative, YAML-based approach, sometimes you need the full flexibility of Python. Netmiko is a Python library that simplifies SSH connections to network devices. It handles the nuances of different vendor CLI prompts, enables you to send commands and capture output, and supports configuration mode for pushing changes. Netmiko supports over 60 device types, including Cisco IOS, Arista EOS, Juniper Junos, HP ProCurve, MikroTik RouterOS, and Fortinet FortiOS. A typical Netmiko script connects to a device, enters configuration mode, sends a list of configuration commands, and disconnects — all in about 15 lines of Python.

NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) takes a higher-level approach. Instead of sending raw CLI commands, NAPALM provides getter methods that return structured data — get_interfaces(), get_bgp_neighbors(), get_facts() — in a vendor-agnostic JSON format. It also supports configuration replacement and merge operations with automatic diff generation and rollback capabilities. NAPALM is particularly powerful for compliance checking: you can pull the running configuration from every device, compare it against a golden template, and flag deviations — all without writing vendor-specific parsing logic.

Configuration drift occurs when the actual state of a device diverges from the intended state — someone makes a manual change during troubleshooting, forgets to document it, and the network slowly accumulates inconsistencies. Drift is one of the most common causes of hard-to-diagnose outages because the documentation no longer reflects reality. Automated drift detection addresses this by periodically pulling the running configuration from every device (using NAPALM getters or Ansible ios_config backups), comparing it against the version-controlled source of truth, and alerting when differences are found. You can implement this as a scheduled Ansible playbook or a Python script run via cron, with results posted to a Slack channel or ticketing system.

The key to effective drift detection is maintaining a golden configuration or desired state template in a Git repository. Every change to the network should be made by updating the template and running the automation pipeline — never by logging into a device and typing commands directly. This "GitOps for networking" approach provides a complete audit trail (who changed what and when), enables peer review through merge requests, and allows instant rollback by reverting a commit. For resellers managing multiple client networks, a Git-based workflow also makes it easy to maintain per-client repositories with standardised templates and client-specific variable files.

Storing your network configuration in Git transforms how your team operates. Instead of ad-hoc changes made via CLI, every configuration update follows a workflow: an engineer creates a feature branch, modifies the Jinja2 template or variable file, opens a merge request, a peer reviews the diff, and once approved the CI/CD pipeline executes the Ansible playbook to push the change. This is not just a theoretical best practice — it is how leading network operations teams at companies like Google, Facebook, and major Australian service providers manage their infrastructure. The tooling is mature, the learning curve is manageable, and the risk reduction is immediate.

To get started, set up a dedicated automation workstation or virtual machine running Ubuntu or another Linux distribution. Install Python 3.10 or later, create a virtual environment, and install Ansible, Netmiko, and NAPALM via pip. Structure your project directory with an inventory/ folder for device lists, a playbooks/ folder for Ansible playbooks, a templates/ folder for Jinja2 configuration templates, and a group_vars/ folder for variables specific to device groups. Initialise the project as a Git repository from day one, and store credentials in Ansible Vault or a secrets manager like HashiCorp Vault rather than in plaintext files.

A common first automation project is VLAN provisioning. Define your VLANs in a YAML variable file — VLAN ID, name, and description — and write an Ansible playbook that uses the cisco.ios.ios_vlans module to ensure those VLANs exist on every access switch. When a new VLAN is needed, an engineer simply adds a line to the YAML file, commits it to Git, and runs the playbook. The playbook is idempotent: if the VLAN already exists with the correct name, Ansible reports no changes. If it is missing or misconfigured, Ansible creates or corrects it. This simple workflow eliminates the risk of typos, ensures every switch has an identical VLAN database, and provides a complete audit trail in Git.

For resellers offering managed network services, automation is the key to profitability at scale. Build a library of standardised playbooks — baseline hardening, VLAN provisioning, NTP/syslog/SNMP configuration, firmware upgrades, and configuration backup — and deploy them consistently across every client network. Use Ansible AWX or Ansible Automation Platform (the upstream of Red Hat's commercial product) as a web-based control plane that provides role-based access, job scheduling, audit logging, and a REST API for integration with your PSA or ticketing system. This lets junior engineers execute standardised changes through a web interface with guardrails, while senior engineers focus on designing templates and handling exceptions.