RESTCONF and NETCONF Configuration

Introduction

Network engineers have traditionally configured devices one at a time using the command-line interface. While the CLI is powerful and intuitive for humans, it was never designed for machines. As networks grow in scale and complexity, the need for model-driven programmability becomes essential. Instead of screen-scraping CLI output or pushing raw text commands through scripts, modern approaches use structured data models and standardized protocols to configure and monitor network devices.

This lesson focuses on two critical protocols in the model-driven programmability stack: RESTCONF and NETCONF. Both protocols use YANG data models to define what can be configured on a device, but they differ in transport, encoding, and how you interact with them. By the end of this lesson, you will understand how RESTCONF and NETCONF work, how to enable them on IOS XE, how to build configuration payloads using YANG models, and how to automate device configuration using Python.

Key Concepts

The Shift from CLI to Model-Driven Programmability

The fundamental mindset change in network automation is moving from human-friendly CLI to machine-friendly models. Traditional CLI commands like conf t, interface GigabitEthernet1, and ipv6 enable are easy for engineers to type and read, but they are difficult for software to parse reliably. Model-driven programmability replaces this approach with structured YANG data models that describe every configurable feature on a device — interfaces, BGP, IPv6, ACLs, and more.

YANG Data Models

YANG is a data modeling language that defines the structure of configuration and operational data on a network device. Think of a YANG model as a schema or blueprint that tells you exactly what parameters are available, what data types they accept, and how they are organized hierarchically. Device features such as interfaces, BGP, IPv6, and ACLs each have corresponding YANG models.

There are two categories of YANG models used on IOS XE:

• Native models — These are platform-specific models defined by the device vendor (for example, Cisco-IOS-XE-native). They closely mirror the CLI structure you are already familiar with.
• Open models — These are vendor-neutral models defined by standards bodies such as IETF and OpenConfig, designed for multi-vendor environments.

Comparing RESTCONF and NETCONF

Both RESTCONF and NETCONF are programmatic interfaces that use YANG data models to interact with network devices. The following table highlights their key differences:

Attribute	NETCONF	RESTCONF
Standard	RFC 6241	RFC 8040
Transport	RPC over SSH	HTTPS
Encoding	XML	XML or JSON
IOS XE Command to Enable	netconf-yang	ip http secure-server and restconf
Python Library	ncclient	requests
Data Support	Configuration data, state data, actions and events	Configuration data, state data, actions and events

Both protocols support reading configuration data, retrieving operational state data, and performing actions and events on the device.

RESTCONF HTTP Methods

When working with RESTCONF, you interact with the device using standard HTTP methods. Each method maps to a specific type of operation, much like CLI commands map to configuration or show actions:

HTTP Method	Purpose
GET	Retrieve configuration or operational data
POST	Create a new resource
PUT	Create or replace a resource entirely
PATCH	Merge configuration into an existing resource
DELETE	Remove a resource
HEAD	Check if a resource exists (no body returned)

Important: The distinction between PUT and PATCH matters. PUT replaces the entire target resource, while PATCH merges the provided data with what already exists. In most automation workflows, PATCH is the safer choice because it modifies only the fields you specify without removing existing configuration.

How It Works

The Four-Step Workflow

Configuring a device through model-driven programmability follows a clear four-step process:

Step 1 — Select your protocol. Decide whether to use NETCONF or RESTCONF based on your requirements. RESTCONF is often the easier starting point because it uses familiar HTTPS and supports JSON encoding, making it accessible from tools like Python's requests library or even a web browser. NETCONF uses SSH and XML, which is more verbose but provides additional capabilities like transaction-based configuration.

Step 2 — Define your configuration in YANG. Before sending anything to the device, you need to understand the YANG model for the feature you want to configure. The YANG model shows you the hierarchy and data types. For example, to enable IPv6 unicast routing and configure an OSPF process, the relevant portion of the Cisco-IOS-XE-native YANG model looks like this:

module: Cisco-IOS-XE-native
  +--rw native
     +--rw ipv6
        +--rw unicast-routing?    Empty
        +--rw router
           +--rw ospf* [id]
              +--rw id    uint16

This tree structure tells you that under native > ipv6, there is a unicast-routing leaf of type Empty (meaning it is either present or absent, like a CLI keyword), and a router container that holds a list of ospf entries keyed by id of type uint16.

Step 3 — Send configuration to the device. Translate the YANG model into a configuration payload and send it to the device using your chosen protocol. For RESTCONF, you construct a URL that points to the target resource and send the payload using the appropriate HTTP method.

Step 4 — Automate with Python. Once you understand the payload and URL structure, you can wrap the entire operation in a Python script for repeatable, scalable automation.

Building the RESTCONF URL

The RESTCONF URL follows a structured pattern that maps directly to the YANG model hierarchy. To configure IPv6 on a device, the URL would be:

https://<device>/restconf/data/Cisco-IOS-XE-native:native/ipv6/

Breaking this down:

• https://<device> — the device management IP with HTTPS
• /restconf/data/ — the RESTCONF API root for configuration data
• Cisco-IOS-XE-native:native — the top-level container from the YANG module
• /ipv6/ — the specific feature branch within the model

This URL structure mirrors the YANG tree. Just as you would navigate from native down to ipv6 in the model, the URL follows the same path separated by forward slashes.

Building the Configuration Payload

The configuration payload is a JSON (or XML) document that follows the YANG model structure. To enable IPv6 unicast routing and create OSPF process 1, the JSON payload looks like this:

