Data Center Automation and Orchestration
This domain tests Day-0 through Day-2 automation: ZTP, configuration management, on-box and off-box APIs, Apstra intent-based operations, and safe change practices.
Junos automation toolbox
- ZTP: DHCP options point the device at an image and configuration server; the device auto-installs and applies config on first boot.
- On-box: commit scripts, event scripts, and op scripts in Python, SLAX, or XSLT;
commit confirmed <minutes>;rollback n; rescue configuration;show system rollback compare. - Off-box: Junos PyEZ (
jnpr.junos.Device,Config,cu.load,cu.commit_check), NETCONF/YANG, the REST API, Ansiblejuniper.device, and Terraform providers. - Telemetry: gNMI with OpenConfig models and Junos Telemetry Interface push structured data instead of polling SNMP.
Apstra
- Intent-based workflow: reference design, then blueprint, then device assignment or discovery, then commit. Configuration is generated from intent, not typed per device.
- Probes and intent-based analytics detect anomalies; the graph datastore models the intended and actual fabric state.
Worked example
Rolling a VLAN change to 40 leaves with PyEZ: open a Device connection, load the set commands with merge=True, run cu.commit_check() to validate, then cu.commit(confirm=5) on a canary leaf. Validate the VLAN, EVPN database, and host reachability. Only then run the same sequence across the remaining leaves in batches, and commit fully on each device after validation rather than letting confirm timers expire.
Traps
- Pushing to every device at once instead of canary plus commit confirmed, so one syntax error becomes a fabric outage.
- Assuming ZTP works without a reachable DHCP server and image server, or with the wrong option values.
- Editing an Apstra-managed device directly; drift is detected and intent is reapplied, silently undoing your change.
- Ignoring
commit_checkoutput and committing a config that fails after the timer.