Hands-On Lab: Configuring Zero-Touch Provisioning (ZTP)

This hands-on lab configures a DHCP server to point a factory-default router toward a bootstrap configuration file, verifying the device automatically downloads and applies its full configuration on first boot without any manual CLI interaction.

Zero-Touch ProvisioningDHCP Option 67Automated Day-Zero Configuration

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure a DHCP server with the option pointing new devices to a bootstrap configuration file, place a complete configuration file on a TFTP server, boot a factory-default router, and verify it automatically retrieves and applies the configuration with zero manual CLI commands entered.

Lab Purpose

Every device throughout this entire series was configured by an engineer manually typing commands at a console. ZTP eliminates this entirely for initial deployment, letting a device fresh out of the box discover its configuration automatically over the network the moment it is connected and powered on — essential for organizations deploying dozens or hundreds of identical branch routers where console-by-console configuration does not scale.

Lab Topology

DHCP/TFTP server: 192.168.254.1

R-NEW (factory-default router,
       no configuration at all)
       ---- Gi0/0 ---- connected to the
                        same network segment

Task 1: Prepare the Bootstrap Configuration File

Create a complete configuration file containing hostname, interface addressing, and basic security settings, and place it on the TFTP server.

Task 2: Configure DHCP Option 67

Configure the DHCP server's scope to include option 67 pointing to the bootstrap file's location.

Task 3: Confirm R-NEW Is in Its Factory-Default State

Verify the router has no startup configuration, which triggers ZTP behavior on boot.

Task 4: Power On R-NEW and Observe the ZTP Process

Boot the router and observe it obtaining a DHCP lease, retrieving option 67, and downloading the configuration file automatically.

Task 5: Verify the Configuration Was Applied

Confirm the router now has the hostname, addressing, and settings from the bootstrap file, all without any manual CLI input.

Solution and Verification

-- Bootstrap file (R-NEW-config.txt) on the
-- TFTP server:

hostname BranchRouter1
interface GigabitEthernet0/0
 ip address 192.168.254.50 255.255.255.0
 no shutdown
enable secret ZtpSecure2026
line vty 0 15
 transport input ssh
end

DHCPServer(config)# ip dhcp pool ZTP-POOL
DHCPServer(dhcp-config)# network 192.168.254.0 255.255.255.0
DHCPServer(dhcp-config)# option 67 ascii "R-NEW-config.txt"
DHCPServer(dhcp-config)# next-server 192.168.254.1

-- Option 67 tells the DHCP client the
-- specific filename to request via TFTP,
-- while next-server (option 66 conceptually)
-- specifies where that TFTP server is

R-NEW> show startup-config

startup-config is not present
-- Confirmed factory-default -- no saved
-- configuration exists, which is precisely
-- the condition that triggers ZTP behavior
-- automatically on boot

-- R-NEW powers on:

*** ZTP - Zero Touch Provisioning ***
DHCP lease obtained: 192.168.254.75
Option 67 received: R-NEW-config.txt
TFTP server: 192.168.254.1
Downloading R-NEW-config.txt...
Applying configuration...
-- All of this occurs automatically,
-- entirely before any human types a
-- single command

BranchRouter1# show running-config | include hostname
hostname BranchRouter1

BranchRouter1# show ip interface brief | include GigabitEthernet0/0
GigabitEthernet0/0    192.168.254.50    YES manual up    up
-- The hostname and interface address from
-- the bootstrap file are both confirmed
-- applied -- the router configured itself
-- entirely through the ZTP process

Key Takeaway

ZTP relies on a factory-default device's built-in behavior of requesting a DHCP lease and checking for option 67 automatically before any configuration exists — this single DHCP option is what bridges an unconfigured device to its intended full configuration, making it the essential piece of infrastructure any organization must have correctly configured before ZTP can work at all, regardless of how correct the bootstrap configuration file itself is.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue