A regional DC build needs identical leaf roles with unique hostnames and management IPs. How does a sound ZTP workflow support that requirement?
Select an answer to reveal the explanation.
Short Explanation
Same job title, different name badges—that is leaf ZTP done right. A shared role template keeps configs consistent, while per-device parameters stamp unique hostnames and IPs. The regional build does not need thirty totally different playbooks or one cloned identity for every switch.
Full Explanation
Sound ZTP delivers a common role template while mapping per-device parameters such as hostname and management IP, giving regional builds consistent leaf behavior with unique identity. Forcing one shared hostname and IP forever creates collisions and breaks management uniqueness. Requiring console renumbering because templates cannot carry identity underestimates parameterized provisioning. Eliminating DHCP so uniqueness comes only from stickers removes a primary binding mechanism between device identity and artifacts. Exam caveat: Uniqueness usually comes from DHCP options or serial/MAC selection into a parameterized template, not handwritten one-offs for every leaf. Operational check: ZTP two same-role lab leaves and confirm shared baseline plus distinct hostname and management IP per serial map. 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.