NETCONF & RESTCONF Overview

1. Why Programmable Interfaces Were Needed

For decades, network engineers configured devices one at a time using the CLI (Command Line Interface) — typing commands into a terminal session, reading back free-form text output, and manually verifying changes. This approach works fine for a handful of devices but becomes a serious bottleneck as networks grow. Managing hundreds or thousands of routers, switches, and firewalls via CLI introduces human error, inconsistency, and slow change cycles. See Python Netmiko for the CLI-automation bridge before moving to NETCONF/RESTCONF.

NETCONF and RESTCONF are programmatic network management interfaces — they expose device configuration and operational state as structured, machine-readable data. Automation tools (Python scripts, Ansible, Terraform, CI/CD pipelines) can read and modify device configuration reliably, at scale, and without the fragility of screen-scraping CLI text output.

Related pages: Network Automation Overview | JSON, XML & YANG | REST API Overview | REST API Methods | Python for Networking | Ansible Overview | Controller-Based Networking | Northbound & Southbound APIs | SSH | SNMP | RESTCONF Basics Lab | NETCONF with ncclient Lab

2. YANG — The Data Modelling Language

YANG (Yet Another Next Generation), defined in RFC 7950, is the data modelling language that underpins both NETCONF and RESTCONF. Before you can understand how these protocols work, you need to understand what YANG does — it provides a precise, vendor-neutral schema that describes exactly what data a device has (its configuration and state), what values are valid, and how everything is structured. See JSON, XML & YANG for a complete guide.

Think of YANG as the grammar and NETCONF/RESTCONF as the transport that carries data conforming to that grammar. Without YANG models, NETCONF and RESTCONF would just be arbitrary XML or JSON — YANG gives the data its meaning.

  YANG model → data → transport relationship:

  ┌──────────────────────────────────────────────────────────────────┐
  │  YANG Model (schema)                                             │
  │  Defines: what data exists, data types, valid values,            │
  │           hierarchy, relationships, constraints                  │
  │  Example: ietf-interfaces YANG module defines how interfaces     │
  │           are structured (name, type, IP address, etc.)          │
  └───────────────────────────┬──────────────────────────────────────┘
                              │ Validates and structures
                              ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │  Data Instance                                                   │
  │  Actual device data conforming to the YANG model:               │
  │  { "name": "GigabitEthernet1", "ip": "192.168.1.1/24" }        │
  └───────────────────────────┬──────────────────────────────────────┘
                              │ Carried by
                        ┌─────┴─────┐
                        ▼           ▼
               NETCONF (XML)    RESTCONF (JSON/XML)

YANG Model Types

YANG Data Node Types

  Key YANG statement types:

  container  — Groups related nodes. Like a folder.
               Example: interfaces/interface/config

  list       — Ordered or unordered set of entries with a key.
               Example: interface[name=GigE1], bgp/neighbors/neighbor[address=10.0.0.1]

  leaf       — A single value (string, integer, boolean, etc.)
               Example: interface/name = "GigabitEthernet1"

  leaf-list  — A list of single values (like a set).
               Example: dns-servers = [8.8.8.8, 8.8.4.4]

  rpc        — Defines a Remote Procedure Call (action on the device).
               Example: rpc close-session, rpc commit

  notification — Device-generated event pushed to the management system.

  typedef    — Reusable type definitions (like int32 with constraints).

  grouping   — Reusable schema fragments referenced with 'uses'.

  YANG path notation (similar to XPath):
  /interfaces/interface[name='GigabitEthernet1']/config/ip-address

3. NETCONF — Network Configuration Protocol

NETCONF (Network Configuration Protocol), defined in RFC 6241, is a standards-based protocol for installing, manipulating, and deleting the configuration of network devices. It uses XML to encode all data and operations, and runs over SSH on port 830. NETCONF was designed from the ground up as a programmatic interface — it is never used interactively by humans (unlike CLI).

