Apstra Blueprint Deploy Fails After Leaf RMA
Apstra manages 60 QFX5120 switches across three blueprints. A leaf in the production blueprint was RMA'd. The replacement switch was discovered in Device Manager, assigned to the blueprint, and deployed. Apstra now shows the device as out of sync; the Deploy button reports a configlet rendering error for a missing property named leaf_asn. The device is passing production traffic, but two server VLANs are absent and one uplink is in the wrong LAG. The operations team is under a change freeze that forbids CLI changes; all changes must go through Apstra. You have a 30-minute window and cannot drain the whole rack. The blueprint uses property sets, interface maps, and a rack type with a fixed ASN pool.
1. Why does Apstra show a deploy failure, and what is the risk of clicking Deploy again without investigating?
Read the worked answer
Apstra renders intended configuration from the blueprint; a configlet error means the blueprint's property set cannot supply a value the template requires, not that the switch is broken. The missing leaf_asn property usually means the replacement device was assigned to a rack type or device profile whose ASN property was not populated, or the property set was not attached after the RMA. Clicking Deploy again without fixing the property will either fail the same way or push a partial configuration that omits the two VLANs and misplaces the uplink LAG. The safe first step is to open the blueprint's Diff/Uncommitted view and compare intended vs. actual, then inspect the device's assigned profile, rack type, and property set.
2. What reconciliation sequence would you follow, and why is a blind full deploy unsafe?
Read the worked answer
Put the leaf in Drain only if you can tolerate losing its traffic; otherwise use the blueprint's per-device deploy. In Device Manager, confirm the replacement serial is the managed device, then update its device profile and interface map so port roles match the rack type. Populate leaf_asn in the property set or attach the correct ASN pool; do not hard-code it in a configlet. Run a dry-run/diff, deploy only the changed device, and verify the two missing VLANs and the LAG membership from Apstra's operational view. A full deploy is unsafe because it can push unchanged or partially rendered intent to other devices and widen the outage beyond the replaced leaf.
3. What blueprint and workflow changes would prevent this on the next RMA?
Read the worked answer
Make the RMA path a tested workflow: store ASN and management IP in property sets tied to the rack type; validate the blueprint with a dry-run before deploying; keep a known-good blueprint version; and use Apstra's ZTP/device discovery so the replacement gets the right profile before it is assigned. Add a post-deploy check that compares VLAN and LAG intent for the replaced leaf, and require the Diff to be empty before closing the change. Keep the per-device deploy option available so a single leaf can be corrected without touching the rack.