Dell OS10 ZTD: Zero-Touch Provisioning Step by Step

Racking a hundred switches and typing the same ten commands into each console port is a waste of a maintenance window. Dell SmartFabric OS10 includes zero-touch deployment (ZTD): the switch boots, finds a DHCP server, downloads a provisioning script plus a CLI batch file, and configures itself. This guide walks the whole path — how ZTD discovers its configuration, what the provisioning script must contain, how to watch the process, and how to un-stick a switch that is waiting for a DHCP offer that will never come.

How OS10 ZTD Actually Works

ZTD is enabled by default the first time a switch boots with a factory-installed OS10 image, or after an ONIE: OS Install from the ONIE menu. On boot it starts a DHCP client on every interface — management and front-panel ports — and sends DHCP DISCOVER packets with option 60 (vendor class identifier). The DHCP server answers with option 240, which carries the URL of the ZTD provisioning script. The switch downloads and executes that script.

Key behaviours worth knowing before you design the DHCP scope:

• ZTD configures all interfaces for untagged VLAN traffic while it is discovering, so the DHCP server must be reachable from an untagged access port.
• ZTD is IPv4 only — DHCPv6 is not supported.
• At least one front-panel port used for discovery must be in non-breakout mode.
• OS10 ZTD and ONIE autodiscovery are different features. ONIE installs the NOS image; OS10 ZTD installs/upgrades the image and configures the switch.

The ZTD Provisioning Script

Write the provisioning script in bash and store it on an HTTP server (only the script needs HTTP; the payload files it references can be HTTP, FTP, SFTP, SCP or TFTP). Three variables drive everything:

#!/bin/bash
####################################################################
#            Example OS10 ZTD Provisioning Script
#   At least ONE of the three variables below must be filled in.
####################################################################
IMG_FILE="http://10.10.10.20/OS10.bin"
CLI_CONFIG_FILE="http://10.10.10.20/cli_config"
POST_SCRIPT_FILE="http://10.10.10.20/no_post_script.py"

################### DO NOT MODIFY THE LINES BELOW #################
sudo os10_ztd_start.sh "$IMG_FILE" "$CLI_CONFIG_FILE" "$POST_SCRIPT_FILE"

If none of the three variables holds a valid URL, or any file cannot be downloaded, ZTD stops and drops the switch into CLI Configuration mode. Empty variables are not a partial success.

DHCP Server Configuration

# ISC DHCP example: hand out the ZTD script URL via option 240
option ztd-provision-url code 240 = text;
subnet 10.10.10.0 netmask 255.255.255.0 {
  range 10.10.10.100 10.10.10.200;
  option routers 10.10.10.1;
  option ztd-provision-url "http://10.10.10.20/ztd_script.sh";
}

Watch It Run — and Stop It When Needed

While ZTD is discovering, the switch CLI is locked: only show commands work and configuration attempts return % Error: ZTD is in progress (configuration is locked). Status is visible with:

OS10# show ztd-status
-----------------------------------
ZTD Status     : disabled
ZTD State      : completed
Protocol State : idle
Reason         : ZTD process completed successfully at Sun Nov 7 09:42:52 2021
-----------------------------------

OS10# ztd cancel        # abort discovery (only valid while ZTD is waiting for DHCP)
OS10# reload ztd        # erase startup config and re-run ZTD from scratch

Two timers catch people out: after booting in ZTD mode, a switch that receives no DHCP answer with option 240 within about five minutes exits ZTD by itself. But once a DHCP answer is received and the script starts, the process does not time out — a script pointing at a dead HTTP server leaves the switch locked until you cancel it.

Preparing the Three Files

ZTD is only as good as the files it downloads, and a badly written CLI batch file is the most common reason a freshly racked switch comes up half configured. Build all three artefacts before the rollout window, test them on one switch, then treat them as versioned code rather than one-off hand-typed configuration.

The CLI batch file is a plain list of OS10 configuration commands executed in order after the image boots. Anything you would type into a console at first login belongs here: hostname, management interface and default route, NTP, syslog, SNMP, the VLANs the switch serves, and the uplink port-channel or VLT configuration. Write it idempotently — assume it may run a second time after a factory reset — and use the command syntax that creates or replaces rather than the one that errors if the object already exists.

! cli_config for rack-A access switches - OS10 10.5.6
hostname rackA-sw01
username netadmin password 0 <redacted> role sysadmin
snmp-server community <redacted> ro
!
interface mgmt1:1
 no shutdown
 ip address dhcp
!
ip route 0.0.0.0/0 10.10.10.1
!
clock timezone UTC 0
ntp server 10.10.10.30
logging server 10.10.10.40
!
interface vlan 100
 description SERVERS
 no shutdown
!
interface ethernet 1/1/1:1
 description UPLINK-to-SPINE-1
 no shutdown
 channel-group 10 mode active
!
interface port-channel 10
 description UPLINK-SPINE
 switchport mode trunk
 switchport trunk allowed vlan 100,110,120,999
 no shutdown
!
end
copy running-configuration startup-configuration

Two details in that file are easy to forget. The default route is not optional — a switch that cannot route to the file server cannot download anything else, and a management path that depends on the DHCP lease it was given during discovery will behave differently once ZTD completes. And the trailing copy running-configuration startup-configuration matters: without it a subsequent reload comes back with the startup configuration the switch had before provisioning, which in the worst case triggers the ZTD process again.

The post script is optional and is where you put anything the CLI cannot express: an API call to register the switch in your inventory or CMDB, a check that writes a marker file, a call to your monitoring system to start scraping the new host. Keep it simple — the default Python interpreter on OS10 is 2.7, so stay with standard libraries and avoid anything that needs a package install.

DHCP Options 60 and 240 in Detail