NETCONF Architecture

  NETCONF architecture — manager and agent:

  ┌─────────────────────────────────────────────────────────┐
  │  NETCONF Manager (Client)                                │
  │  Python/ncclient, Ansible, NSO, Cisco DNA Centre         │
  │  → Sends RPC requests in XML                             │
  │  → Parses XML responses                                  │
  └─────────────────────────┬───────────────────────────────┘
                            │  SSH (TCP port 830)
                            │  XML-encoded RPC messages
                            ▼
  ┌─────────────────────────────────────────────────────────┐
  │  NETCONF Agent (Server) — the network device            │
  │  Cisco IOS XE, IOS XR, NX-OS, Junos, etc.               │
  │  → Maintains datastores (running, candidate, startup)   │
  │  → Processes RPC requests and returns responses         │
  │  → Validates changes against YANG models                │
  └─────────────────────────────────────────────────────────┘

  NETCONF session establishment:
  1. SSH connection to device port 830
  2. Device sends hello message with list of capabilities
     (YANG modules it supports, NETCONF features)
  3. Client sends its own hello
  4. NETCONF session is established
  5. Client sends RPCs; device responds
  6. Client sends close-session RPC to terminate

NETCONF Datastores

NETCONF introduces the concept of datastores — named repositories of device configuration. This is fundamentally different from CLI where there is only one running configuration. NETCONF defines up to three datastores:

  Candidate datastore workflow (safe transactional change):

  ┌─────────────────────────────────────┐
  │  Current running config (active)    │
  └───────────────────────┬─────────────┘
                          │ copy-config or implicit
                          ▼
  ┌─────────────────────────────────────┐
  │  Candidate datastore (staging)      │
  │  → Make changes here (edit-config)  │
  │  → Review with get-config           │
  │  → Validate (validate RPC)          │
  └───────────────────────┬─────────────┘
                          │ commit (atomic)
                          ▼
  ┌─────────────────────────────────────┐
  │  Running datastore (updated)        │
  │  All changes applied atomically     │
  │  If any change fails → full rollback│
  └─────────────────────────────────────┘

4. NETCONF Operations — RPC Methods

NETCONF uses RPC (Remote Procedure Call) messages wrapped in XML to perform operations on the device. Every NETCONF request is an <rpc> element containing an operation, and every response is an <rpc-reply> element containing the result or an error.

NETCONF XML Example — Reading an Interface

  NETCONF get-config request (client → device):
  ─────────────────────────────────────────────
  <?xml version="1.0" encoding="UTF-8"?>
  <rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
      <source>
        <running/>
      </source>
      <filter type="subtree">
        <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
          <interface>
            <name>GigabitEthernet1</name>
          </interface>
        </interfaces>
      </filter>
    </get-config>
  </rpc>

  NETCONF rpc-reply response (device → client):
  ──────────────────────────────────────────────
  <rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>GigabitEthernet1</name>
          <type>ianaift:ethernetCsmacd</type>
          <enabled>true</enabled>
          <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
            <address>
              <ip>192.168.1.1</ip>
              <prefix-length>24</prefix-length>
            </address>
          </ipv4>
        </interface>
      </interfaces>
    </data>
  </rpc-reply>

NETCONF XML Example — Configuring an Interface

  NETCONF edit-config request (setting an IP address):
  ──────────────────────────────────────────────────────
  <?xml version="1.0" encoding="UTF-8"?>
  <rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
      <target>
        <candidate/>        <!-- write to candidate, not running -->
      </target>
      <config>
        <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
          <interface>
            <name>GigabitEthernet2</name>
            <enabled>true</enabled>
            <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
              <address>
                <ip>10.0.0.1</ip>
                <prefix-length>30</prefix-length>
              </address>
            </ipv4>
          </interface>
        </interfaces>
      </config>
    </edit-config>
  </rpc>

  Then commit:
  <rpc message-id="3" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <commit/>
  </rpc>

  Success response:
  <rpc-reply message-id="3" ...>
    <ok/>
  </rpc-reply>

