4.6 Configure and verify NETCONF and RESTCONF

NETCONF and RESTCONF are model-driven management protocols. They let software read and change network configuration and operational state using structured data instead of screen-scraping CLI output.

The model is usually YANG. The transport and style differ.

Why this matters

Traditional CLI automation often does this:

1. SSH to device.
2. Run CLI command.
3. Parse human text.
4. Hope the output format did not change.

Model-driven automation tries to do this:

1. Connect to a management protocol.
2. Request a modeled resource.
3. Receive structured XML or JSON.
4. Change configuration with a predictable operation.

That is cleaner, easier to validate, and safer to integrate with software.

Automation client | +
NETCONF (SSH/TCP 830)
RPC: get-config / edit-config
XML reply | +
RESTCONF (HTTPS/443)
GET/PATCH on /restconf/data/...
JSON or XML | v YANG models define valid config + state tree on the device

Enable NETCONF on IOS XE

Basic NETCONF over SSH configuration:

conf t
hostname R1
ip domain-name lab.local
username ccnp privilege 15 secret STRONG_PASSWORD
crypto key generate rsa modulus 2048
ip ssh version 2
netconf-yang
end

Verify:

show platform software yang-management process
show netconf-yang status
show running-config | include netconf-yang

NETCONF commonly listens on TCP 830. Make sure management reachability and access policy allow it.

From a Linux/macOS host, test TCP reachability:

nc -vz 10.10.10.1 830

Read data with Python NETCONF

The ncclient library is a common way to test NETCONF.

from ncclient import manager

DEVICE = {
    "host": "10.10.10.1",
    "port": 830,
    "username": "ccnp",
    "password": "STRONG_PASSWORD",
    "hostkey_verify": True,
    "device_params": {"name": "iosxe"},
}

with manager.connect(**DEVICE) as m:
    print("NETCONF capabilities:")
    for cap in m.server_capabilities:
        if "Cisco-IOS-XE" in cap:
            print(cap)

    filter_xml = """
    <filter xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
    </filter>
    """
    reply = m.get_config(source="running", filter=filter_xml)
    print(reply.xml)

If a disposable lab has no host-key trust set up, you may see examples use hostkey_verify=False. Treat that as a lab shortcut, not the default. In real automation, validate SSH host keys or manage the trust decision deliberately. ENCOR can test both protocol enablement and secure API or management habits; do not let a quick lab example train you to ignore trust.

The exact YANG model and namespace matter. That is the part students often skip. NETCONF is not “SSH but fancy.” It is model-driven.

Also read the datastore name. get_config(source="running") asks for configuration from the running datastore; it does not ask for arbitrary live operational counters. For state data, use a model and operation that returns state, not just configuration. This matters when an interface is configured enabled: true but operationally down.

Enable RESTCONF on IOS XE

RESTCONF uses HTTPS. A basic setup usually includes secure HTTP and RESTCONF.

conf t
hostname R1
ip domain-name lab.local
username ccnp privilege 15 secret STRONG_PASSWORD
crypto key generate rsa modulus 2048
ip http secure-server
restconf
end

Verify:

show running-config | include restconf|ip http secure-server
show ip http server status

RESTCONF commonly uses TCP 443.

curl --cacert "$RESTCONF_CA_BUNDLE" -u ccnp:STRONG_PASSWORD \
  https://10.10.10.1/restconf/data/ietf-interfaces:interfaces \
  -H 'Accept: application/yang-data+json' \
  | python3 -m json.tool

curl -k disables TLS certificate validation. It is acceptable only for a controlled lab with a self-signed certificate. The safer default is to install or trust the correct CA certificate and point the client at that bundle.

RESTCONF methods

The HTTP method tells the device what you want to do.

For the exam, understand the method meanings and the idea of a resource URI. Do not treat RESTCONF as one magic URL.

RESTCONF URI precision is not trivia. The model prefix before the colon identifies the YANG module namespace, and list keys appear in the path. A wrong namespace or key can turn a valid HTTPS request into a 404 even when the device, credentials, and TLS are fine.

Configure an interface description with RESTCONF

Example payload:

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet1",
    "description": "Configured by RESTCONF lab",
    "type": "iana-if-type:ethernetCsmacd",
    "enabled": true
  }
}

Example request:

curl --cacert "$RESTCONF_CA_BUNDLE" -u ccnp:STRONG_PASSWORD \
  -X PATCH \
  "https://10.10.10.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1" \
  -H 'Content-Type: application/yang-data+json' \
  -H 'Accept: application/yang-data+json' \
  --data @interface-description.json

The -k flag is still only a lab shortcut here. Use it to get past a disposable self-signed lab certificate, not as the normal RESTCONF habit.

Then verify from the device:

show running-config interface GigabitEthernet1

NETCONF vs RESTCONF exam comparison

Lab: Enable and test both protocols

Topology

Automation host 10.10.10.50
R1 10.10.10.1

Goal

Enable NETCONF and RESTCONF on R1, then read interface data using Python and curl.

Device configuration

conf t
hostname R1
ip domain-name lab.local
username ccnp privilege 15 secret STRONG_PASSWORD
crypto key generate rsa modulus 2048
ip ssh version 2
ip http secure-server
netconf-yang
restconf
end

Test NETCONF reachability

nc -vz 10.10.10.1 830

Test RESTCONF read

curl --cacert "$RESTCONF_CA_BUNDLE" -u ccnp:STRONG_PASSWORD \
  https://10.10.10.1/restconf/data/ietf-interfaces:interfaces \
  -H 'Accept: application/yang-data+json' \
  | python3 -m json.tool

Test NETCONF read with Python

from ncclient import manager

with manager.connect(
    host="10.10.10.1",
    port=830,
    username="ccnp",
    password="STRONG_PASSWORD",
    hostkey_verify=True,
    device_params={"name": "iosxe"},
) as m:
    print(m.get_config(source="running").xml[:1000])

Again, hostkey_verify=False and curl -k are shortcuts for a controlled lab. Secure management means validating device identity and TLS or SSH trust when the automation moves beyond a throwaway sandbox.

Expected lesson

The protocol is only half the story. The data model matters. On the exam, connect these ideas:

YANG model
NETCONF or RESTCONF -> structured config/state data

Troubleshooting checklist

If NETCONF fails:

• Is netconf-yang enabled?
• Is SSH enabled and reachable?
• Is TCP 830 allowed?
• Are username/password and authorization correct?
• Is the YANG management process healthy?

If RESTCONF fails:

• Is restconf enabled?
• Is ip http secure-server enabled?
• Is HTTPS reachable?
• Are the URI, namespace, and headers correct?
• Does the user have privilege to read or change the resource?

Exam takeaways

• NETCONF uses structured RPC-style operations over SSH.
• RESTCONF uses HTTP methods against YANG-modeled resources.
• Both are model-driven and commonly rely on YANG.
• Enable netconf-yang for NETCONF on IOS XE.
• Enable HTTPS and restconf for RESTCONF.
• Know how to verify the service and test with a simple client.