Chapter 7: Day 0 Provisioning and Zero-Touch Deployment
Learning Objectives
Design and implement device-level Day 0 provisioning solutions for Cisco IOS XE devices
Configure Zero-Touch Provisioning (ZTP) using Python scripts and DHCP Option 67
Deploy Cisco Plug and Play (PnP) for automated device onboarding with Catalyst Center
Build complete provisioning workflows using DHCP, TFTP/HTTP servers, and bootstrap configurations
Automate initial device setup including management connectivity, AAA, and base security hardening
Section 1: Day 0 Provisioning Concepts — Knowledge Check
Before reading this section, answer these questions to assess your existing understanding.
Pre-Quiz — Section 1: Day 0 Provisioning Concepts
1. In the Day 0/1/2 framework, which activities fall within the Day 0 phase?
2. Which DHCP option is the primary trigger that causes an IOS XE device to initiate Zero-Touch Provisioning?
3. What single condition must be met for a Cisco IOS XE device to automatically enter ZTP or PnP mode?
4. What is the key architectural difference between ZTP and PnP provisioning?
5. Which business driver is best addressed by Day 0 automation's use of version-controlled templates?
1.1 The Day 0/1/2 Framework
Network automation practitioners divide the device lifecycle into three operational phases. Day 0 covers initial boot and onboarding with no existing configuration — assigning IP addresses, hostnames, AAA credentials, and management access. Day 1 handles post-onboarding service configuration such as routing protocols, VLANs, and QoS. Day 2 governs ongoing lifecycle management: drift correction, software upgrades, and telemetry.
Phase
Timing
Scope
Example Activities
Day 0
Initial boot, no config
Onboarding and baseline
IP assignment, hostname, AAA, SSH, image verification
Day 1
Post-onboarding, pre-production
Service configuration
Routing protocols, VLANs, QoS, security profiles
Day 2
Ongoing operations
Lifecycle management
Drift correction, upgrades, telemetry collection
flowchart TD
A([Device Ships from Factory\nNo Configuration]) --> B
subgraph D0["Day 0 — Onboarding"]
B[Power On\nNo Startup Config] --> C[DHCP Discovery]
C --> D{ZTP or PnP?}
D -->|Option 67| E[ZTP: Download and Run\nPython Script]
D -->|Option 43 / DNS| F[PnP: Register with\nCatalyst Center]
E --> G[Base Config Applied\nHostname · Mgmt IP · AAA · SSH]
F --> G
end
G --> H
subgraph D1["Day 1 — Service Configuration"]
H[Push Service Config\nVLANs · Routing · QoS · Security]
end
H --> I
subgraph D2["Day 2 — Lifecycle Management"]
I[Ongoing Operations\nDrift Correction · Upgrades · Telemetry]
end
style D0 fill:#e8f4f8,stroke:#2980b9
style D1 fill:#eafaf1,stroke:#27ae60
style D2 fill:#fef9e7,stroke:#f39c12
1.2 Business Case for Automated Provisioning
Scale: Enterprise refresh cycles routinely deploy hundreds of devices per quarter. Manual provisioning at this rate consumes engineering time that adds no architectural value. Consistency: Automation enforces a single, version-controlled template — two engineers configuring the same device type no longer produce subtly different results. Speed: A device provisioned via ZTP or PnP is fully configured within minutes of first power-on vs. thirty-to-sixty minutes manually. Auditability: Automated provisioning creates a complete record of what configuration was applied, when, and from which template version.
1.3 Provisioning Architecture Overview
Both ZTP and PnP share a common pattern: a device with no configuration reaches out to infrastructure that delivers configuration to it. ZTP is infrastructure-centric — the device downloads and executes a Python script from an HTTP/TFTP server with no external controller needed. PnP is controller-centric — the device discovers Cisco Catalyst Center and receives configuration through a managed workflow.
Key Points — Section 1
Day 0 is triggered by a device booting with no startup configuration; this is the only required precondition for ZTP or PnP to activate.
The Day 0/1/2 framework separates concerns: onboarding, service delivery, and lifecycle management are distinct automation domains.
DHCP is the universal first contact mechanism for both ZTP and PnP; no connectivity is possible without it.
1. In what environment does the ZTP Python script execute on an IOS XE device?
2. Which Python module pair is used to apply multi-line configuration to an IOS XE device from within a ZTP script?
3. What is the correct syntax for specifying DHCP Option 67 on an IOS DHCP pool to point to a ZTP script at 192.168.1.1?
4. What happens if a ZTP Python script completes successfully but never calls cli.executep("write memory")?
5. Since IOS XE 16.8, why does a booting device alternate its DHCP Client Identifier (Option 61) between its serial number and management MAC address?
2.1 How ZTP Works: The Complete Workflow
ZTP is triggered when an IOS XE device boots and finds no startup configuration. The device sends DHCP Discover messages on the management interface (Gi0) and all front-panel data ports simultaneously. If the DHCP response includes Option 67 (the bootfile-name option containing a URL), ZTP activates automatically. The device downloads the Python script from that URL via HTTP or TFTP, starts Guest Shell, and executes the script inside it.
Animation: ZTP Boot Sequence
1. Device boots — no startup-config detected
2. DHCP Discover sent on Gi0 + all ports
3. DHCP Offer received with Option 67 URL
4. Device downloads ztp.py via HTTP/TFTP
5. Guest Shell container starts automatically
6. ztp.py executes — cli.configurep() called
7. write memory — startup-config saved
Device fully configured — ready for Day 1
sequenceDiagram
participant Dev as IOS XE Device
participant DHCP as DHCP Server (Option 67)
participant HTTP as HTTP Server (ztp.py)
participant GS as Guest Shell
Dev->>DHCP: DHCP Discover (Gi0 + all ports)
DHCP-->>Dev: DHCP Offer — IP lease + Option 67 URL
Note over Dev: Option 67 detected — ZTP activates
Dev->>HTTP: GET /ztp.py
HTTP-->>Dev: 200 OK — Python script payload
Note over Dev: IOS XE initializes Guest Shell
Dev->>GS: Start container, mount IOS XE CLI
GS-->>Dev: Guest Shell ready
Dev->>GS: Execute ztp.py
GS->>GS: get_serial() via show version
GS->>GS: cli.configurep(base_config)
GS->>GS: cli.executep("write memory")
GS-->>Dev: Script complete — startup-config written
Note over Dev: Device ready for Day 1 automation
2.2 Guest Shell Execution Environment
Guest Shell is a CentOS-based Linux container embedded in IOS XE. It starts automatically during ZTP — no operator intervention is needed. It has network access through the device management interface, can make outbound HTTP/HTTPS calls, install Python packages, and exposes the IOS XE CLI through Python modules. Its isolation means a poorly written script cannot crash the switch OS. The ZTP script file (ztp.py) is typically hosted at /var/www/html/ on an Apache HTTP server.
2.3 Python CLI Modules
Module Pair
Mode
Purpose
cli.cli / cli.clip
Exec
Run show commands, returns string output
cli.execute / cli.executep
Exec
Run exec-mode commands (e.g., write memory)
cli.configure / cli.configurep
Config
Apply configuration via configure terminal
2.4 DHCP Option 67 Configuration
Option 67 is the single required DHCP option for ZTP. On a Cisco IOS DHCP pool:
ip dhcp pool ZTP_POOL
network 192.168.69.0 255.255.255.0
default-router 192.168.69.1
dns-server 8.8.8.8
option 67 ascii http://192.168.69.1/ztp.py
On ISC DHCP (/etc/dhcp/dhcpd.conf), the equivalent is option bootfile-name "http://192.168.69.1/ztp.py";. Option 150 (TFTP Server Address) is supplementary and not required for ZTP to function.
2.5 ZTP Script Best Practices
A production ZTP script should: extract the serial number for dynamic hostname generation, configure SSH and disable Telnet, enable NETCONF/RESTCONF for subsequent Day 1 automation, use algorithm-type scrypt for password hashing, and always call cli.executep("write memory") to persist the configuration across reboots. Write scripts to be idempotent — safe to run multiple times without causing configuration damage.
Key Points — Section 2: IOS XE ZTP
ZTP requires only three components: a DHCP server with Option 67, an HTTP/TFTP server hosting ztp.py, and an IOS XE device booting without startup config.
Guest Shell is a CentOS Linux container embedded in IOS XE — it starts automatically; the script runs in isolation from the IOS XE control plane.
Use cli.configurep() to apply configuration lists; always follow with cli.executep("write memory") to persist across reboots.
Since IOS XE 16.8, DHCP Option 61 alternates between serial number and MAC address — DHCP servers must be prepared to issue a lease on either identifier.
Use HTTPS for script delivery in production; plaintext HTTP exposes the configuration script to MITM interception and replacement.
1. In what environment does the ZTP Python script execute on an IOS XE device?
2. Which Python module pair is used to apply multi-line configuration to an IOS XE device from within a ZTP script?
3. What is the correct syntax for specifying DHCP Option 67 on an IOS DHCP pool to point to a ZTP script at 192.168.1.1?
4. What happens if a ZTP Python script completes successfully but never calls cli.executep("write memory")?
5. Since IOS XE 16.8, why does a booting device alternate its DHCP Client Identifier (Option 61) between its serial number and management MAC address?
Section 3: Cisco Plug and Play (PnP)
Pre-Quiz — Section 3: Cisco Plug and Play (PnP)
1. What is the correct ASCII string format for DHCP Option 43 pointing a PnP device to Catalyst Center at 10.10.20.85 on HTTPS port 443?
2. In what order does a PnP-capable device attempt to discover Catalyst Center if DHCP Option 43 is not present?
3. What IOS XE command must be configured on an upstream switch to steer unconfigured devices into a specific management VLAN (e.g., VLAN 100) for PnP discovery?
4. Which DHCP option does a PnP-capable device include in its Discover message to signal that the server should return Option 43?
5. What PnP device state indicates that a device has connected to the network and established a link to Catalyst Center, but no site or template has been assigned to it yet?
3.1 PnP Architecture and Core Components
Cisco Plug and Play is a controller-driven provisioning solution. Instead of executing a locally downloaded script, an unconfigured device discovers and registers with Cisco Catalyst Center (formerly DNA Center), which orchestrates the entire onboarding workflow from a central management plane. Four components make up the solution: the on-device PnP Agent (embedded in firmware, no pre-installation needed), the PnP Server (Catalyst Center), the PnP Protocol (HTTPS-based communication), and optionally PnP Connect — Cisco's cloud redirect service at devicehelper.cisco.com.
3.2 The Four Discovery Methods
Priority
Method
Mechanism
Requirement
1
DHCP Option 43
Server returns controller IP in Option 43
DHCP server configured with Option 43
2
DNS Lookup
Device resolves pnpserver.<domain>
DNS A record pointing to Catalyst Center
3
PnP Connect (Cloud)
Contact devicehelper.cisco.com
Valid Cisco contract; device registered at software.cisco.com
4
USB Key
Bootstrap config on USB drive
Physical USB preparation
The DNS method is elegant at scale: add a single A record pnpserver.corp.example.com pointing to Catalyst Center and every new device in that domain finds its controller automatically — no DHCP modifications needed.
flowchart TD
A([Device Boots - No Startup Config - PnP Agent Activates]) --> B
B[Send DHCP Discover with Option 60 ciscopnp] --> C{Option 43 in DHCP response?}
C -->|Yes| Z[Connect to Catalyst Center via Option 43 IP]
C -->|No| D[Resolve pnpserver.domain via DHCP domain name]
D --> E{DNS A record exists?}
E -->|Yes| Z
E -->|No| F[Contact devicehelper.cisco.com]
F --> G{Device registered at software.cisco.com?}
G -->|Yes| H[Cloud redirects to on-premises Catalyst Center]
H --> Z
G -->|No| I[Check for USB Key with bootstrap config]
I --> J{USB config found?}
J -->|Yes| K[Apply USB bootstrap configuration]
J -->|No| L([Discovery Failed - Retry or Manual Intervention])
Z --> M([PnP Agent Registers with Catalyst Center])
style Z fill:#eafaf1,stroke:#27ae60
style L fill:#fdedec,stroke:#e74c3c
3.3 DHCP Option 43 Format
Option 60 in the device's DHCP Discover (value "ciscopnp") signals the server to return Option 43. The Option 43 ASCII string uses a structured format:
5A1N;B2;K4;I10.10.20.85;J443
Field
Value
Meaning
5A1N
Protocol version
PnP protocol identifier
B2
Address type
1 = FQDN, 2 = IPv4 address
K4
Transport type
4 = HTTPS, 5 = HTTP
I<IP>
Controller address
IP or FQDN of Catalyst Center
J443
Port
80 = HTTP, 443 = HTTPS
3.4 PnP Device States
Animation: PnP Device State Transitions
Planned
Unclaimed
Onboarding
Provisioned
Error
Click Play to walk through PnP device states
stateDiagram-v2
[*] --> Planned : Serial pre-registered via REST API
Planned --> Unclaimed : Device powers on and connects to network
[*] --> Unclaimed : Device connects (not pre-registered)
Unclaimed --> Onboarding : Operator claims device, assigns site and template
Onboarding --> Provisioned : Day 0 config pushed, device applies and re-registers
Provisioned --> [*] : Device moves to managed inventory
Onboarding --> Error : Provisioning failure (template error, connectivity loss)
Unclaimed --> Error : Discovery failure (DHCP/DNS/cloud unreachable)
Error --> Unclaimed : Issue resolved, device retries
3.5 Critical Infrastructure Prerequisites
Two prerequisites are most commonly overlooked in PnP deployments:
DHCP Relay: Configure ip helper-address <dhcp-server> on all access uplinks so unconfigured devices can reach the DHCP server across Layer 3 boundaries.
PnP Startup VLAN: If the management VLAN is not VLAN 1, configure pnp startup-vlan 100 on the upstream switch to steer new devices into the correct VLAN for discovery.
Key Points — Section 3: Cisco PnP
PnP devices include DHCP Option 60 ("ciscopnp") in their Discover; the server responds with Option 43 containing the Catalyst Center address.
The Option 43 ASCII string format is 5A1N;B2;K4;I<IP>;J<port> — memorize the field order for the exam.
Discovery fallback order: DHCP Option 43 → DNS pnpserver.<domain> → PnP Connect cloud → USB key.
pnp startup-vlan and ip helper-address are the two most commonly missed PnP prerequisites.
Pre-registering device serial numbers via the Catalyst Center REST API enables fully automated zero-touch claiming with no operator intervention.
Post-Quiz — Section 3: Cisco Plug and Play (PnP)
1. What is the correct ASCII string format for DHCP Option 43 pointing a PnP device to Catalyst Center at 10.10.20.85 on HTTPS port 443?
2. In what order does a PnP-capable device attempt to discover Catalyst Center if DHCP Option 43 is not present?
3. What IOS XE command must be configured on an upstream switch to steer unconfigured devices into a specific management VLAN (e.g., VLAN 100) for PnP discovery?
4. Which DHCP option does a PnP-capable device include in its Discover message to signal that the server should return Option 43?
5. What PnP device state indicates that a device has connected to the network and established a link to Catalyst Center, but no site or template has been assigned to it yet?
Section 4: Building Complete Provisioning Workflows
1. Which scaling best practice is most important when rolling out 200 new switches across a campus in a single morning?
2. In a Jinja2 PnP template, how are per-device variable values such as hostname and management IP differentiated from static policy configuration?
3. A troubleshooting engineer finds a device that runs the ZTP script successfully but always loses its configuration after a reload. What is the most likely cause?
4. Which security measure is specifically recommended to prevent a malicious actor from replacing your ZTP configuration script during the provisioning process?
5. An organization uses ZTP to provision initial management connectivity at remote sites, then relies on a second mechanism to complete Day 1 service configuration. What is this approach called?
Stagger deployments: Power on 10-20 devices at a time to avoid DHCP floods and HTTP server saturation.
Local provisioning servers: Deploy HTTP servers at each major site; a 50KB script downloaded by 200 switches simultaneously can saturate a 10 Mbps WAN link.
Version control: Store all ZTP scripts and PnP templates in Git with tags (git tag v1.4.2) for audit trail.
HTTPS delivery: HTTP transmits the configuration script in cleartext — use HTTPS to prevent MITM script replacement.
Serial number whitelisting: Reject provisioning requests from devices not in the pre-approved serial number list.
Idempotency: Write ZTP scripts that are safe to run multiple times — a device that reboots mid-provisioning should converge correctly on re-run.
4.4 Common Troubleshooting
Symptom
Likely Cause
Resolution
Device does not enter ZTP
Existing startup-config present
erase startup-config + reload
DHCP received but no script download
Option 67 URL unreachable
Verify HTTP server running; check routing
Script runs but config not applied
Python CLI error in script
Test interactively in Guest Shell
Script completes but config lost after reload
write memory not called
Add cli.executep("write memory")
PnP device stuck in Unclaimed
No site/template assigned
Claim device in Catalyst Center; check pre-registration
Key Points — Section 4: Workflows and Best Practices
Production provisioning requires coordinated DHCP, HTTP/TFTP, and for PnP, a Catalyst Center controller with proper network profiles.
Stagger rollouts to 10-20 devices per wave; simultaneous mass booting can flood DHCP and saturate provisioning servers.
Always use HTTPS for ZTP script delivery — HTTP exposes configuration scripts to MITM interception and replacement attacks.
ZTP and PnP can be combined in hybrid architectures: ZTP provisions initial management connectivity, PnP completes Day 1 service configuration.
Run a pre-deployment checklist before every large rollout: verify DHCP relay, Option 43/67 format, HTTP server accessibility, and serial number pre-registration.
1. Which scaling best practice is most important when rolling out 200 new switches across a campus in a single morning?
2. In a Jinja2 PnP template, how are per-device variable values such as hostname and management IP differentiated from static policy configuration?
3. A troubleshooting engineer finds a device that runs the ZTP script successfully but always loses its configuration after a reload. What is the most likely cause?
4. Which security measure is specifically recommended to prevent a malicious actor from replacing your ZTP configuration script during the provisioning process?
5. An organization uses ZTP to provision initial management connectivity at remote sites, then relies on a second mechanism to complete Day 1 service configuration. What is this approach called?
Post-Quiz — Section 1: Day 0 Provisioning Concepts
1. In the Day 0/1/2 framework, which activities fall within the Day 0 phase?
2. Which DHCP option is the primary trigger that causes an IOS XE device to initiate Zero-Touch Provisioning?
3. What single condition must be met for a Cisco IOS XE device to automatically enter ZTP or PnP mode?
4. What is the key architectural difference between ZTP and PnP provisioning?
5. Which business driver is best addressed by Day 0 automation's use of version-controlled templates?