5. Enabling and Using NETCONF on Cisco IOS XE

  ! Enable NETCONF on a Cisco IOS XE device:
  Router(config)# netconf-yang
  ! This single command enables NETCONF (port 830) and YANG processing
  ! The device must have SSH configured (version 2 recommended)

  ! Verify NETCONF is enabled and listening:
  Router# show platform software yang-management process
  Router# show netconf-yang sessions
  Router# show netconf-yang statistics

  ! NETCONF also requires AAA and local/RADIUS authentication:
  Router(config)# aaa new-model
  Router(config)# aaa authentication login default local
  Router(config)# username admin privilege 15 secret Cisco123

  ! SSH must be configured (NETCONF uses SSH transport):
  Router(config)# ip domain-name lab.local
  Router(config)# crypto key generate rsa modulus 2048
  Router(config)# ip ssh version 2

  ! View supported YANG capabilities on the device:
  Router# show netconf-yang capabilities
  ! Returns a list of YANG modules the device supports

NETCONF requires SSH version 2 to be configured on the device. See SSH & Telnet Security for hardening SSH before enabling NETCONF. AAA must also be configured — see RADIUS vs TACACS+ for authentication options.

Using NETCONF with Python (ncclient)

  # Python ncclient — NETCONF client library
  # Install: pip install ncclient

  from ncclient import manager

  # Connect to device via NETCONF (SSH port 830)
  with manager.connect(
      host       = "192.168.1.1",
      port       = 830,
      username   = "admin",
      password   = "Cisco123",
      hostkey_verify = False    # In production, verify host keys!
  ) as m:

      # Get the running config for all interfaces (filtered):
      filter = """
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
      </interfaces>
      """
      result = m.get_config(source="running", filter=("subtree", filter))
      print(result)  # Returns XML string

      # Edit config — add IP address to GigabitEthernet2:
      config_payload = """
      <config>
        <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
          <interface>
            <name>GigabitEthernet2</name>
            <enabled>true</enabled>
            <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
              <address>
                <ip>10.0.0.1</ip>
                <prefix-length>30</prefix-length>
              </address>
            </ipv4>
          </interface>
        </interfaces>
      </config>
      """
      m.edit_config(target="candidate", config=config_payload)
      m.commit()  # Apply changes atomically
      print("Configuration committed successfully")

See full detail: NETCONF with ncclient Python Lab | Python for Networking

6. RESTCONF — REST API for Network Devices

RESTCONF, defined in RFC 8040, is a lighter-weight alternative to NETCONF that exposes the same YANG-modelled data through a standard HTTP/HTTPS REST API. If you are familiar with REST APIs for web services, RESTCONF will feel immediately familiar — it uses standard HTTP methods (GET, POST, PUT, PATCH, DELETE) and returns data in JSON or XML. See JSON, XML & YANG and REST API Methods.

RESTCONF is designed for simplicity and ease of use — it is stateless, requires no session establishment, and can be accessed from any HTTP client (curl, Postman, Python requests, web browser). The trade-off is that RESTCONF does not support the full transactional capabilities of NETCONF (no candidate datastore or atomic commit).

  RESTCONF URL structure:

  https://<device-ip>/restconf/data/<yang-module>:<path>

  Examples:
  GET all interfaces:
  https://192.168.1.1/restconf/data/ietf-interfaces:interfaces

  GET a specific interface:
  https://192.168.1.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1

  GET Cisco-native interface config:
  https://192.168.1.1/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet

  RESTCONF root path (shows supported YANG modules):
  https://192.168.1.1/restconf/data/

  RESTCONF Yang Library (discover available modules):
  https://192.168.1.1/restconf/data/ietf-yang-library:modules-state

RESTCONF HTTP Methods

See REST API Methods for a full explanation of HTTP verbs and how they map to CRUD operations.

