Automating the network lifecycle: discovery, zero-touch provisioning, upgrades and decommissioning

The lifecycle view

When people hear "network automation" they usually think of a script that changes configurations. In practice most of an engineer's time goes on other repetitive jobs: finding out what is on the network, setting up new devices, upgrading software and tidying up old kit. Engineers often describe these as day 0 (plan and design), day 1 (deploy) and day 2 (operate). Automating each stage gives quicker results, and a more consistent network, than automating changes alone.

Day 0: discovery and standard profiles

You can't automate what you don't know about. Discovery tools sweep address ranges and use SNMP, SSH, CDP or LLDP to find devices, their models, software versions and neighbours. The results should feed your source of truth rather than a spreadsheet nobody updates.

Next, agree standard profiles: one approved configuration per device role, such as "classroom access switch" or "branch router". A profile fixes the things that should never differ between sites, such as management access, logging, NTP, AAA and security hardening, and leaves variables (hostname, VLAN numbers, addresses) to be filled in from the source of truth. Templates written in a language such as Jinja2 turn a profile plus variables into a full configuration.

Day 1: zero-touch provisioning

Zero-touch provisioning (ZTP) lets a new device configure itself the first time it powers on, so whoever installs it only needs to rack it and plug it in. The details vary by vendor, but most follow the same pattern:

1. The new device boots with no configuration and requests an address with DHCP on its management or uplink port.
2. The DHCP server replies with extra options, such as option 67 (a boot file or script name) and a server to fetch it from, or a vendor-specific option that points to a provisioning service.
3. The device downloads the script or configuration over HTTP(S) or TFTP and, if needed, an approved software image.
4. The provisioning system identifies the device by serial number and applies the right template for its site and role.
5. The device reports back, and the automation checks that it is reachable and configured as expected.

Tip: ZTP trusts whatever the DHCP server tells it. Run provisioning on a protected management network, prefer HTTPS with certificate checks where the platform supports it, and use DHCP snooping so a rogue DHCP server can't hand out a malicious script.

Upgrades and decommissioning

Software upgrades are risky and repetitive, which makes them good candidates for automation. A typical automated upgrade workflow:

• Pre-checks: confirm free storage, save the configuration and record the state (interfaces up, neighbours, routes).
• Stage: copy and verify the image's hash ahead of time, outside the maintenance window.
• Upgrade in waves: a few lab or low-risk devices first, then a small group, then the rest. Never every core switch at once.
• Post-checks: compare the new state with the recorded one and stop the wave automatically if anything differs.

Retiring a device should also be scripted: remove it from monitoring, the source of truth, backups, AAA and firewall rules, and wipe its configuration before it leaves the building. Forgotten entries cause false alarms and leave holes in security rules.

Real-world example: forty new switches in a weekend

A fictional university replaced 40 access switches in a teaching building over one weekend. The network team pre-loaded each serial number and its location into their source of truth, wrote one template for the "teaching access switch" profile, and set up DHCP option 67 on the management VLAN to point at a provisioning script. Facilities staff racked and cabled the switches; each one booted, downloaded its software image and configuration, and appeared in monitoring within 15 minutes. The post-check script found two switches patched to the wrong uplinks, which were fixed before Monday.