Core: Automation
In one line Automation's real value isn't speed - it's consistency at scale and the elimination of drift, which is an operating-model change, not a tool. Why automate * Consistency - the same intent rendered identically everywhere (no snowflakes). * Scale & speed - change hundreds of devices
Core: Automation
Requirement / business driver Bring devices online at scale without a technician on the CLI - Day-0 onboarding that's fast, consistent, and secure. How ZTP works A factory-default device boots, gets an address (DHCP), and is pointed at a config/image source - then pulls and applies its Day-
Core: Automation
Requirement / business driver Manage network configuration the way software is managed - versioned, reviewed, tested, and reproducible - so changes are safe and the network never drifts from intent. The principles * Source of truth in Git - the repo defines desired state; devices are reconciled to it (not the other way round). * Declarative
Core: Automation
Requirement / business driver Pick the right tool for the job - the blueprint's emphasis is when to use each, not how to code them. Options * Ansible - agentless config management; idempotent modules push config/state to existing devices. * Terraform - declarative provisioning with a state file; stands up infrastructure/cloud resources
Core: Automation
Requirement / business driver Deliver network changes through a pipeline - validated, tested, staged, and reversible - instead of ad-hoc CLI pushes. Pipeline stages On a commit to the source of truth (Infrastructure as Code - declarative, idempotent, source of truth), a CI/CD platform (Jenkins, GitLab CI, GitHub Actions) runs: 1. Lint
Core: Automation
Requirement / business driver Move from open-loop "push config" to closed-loop: the network observes itself and acts - the bridge from automation to assurance. The loop Streaming telemetry (Network management - traditional vs model-driven) feeds analytics that detect a condition, decide a response, and act (push a change)