Automation and programmability: when the CLI stops being the interface

Everything in the previous fifteen articles assumed a person at a prompt. That assumption held for thirty years and stopped holding somewhere around the point where a network had more devices than an engineer could visit in a week. The change is not that the CLI disappears — it is that the CLI stops being the interface and becomes an implementation detail, while intent is expressed somewhere it can be reviewed, versioned and applied identically to three hundred devices at once.

The map

Read this first when short on time. Every branch is a section below.

What the CLI cannot do

The command line is excellent at what it was built for: one engineer, one device, full control, immediate feedback. Its limits show up as soon as either number grows.

It does not scale with device count. Adding a VLAN across three hundred switches is the same six commands typed three hundred times. Two minutes each is ten hours, spread over a maintenance window nobody wants to staff.

It produces drift. Three hundred devices configured by hand over five years by a dozen people are three hundred slightly different devices. Nobody knows what is actually deployed, so nobody can predict the effect of a change — and the first accurate inventory usually arrives during an incident.

It has no review step. A command typed into a production device takes effect immediately. There is no diff, no second pair of eyes, no test. This matters because change is the leading cause of outages: not hardware failure, not attacks, but somebody applying something that behaved differently in production than they expected.

Its output is not data. Scripting the CLI means screen-scraping show output written for humans. Column widths shift, fields appear in new software versions, and a script that has worked for two years breaks silently after an upgrade. Parsing formatted text is guessing with extra steps.

Control plane, data plane, and what a controller does

Every network device does two separable jobs.

Traditionally both planes live in every device, and each device decides for itself. That is robust — there is no single point of failure — and it means the network's behaviour is an emergent result of three hundred independent decisions, which is hard to reason about and harder to change deliberately.

Controller-based networking moves the control plane out. A central controller holds the whole picture, computes what each device should do, and programs it. Devices become forwarders that do what they are told.

flowchart TD
  APP["Applications and scripts"] -->|"northbound API<br/>REST, JSON"| C["Controller<br/>holds the whole topology<br/>and the intended state"]
  C -->|"southbound API<br/>NETCONF, OpenFlow"| D1["Switch"]
  C -->|"southbound"| D2["Switch"]
  C -->|"southbound"| D3["Router"]

The two words worth keeping straight:

• Southbound — controller to device. NETCONF, RESTCONF, OpenFlow, or a vendor protocol. This is where the actual configuration happens.
• Northbound — application to controller. Almost always a REST API. This is where a script, a portal, or another system says what it wants without knowing anything about the devices.

The northbound API is the real prize. A request to add a guest network becomes one API call, and the controller works out which of two hundred devices need changing and what to send them. The alternative — a script that knows about every device individually — puts the complexity back where it started.

The trade is honest and worth stating: a controller is a single point of policy, and sometimes a single point of failure. Most designs mitigate it by letting devices keep forwarding on their last known state when the controller is unreachable — the network keeps running, it just stops accepting changes.

REST: HTTP used as an interface

A REST API treats things as resources named by URLs, and uses HTTP verbs to act on them. If you can read a URL, you can mostly read a REST API.

REST is stateless: every request carries its own authentication and everything else it needs, and the server keeps nothing between calls. That is what lets a load balancer send consecutive requests to different servers, and it is why an API token appears in every single request rather than in a login step.

curl -X GET https://controller.example.com/api/v1/network/vlans \
     -H "Authorization: Bearer eyJhbGciOi..." \
     -H "Accept: application/json"

The response codes are worth knowing because they tell you which side of the problem to look at:

The 401 versus 403 distinction saves real time: 401 means the credential was not accepted, 403 means it was accepted and does not have permission. They send you to completely different places.

Three ways to write the same data

Automation moves structured data around, and three encodings dominate. They are equivalent — the same structure written differently — and each is preferred in a different place.

{
  "vlan": {
    "id": 20,
    "name": "GUEST",
    "ports": ["Gi1/0/16", "Gi1/0/17"],
    "enabled": true
  }
}

<vlan>
  <id>20</id>
  <name>GUEST</name>
  <ports>
    <port>Gi1/0/16</port>
    <port>Gi1/0/17</port>
  </ports>
  <enabled>true</enabled>
</vlan>

vlan:
  id: 20
  name: GUEST
  ports:
    - Gi1/0/16
    - Gi1/0/17
  enabled: true

