Network automation: why automate, the toolchain and model-driven APIs

Why automate the network

Configuring devices one at a time by hand is slow, and humans make typing mistakes: many outages start with a manual change. Automation lets you make the same change on 500 devices in minutes, exactly the same way every time. It also frees engineers from repetitive tasks such as backups, audits and VLAN changes, so they can work on design and problems.

• Speed: changes and new sites in minutes, not days.
• Consistency: every device follows the same standard.
• Fewer errors: tested templates instead of copy-and-paste.
• Compliance: automatic checks that configs match policy.
• Documentation: the code itself records what was done.

The automation stack

How tools talk to devices

Model-driven interfaces use YANG data models, which describe a device's configuration and state as structured data instead of free text.

Data formats you'll meet

# YAML: easy for people to read and write
hostname: BR1-SW1
vlans:
  - id: 10
    name: STAFF
  - id: 20
    name: GUEST

# JSON: the same data, common in APIs
# {"hostname": "BR1-SW1", "vlans": [{"id": 10, "name": "STAFF"}, {"id": 20, "name": "GUEST"}]}

Key ideas: source of truth and idempotency

• Source of truth: one trusted place (a database, IPAM tool or Git repository) that holds what the network should look like. Automation reads it; people change the source, not the devices.
• Idempotency: running the same automation twice gives the same result and changes nothing the second time. Safe to re-run.
• Start small: read-only tasks first (backups, inventory, audits), then simple changes, then full deployments.

Real-world example: a VLAN change across 120 switches

A fictional hospital needed to add a new VLAN for wireless infusion pumps to 120 access switches across four buildings. Done by hand, two engineers estimated three nights of work, with a real risk of typing mistakes on a clinical network. Instead they listed the switches and their uplink ports in their source of truth and wrote a short automation job using RESTCONF where the switches supported it and SSH for the older models. The job ran first in check mode to show exactly what would change, then on ten switches in one ward, then on the rest. It finished in under an hour, and a final read-only check confirmed that every switch carried the new VLAN on the correct trunks.