Configuring and Verifying NETCONF and RESTCONF on Cisco IOS XE for CCNP 350-401 ENCOR

1. Introduction to Model-Driven Programmability in ENCOR

For CCNP 350-401 ENCOR, NETCONF and RESTCONF aren’t just bonus topics tucked in the corner. They’re Cisco’s way of saying, “Please stop scraping CLI like it’s 2008.” Instead of wrestling human-readable output into submission, you work with structured data. SNMP doesn’t vanish. CLI doesn’t turn to dust. But modern automation keeps drifting toward cleaner schemas, explicit APIs, and responses that don’t require guesswork.

The exam wants you to keep three ideas separate, no blending, no fuzzy edges: YANG is the model, NETCONF and RESTCONF are the protocols, and XML/JSON are encodings. You also need to know how these services are turned on, how to prove they’re actually alive, and how to tell whether something broke because of transport, login, authorization, media type, a mangled path, or a model that simply doesn’t do what you hoped.

2. YANG, Standards, and Core Architecture

YANG is the data modeling language behind both NETCONF and RESTCONF. It describes how configuration and operational data are shaped. NETCONF and RESTCONF then give you standardized ways to reach in and work with that data.

Useful YANG terms for ENCOR:

module: the YANG file defining a schema
namespace: unique identifier used in XML and model references
revision: model version
container: grouping of related nodes
list: repeated keyed entries
leaf: single value
leaf-list: repeated scalar values
choice: mutually exclusive branches
augment: adds data to an existing model
rpc/action: executable operation
notification: event data, supported through specific capabilities or subscriptions

The big practical split is configuration data versus operational state. Some YANG nodes are writable; some are read-only; some sit in that awkward “depends what you’re asking for” zone. That changes the operation you use and the answer you should expect. Hostname? Configuration. Interface status? That’s state. Different beast.

On IOS XE, you may run into both Cisco native models and OpenConfig/IETF models. Native models tend to show Cisco features sooner, and often in fuller detail. Standards-based models are nicer for portability, but support varies. Always does. Release, feature set, platform... the usual suspects.

3. NETCONF and RESTCONF at a Glance

Category	NETCONF	RESTCONF
Transport	SSH	HTTPS
Default port	TCP 830	TCP 443
Encoding	XML	JSON or XML
Model	YANG	YANG
Access style	RPC/session based	URI/resource based
Common reads	<get>, <get-config>	GET
Common writes	<edit-config>	POST, PUT, PATCH, DELETE

Memory hook: NETCONF = SSH + TCP 830 + XML + RPCs. RESTCONF = HTTPS + TCP 443 + JSON/XML + URIs. And YANG is the blueprint, not the pipe.

4. NETCONF Fundamentals and IOS XE Caveats

NETCONF opens an SSH session, usually on TCP 830, and then talks through the SSH netconf subsystem. Client and server trade <hello> messages and advertise capabilities like base version, candidate support, validate support, or XPath filtering. A little handshake, a little boasting.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> <capability>urn:ietf:params:netconf:base:1.1</capability> <capability>urn:ietf:params:netconf:capability:validate:1.1</capability> </capabilities> </hello>

Common NETCONF operations include get, get-config, edit-config, copy-config, delete-config, lock, unlock, validate, close-session, and kill-session. Optional operations such as commit or discard-changes are capability-dependent. Sometimes they’re there, sometimes they’re not. Welcome to networking.

Datastore details matter. NETCONF conceptually includes running, candidate, and startup, but on IOS XE the running datastore is the main one in many everyday workflows. Don’t just assume candidate or commit are available. Check the capabilities first. That’s not just good practice; it’s an exam booby trap with a smile on its face.

Also keep the read split straight:

<get-config>: configuration datastore retrieval
<get>: operational data and, depending on request or model, configuration plus state

5. RESTCONF Fundamentals, Resource Paths, and Discovery

RESTCONF exposes YANG-modeled data over HTTPS. The main entry points are:

/restconf/data for datastore resources
/restconf/operations for RPCs and actions

