You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
Network automation is the process of using software to automatically configure, manage, test, deploy, and operate physical and virtual network devices. Instead of logging into each device one by one and typing CLI commands, engineers write code or use tools to push changes across hundreds or thousands of devices in seconds.
Manual network management worked when organisations had a handful of devices. Modern networks have grown far beyond that scale:
| Challenge | Manual Approach | Automated Approach |
|---|---|---|
| Configuration changes | SSH into each device, type commands one by one | Push a template to all devices in parallel |
| Consistency | Human errors lead to configuration drift | Every device receives the identical configuration |
| Speed | Hours or days to roll out a change | Seconds or minutes |
| Auditing | Difficult to track who changed what | Every change is version-controlled and logged |
| Disaster recovery | Rebuild configurations from memory or notes | Redeploy from code in minutes |
| Scaling | Adding devices means more manual work | Adding devices means updating an inventory file |
Tip: The number one driver for network automation is consistency. Human beings make mistakes — automation does not forget a step.
Network Infrastructure as Code means storing your device configurations in version-controlled files (Git) rather than only on the devices themselves:
Traditional:
Engineer → SSH → Device → type commands → hope it works
IaC:
Engineer → writes config file → Git commit → automation tool → all devices
An operation is idempotent if running it once produces the same result as running it multiple times:
| Approach | Idempotent? | Example |
|---|---|---|
interface GigabitEthernet0/1; ip address 10.0.0.1 255.255.255.0 | Yes — setting the same address twice changes nothing | CLI command |
no shutdown on an already-up interface | Yes | CLI command |
| Appending a line to a config file without checking if it exists | No — duplicates accumulate | Script bug |
Automation tools like Ansible are designed to be idempotent — they check the current state before making changes.
| Style | Description | Example |
|---|---|---|
| Imperative | You specify the exact steps to reach the desired state | "Add VLAN 10, then set the name, then add it to the trunk" |
| Declarative | You describe the desired end state; the tool figures out the steps | "Ensure VLAN 10 exists with name SALES on all switches" |
Most modern automation tools favour the declarative approach.
A typical network automation environment includes several layers:
┌──────────────────────────────────────┐
│ Source of Truth │
│ (Git, NetBox, IPAM, CMDB) │
├──────────────────────────────────────┤
│ Automation Engine │
│ (Ansible, Python scripts, CI/CD) │
├──────────────────────────────────────┤
│ Transport / Protocol │
│ (SSH, NETCONF, RESTCONF, gNMI) │
├──────────────────────────────────────┤
│ Network Devices │
│ (Routers, switches, firewalls) │
└──────────────────────────────────────┘
| Layer | Purpose | Examples |
|---|---|---|
| Source of Truth | Stores the intended state of the network | Git repositories, NetBox, Nautobot |
| Automation Engine | Orchestrates and executes changes | Ansible, Nornir, custom Python |
| Transport | How the automation tool talks to devices | SSH (CLI), NETCONF (XML), RESTCONF (JSON), gNMI (protobuf) |
| Network Devices | The actual infrastructure being managed | Cisco IOS, Arista EOS, Juniper Junos, Palo Alto |
| Use Case | Description |
|---|---|
| Configuration backups | Automatically pull running configs from all devices and store them in Git |
| Compliance checks | Verify that every device matches the approved configuration baseline |
| VLAN provisioning | Create a new VLAN across all switches in a data centre with one command |
| OS upgrades | Stage firmware, validate compatibility, upgrade, and verify — hands-free |
| User provisioning | Add a new employee's port to the correct VLAN automatically |
| Change validation | Compare pre-change and post-change state to confirm the change succeeded |
| Self-healing | Detect configuration drift and automatically correct it |
| Tool | Type | Description |
|---|---|---|
| Python | Programming language | The dominant language for network automation |
| Paramiko | Python library | Low-level SSH connectivity |
| Netmiko | Python library | Simplified SSH for multi-vendor network devices |
| NAPALM | Python library | Unified API for multi-vendor config management |
| Ansible | Automation framework | Agentless, YAML-based automation with network modules |
| Nornir | Python framework | Ansible-like inventory with pure Python execution |
| Terraform | IaC tool | Declarative provisioning for cloud and some network devices |
| Git | Version control | Tracks every change to configuration files |
| Jinja2 | Template engine | Generates device-specific configs from templates |
| NETCONF | Protocol | XML-based programmatic interface (RFC 6241) |
| RESTCONF | Protocol | RESTful HTTP interface to YANG models (RFC 8040) |
| gNMI | Protocol | gRPC-based streaming telemetry and configuration |
To begin automating your network, you need:
# Create a project directory
mkdir network-automation && cd network-automation
# Create a Python virtual environment
python3 -m venv venv
source venv/bin/activate
# Install key libraries
pip install netmiko napalm ansible jinja2 pyyaml
# Initialise a Git repository
git init
Network automation replaces manual, error-prone, device-by-device configuration with repeatable, version-controlled, programmatic workflows. It brings consistency, speed, and auditability to network operations. The ecosystem includes Python libraries (Paramiko, Netmiko, NAPALM), frameworks (Ansible, Nornir), protocols (NETCONF, RESTCONF, gNMI), and practices borrowed from software engineering (Git, CI/CD, testing). In the next lesson, we will dive into Python — the language that underpins the majority of network automation tooling.