{
  "Cisco-IOS-XE-native:ipv6": {
    "unicast-routing": [null],
    "router": {
      "ospf": [{"id": 1}]
    }
  }
}

Notice how the JSON structure maps directly to the YANG tree: ipv6 contains unicast-routing (set to [null] because it is an Empty type) and a router object containing an ospf list with an entry whose id is 1.

Configuration Example

Enabling RESTCONF and NETCONF on IOS XE

Before you can use model-driven programmability, you must enable the protocols on the device. For NETCONF, enter the following in global configuration mode:

R1(config)# netconf-yang

For RESTCONF, you need an HTTPS server running on the device:

R1(config)# ip http secure-server
R1(config)# restconf

Sending Configuration via RESTCONF with Python

The following Python script demonstrates the complete workflow for enabling IPv6 unicast routing and OSPF process 1 on an IOS XE device using RESTCONF:

import requests
import urllib3

# Disable SSL warnings for lab environments
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

# Step 1: Define connection details to your device
device = "lab.nhprep.com"
username = "admin"
password = "Lab@123"
base_url = f"https://{device}/restconf/data"

# Step 2: Define your configuration in YANG (JSON payload)
payload = {
    "Cisco-IOS-XE-native:ipv6": {
        "unicast-routing": [None],
        "router": {
            "ospf": [{"id": 1}]
        }
    }
}

# Step 3: Build the URL for the targeted resource
url = f"{base_url}/Cisco-IOS-XE-native:native/ipv6/"

headers = {
    "Content-Type": "application/yang-data+json",
    "Accept": "application/yang-data+json"
}

# Step 4: Send to device using the required HTTPS method (PATCH)
response = requests.patch(
    url,
    json=payload,
    headers=headers,
    auth=(username, password),
    verify=False
)

print(f"Status Code: {response.status_code}")

Let us walk through what this script does:

1. Import the Requests library — The requests library handles all HTTPS communication with the device, serving as the Python equivalent of RESTCONF's HTTP transport.
2. Define connection details — Specify the device hostname or IP, credentials, and the RESTCONF base URL.
3. Define configuration in YANG — The JSON payload follows the exact structure from the YANG model. This is the same payload we built in the previous section.
4. Build the URL for the targeted resource — The URL points to the ipv6 container under Cisco-IOS-XE-native:native.
5. Send the configuration using PATCH — The PATCH method merges this configuration into the device's existing configuration without overwriting unrelated settings.

Best Practice: In lab environments, you may disable SSL certificate verification with verify=False. In production, always use valid certificates and set verify=True to ensure secure communication.

Equivalent CLI Commands

For context, the RESTCONF operation above achieves the same result as these CLI commands:

R1(config)# ipv6 unicast-routing
R1(config)# ipv6 router ospf 1

The difference is that the programmatic approach is repeatable, scalable, and can be applied to hundreds of devices without manual intervention.

Real-World Application

Model-Driven Telemetry and the Bigger Picture

RESTCONF and NETCONF are not used in isolation. In production networks, they form part of a larger model-driven manageability ecosystem. Configuration flows from orchestrators and controllers down to devices using NETCONF or RESTCONF, while model-driven telemetry (MDT) pushes operational data from devices up to monitoring platforms using protocols like gRPC.

The encoding formats (XML, JSON, GPB) and transport protocols (SSH, HTTP, TCP) remain consistent across both configuration and telemetry workflows, all built on the same core YANG models. Tools like YANG Suite help engineers explore and validate YANG models before writing automation scripts.

Cross-Domain Automation

Modern enterprise networks span campus, data center, WAN, and cloud environments. The trend toward cross-domain automation (CDA) means consolidating from multiple platforms to fewer, more integrated ones. RESTCONF and NETCONF provide the standardized API layer that enables workflow orchestration tools and Infrastructure as Code (IaC) pipelines to manage network devices alongside compute and storage resources.

In a typical NetDevOps workflow:

• IaC definitions describe the desired network state
• CI/CD pipelines validate and deploy changes
• Per-domain network controllers manage individual network segments
• Cross-domain analytics provide visibility across the entire infrastructure
• REST APIs tie everything together, from controllers to ITSM platforms

When to Choose RESTCONF vs. NETCONF

• Use RESTCONF when you need quick, stateless interactions, want JSON encoding for easier integration with web-based tools, or are building lightweight scripts with the Python requests library.
• Use NETCONF when you need transaction-based operations (commit/rollback), require candidate configuration datastores, or are working in environments where SSH is the preferred transport.

Summary

• Model-driven programmability replaces human-friendly CLI with machine-friendly YANG data models, enabling scalable and repeatable network automation.
• NETCONF (RFC 6241) uses RPC over SSH with XML encoding, while RESTCONF (RFC 8040) uses HTTPS with XML or JSON encoding — both driven by the same YANG models.
• The four-step workflow for programmatic configuration is: select your protocol, define configuration in YANG, send configuration to the device, and automate with Python.
• RESTCONF URLs map directly to the YANG model hierarchy, making it straightforward to target specific device features like interfaces, IPv6, or routing protocols.
• RESTCONF and NETCONF fit into a larger ecosystem of model-driven telemetry, cross-domain automation, and NetDevOps practices that are transforming how production networks are managed.

In the next lesson, we will build on these foundations and explore how to use Ansible for network automation, leveraging modules that use NETCONF and RESTCONF under the hood to manage device configurations at scale.