Skip to main content
PacketMentor logo
Open menu
← All topics
Automation & Programmability Foundational

YANG, RESTCONF and NETCONF in Practice

The three-layer stack that lets any Cisco (and any vendor) device be managed through a common data model. YANG describes the data; NETCONF and RESTCONF are two transports to read and write it.

Quick summary
  • YANG = the schema (what fields exist, what types they are). Not a transport.
  • NETCONF = XML over SSH. RESTCONF = JSON over HTTPS. Both carry YANG-shaped data.
  • Standard IETF modules (ietf-interfaces, ietf-ip, openconfig-interfaces) work across vendors. Cisco-specific modules add vendor features.

Mental model

Cisco objective 3.8 (and objective 5.11 for YANG model interpretation) treats model-driven programmability as a three-layer stack:

[ YANG model ]  — defines what data looks like (types, hierarchy, constraints)
    │
    ├── carried by NETCONF (XML over SSH, port 830)
    └── carried by RESTCONF (JSON or XML over HTTPS, port 443)

YANG is the schema. NETCONF and RESTCONF are two transports that both carry data shaped by YANG. Same data, two wire formats, two protocols.

YANG, in one page

YANG (Yet Another Next Generation) is a language for describing data models. Think of it as the IDL (interface definition language) for network configuration and state.

A tiny excerpt from ietf-interfaces looks like:

container interfaces {
  list interface {
    key "name";
    leaf name        { type string; }
    leaf description { type string; }
    leaf type        { type identityref { base interface-type; } }
    leaf enabled     { type boolean; default "true"; }
    leaf-list ipv4-address { type inet:ipv4-address; }
  }
}

What it tells you:

  • There is an interfaces container.
  • Inside it, a list of interface entries, keyed by name.
  • Each entry has name, description, type, enabled, and 0+ ipv4-address leaves.

That schema is identical whether you read it over RESTCONF or NETCONF.

Standard vs vendor modules

  • IETF modules (ietf-interfaces, ietf-ip, ietf-routing) are vendor-neutral. Learn these first.
  • OpenConfig modules (openconfig-interfaces, openconfig-system) are an industry-group alternative with broader scope.
  • Vendor-specific modules (Cisco-IOS-XE-native, Cisco-NX-OS-device) expose features that are not standardised.

A device usually implements many modules at once. show platform software yang-management process on IOS XE lists what is active.

RESTCONF: how the YANG tree maps to URLs

Each level of the YANG tree becomes a URL segment. The module name prefixes the top container with a colon.

YANG pathRESTCONF URL
/interfaces (from ietf-interfaces)/restconf/data/ietf-interfaces:interfaces
/interfaces/interface[name="GigabitEthernet0/0"]/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0
/interfaces/interface[name="Gi0/0"]/enabled/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0/enabled

Rules:

  • Path segments URL-encoded (/ → %2F).
  • List keys shown with =keyvalue.
  • JSON responses labelled with the fully-qualified name: "ietf-interfaces:interface" not just "interface".

RESTCONF: read

curl -k -u admin:cisco123 \
  -H "Accept: application/yang-data+json" \
  https://10.0.0.1/restconf/data/ietf-interfaces:interfaces

Response (abbreviated):

{
  "ietf-interfaces:interfaces": {
    "interface": [
      { "name": "GigabitEthernet0/0", "description": "WAN uplink", "enabled": true },
      { "name": "GigabitEthernet0/1", "enabled": false }
    ]
  }
}

RESTCONF: write

Three methods:

  • POST — create a new entry in a list.
  • PUT — replace an entry entirely.
  • PATCH — partial update (change only the fields you include). Most common.
curl -k -u admin:cisco123 -X PATCH \
  -H "Content-Type: application/yang-data+json" \
  -d '{"ietf-interfaces:interface":{"name":"GigabitEthernet0/1","enabled":true}}' \
  https://10.0.0.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1

Returns 204 No Content on success.

NETCONF: same thing in XML

<get-config>
  <source><running/></source>
  <filter type="subtree">
    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
  </filter>
</get-config>

Response is the same tree in XML. Operations: get, get-config, edit-config, commit, discard-changes, close-session.

Interpreting a YANG tree (exam skill)

Given a snippet like:

container system {
  leaf hostname  { type string; mandatory true; }
  leaf location  { type string; }
  container ntp {
    list server { key "address";
      leaf address { type inet:ipv4-address; }
      leaf prefer  { type boolean; default "false"; }
    }
  }
}

Answer: “What is the path to the address of the NTP server?” → /system/ntp/server[address=...]/address.

Read the tree top-down; identify leaf (single value) vs list (keyed collection) vs container (grouping only).

Comparison

NETCONFRESTCONF
TransportSSH (port 830)HTTPS (port 443)
PayloadXMLJSON (preferred) or XML
OperationsRPCs: get-config, edit-config, commitHTTP methods: GET, POST, PUT, PATCH, DELETE
CapabilitiesFull (locks, candidates, confirmed commit)Simpler subset
Easiest from curlNoYes
Easiest from Ansible / NSOYesYes

For a first script, choose RESTCONF. For tooling that needs confirmed-commit or candidate datastores, NETCONF.

FAQ

What is the difference between a candidate datastore and running datastore? Running is live config. Candidate is a scratch area you can edit, review, then commit. RESTCONF only exposes running by default.

Do I need to memorise YANG syntax for the exam? No. You need to read a YANG snippet and identify leaves, lists, containers, and construct the path to a value.

What is pyATS? Cisco’s test automation framework. Uses the same YANG models under the hood. See the CML and pyATS topic when it ships in Phase 5.

Which is faster: NETCONF, RESTCONF, or gNMI? gNMI streaming is fastest for metrics (push, binary payloads). RESTCONF is faster than NETCONF for one-off calls (no SSH session setup). For a bulk config push, NETCONF with a locked candidate datastore is cleanest.

Master this on a real network

Want this drilled into reflex?

1:1 weekly sessions, live feedback on your labs, and US interview prep: built around the CCNA Automation® exam blueprint. Free first session. No card on file until you decide.

Claim my free session →

Get the free CCNA 12-week roadmap

You're already reading up on YANG, RESTCONF and NETCONF in Practice. The roadmap is the order I recommend studying every CCNA topic in: with what to lab each week and where YANG, RESTCONF and NETCONF in Practice fits. A written personal reply, not an autoresponder. Expect it within one business day.

Personal reply from a senior network engineer. No third-party tracking. Unsubscribe any time.