Network Automation
Network automation should reduce repetitive work and configuration drift without turning routine changes into an opaque system that only one person understands. The safest automation starts with accurate inventory, backups, validation, and small repeatable tasks.
Good First Automation Projects
- Back up configurations on a schedule.
- Collect device facts and software versions.
- Validate NTP, DNS, syslog, and authentication settings.
- Check interface descriptions and shutdown state.
- Generate standard access-switch configurations.
- Audit routing neighbors and prefix counts.
- Compare running configuration against an approved baseline.
Source of Truth
Automation needs an authoritative source for intended state. This may be an IP address management platform, a configuration repository, a database, or structured YAML and JSON files. Device configurations should be generated from that source rather than becoming the only place where intent exists.
Templates
Templates convert structured data into configuration. A template should avoid assumptions that are hidden in code. Inputs such as hostname, management address, site, VLANs, routing neighbors, and interface roles should be explicit and validated.
Example data
hostname: access-sw-01
management_ip: 10.10.0.11/24
default_gateway: 10.10.0.1
vlans:
- id: 10
name: management
- id: 20
name: users
- id: 30
name: voice
Common Automation Approaches
| Approach | Best use |
|---|---|
| SSH command execution | Legacy devices and simple collection tasks |
| Configuration management | Repeatable multi-device changes and compliance |
| REST or vendor APIs | Structured state changes and controller platforms |
| NETCONF or RESTCONF | Model-driven configuration on supported devices |
| Event-driven automation | Responding to verified operational conditions |
Prechange Validation
Before changing a device, automation should verify:
- The target identity matches inventory.
- The device is reachable through the expected management path.
- A current configuration backup exists.
- The running state is compatible with the intended change.
- The generated configuration passes syntax and policy checks.
- The change window and affected devices are correct.
Postchange Validation
Do not treat a successful command response as proof that the network is healthy. Validate the desired outcome:
- Interfaces and routing neighbors remain up.
- Expected routes are installed.
- Management access still works.
- Critical applications remain reachable.
- Error counters and logs show no new issue.
- The resulting configuration matches intended state.
Idempotency
An idempotent automation can run repeatedly without creating duplicate or unintended changes. It compares current state with desired state and changes only what is necessary.
Version Control and Review
Store templates, inventory, validation rules, and generated changes in version control. Review changes before deployment, especially for routing policy, ACLs, and multi-device work. A pull request provides a readable record of who changed what and why.
Secrets
Do not store passwords, API tokens, or private keys directly in scripts or repositories. Use a secrets manager, protected environment variables, or an encrypted vault. Limit credentials to the permissions required by the automation.
Rollback
Every automated change needs a rollback strategy. Depending on the platform, this may be a configuration checkpoint, candidate configuration, timed rollback, saved startup configuration, or an automatically generated reverse change.
When Not to Automate
- The process is not yet understood manually.
- The source data is incomplete or unreliable.
- The platform lacks a safe rollback mechanism.
- The change is rare, high risk, and difficult to validate.
- Automation would conceal rather than reduce complexity.