NightFox

Network Automation

I like automation that takes boring, repetitive work off my plate and stops configs from slowly drifting apart. I don't like automation that turns a simple change into a black box only one person understands. The safe way in is to start small: good inventory, backups, checks, and little repeatable jobs. Let the scripts read for a while before you let them write.

Good first projects

None of these change anything on your devices, which makes them a great place to start:

• Back up configs on a schedule.
• Collect device facts and software versions.
• Check that NTP, DNS, syslog, and authentication are set the way they should be.
• Audit interface descriptions and which ports are shut down.
• Generate standard access-switch configs (like my Cisco config generator).
• Check routing neighbors and prefix counts.
• Compare running configs to an approved baseline.

Have a source of truth

Automation needs one place that says what the network is supposed to look like. That could be an IPAM tool, a database, a Git repo, or a folder of YAML files. The important part is that device configs get generated from it, so the device isn't the only place your intent lives.

Templates

Templates turn structured data into config. I try to keep logic out of them as much as possible. The inputs should be spelled out: hostname, management IP, site, VLANs, neighbors, interface roles. And they should be checked before anything is generated. Something like:

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

Ways to talk to devices

Check before you change

Before a script touches a device, it should confirm:

• The device is the one inventory says it is.
• It's reachable over the management path you expect.
• There's a fresh config backup.
• The current state makes sense for this change.
• The generated config passes syntax and policy checks.
• It's the right change window and the right list of devices.

Check after, too

"The command didn't return an error" doesn't mean the network is fine. Check the actual result:

• Interfaces and routing neighbors are still up.
• The routes you expect are there.
• You can still get in to manage it.
• Important applications are still reachable.
• No new errors in the counters or logs.
• The config on the box matches what you meant to push.

Idempotency

Fancy word, simple idea: you should be able to run the same automation twice without it doing anything weird the second time. It compares what's there with what should be there and only changes the difference.

Put it in Git

Templates, inventory, checks, and generated changes all go in version control. Have someone review changes before they go out, especially routing policy, ACLs, and anything touching lots of devices. A pull request is a nice readable record of who changed what and why. Even if it's just you, future you will appreciate it.

Secrets

Don't put passwords, API tokens, or private keys in scripts or repos. Use a secrets manager, protected environment variables, or an encrypted vault. And give the automation's account only the permissions it actually needs.

Rollback

Every automated change needs a way back. Depending on the platform that could be a config checkpoint, a candidate config, a timed rollback (commit confirmed is wonderful), a saved startup config, or a generated reverse change.

When I wouldn't automate

• You don't understand the process well enough to do it by hand yet.
• The source data is incomplete or wrong.
• There's no safe way to roll back on that platform.
• It's rare, risky, and hard to verify.
• The automation would hide complexity instead of reducing it.

Last Modified: October 12, 2026, 11:41 am