Rolling Out a Configlet to a Mixed-Firmware Leaf Pair
You manage a two-leaf MLAG pair, leaf1 and leaf2, running EOS 4.29.2F and 4.31.1F respectively. Both are in the same CloudVision container and the same configlet builder scope. You need to push a new management-interface ACL and an updated NTP server list to both. The configlet uses a {{ mgmt_acl_name }} variable that resolves from a device tag. During a maintenance window you attach the configlet to the container. After the change-control task completes, leaf1 shows the new ACL and NTP servers, but leaf2 still shows the old NTP servers and no new ACL. CloudVision reports the task as completed with no errors. You verify the configlet is assigned to the container and the tag exists on both devices.
1. What is the most likely reason leaf2 did not receive the change, and how would you confirm it before re-running?
Read the worked answer
The most likely cause is that leaf2 is not in compliance with the configlet's reconciliation mode or is excluded by a device-level configlet exclusion, or more commonly that the configlet change was applied only to devices whose running config differed in a way that triggered a merge conflict. But the cleanest first check is the configlet's per-device status in the Change Control / Configlet status view: CloudVision tracks each device's last applied configlet hash.
Confirm by:
- Open the configlet in the Configlet tool and check the per-device status column - leaf2 likely shows
Not appliedorOut of syncrather thanApplied. - Check whether leaf2 has a configlet exclusion or is in a different container than you assumed (container membership is inherited; a device can be moved).
- Check the device tag resolution: if
mgmt_acl_nameis undefined on leaf2, the variable may render empty and CloudVision may skip or fail silently depending on the builder's strictness.
A completed change-control task does not guarantee every device applied - it guarantees the task ran. Always verify per-device status, not just task status.
2. You discover leaf2 is excluded from the configlet. What is the correct remediation, and what should you check about firmware before re-applying?
Read the worked answer
Remediation: remove the exclusion (or add leaf2 to the correct container/scope) and run a new change control rather than editing the completed one - completed change controls are immutable audit records.
Before re-applying, check firmware compatibility: leaf2 runs 4.31.1F while leaf1 runs 4.29.2F. The configlet's CLI syntax (e.g., ACL syntax, NTP ntp server vs ntp server vrf) may differ across these trains. Verify the configlet is syntactically valid on both trains - ideally by testing on a lab device of each version, or by using a configlet builder with version-conditional logic. Also check whether the container has a firmware compliance requirement that would block the change on a non-compliant device. If the configlet is version-sensitive, split it into per-version configlets or use a builder that branches on EOS version.