Arista EOS ZTP: DHCP Options and Boot Scripts - 夜莺博客

Arista EOS ZTP: DHCP Options and Boot Scripts

Zero touch provisioning is the difference between a rack of switches that configures itself on first boot and an engineer pasting commands into a console at midnight. On Arista EOS the mechanism is deliberately simple: a factory-default switch with no startup configuration sends a DHCP request, receives a bootfile name in option 67, downloads that file and executes it. Almost every ZTP failure in the field is one of four things — a missing option 67, an unreachable HTTP server, a script with a nonzero exit code, or ZTP running on the wrong interface. This article covers the correct setup and each of those failure modes.

What happens on first boot

  1. The switch boots without a startup configuration and enters ZTP mode.
  2. It sends DHCP requests on the management interface.
  3. It receives an address, gateway, DNS server and option 67 (bootfile name).
  4. It fetches that URL — an EOS script, a Python file, or a CloudVision bootstrap URL.
  5. It runs the script, which applies configuration, and exits cleanly.
  6. On success the switch reloads with the applied configuration; ZTP is disabled afterwards.

Because the script runs with full configuration privileges, anything that fails silently leaves the switch in a half-provisioned state that is harder to diagnose than a clean failure.

DHCP server configuration

The critical line is option bootfile-name. Both a scope-wide default and a per-host override work; a per-host entry keyed on the MAC address is the usual choice because it lets you point each chassis at its own provisioning script.

subnet 192.0.2.0 netmask 255.255.255.0 {
  range 192.0.2.20 192.0.2.225;
  option routers 192.0.2.1;
  option subnet-mask 255.255.255.0;
  option domain-name-servers 192.0.2.53;
  option bootfile-name "http://192.0.2.10/ztp/provision.py";
}

host leaf01 {
  hardware ethernet fc:bd:67:c7:f5:00;
  fixed-address 192.0.2.200;
  option host-name "leaf01";
  option bootfile-name "http://192.0.2.10/ztp/leaf01.py";
}

Prefer HTTP over TFTP. HTTP returns real status codes you can test with curl -I, transfers larger files reliably, and does not depend on UDP block-size negotiation. If you must keep TFTP, raise the block size to reduce transfer overhead, but expect far less useful error messages.

If the fleet is managed by CloudVision as a service, option 67 can point at the tenant bootstrap URL instead of a local script. On EOS 4.30.0F and later the option is not even required: the device contacts the tenant automatically once it has an address. Use the regional tenant URL that matches your CVaaS instance; pointing every region at the US endpoint produces slow or failed onboarding from other continents.

Test the DHCP path before the switch arrives

sudo dhclient -v eth0 2>&1 | grep -i "bootfile"
# DHCPOFFER of 192.0.2.51 from 192.0.2.5
# option bootfile-name: http://192.0.2.10/ztp/provision.py

curl -I http://192.0.2.10/ztp/provision.py
# HTTP/1.1 200 OK

A test host on the management VLAN proves the scope, the option and the web server in under a minute, and it removes three variables from the racking day.

Failure modes and their fingerprints

Symptom Cause Fix
DHCP lease obtained, provisioning URL "None" option 67 missing from the scope Add option bootfile-name and restart the DHCP daemon
Script download times out Wrong URL, wrong file name, web server down Fetch the URL from a test host; check the file name character by character
Script downloads then provisioning fails Python syntax error, nonzero exit Run the script locally with a linter before serving it
ZTP active but no DHCP traffic ZTP bound to the wrong interface Check the management port used and the DHCP scope on that subnet
show zerotouch
zerotouch cancel
zerotouch run

show zerotouch prints the last action, the provisioning URL and whether a script download was attempted — the three fields that separate a DHCP problem from a script problem. After fixing the server side, zerotouch cancel followed by zerotouch run retries without a reload.

Make ZTP safe to leave enabled

ZTP is a powerful default: any device that can reach the DHCP scope can hand a switch a script. Keep the management VLAN isolated, validate the script before publishing it, and confirm that the configuration the script applies includes the management addressing and credentials — if it does not, the switch finishes ZTP unreachable and you are back on the console. Once the fleet is provisioned, use a configuration backup platform so that a replacement switch can be restored rather than reinvented; the workflow in network configuration backup with Oxidized covers the collection side. For the MLAG and VLAN configuration your ZTP script will likely apply, the command sequence in Arista EOS MLAG configuration is a good template.

原文链接:https://arista.io/help/articles/overview-ztp