7. RESTCONF Examples — JSON Requests and Responses

7.1 GET — Read an Interface Configuration

  HTTP Request:
  GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1
  Host: 192.168.1.1
  Accept: application/yang-data+json
  Authorization: Basic YWRtaW46Q2lzY28xMjM=  (admin:Cisco123 base64)

  HTTP Response: 200 OK
  Content-Type: application/yang-data+json

  {
    "ietf-interfaces:interface": {
      "name": "GigabitEthernet1",
      "type": "iana-if-type:ethernetCsmacd",
      "enabled": true,
      "ietf-ip:ipv4": {
        "address": [
          {
            "ip": "192.168.1.1",
            "prefix-length": 24
          }
        ]
      }
    }
  }

7.2 PUT — Configure an Interface IP Address

  HTTP Request:
  PUT /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet2
  Host: 192.168.1.1
  Content-Type: application/yang-data+json
  Accept: application/yang-data+json
  Authorization: Basic YWRtaW46Q2lzY28xMjM=

  Request body (JSON):
  {
    "ietf-interfaces:interface": {
      "name": "GigabitEthernet2",
      "type": "iana-if-type:ethernetCsmacd",
      "enabled": true,
      "ietf-ip:ipv4": {
        "address": [
          {
            "ip": "10.0.0.1",
            "prefix-length": 30
          }
        ]
      }
    }
  }

  HTTP Response: 204 No Content
  (Success — no response body; the resource was created/replaced)

7.3 PATCH — Change Only One Field

  HTTP Request:
  PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet2
  Host: 192.168.1.1
  Content-Type: application/yang-data+json

  Request body (only the field being changed):
  {
    "ietf-interfaces:interface": {
      "name": "GigabitEthernet2",
      "enabled": false
    }
  }

  HTTP Response: 204 No Content
  (Only the 'enabled' field was changed; IP address unchanged)

7.4 DELETE — Remove a Configuration

  HTTP Request:
  DELETE /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet2
  Host: 192.168.1.1
  Authorization: Basic YWRtaW46Q2lzY28xMjM=

  HTTP Response: 204 No Content
  (Interface configuration deleted)

7.5 HTTP Status Codes in RESTCONF

8. Enabling and Using RESTCONF on Cisco IOS XE

  ! Enable RESTCONF on Cisco IOS XE:
  Router(config)# restconf
  ! This enables the RESTCONF API server (HTTPS port 443)

  ! RESTCONF also requires netconf-yang to be enabled:
  Router(config)# netconf-yang

  ! AAA authentication required (same as NETCONF):
  Router(config)# aaa new-model
  Router(config)# aaa authentication login default local
  Router(config)# username admin privilege 15 secret Cisco123

  ! HTTPS must be enabled (RESTCONF uses HTTPS):
  Router(config)# ip http secure-server
  Router(config)# ip http authentication local

  ! Verify RESTCONF is running:
  Router# show platform software yang-management process

RESTCONF requires AAA to be configured. See RADIUS vs TACACS+ for enterprise authentication options, and SSH & Telnet Security for securing the underlying transport.

Using RESTCONF with Python (requests library)

  import requests
  import json

  # Disable SSL warnings for lab environments (DO NOT use in production):
  requests.packages.urllib3.disable_warnings()

  BASE_URL  = "https://192.168.1.1/restconf/data"
  AUTH      = ("admin", "Cisco123")
  HEADERS   = {
      "Content-Type": "application/yang-data+json",
      "Accept":       "application/yang-data+json"
  }

  # GET — Read GigabitEthernet1 configuration:
  url = f"{BASE_URL}/ietf-interfaces:interfaces/interface=GigabitEthernet1"
  response = requests.get(url, auth=AUTH, headers=HEADERS, verify=False)
  print(f"Status: {response.status_code}")
  print(json.dumps(response.json(), indent=2))

  # PUT — Set IP address on GigabitEthernet2:
  url = f"{BASE_URL}/ietf-interfaces:interfaces/interface=GigabitEthernet2"
  payload = {
      "ietf-interfaces:interface": {
          "name":    "GigabitEthernet2",
          "type":    "iana-if-type:ethernetCsmacd",
          "enabled": True,
          "ietf-ip:ipv4": {
              "address": [{"ip": "10.0.0.1", "prefix-length": 30}]
          }
      }
  }
  response = requests.put(url, auth=AUTH, headers=HEADERS,
                          json=payload, verify=False)
  print(f"PUT Status: {response.status_code}")  # 204 = success

  # DELETE — Remove GigabitEthernet2 configuration:
  response = requests.delete(url, auth=AUTH, headers=HEADERS, verify=False)
  print(f"DELETE Status: {response.status_code}")  # 204 = success