YAML's use of indentation for structure makes it pleasant to write and unforgiving to get wrong — a tab character where spaces belong produces an error a long way from the actual mistake. That is the price of the readability, and it is why YAML is used for files people author and JSON for data machines exchange.

NETCONF, RESTCONF and YANG

Screen-scraping fails because show output has no schema. Model-driven interfaces fix this properly.

YANG is a modelling language. A YANG model defines exactly what configuration and state data exists for something — what fields an interface has, their types, which are mandatory, what values are legal. It is a contract, published by the vendor or by a standards body such as OpenConfig, and both sides can validate against it.

NETCONF is the protocol that carries YANG-modelled data as XML over SSH, on port 830. Its important property is that it is transactional:

1. The client locks the configuration so nobody else changes it concurrently.
2. It writes to a candidate configuration, which is not yet live.
3. It validates the candidate against the model.
4. It commits — and all the changes take effect together, or none of them do.
5. If something is wrong, it rolls back to the previous state.

Compare that with the CLI, where every line takes effect the instant it is typed. A half-applied ACL is a real state a device can be in, and it is often a broken one. NETCONF makes a change atomic, which is the single biggest reliability difference between the two approaches.

RESTCONF exposes the same YANG models over ordinary HTTPS with JSON, which is easier to use from a script and gives up NETCONF's locking and transactions. The choice is the usual one: RESTCONF for convenience, NETCONF where a change must be all-or-nothing.

Router(config)# netconf-yang
Router(config)# restconf
Router(config)# ip http secure-server
Router(config)# username automation privilege 15 secret AutomationPass

The tools people actually use

Ansible

The most common choice for network devices, because it is agentless: it connects over SSH or an API and needs nothing installed on the device. Tasks are written in YAML, which is readable by people who are not programmers.

- name: Ensure guest VLAN exists on all access switches
  hosts: access_switches
  gather_facts: false
  tasks:
    - name: Create VLAN 20
      cisco.ios.ios_vlans:
        config:
          - vlan_id: 20
            name: GUEST
            state: active
        state: merged

    - name: Save configuration
      cisco.ios.ios_config:
        save_when: modified

The property that makes this safe is idempotence: running the playbook twice produces the same result as running it once. Ansible checks the current state, and if VLAN 20 already exists with that name it reports "ok" and changes nothing. That is what allows the same playbook to be run against the whole estate regularly, as a way of correcting drift rather than as a one-off change.

Terraform

Declarative and state-aware. You describe the desired end state, Terraform compares it with a recorded state file, and produces a plan — an explicit list of what it will create, change and destroy — before touching anything. The plan is reviewable, which is a meaningful safety property.

It dominates cloud networking, where every resource has a clean API. On traditional network devices it is used less, largely because the device state is harder to model reliably.

Declarative against imperative

The CLI is imperative by nature, which is exactly why it produces drift: it describes a change, not a state, so nothing ever compares the device against what it was supposed to be.

What changes for the person who used to type

The networking knowledge does not change. Everything in the previous fifteen articles is still what you need to know — a controller that builds a broken spanning tree is still a broken spanning tree, and an API that applies the wrong ACL still locks you out. What changes is how the knowledge is delivered.

• The configuration lives in Git. Every change is a commit with an author, a timestamp and a message. The current state is knowable, and so is every state it has been in.
• Changes are reviewed before they are applied. A pull request means somebody else reads the diff, which catches the class of error no amount of care catches in yourself.
• Changes are tested first. Virtual devices — Cisco CML, containerlab, and vendor images — let a pipeline build the topology, apply the change and run tests before anything reaches production.
• The source of truth moves. The devices stop being the authority on their own configuration. The repository is, and a device that differs from it is drift to be corrected rather than a fact to be documented.

None of that removes the need to understand what a native VLAN mismatch does, or why an ACL is placed where it is. It makes those decisions reviewable, repeatable and reversible — which is a better place to be doing them from.

Control plane

The part of a device that decides how traffic should be forwarded, as distinct from the data plane that forwards it.

Northbound API

The interface a controller offers to applications and scripts, almost always REST.

Southbound API

The interface a controller uses to program devices — NETCONF, RESTCONF or OpenFlow.

YANG

A modelling language defining exactly what configuration and state data a device exposes, so both sides can validate against a schema.

Idempotent

An operation that produces the same result whether run once or many times — the property that makes automation safe to repeat.

Recap