Discovery is a two-option conversation. The switch sends a DISCOVER carrying option 60, the vendor class identifier, which lets the DHCP server recognise it as a Dell OS10 device and hand it the right scope. The server replies with a lease and option 240, a text option carrying the URL of the ZTD provisioning script. The switch fetches that URL over HTTP, executes the script, and the script tells it what to install and how to configure itself.

# ISC DHCP: define option 240 and scope it with a class based on option 60
option ztd-provision-url code 240 = text;

class "dell-os10-ztd" {
  match if substring(option vendor-class-identifier, 0, 20) = "Dell EMC Networking";
  option ztd-provision-url "http://10.10.10.20/ztd_script.sh";
}

# Kea: same idea, expressed as a client class and an option-data entry
{
  "client-classes": [
    { "name": "dell-os10-ztd",
      "test": "substring(option[60].hex, 0, 20) == 'Dell EMC Networking'" }
  ],
  "option-data": [
    { "name": "ztd-provision-url", "code": 240, "space": "dhcp4",
      "data": "http://10.10.10.20/ztd_script.sh",
      "client-classes": [ "dell-os10-ztd" ] }
  ]
}

On a Windows DHCP server the mechanics are the same but the interface differs: define vendor class Dell OS10 ZTD, then add option 240 as a string option to the scope or to a policy that matches that vendor class. Whichever server you use, keep the URL short — option 240 is a text option and very long URLs are easy to truncate or mistype — and confirm the script is served with a content type the switch accepts rather than an HTML error page a web server generated for a path it could not find. A 404 page returned with HTTP 200 is the classic silent failure: the switch downloads the page, tries to execute it as a shell script, fails, and lands in CLI configuration mode with no useful message.

Scaling Beyond a Rack

ZTD stops being a novelty and starts paying for itself when you template the files. Instead of one CLI batch file per switch, generate them from an inventory: a loop that renders a jinja2 template with hostname, management address, uplink ports and VLAN list for each device produces a validated configuration per switch with no typing. The same template can be previewed and reviewed in a pull request, which is exactly the control you want over a hundred identical switches.

The post script is the natural place to close the loop: have it call your inventory system with the serial number, the model and the fact that provisioning finished, so a newly racked switch appears in monitoring and in your documentation without anyone updating a spreadsheet. If the post script fails, treat that as a signal worth alerting on — a switch that is up but unknown to your inventory is a switch nobody will notice going down.

Requirements, Failure Modes and How to Diagnose Them

Most ZTD failures are network reachability problems, not ZTD problems. Check these conditions before the rollout window and the remaining failures become straightforward to read.

OS10# show ztd-status                 # current state, protocol state and reason
OS10# show version                    # did the intended image actually activate?
OS10# show boot                       # which image is set to boot next?
OS10# show interface mgmt1:1          # did the management interface get an address?
OS10# show file-systems               # is the image present on flash?
OS10# show logging | grep -i ztd      # what the process reported
OS10# ztd cancel                      # stop discovery while it is waiting for DHCP
OS10# reload ztd                      # erase startup config and re-run ZTD from scratch
OS10# image validate                  # checksum-check an image before a fleet-wide rollout

The Reason line in show ztd-status is the single most informative field and it is worth reading literally: "completed successfully" means exactly that, while a reason mentioning a file or a download tells you which artefact to look at. If the state says ZTD is still in progress but no DISCOVER packet ever left the switch, look at the physical path and the port mode rather than at the DHCP server.

ZTD, ONIE Autodiscovery and Manual Configuration

These are three different tools and using the wrong one wastes a maintenance window. ONIE autodiscovery installs a network operating system image onto a bare switch — it gets the device to a bootable state but configures nothing. ZTD goes further: it installs or upgrades the image and applies configuration, and it is what you want on a factory-fresh switch. Manual console configuration remains the right answer for a single switch, for a lab unit, and for recovering a device whose ZTD attempt went wrong.

Security Notes Worth Taking Seriously

ZTD deliberately accepts configuration from the network, which is a powerful capability and deserves the same scrutiny as any other trust decision. A few controls make it reasonable rather than reckless.

• Keep the provisioning infrastructure on a dedicated management VLAN. The script server, the DHCP scope and the switches being provisioned should all live somewhere a user device cannot reach.
• Scope the DHCP offer to the devices that should receive it. A switch answering option 240 on the access network will happily provision any racked device that asks. Narrow the class, and remove or disable the offer once the rollout finishes.
• Validate the image before handing it to a fleet. image validate on a single unit catches a corrupt or partial download before it reaches a hundred switches.
• Do not put reusable privileges in the CLI batch file. Use AAA with a central directory where you can, and treat any local account in the file as a break-glass account to be rotated.
• Remember the post script runs with elevated rights. Whatever it can reach, an attacker who can modify it can reach. Serve it over HTTPS where possible and restrict write access to one account.

Deployment Checklist

1. Put the provisioning script on HTTP, and the image / CLI batch / post script on whichever file server your management network can reach.
2. Verify the DHCP scope answers with option 240 from an untagged port that the rack switch can see.
3. Keep the CLI batch file idempotent: management IP, hostname, NTP, syslog, uplink port-channel.
4. Validate the OS10 image before handing it to a fleet — use image validate for a manual check on one unit first.
5. Confirm with show ztd-status and a show version afterwards, then save the config so a later reload does not re-trigger provisioning.

相关阅读：Dell OS10 基础管理与 CLI、OS10 固件升级：ONIE 与 image install 的区别 以及 Dell OS10 默认网关与管理路由；批量生成配置文件见 Ansible Jinja2 网络配置模板，复位与清空启动配置见 Dell OS10 恢复出厂设置，VLT 排障见 Dell OS10 VLT 排障命令。

原文链接：Dell SmartFabric OS10 User Guide - Zero-touch deployment