Zero-Touch Provisioning Fails on Three of Twenty-Four Switches
You are staging 24 QFX5120-48Y switches using ZTP. A DHCP server on the management subnet returns option 43 with sub-option 1 for the Junos image and sub-option 2 for the configuration file. The image and a junos.conf template are served by an internal HTTP server at 10.1.1.10. All switches start from a zeroized state and are cabled to untagged access ports in VLAN 400. Twenty-one switches complete ZTP and appear in monitoring. Three do not: switch A loops on an image download error; switch B downloads the configuration, boots Junos, but ends up with a factory-style configuration and no hostname; switch C never receives a DHCP offer and sits at the boot prompt. The DHCP scope has free addresses, and the HTTP server is reachable from the staging subnet.
1. For switch A, what is the most likely cause of the image download failure, and how would you verify and fix it?
Read the worked answer
A download loop usually means the URL in option 43 does not resolve to a real object on the HTTP server. Check the exact string the DHCP server returns and compare it character by character with the file on disk: HTTP paths are case-sensitive, and a filename mismatch, a missing directory, or an extra path segment produces a 404 that ZTP cannot recover from by itself. Verify from a host in the staging subnet with curl -I against the exact URL; a 200 confirms the path, a 404 confirms the string is wrong.
On the switch console, check show system autoinstallation status and the messages log for the failing URL. Fix the DHCP option 43 sub-option string or rename the file so they match, then zeroize the switch with request system zeroize and let it retry from a clean state. Do not debug the switch configuration first: ZTP has not reached configuration yet, so the image path is the only thing that matters.
2. Switch B downloads the configuration but does not apply it. What is the likely reason and how do you confirm it?
Read the worked answer
Check whether the delivered configuration can actually commit. ZTP commits non-interactively, so anything that would require a prompt or that fails validation causes the commit to fail and the switch to fall back to a default-style configuration. A very common cause is a missing or malformed root-authentication stanza in the template: the commit cannot complete without it, and no one is there to type a password.
Confirm on the console by reviewing the log around the autoinstallation attempt and running a manual commit check after loading the same file, which surfaces the exact validation error. Also verify that the template is syntactically valid for that Junos release and that it does not depend on interfaces that do not exist on this model. Fix the template, confirm it commits on a lab switch, then zeroize switch B and retry. Treat the template as code: one bad stanza silently affects every switch that uses it.
3. Switch C never gets a DHCP offer. What architectural or Layer 2 checks would you make?
Read the worked answer
If the switch is at the boot prompt and has no address, look below ZTP. Confirm the access port is actually in VLAN 400 and untagged, because a trunk/native VLAN mismatch means the DHCP discover never reaches the server. Check the port's VLAN membership and status on the access switch, and confirm link is up at the expected speed.
Next, run a packet capture on the access port filtering UDP 67 and 68, or check the DHCP server logs for a discover from switch C's MAC. No discover means a Layer 2 or VLAN problem; a discover with no offer means scope, relay, or option 82 handling on the server. Also confirm the server is not tied to a circuit-ID or MAC allow-list that does not include the new port. Fix the VLAN or the matching rule, then power-cycle the switch so it re-runs DHCP.