Zero-Touch Provisioning with POAP, NX-API, and Config Compliance
A service provider is deploying 40 Cisco Nexus 93180YC-FX leaf switches in a new pod. The current process uses a spreadsheet and manual console configuration. Last quarter, three outages were traced to mismatched MTU and VLAN assignments, and one switch was configured with the wrong NTP server. The team has a Windows DHCP server, a Git repository, Ansible, and Cisco NX-API. They want a repeatable build with an automated compliance check before a switch is admitted to production. The security team requires TACACS+ authentication, role-based access, and no local fallback except for break-glass. The switches will boot from ONIE and need to download the correct NX-OS image and configuration from an internal repository that requires HTTPS client authentication.
1. Design the POAP flow, including DHCP options, image download, and configuration delivery, and explain how you prevent a switch from receiving another switch's configuration.
Read the worked answer
Use a DHCP reservation keyed to each switch serial number or chassis MAC, with option 66 pointing to the boot server and option 67 pointing to the POAP script path. The script identifies the platform with show version and the serial number, downloads the correct NX-OS image over HTTPS or SCP, verifies the hash, installs it with install all nxos bootflash:..., and reboots. After reboot, the script downloads the golden configuration for that serial number from the repository. The per-serial mapping is what prevents cross-configuration: do not use a single generic option 67 script that applies the same config to every switch. The golden configuration includes TACACS+ servers, RBAC roles, NTP, MTU, VLANs, vPC, and management ACLs. Use HTTPS client authentication with a dedicated certificate or service account, and log every POAP request so a failed or repeated download can be traced.
2. How would you implement the compliance gate and RBAC so a switch is not admitted to production until it passes, while preserving break-glass access?
Read the worked answer
Treat Git as the source of truth and run Ansible or pyATS after POAP to pull show running-config and operational state via NX-API. Compare the running configuration against the intended per-switch configuration, and check specific invariants such as system MTU, VLAN-to-port mapping, NTP reachability, vPC peer status, and TACACS+ reachability. Only after the diff is clean and the operational checks pass should the switch be moved into the production Ansible inventory or allowed by the upstream ACL. Use TACACS+ for authentication and command authorization, with a local break-glass account that is disabled by default or restricted by an ACL and a strong password. Define RBAC roles such as network-operator for read-only, network-admin for build changes, and an automation role limited to the NX-API calls Ansible needs. Keep configuration backups in Git so a failed compliance check can be rolled back with configure replace.