Chapter 6 · CCNA 200-301 Study Guide · Based on the CCNA 200-301 v2.0 exam blueprint (effective February 2027)

Chapter 6: Automation and Programmability

6.1 Why Automation Matters

For decades, network engineers configured devices one at a time: SSH into a switch, paste commands, verify, repeat on the next box. That "box-by-box" CLI approach works for ten devices and collapses at ten thousand. A single typo pasted into 200 switches can cause an outage that takes hours to trace. Automation replaces that repetitive work with software — controllers, templates, and scripts — that configures devices quickly, identically, and verifiably. It is an official CCNA domain because the industry has moved there: engineers are now expected to understand controllers, APIs, and data formats, not just the command line.

6.2 Traditional Networking vs Controller-Based Networking

6.2.1 The Three Planes of Operation

Every network device does three kinds of work, grouped into "planes":

A helpful memory trick: the control plane thinks, the data plane does, and the management plane watches and configures.

6.2.2 What Changes with a Controller

In traditional networking, each device runs its own control plane: every router runs OSPF independently and computes its own routing table. Intelligence is distributed — resilient, but every device must be configured individually.

In controller-based networking, the control plane moves into a centralized software controller. Devices keep their data planes (still forwarding in hardware at full speed) but take direction from the controller: configure once, apply everywhere.

6.3 SDN Architecture

Software-Defined Networking (SDN) is the architecture behind controller-based networking: the control plane is separated from the data plane and centralized. It has three layers:

• Application layer — business apps and network services (e.g., a security app that quarantines infected hosts).
• Controller layer — the SDN controller, the "brain" with a complete view of the network.
• Infrastructure layer — switches and routers that forward traffic as directed.

The layers talk through APIs (Application Programming Interfaces): southbound APIs run between controller and devices (how the controller programs forwarding — e.g., OpenFlow, NETCONF), and northbound APIs run between the controller and applications above it (typically REST APIs, covered in Section 6.5).

Two more terms appear constantly in SDN discussions: the underlay is the physical network (routers, switches, cables), while overlays are virtual networks built on top of it (commonly VXLAN tunnels), letting multiple isolated logical networks share one physical fabric.

6.4 Cisco DNA Center

Cisco DNA Center is Cisco's enterprise SDN controller for campus and branch networks. (Cisco has rebranded it as Catalyst Center — either name refers to the same product.) Instead of configuring hundreds of devices by hand, you define intent in DNA Center and it handles the details. Its three headline capabilities:

1. Automation / provisioning — plug-and-play onboarding (a fresh switch pulls its config automatically), configuration templates pushed to many devices at once, and fleet-wide software image management (SWIM).
2. Assurance — continuous monitoring with analytics that detect issues (often before users notice), device and client health scores, and guided remediation.
3. Policy — access policies defined once and enforced consistently across wired and wireless.

6.5 REST APIs

Applications — including DNA Center's northbound interface — expose functions through REST APIs. REST (Representational State Transfer) is a design style for APIs built on the same HTTP machinery as the web. If you understand how a browser fetches a page, you understand most of REST.

6.5.1 HTTP Methods

A REST API client tells the server what to do with an HTTP method:

6.5.2 URIs and Responses

Resources are addressed with URIs — structured paths like /dna/intent/api/v1/network-device (API version, then the resource collection). Appending an identifier addresses one specific device.

The server answers with an HTTP status code plus data, usually JSON. Know these cold: 200 (OK), 201 (Created — POST worked), 400 (Bad Request), 401 (Unauthorized — authentication failed), 404 (Not Found).

6.5.3 Authentication Basics

APIs do not accept anonymous commands that reconfigure networks. Common approaches: basic authentication (username/password, only over HTTPS), token-based authentication (log in once, present the token on later requests), and API keys (long-lived secrets identifying the calling application).

6.6 Data Formats: JSON, XML, and YAML

APIs need a standard way to encode data. Three formats appear on the CCNA:

6.6.1 Reading JSON

JSON (JavaScript Object Notation) is built from two structures you must recognize instantly:

• Objects — unordered collections of key-value pairs, wrapped in curly braces {}. Keys are always strings in double quotes.
• Arrays — ordered lists of values, wrapped in square brackets []. Array positions start at 0.

Values can be strings ("up"), numbers (1500), booleans (true/false), null, nested objects, or arrays.

{
  "hostname": "Dist-SW-01",
  "mgmt_ip": "10.10.10.5",
  "interfaces_up": 24,
  "is_reachable": true,
  "vlans": [10, 20, 30],
  "location": {
    "building": "HQ",
    "floor": 2
  }
}

Reading it: hostname is the string "Dist-SW-01"; interfaces_up is the number 24 (no quotes = number); is_reachable is the boolean true; vlans is an array of three numbers where vlans[0] is 10 (counting starts at zero); and location is a nested object with its own pairs (building "HQ", floor 2).

6.6.2 Data Models and YANG

Controllers and devices agree on the shape of configuration data using data models. The modeling language used with NETCONF and RESTCONF is YANG. You do not need to write YANG for the CCNA — just know that YANG defines data models, NETCONF transports them as XML, and RESTCONF transports them over REST (usually as JSON).

6.7 Configuration Management Tools

Beyond controllers, dedicated configuration management tools automate device configuration from a central server. The CCNA expects you to compare the big three:

Two distinctions do all the work on exam questions:

• Agent vs agentless: Ansible needs nothing installed on the managed device (it just uses SSH, which network gear already has). Puppet and Chef require their agent software on every managed node.
• Push vs pull: In the push model (Ansible), the central server initiates and sends configuration outward. In the pull model (Puppet, Chef), each device's agent periodically contacts the server and fetches its own configuration.

6.8 Worked Example: Interpreting JSON from a Controller

Putting it together: here is a realistic (simplified) response from a DNA Center-style API asking for the campus device inventory — GET /dna/intent/api/v1/network-device:

{
  "response": [
    {
      "hostname": "Core-SW-01",
      "managementIpAddress": "10.1.0.2",
      "reachabilityStatus": "Reachable",
      "softwareVersion": "17.9.4",
      "role": "CORE",
      "serialNumber": "FOC2210A1B2"
    },
    {
      "hostname": "Access-SW-01",
      "managementIpAddress": "10.1.1.11",
      "reachabilityStatus": "Reachable",
      "softwareVersion": "17.9.4",
      "role": "ACCESS",
      "serialNumber": "FOC2210C3D4"
    },
    {
      "hostname": "Access-SW-02",
      "managementIpAddress": "10.1.1.12",
      "reachabilityStatus": "Unreachable",
      "softwareVersion": "17.6.5",
      "role": "ACCESS",
      "serialNumber": "FOC2210E5F6"
    }
  ],
  "version": "1.0"
}

How to read it like the exam wants:

1. The top-level object has two keys: response (an array of device objects) and version.
2. response holds 3 objects — a 3-device inventory. response[0] is Core-SW-01, response[1] is Access-SW-01, response[2] is Access-SW-02.
3. Reachability: two devices are "Reachable"; Access-SW-02 (response[2]) is "Unreachable" — it needs attention (powered off, disconnected, or a credentials problem).
4. Software versions: two devices run 17.9.4; Access-SW-02 runs the older 17.6.5 — a software-compliance issue DNA Center's SWIM could fix once the device is reachable.
5. Extracting a value: the management IP of Access-SW-01 is response[1].managementIpAddress = "10.1.1.11" — second object in the array, managementIpAddress key.

End-of-Chapter Test