6 Network Automation and Programmability

Network automation and programmability

Network automation uses software to configure, monitor, and verify network devices and services. Programmability lets software interact with a network through defined interfaces such as APIs. Together, they make changes more repeatable and scalable than configuring devices one at a time.

Automation requires planning, testing, access control, and verification. A faulty automated change can affect many devices at once.

Controllers and network interfaces

In a traditional device-by-device approach, an administrator configures each router or switch through its command-line interface. This can work well for small networks, but repeated changes across many devices take time and can produce inconsistent configurations.

A Controller-based network uses software to provide a centralized view and manage policies or configurations across multiple devices. In software-defined networking (SDN), the control plane—the logic that decides how traffic should be handled—is separated from the data plane, which forwards traffic. Control is logically centralized, but packet forwarding usually remains distributed across network devices.

Northbound API connections link a controller to applications, orchestration systems, or policy tools. Southbound API connections link it to network devices, allowing it to read information or apply configurations. An application might request a network policy through a controller’s northbound API; the controller then translates the request into device-specific actions through southbound interfaces.

An Underlay is the underlying physical or routed network that provides connectivity. An Overlay is a logical network built on top of that underlay. A controller can coordinate overlay policies while the underlay continues to transport traffic.

Centralized management does not mean that all devices have identical capabilities or that the controller forwards all user traffic. Devices still forward packets, and the controller’s role and protocols depend on the solution.

APIs and REST operations

An Application programming interface (API) defines how one software component can request information or actions from another. A REST API commonly uses HTTP requests to work with resources identified by URLs. Its operations often correspond to CRUD: Create, Read, Update, and Delete.

• Create: POST commonly creates a resource or submits an action.

• Read: GET commonly retrieves information.

• Update: PUT or PATCH commonly replaces a resource or modifies selected fields.

• Delete: DELETE commonly removes a resource.

Exact behavior depends on the API. A client should check both the response status and body rather than assume a request succeeded. APIs commonly require authentication and authorization. Use encrypted transport, protect credentials, and grant only the permissions needed.

For example, a network-management application could use GET to retrieve an interface’s status and then send an update request to change a setting. A safe workflow is to inspect the target and request, test changes in a limited environment, apply the change, and verify the resulting device state.

NETCONF, RESTCONF, and YANG

NETCONF and RESTCONF are network-management protocols that can use YANG data models. NETCONF commonly exchanges XML and uses an RPC-style protocol. RESTCONF provides access to YANG-defined data using HTTP methods and can use XML or JSON.

YANG describes the structure and meaning of configuration and operational data. It is a data-modeling language, not a transport protocol.

Automation and configuration management

Automation can collect device information, generate configurations, deploy changes, check compliance, and report results. Effective automation relies on repeatability, Idempotence, drift detection, and validation.

• Repeatability: The same inputs and procedure should produce predictable results.

• Idempotence: Applying the same desired-state operation more than once leaves the system in the same intended state. For example, “ensure VLAN 20 exists” is safer to repeat than “create VLAN 20” if the second command fails when the VLAN already exists.

• Configuration drift: Differences between the intended configuration and the actual device state. Periodic checks can detect drift, and corrective automation can restore the intended state.

• Validation: Verify both that the change was applied and that the network still behaves as expected.

Configuration-management tools express and apply desired configurations or repeatable tasks. Ansible commonly uses agentless connections and YAML playbooks to describe tasks for managed devices. Puppet uses manifests and resources to describe desired state; its system compares actual and desired state and corrects differences. Chef uses cookbooks and recipes to define infrastructure configuration and actions.

Tool capabilities and device support vary. These tools can automate repeatable tasks and help maintain consistency, but they do not remove the need to understand device behavior and validate changes.

An Ansible-style example

This simplified Ansible-style playbook describes the intent to ensure that a management VLAN is present:

The specific collection, connection method, device platform, and supported parameters must match the environment.

Common data formats

Automation exchanges structured data between programs. JSON, YAML, XML, and CSV have different syntax and uses.

JSON

JSON uses objects ({}), arrays ([]), key–value pairs, quoted strings, numbers, booleans, and null. Object keys and string values use double quotes, and JSON does not allow comments.

YAML

YAML is a human-readable format frequently used for configuration files and automation playbooks. Indentation expresses structure, so spaces must be consistent; tabs are generally not used for indentation.

XML and CSV

XML represents data with nested opening and closing tags and is common in network-management protocols such as NETCONF. CSV stores tabular data as rows and fields, making it convenient for simple inventories, but it does not naturally represent deeply nested structures.

When interpreting data, distinguish a format’s syntax from its meaning. JSON and YAML can both represent the same interface settings; the API or data model defines what fields mean and whether they are valid.