Media types are one of those tiny details that love to ruin your afternoon. For JSON use application/yang-data+json. For XML use application/yang-data+xml. Accept tells the server what you want back. Content-Type tells it what you’re sending. Easy in theory. In practice... well, you know.

HTTP method semantics:

GET: read resource
POST: create under a parent resource or invoke an operation
PUT: replace target resource
PATCH: partial modification
DELETE: remove target resource

RESTCONF paths have to line up exactly with the implemented YANG model. For keyed lists, the URI carries the key value. Example using an IETF-style interface entry:

/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1

And yes, that sort of path is a classic face-plant zone. Wrong prefix, wrong key, wrong hierarchy... hello, 404 Not Found.

6. Configuring NETCONF and RESTCONF on IOS XE

Minimal NETCONF lab setup:

hostname R1 ip domain-name example.local username apiuser privilege 15 secret <PASSWORD> crypto key generate rsa modulus 2048 ip ssh version 2 line vty 0 4 login local transport input ssh netconf-yang

Minimal RESTCONF lab setup:

hostname R1 ip domain-name example.local username apiuser privilege 15 secret <PASSWORD> ip http secure-server restconf

One thing to keep straight: SSH settings matter for NETCONF, not for RESTCONF. RESTCONF rides on HTTPS and TLS. In labs, that often means a self-signed cert or a default trustpoint. In production, that’s not the whole story. You want actual certificate management and hostname validation, not “eh, close enough.”

Production-minded hardening should also include AAA integration, RBAC or privilege review, a dedicated management interface or VRF where possible, and ACLs restricting TCP 830 and TCP 443 to automation hosts.

ip access-list standard MGMT-API-HOSTS permit 10.10.10.50 permit 10.10.10.51 line vty 0 4 access-class MGMT-API-HOSTS in

7. Verification Workflow That Actually Proves Service Health

Don’t stop at “it’s enabled.” That’s how people convince themselves things work right up until they don’t. Use a layered workflow:

Reachability: can the automation host reach the management IP?
Port test: TCP 830 for NETCONF, TCP 443 for RESTCONF
Service config: confirm netconf-yang, restconf, and HTTPS settings
Authentication/AAA: verify the account can log in and is authorized
Discovery: confirm capabilities or available resources and models
Read test: perform a valid GET or RPC read
Write test: make a controlled change and confirm resulting state

Useful device-side checks include:

show running-config | section netconf|restconf|ip http|ssh show ip http server status show netconf-yang sessions

Command availability changes from one IOS XE release to another, so treat outputs as platform-specific. And show ssh can help with SSH details, sure — but by itself it doesn’t prove NETCONF is actually listening on TCP 830. That’s a separate creature.

For RESTCONF, root discovery is a strong first test. A basic HTTPS request to the RESTCONF data root should return the available top-level resources in the format you asked for.

For model discovery, query the YANG library resource supported by the release instead of making up paths and hoping the device is in a forgiving mood.

8. Practical Read and Write Examples

NETCONF read of running configuration:

NETCONF write of hostname:

RESTCONF read of hostname:

A typical RESTCONF hostname read targets the native model hostname resource and asks for JSON using the proper YANG media type.

GET /restconf/data/Cisco-IOS-XE-native:native/hostname Accept: application/yang-data+json Authorization: Basic credentials-for-apiuser

RESTCONF partial update using a model-specific path. Exact support and payload shape depend on the implemented model and release, so check the discovered schema first. Don’t freestyle it.

PATCH /restconf/data/Cisco-IOS-XE-native:native Content-Type: application/yang-data+json Accept: application/yang-data+json {"Cisco-IOS-XE-native:hostname":"R2"}

That example is just that — an example. The safe rule is boring but solid: match the resource and payload exactly to the supported YANG model.

Operational state example should use an operational model rather than a config-oriented native example. Conceptually:

/restconf/data/ietf-interfaces:interfaces-state/interface=GigabitEthernet1

