NETCONF & YANG

Mental model

Imagine telling 50 devices “add VLAN 100” by SSHing into each and typing the commands. Painful.

Modern alternative: send each device a structured XML document describing the change. The device parses it, validates against its schema, applies it transactionally, and reports back. No screen-scraping, no regex parsing, no surprises when IOS adds a column.

Two pieces are involved:

• NETCONF — the protocol. Carries the XML between client and device. Runs over SSH (TCP 830).
• YANG — the schema language. Describes the structure of the data being moved. Vendor-neutral models like ietf-interfaces mean the same data shape works across Cisco IOS-XE, Juniper, and Arista.

RESTCONF is the same concept exposed as a REST API (HTTP + JSON or XML, port 443). Same YANG models, different transport.

For CCNA: know that NETCONF and YANG exist, what each does, and how they compare to REST APIs. You won’t write them yet, but you need to recognize them.

What a NETCONF exchange looks like

Step 1 — client opens an SSH connection to TCP 830 on the device.

Step 2 — both sides send <hello> messages advertising capabilities.

Step 3 — client sends an <rpc> (remote procedure call):

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
        <vlan>
          <vlan-list>
            <id>100</id>
            <name>USERS</name>
          </vlan-list>
        </vlan>
      </native>
    </config>
  </edit-config>
</rpc>

Step 4 — device parses, validates, applies, replies:

<rpc-reply message-id="101" xmlns="...">
  <ok/>
</rpc-reply>

That’s the full exchange. Verbose, but it’s machine-to-machine — no human is meant to type it.

YANG — the schema, in 90 seconds

YANG is a modeling language. A YANG module describes the structure of configuration / operational data: what keys exist, what their types are, what’s required vs optional, what constraints apply.

Snippet of a YANG model for interfaces:

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name {
        type string;
      }
      leaf type {
        type identityref { base interface-type; }
        mandatory true;
      }
      leaf enabled {
        type boolean;
        default true;
      }
    }
  }
}

You don’t write YANG models — vendors and standards bodies (IETF, OpenConfig) write them. You consume them: tools auto-generate API clients, the NETCONF / RESTCONF endpoints expose the corresponding data, and you write code against the model rather than against device-specific text.

NETCONF vs REST API — which to use

Both are valid in 2026. They overlap.

	NETCONF	RESTCONF / REST
Transport	SSH (TCP 830)	HTTPS (TCP 443)
Data format	XML	JSON or XML
Operations	get, get-config, edit-config, copy-config, delete-config	GET, POST, PUT, PATCH, DELETE
Transactions	Yes — multi-step changes commit atomically	Limited — single resource per request
Streaming subscriptions	Yes (RFC 5277, RFC 8639)	No (need a separate gNMI / webhooks)
Standard library support	ncclient for Python	Any HTTP library
Best for	Bulk transactional changes	Single reads/writes, simpler clients

Rule of thumb: REST/RESTCONF for simple per-resource operations, NETCONF for atomic bulk changes (e.g. “configure 100 interfaces or none”).

Common Python tooling

Talking NETCONF — ncclient

from ncclient import manager

with manager.connect(
    host="10.0.0.1",
    port=830,
    username="admin",
    password="cisco123",
    hostkey_verify=False,
) as m:
    config = """
    <config>
      <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
        <vlan>
          <vlan-list>
            <id>200</id>
            <name>GUEST</name>
          </vlan-list>
        </vlan>
      </native>
    </config>
    """
    response = m.edit_config(target="running", config=config)
    print(response)

Talking RESTCONF — requests

import requests

requests.post(
    "https://10.0.0.1/restconf/data/Cisco-IOS-XE-native:native/vlan",
    auth=("admin", "cisco123"),
    headers={
        "Accept": "application/yang-data+json",
        "Content-Type": "application/yang-data+json",
    },
    json={"vlan-list": [{"id": 200, "name": "GUEST"}]},
    verify=False,
)

Same change, two different transports.

Enabling NETCONF / RESTCONF on Cisco IOS-XE

R1(config)# netconf-yang
R1(config)# restconf

! Required for the REST endpoint to work
R1(config)# ip http secure-server

Verify NETCONF is listening:

R1# show platform software yang-management process

Datastores — running vs candidate vs startup

NETCONF distinguishes between several config datastores:

• running — the live, active config on the device
• candidate — a staging area for proposed changes (must explicitly commit to make them live)
• startup — what reloads after a power cycle

The candidate datastore is the killer feature for risky changes:

1. edit-config target=candidate (propose changes)
2. validate (check syntax/semantics)
3. commit (apply atomically)
4. (if anything breaks) → discard-changes or rollback

Compare to traditional CLI: every command is immediately live, every typo is a production change.

Common mistakes

1. Confusing NETCONF and REST APIs. They’re both “automation APIs” but use different transports and message formats. NETCONF = SSH + XML. RESTCONF = HTTPS + JSON/XML. Pick the right one for the tool you’re using.

2. Trying to write YANG modules. You consume vendor / standards models. You don’t author them unless you’re at a vendor or contributing to IETF working groups.

3. Editing running directly without a backup. Use candidate + commit when available. Cisco IOS-XE’s running config edits are immediate — no candidate datastore by default (some platforms add one).

4. Skipping certificate / host-key verification in production. hostkey_verify=False and verify=False are fine in a lab. In production they’re dangerous — a man-in-the-middle attacker could intercept config.

5. Treating it like CLI just over a different transport. NETCONF is transactional and structured. Edit a list of interfaces in one RPC, commit in one shot. Don’t loop “edit-config one interface, commit, edit-config next interface” — defeats the point.

6. Not validating before commit. NETCONF’s <validate> operation catches syntax/semantic errors before they hit running. Free safety net — use it.

Lab to try tonight

Use a Cisco DevNet sandbox (free IOS-XE sandbox available 24/7).

1. SSH to the sandbox. Verify NETCONF is enabled: show platform software yang-management process.
2. From your laptop, install ncclient: pip install ncclient.
3. Write a Python script that:
   • Connects via NETCONF
   • Issues <get-config><source><running/></source></get-config>
   • Prints the running config as XML
4. Try a small change: add a loopback interface via <edit-config>. Verify via SSH that it appeared.
5. Now do the same change via RESTCONF using curl or requests. Compare the two approaches.
6. Bonus: use pyang to download a Cisco YANG model and explore the schema.

Cheat strip

Concept	Plain English
NETCONF	Protocol for getting / setting config via XML over SSH (TCP 830)
YANG	Schema language describing the shape of the data
RESTCONF	Same idea as NETCONF, exposed as a REST API over HTTPS
edit-config	The “make a change” RPC
get / get-config	Read operational state / read config
Datastores	running / candidate / startup — different config states
commit	Atomically apply candidate → running
validate	Pre-commit syntax check
ncclient	Python library for NETCONF
OpenConfig	Vendor-neutral YANG models (Google-led)
IETF YANG	Standards-body YANG models (e.g. ietf-interfaces)