Cisco Catalyst Zero-Touch Field Activation
Cisco Catalyst 9000 Zero Touch Provisioning can bootstrap an unconfigured switch using DHCP and a referenced script or configuration path. Successful field activation depends on factory-default state, DHCP options, routing, name and time services, reachable resources, trusted artifacts and a technician prepared to stop or recover the process.
Make each dispatch repeatable and recoverable
Define prerequisites, remote ownership, method of procedure, acceptance evidence and rollback before technicians arrive onsite.
ZTP workflow and site prerequisite validation
Confirm whether the project uses IOS XE ZTP, Catalyst Center Plug and Play or another approved automation path; these are not interchangeable workflows. Reconcile serial, model, modules, software, stack plan and site profile with the automation inventory.
Validate DHCP, option values, gateway, DNS, NTP, firewall and bootstrap server reachability in the staging network. Protect scripts and configurations and verify integrity and change approval. Define what the technician should see and when to stop.
Before dispatch, the packet should tie each serial to a stack position, a bootstrap profile and a named engineer who can watch the provisioning attempt in real time. A technician who arrives without that mapping cannot tell a wrong profile from a slow download, which turns a short activation into a return visit.
- Correct automation method
- Serial/model/site mapping
- DHCP and service reachability
- Approved artifacts and integrity
Physical installation and controlled bootstrap
Rack, power, stack and label the switch, then connect only the designated bootstrap uplink and console according to the method. Confirm factory-default or intended startup state before initiating. Avoid attaching production access ports until the correct site configuration is verified.
Observe DHCP, download, script execution, reloads and controller or management registration. Record timestamps and messages. If the device loops, downloads the wrong profile or loses reachability, stop and use the approved recovery rather than repeatedly erasing it.
Capture the console session to a file for the whole boot cycle, not just the moment it fails. That transcript, paired with a photo of the uplink patch before anything moved, gives the escalation engineer something to read at midnight and reduces the temptation to erase the switch and start over blind.
- Console and fallback ready
- Bootstrap-only uplink first
- Observed downloads/reloads
- Stop conditions defined
| Phase | Observe | Stop or escalate when |
|---|---|---|
| Discovery | DHCP and bootstrap URL | Wrong scope or artifact |
| Execution | Script/config and reloads | Loop, errors or lost access |
| Validation | Site profile and services | Partial or incorrect configuration |
| Handoff | Inventory and source of truth | Ownership remains unclear |
Configuration, software and service acceptance
Verify hostname, management, AAA, certificates, NTP, software, license, VLANs, trunks, spanning tree, routing, telemetry and intended template. Compare the running result with the site source of truth and check for rejected commands or partial automation.
Connect and test access-port groups only after the baseline passes. Validate PoE, voice, wireless, security and representative clients. Exercise approved uplink or stack recovery when applicable and confirm automation will not overwrite authorized local exceptions unexpectedly.
Acceptance reads better as a diff than as a checkmark: the running configuration against the intended template, the rejected lines if any, and which access groups carried live traffic. Note the client type used on each group so a later dispute about a dead port can be retested the same way.
- Template/config comparison
- AAA/cert/time/software
- Ports, PoE and endpoints
- Automation exception behavior
Evidence, exception and lifecycle handoff
Deliver serial, site/profile, bootstrap service, timestamps, software, configuration comparison, port tests, logs, exceptions and recovery actions. Remove temporary bootstrap access and credentials according to the security plan.
Operations must own the automation source, certificates, images, DHCP options, templates, inventory and change process. Keep private artifacts in the client repository and link publicly only to official Cisco documentation.
The record that matters later names the automation path that actually completed, the image and license state the switch landed on, and whether the DHCP option or provisioning entry was cleared. Leave one behind and a future reload can pull an old profile onto a switch nobody planned to touch.
- Activation evidence
- Temporary access removed
- Source-of-truth ownership
- Protected scripts/configuration
How we plan and deliver the work
The final design depends on site conditions, existing systems, client policies and the selected manufacturer or platform.
Validate bootstrap path
Confirm DHCP options, routing, name and time services and artifact reachability before a switch is powered at the site.
Verify startup state
Confirm no startup configuration is present so the switch enters provisioning, and keep console access available for recovery.
Rack and bootstrap
Install the switch, connect the provisioning uplink and observe the automated bootstrap through to a stable configuration.
Accept activation
Compare running configuration, software level and reachability against the approved target before releasing the switch.
Information to gather before design
Zero touch provisioning fails quietly when a dependency is missing, so DHCP options, the artifact path and image targets need confirming before anyone racks a Catalyst switch.
- DHCP scope and option values
- Provisioning server and script location
- Target software image and version
- Console cable and out-of-band contact
- Approved rollback and abort criteria
Frequently asked questions
These are common planning questions. A site-specific answer should be confirmed during discovery and design.
Is Cisco ZTP the same as Catalyst Center Plug and Play?
No. Confirm the exact automation architecture and prerequisites used by the client.
Must the switch be factory default?
The required startup state depends on the workflow, but conflicting saved configuration can prevent the intended bootstrap.
Why keep console access if the process is zero touch?
Local recovery is essential when DHCP, scripts, software or management reachability fail.
What proves activation succeeded?
Correct site configuration, management, software, ports, PoE, endpoints, logs and source-of-truth reconciliation.
Manufacturer software, firmware and technical files remain on the manufacturer’s official website. We do not mirror firmware files locally.
Plan a Catalyst zero-touch activation wave
If the provisioning path is already built but field results have been inconsistent, describe the DHCP scope, the artifact location and the switch models in scope. Site access hours and console availability shape the plan.