Whether that exact path exists depends on release and model support, which is why discovery matters instead of guesswork.

9. Error Handling and Diagnostics

A transport session that succeeds doesn’t mean the operation itself will. Read the error body. That’s where the real story lives.

NETCONF rpc-error example:

<rpc-reply message-id="103" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <error-type>application</error-type> <error-tag>unknown-element</error-tag> <error-severity>error</error-severity> <error-path>/native/hostnme</error-path> <error-message>unknown element: hostnme</error-message> </rpc-error> </rpc-reply>

RESTCONF JSON error example:

{ "errors": { "error": [ { "error-type": "protocol", "error-tag": "invalid-value", "error-message": "malformed resource path" } ] } }

Symptom	Likely cause	Fix
NETCONF cannot connect	TCP 830 blocked, SSH or AAA issue, service not enabled	Check reachability, ACLs, `netconf-yang`, and authentication policy
RESTCONF 401	Bad credentials	Correct authentication
RESTCONF 403	User authenticated but not authorized	Review AAA or RBAC mapping
RESTCONF 404	Wrong URI, namespace, or key	Validate model path through discovery
RESTCONF 405	Wrong HTTP method	Use GET, POST, PUT, PATCH, or DELETE correctly
RESTCONF 415	Wrong media type	Use correct `Accept` and `Content-Type`

10. Tooling and Automation Examples

For labs and real automation, common choices are ncclient for NETCONF and Python requests for RESTCONF.

from ncclient import manager with manager.connect(host="10.10.10.1", port=830, username="apiuser", password="password", hostkey_verify=False) as m: print(m.get_config("running").xml) import requests api_path = "/restconf/data/Cisco-IOS-XE-native:native/hostname" headers = {"Accept": "application/yang-data+json"} r = requests.get("device-api-endpoint" + api_path, headers=headers, auth=("apiuser", "password"), verify=False) print(r.status_code, r.text)

Ansible can work through NETCONF-capable or HTTPAPI-based workflows depending on module support. The exam is more likely to test recognition than playbook syntax, but the design instinct stays the same: discover supported models first, then build idempotent reads and writes against those models.

11. Security and Production Deployment Considerations

Secure management APIs the same way you secure CLI access:

Use AAA, not just a hardcoded local admin account
Apply least privilege and verify authorization behavior
Restrict access with ACLs and preferably a management VRF or out-of-band path
Use trusted certificates for HTTPS in production
Do not leave unnecessary HTTP services enabled
Log and audit API access
Avoid embedding secrets directly in scripts

A common production headache is TLS validation failure caused by a self-signed certificate or hostname mismatch. That’s why disabling certificate checks can be fine in a lab, but not as a standing practice. Convenience is a slippery little thing.

12. Exam Traps, Recognition Cues, and Final Review

Common exam traps:

YANG is not a transport protocol
RESTCONF does not use SSH
NETCONF does not use HTTP verbs
NETCONF commonly uses TCP 830, not generic HTTPS port 443
RESTCONF commonly uses TCP 443, not NETCONF port 830
commit is not universally relevant unless candidate support exists
Configuration data and operational state are not the same thing

Quick recognition cues:

SSH + XML + <rpc> means NETCONF
HTTPS + JSON + /restconf/data means RESTCONF
200/201/204/401/403/404/415 suggests RESTCONF troubleshooting
<hello> capability exchange suggests NETCONF session setup
Module prefix in path suggests YANG-modeled RESTCONF resource addressing

ENCOR quick facts:

NETCONF: SSH, TCP 830, XML, RPC, capability exchange
RESTCONF: HTTPS, TCP 443, JSON/XML, URIs, HTTP methods
YANG: schema or model used by both
Enable NETCONF: netconf-yang
Enable RESTCONF: ip http secure-server and restconf

If you want the right mental flow for this ENCOR topic, use this sequence: discover the model, confirm the transport and port, verify authentication and authorization, test a read, test a write, then confirm resulting state. That’s how you answer exam questions correctly. Also how you avoid embarrassing assumptions in production.