DNA Center Template Rollout Across Three Switch Families
A university is onboarding 1,200 Catalyst 9200, 9300, and 9500 access switches into DNA Center 2.3.7. A regular Day-N template named access-base uses variables hostname, mgmt_vlan, and uplink_ports. The first rollout to 120 switches succeeds on 82, fails on 38 with Invalid value: mgmt_vlan and Unable to find interface, and shows 20 switches compliant but with the wrong NTP server. Investigation shows some sites pass mgmt_vlan: 100 as a string, some pass 100 as an integer, and one site's CSV has uplink_ports as Gi1/0/1,Gi1/0/2 while the template expects a list. The 9500 switches run a different software version and reject two commands. The change window is in two days. The team wants to use the template compliance tool to prove drift is fixed.
1. Diagnose the template deployment failures and explain why 20 switches show compliant with the wrong NTP server.
Read the worked answer
The failures are type and naming mismatches, not device faults. mgmt_vlan is consumed by CLI as an integer; a string value can render with quotes or fail validation depending on the template engine and device parser. uplink_ports is declared as a list variable, but the CSV supplies one comma-delimited string, so the template's loop iterates characters or fails interface lookup. Unable to find interface also appears when the inventory uses short names such as Gi1/0/1 while the platform expects GigabitEthernet1/0/1, or when a stack member number differs from the template's assumption.
The 9500 failures are platform/version variance. Two commands accepted on 9200/9300 are rejected on the 9500 software version. A single template body cannot safely assume command parity across families.
Wrong NTP but compliant is the dangerous case. Compliance compares rendered intent to running config using the template bound to the device. If the template supplies a default NTP server when the site variable is missing, the rendered intent contains that default, so the device matches the template and reports compliant. Compliance proves conformance to the template, not correctness of the site data. The missing variable is invisible unless the template marks it required or the input is validated before deployment.
2. Redesign the template and variable handling for three switch families and mixed data types. Address required variables, types, interface naming, and versioning.
Read the worked answer
Split by capability, not by site. Use a common template for shared intent and family-specific templates or conditional blocks for commands that differ. In DNA Center, composite templates can sequence common and family-specific regular templates; that is cleaner than a single template full of conditionals. Bind the correct template version to each device family and software version.
Define variables with explicit types and requirements. Mark mgmt_vlan as an integer and validate the CSV before rendering. Accept uplink_ports as a list or split a delimited string with a filter, then normalize names to the platform's expected interface format. Provide a mapping variable for stack member and interface prefix rather than hard-coding Gi1/0/1. Do not use a default NTP value silently; make the variable required or fail closed when it is absent.
Version templates. Clone access-base to a new version for the change window; do not edit the in-use template in place. Attach the version to the site and device family. Preview rendering for one device of each family and software version, including a device with missing variables, before deployment. Validate against the intended CLI or YANG model, not just a successful render.
3. How should the team use compliance and rollback within the two-day window without declaring success prematurely?
Read the worked answer
First, fix the binding before trusting compliance. A device is compliant against the template version currently attached to it. If the wrong version or a defaulted variable is attached, compliant is meaningless. Rebind the corrected template version to the canary devices, deploy, then run compliance. Compare the compliance report's rendered intent to the site's source-of-truth NTP and VLAN data, not only to the template.
Use a canary sequence: two devices per family, one with string inputs and one with a delimited uplink list, then a site with mixed stack members. Verify management reachability, NTP association, uplink trunk state, and the exact two commands rejected on the 9500. Only then expand in batches with a pause.
Rollback plan: archive the pre-change running config, keep console or out-of-band access, and know whether the deployment can revert automatically on failure. If not, have a tested configure replace or manual rollback per family. Within two days, do not attempt all 1,200; land the template and canaries, then schedule the remainder. Declare drift fixed only when compliance matches both the template and the validated site data.