Zero-Touch Provisioning: From Rack-and-Stack to Production Without a Console Cable

Manually provisioning a new switch is slow, error-prone, and impossible to audit. Zero-Touch Provisioning (ZTP) flips it: a device boots from factory defaults, fetches its identity and config, applies it, and reports back — no console cable, no copy-paste.

How ZTP works

When a fresh device boots, it requests an address over DHCP. The DHCP response hands it a bootstrap script URL. The device downloads and runs that script, which pulls its role-specific configuration and applies it.

• DHCP option points the device at a provisioning server.
• Bootstrap script identifies the device (serial, MAC) and selects its config template.
• Config render fills the template with site, VLAN, and uplink data from your source of truth.
• Apply + report pushes the config and signals success back to the pipeline.

Driving ZTP from a pipeline

The fragile part of ZTP is the config it serves. If the template is wrong, you've now automated a mistake across every new device. Putting the templates under config-as-code and rendering them through a pipeline fixes that:

• Schema Validate — every device's rendered config matches your NaC schema.
• Dry Run — render the config for a sample serial and diff it before any device boots.
• State Snapshot + Post-Validate — once the device checks in, confirm its interfaces, VLANs, and uplinks match intent.

Verification closes the loop

ZTP isn't done when the device boots — it's done when you've proven it booted into the right state. A Connectivity Test from the new device to its gateway and a Post-Validate against the intended VLAN set turn "it powered on" into "it's in production correctly."