Lesson 1 — Network Automation Overview
Network Automation Overview
Explain in operational terms why a team moves from device-by-device CLI to controller-based automation, and state precisely what a controller centralises and what still happens on each device.
Lesson orientation
What you'll learn (4 objectives)~25 min: video → lesson → check → apply → lab prep
Learning objectives
- Explain how network automation changes daily operations compared with per-device CLI
- Contrast controller-based management with the traditional distributed control model
- Identify realistic automation use cases and the risks that scale along with them
- Locate the management, control, and data planes and say where a controller sits
Terms you will see
Time breakdown
- Read the notes14 min
- Compare the two workflows6 min
- Predict the controller-failure case5 min
Assigned video
Intro to Network Automation (Day 59 part 1)
By Jeremy's IT Lab · Opens externally on YouTube
- Assigned watch
- ~6 min
Where to stop
If config drift is already clear, skip the motivation and concentrate on the controller-based management portion.
The source marks this segment timestampStatus="unresolved" with no start or end, so no bounds are shown here.
The link opens in a new browser tab. Return here when you finish watching.
Watch for these concepts
- The contrast between SSHing to each device and a controller pushing intended state
- Why configuration drift is the underlying problem
Go beyond the video
The assigned video introduces the idea. CCNA Practice Labs completes the learning path: clarify core concepts, explore how each device behaves, visualize the communication path, check your understanding, and prepare for hands-on lab work.
Watch the concept → understand it → visualize it → practice it → apply it.
The problem is drift, and the fix is an authoritative intended state
A change control asks you to add one VLAN to 40 access switches by tomorrow morning. Done at the CLI, that is forty SSH sessions and forty chances to fumble a name or an ID — and afterwards no record at all of what "correct" was supposed to look like. That gap is exactly what automation closes.
Traditional operations keep the network's real configuration only on the devices themselves. Over months, hands-on edits accumulate and the devices quietly diverge from each other and from any diagram — configuration drift. Automation flips the source of truth: the intended configuration lives in a file under version control, and a script, template, or controller pushes that intent onto every device. Because the intent is text you can review, diff, and roll back, a change becomes repeatable and auditable rather than a one-off keystroke sequence.
| Aspect | Traditional CLI | Controller-based automation |
|---|---|---|
| Source of truth | Whatever is on each device | A reviewed file in version control |
| How the change is applied | Manual SSH, one device at a time | The controller pushes to all devices via APIs |
| Chance of a typo | Once per device | Once, in the reviewed template |
| Record of intent | None after the session | Commit history you can diff and roll back |
| Who forwards packets | The devices | Still the devices — the controller does not |
Three planes, so you can say where a controller lives
| Plane | Job | Examples |
|---|---|---|
| Data (forwarding) | Moves frames and packets as fast as possible | MAC-table lookups, IP routing, ACL application |
| Control | Builds the tables the data plane uses | OSPF, STP, ARP |
| Management | How humans and tools configure and monitor the device | SSH, HTTPS, SNMP, APIs |
Automation and controllers operate in the management and control planes. Nothing about automation changes the fact that the data plane still forwards traffic on each box — which is the same point as the callout above, arrived at from the architecture rather than from the workflow.
What teams actually automate is unglamorous and high-volume: provisioning new devices, enforcing software-version and compliance standards, collecting statistics and reports, and speeding troubleshooting across many devices at once. The payoff is speed and consistency at scale.
What you should retain
- Automation is programmatic, repeatable, version-controlled change replacing per-device CLI.
- Configuration drift is the core problem; the fix is an authoritative intended state held outside the devices.
- A controller centralises control and policy. The devices still forward traffic locally.
- Three planes: data forwards, control builds the tables, management configures and monitors. Automation lives in management and control.
- Risk scales with reach — test in a lab, then verify with show commands.
Before you read on
You must add one VLAN to 40 access switches by tomorrow. (1) How many chances to make a typo does the CLI approach give you, and what is left behind afterwards to prove the change was correct? (2) If you push the same change through a controller instead, what is centralised and what is not?
See it happen
Automation Sandbox
Step through the traditional-versus-controller framing before the quick check — seeing the same change applied both ways makes the "forwarding stays distributed" point concrete rather than abstract.
Section quiz follows Lesson 2, once the API mechanics have joined the automation vocabulary.
Study deeper
Topic guides extend this lesson — they do not replace the first-party walkthrough above.
Automation & APIs
For the fuller traditional-versus-controller comparison and the automation use-case list