See full detail: RESTCONF Basics Lab | Python for Networking

9. NETCONF vs RESTCONF — When to Use Each

  Decision guide — which protocol to use?

  Need transactional config changes (all-or-nothing commit)?
  → Use NETCONF (candidate datastore + commit)

  Building a network controller or orchestration platform?
  → Use NETCONF (full feature set, event notifications)

  Quick script to read or change a few device settings?
  → Use RESTCONF (simpler, any HTTP client)

  Team more familiar with REST APIs (web developers)?
  → Start with RESTCONF, JSON encoding

  Need to push event-driven notifications from device to manager?
  → Use NETCONF (native subscription support)

  Both NETCONF and RESTCONF use the same YANG models —
  the data is the same, only the transport and encoding differ.

See also: JSON, XML & YANG | REST API Overview | Network Automation Overview | Python for Networking | Ansible Overview | Northbound & Southbound APIs

10. NETCONF & RESTCONF in the Broader Automation Landscape

NETCONF and RESTCONF are two of several southbound interfaces that automation tools and network controllers use to communicate with network devices. Understanding where they fit in the broader automation ecosystem is essential for the CCNA DevNet associate track and modern network engineering. See Northbound & Southbound APIs for the full API architecture picture.

  Network automation stack:

  ┌────────────────────────────────────────────────────────────────┐
  │  Human / Business Layer                                        │
  │  Network operator → writes policy in plain language            │
  │  "All branch VoIP traffic should use the MPLS path"            │
  └────────────────────────────────┬───────────────────────────────┘
                                   │
  ┌────────────────────────────────▼───────────────────────────────┐
  │  Orchestration / Automation Tools (Northbound)                 │
  │  Ansible, Terraform, Python scripts, Cisco NSO,                │
  │  Cisco DNA Centre, ServiceNow                                  │
  └────────────────────────────────┬───────────────────────────────┘
                                   │  Northbound APIs (REST, NETCONF)
  ┌────────────────────────────────▼───────────────────────────────┐
  │  Network Controller (optional layer)                           │
  │  Cisco DNA Centre, Cisco vManage (SD-WAN), APIC (ACI)          │
  └────────────────────────────────┬───────────────────────────────┘
                                   │  Southbound APIs
                     ┌─────────────┼────────────────┐
                     ▼             ▼                 ▼
               NETCONF/YANG   RESTCONF/YANG     OpenConfig
               (RFC 6241)     (RFC 8040)        (Protobuf/gNMI)
                     │             │                 │
  ┌──────────────────▼─────────────▼─────────────────▼────────────┐
  │  Network Devices (routers, switches, firewalls)                │
  │  Cisco IOS XE, IOS XR, NX-OS, Junos, Arista EOS               │
  └────────────────────────────────────────────────────────────────┘

See also: JSON, XML & YANG | REST API Overview | REST API Methods | Network Automation Overview | Python for Networking | NetFlow Overview | SNMP | RESTCONF Basics Lab | NETCONF with ncclient Lab | NetFlow Configuration Lab

Test Your Knowledge — NETCONF & RESTCONF Quiz