4.6 Configure and verify NETCONF and RESTCONF

What this objective tests

NETCONF and RESTCONF are model-driven management protocols. Software uses them to read and change device state as structured data, not as parsed CLI text. The exam tests how to enable both on IOS XE, how each protocol works, and how to read a reply.

Both protocols use the same YANG models. YANG defines the valid configuration and state tree on the device.

Why model-driven management matters

Traditional automation logs in with SSH, runs a CLI command, and parses human text. It breaks when the output format changes.

Model-driven automation connects to a management protocol, requests a modeled resource, and receives structured XML or JSON. It is easier to validate and safer to integrate with software.

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

Enable NETCONF and RESTCONF on IOS XE

Both protocols need a local user, a domain name, and crypto keys:

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

• netconf-yang enables NETCONF over SSH.
• restconf enables RESTCONF. It needs ip http secure-server for HTTPS.

Verify on the device:

show platform software yang-management process
show netconf-yang status
show ip http server status

From the automation host, test reachability:

nc -vz 10.10.10.1 830
nc -vz 10.10.10.1 443

Note: Give the YANG processes time to start after netconf-yang. Check show netconf-yang status before you blame the client.

RESTCONF example: GET interfaces with curl

This example reads operational interface data with the Cisco-IOS-XE-interfaces-oper model:

curl -k -u ccnp:STRONG_PASSWORD \
  https://10.10.10.1/restconf/data/Cisco-IOS-XE-interfaces-oper:interfaces \
  -H 'Accept: application/yang-data+json'

Expected JSON reply (shortened):

{
  "Cisco-IOS-XE-interfaces-oper:interfaces": {
    "interface": [
      {
        "name": "GigabitEthernet1",
        "interface-type": "iana-if-type:ethernetCsmacd",
        "admin-status": "if-state-up",
        "oper-status": "if-oper-state-ready",
        "speed": "1000000000",
        "statistics": {
          "in-octets": 12849302,
          "out-octets": 9022118
        }
      }
    ]
  }
}

Read the URI in parts. The model prefix before the colon names the YANG module. The path after it names the container or list. A wrong module name or key returns 404, even when credentials and TLS are correct.

Note: curl -k disables TLS certificate checks. Use it only in a disposable lab with a self-signed certificate. In production, trust the correct CA bundle.

NETCONF example: a get RPC

NETCONF sends XML RPCs over the SSH session. This <get> asks for the same operational interface data:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <get>
    <filter type="subtree">
      <interfaces xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-interfaces-oper"/>
    </filter>
  </get>
</rpc>

The device answers with an <rpc-reply> that carries the matching <data> in XML. Common RPC operations:

Read the datastore name in client code. <get-config> on running returns configuration, not live counters. An interface can show enabled in configuration and still be operationally down. Use <get> or a state model for operational data.

RESTCONF methods and response codes

The HTTP method tells the device what to do:

Know the common response codes:

Note: PUT replaces the target resource. PATCH merges into it. Using PUT to change one field can remove sibling configuration.

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 with curl.

Do these steps:

1. Configure R1 with hostname, domain name, a privilege 15 user, RSA keys, SSH v2, ip http secure-server, netconf-yang, and restconf.
2. Verify on R1: show netconf-yang status and show ip http server status.
3. From the host, test ports: nc -vz 10.10.10.1 830 and nc -vz 10.10.10.1 443.
4. Read operational interface data with curl:

   curl -k -u ccnp:STRONG_PASSWORD \
     https://10.10.10.1/restconf/data/Cisco-IOS-XE-interfaces-oper:interfaces \
     -H 'Accept: application/yang-data+json'

1. Confirm the reply contains interface entries with admin-status, oper-status, and counters.
2. Change a URI component to a wrong module name. Send the request again and confirm the reply is 404.
3. Send a wrong password and confirm the reply is 401.
4. Send the NETCONF <get> RPC from the example with an SSH NETCONF client. Confirm the <rpc-reply> contains interface XML.

Expected result: the curl GET returns JSON like the example above. The wrong URI gives 404. The wrong password gives 401. The NETCONF <get> returns matching data in XML.

Exam traps

• Port swap is the classic trap. NETCONF runs over SSH on TCP 830. RESTCONF runs over HTTPS on TCP 443.
• NETCONF is XML only. RESTCONF uses JSON or XML. Both are model-driven by the same YANG models.
• RESTCONF needs ip http secure-server. restconf alone is not enough.
• A 401 means authentication. A 404 means the URI. Do not confuse them.
• PUT replaces; PATCH merges. Pick PATCH for a one-field change.

Pass check

You are ready when you can do these things:

• Enable netconf-yang and restconf on IOS XE with the supporting commands.
• Build a RESTCONF URI from a model name and read the JSON reply.
• Read a NETCONF <get> RPC and say what it asks for.
• Map common HTTP response codes to their causes.
• Explain why YANG models matter more than the transport choice.