CCNA Automation and Programmability

SDN: Control Plane vs Data Plane

Traditional routers and switches keep two jobs in one box: the control plane decides where traffic should go (running OSPF, building routing tables, handling ARP), and the data plane (forwarding plane) actually moves the packets (CEF switching in hardware). There's also a management plane — SSH, SNMP, syslog — for human administration. The exam tests the split cold: control = decisions, data = forwarding, management = administration.

SDN (Software-Defined Networking) physically separates them: the control plane moves into a centralised controller, while the network devices become simpler forwarding elements obeying the controller's instructions. The payoff is programmability — push a policy once to the controller and it configures hundreds of devices — plus a global view no single router ever had. The trade-off the exam hints at: the controller becomes critical infrastructure to protect and scale.

Learn the vocabulary as contrasts: distributed control (every device runs its own OSPF) vs centralised control (the controller computes paths); device-by-device CLI vs intent-based policy ("I want guests isolated" rather than fifty ACL lines). When a question describes a single point of management pushing config to many devices, it's describing controller-based networking.

Northbound and Southbound APIs

A controller talks in two directions, and the exam names both. Southbound APIs go from the controller down to the network devices to programme them: OpenFlow (the original SDN protocol, pushing flow tables into switches), NETCONF (XML-encoded config over SSH, port 830, modelled with YANG), and RESTCONF (the same YANG models accessed with familiar HTTP verbs). Northbound APIs go up from the controller to applications and orchestration tools — typically REST APIs returning JSON, which is how a self-service portal or a script asks the network for things.

YANG deserves one line of understanding: it's a data-modelling language describing what can be configured on a device (interfaces, routing, ACLs) — NETCONF and RESTCONF both speak YANG models, just with different transports. You won't write YANG on the exam, but you should recognise the term when a question explains a controller workflow.

The mental picture: applications → northbound REST → controller → southbound NETCONF/RESTCONF/OpenFlow → devices. A question asking "which API does the controller use to configure a switch?" wants a southbound answer (NETCONF/RESTCONF); "how does the ticketing app request a new VLAN?" wants the northbound REST API.

Cisco DNA Center and Intent-Based Networking

Cisco DNA Center is Cisco's SDN controller for campus and branch networks — the concrete product the exam attaches to controller concepts. It delivers three things: automation (provision and configure many devices from templates instead of per-device CLI), assurance (continuous monitoring, analytics and guided remediation when the network degrades), and policy (define intent once — "contractors get internet only" — and have it enforced everywhere).

That policy idea has a name: intent-based networking. You declare the business intent, the controller translates it into device configuration, activates it across the fabric, and then assures it — verifying the network actually delivers what was asked and flagging drift. The exam contrasts this with traditional networking's box-by-box CLI grind: intent is declarative ("what"), CLI is imperative ("how", device by device).

Two related architectures appear by name. SD-Access is the campus fabric DNA Center builds (with VXLAN overlays and group-based policy). SD-WAN applies the same controller thinking to wide-area links, with vManage (management GUI), vSmart (control plane), vBond (orchestration) and WAN Edge routers (data plane) — notice the planes mapped onto products. Know the names and their plane; configuration detail is beyond CCNA.

REST APIs and HTTP Methods

REST (Representational State Transfer) is the lingua franca of network automation: stateless HTTP requests, usually carrying JSON, to URLs that represent resources. The exam tests the CRUD mapping — which HTTP method does what — so memorise the table below. Stateless means every request carries its own authentication (typically a token in the header); the server remembers nothing between calls.

HTTP status codes tell you what happened: 2xx success (200 OK, 201 Created, 204 No Content), 4xx client error (400 Bad Request, 401 Unauthorized — bad/missing credentials, 403 Forbidden, 404 Not Found — wrong URL), 5xx server error (500 Internal Server Error). The exam shows API responses and asks what went wrong: 401 means fix your token, 404 means fix your URL, 500 means the problem is server-side.

Authentication for automation is usually token-based (an API key or bearer token in the Authorization header) rather than interactive login — scripts can't type passwords. Expect questions contrasting this with CLI's interactive sessions, and remember REST runs over HTTPS (TLS) in any sane deployment.

Data Formats: JSON, XML and YAML

Automation data comes in three formats and the exam shows you snippets of each. JSON is the default for REST APIs: {"hostname": "R1", "interfaces": ["G0/0", "G0/1"], "enabled": true}. Rules that get tested: keys and strings in double quotes, no trailing commas, booleans lowercase (true/false), {} for objects, [] for arrays, nesting for hierarchy. Be able to read a payload and pull out a value — "what is the hostname?" from the example is R1.

XML is the older, verbose cousin used by NETCONF: <hostname>R1</hostname> — everything wrapped in opening/closing tags. It's heavier than JSON but self-describing, and you'll recognise it rather than write it. YAML is the human-friendly one used by Ansible playbooks: indentation defines structure (no tabs — spaces only), key: value pairs with a space after the colon, - for list items, # for comments.

The exam's angle is interpretation over memorisation: given a JSON response from a controller, extract the interface status; given a YAML playbook, say what it will do; spot the syntax error (a missing quote, a tab in YAML, a trailing comma in JSON). Practice reading all three until the structure is transparent.

Automation Tools Compared

Four tools, four philosophies — the exam wants the contrasts. Ansible is agentless: it pushes YAML playbooks over SSH (no software to install on the managed devices), executes tasks in order, and is idempotent (running it twice gives the same result, not double the config). It's the network automation favourite and Cisco's go-to example.

Puppet is agent-based with a pull model: each device's agent periodically fetches its desired state (manifests) from the master and converges to it — declarative, self-healing, but needs the agent everywhere. Chef is similar in shape (agents, pull) but its recipes/cookbooks are written in Ruby and lean more procedural. Terraform is declarative infrastructure-as-code: you describe the end state in HCL, terraform plan previews changes, terraform apply makes them, and a state file tracks what exists.

The one-line differentiators to drill: agentless + SSH = Ansible; agent + pull + manifests = Puppet; Ruby cookbooks = Chef; plan/apply + state file = Terraform. A question describing "push configuration to 200 switches without installing anything on them" is Ansible; "preview infrastructure changes before applying" is Terraform.

Reading API Outputs in the Exam

This domain rewards interpretation more than recall: the exam shows you controller output, a REST call or a playbook and asks what it means. Build a repeatable reading method. For JSON: find the top-level keys, drill into the nested object named in the question, and read the exact value — don't paraphrase, quote it. For REST calls: method + URL tells the action (GET /api/v1/devices lists devices; POST /api/v1/devices creates one), the status code tells the outcome.

For YAML playbooks, read top-down: hosts: says where it runs, tasks: says what happens in order, each task's name: summarises it. A playbook with hosts: switches and a task "ensure VLAN 10 exists" does exactly that — on the switches group, idempotently. Common traps: a task targeting the wrong host group, or indentation that puts a task outside the tasks list.

Finally, tie automation back to the rest of the blueprint. Controllers use the same southbound mechanisms to push the configs you've learned as CLI: VLANs, OSPF, ACLs. A question might show a JSON payload creating a VLAN and ask which traditional concept it implements — the answer is still "a VLAN", just delivered by API. Automation changes the delivery, not the networking.

Related CCNA study guides

• CCNA Network Services: NTP, SNMP, Syslog, QoS
• CCNA Wireless Fundamentals
• CCNA Switching Fundamentals
• CCNA Routing Fundamentals

Frequently asked questions