Ops installs a leaf that already has a saved configuration and wonders why ZTP did not run. Which explanation is most accurate?
Select an answer to reveal the explanation.
Short Explanation
If the leaf already has a filled-out playbook in flash, it will not go hunting for a new ZTP script like a blank device would. Ops should expect ZTP on factory-default style boots, not on already-configured gear. That saved config is why the autopilot stayed parked.
Full Explanation
ZTP typically applies under factory-default or no-config conditions, not on devices that already have a saved configuration. Preconfigured municipal leaves boot their saved config and skip the ZTP chase. Claiming ZTP always runs on every reboot would constantly re-provision production devices after routine reloads. Blaming missing VXLAN in the saved config confuses overlay features with the factory-default initiation trigger. Saying ZTP only runs on spines invents a role restriction that does not explain leaf saved-config behavior. Exam caveat: To re-enter ZTP, return the device to an unconfigured/factory state and ensure management services are ready. Operational check: Compare a factory-default leaf with a configured twin on the same management VLAN; only the blank device should perform DHCP/file ZTP. In civic data-center practice, treat the correct concept as part of a controlled management design rather than an isolated checkbox, and document the expected show-command or log evidence so the next on-call engineer can prove the fabric behavior without re-deriving the theory under pressure. In civic data-center practice, treat the correct concept as part of a controlled management design rather than an isolated checkbox, and document the expected show-command or log evidence so the next on-call engineer can prove the fabric behavior without re-deriving the theory under pressure.