For decades, network automation meant SSH into a box and typing show commands. That model doesn't scale. NETCONF and RESTCONF are YANG-driven protocols that let you manage network devices programmatically, using structured data instead of screen scraping. The 200-301 exam expects you to understand the differences between these two protocols, their transport layers, and their place in a model-driven automation workflow. This chapter gives you the exact details Cisco tests — from port numbers to payload formats.
Jump to a section
Imagine a large hotel. The front desk (NETCONF) has a strict procedure: you fill out a specific form (YANG data model), hand it to the clerk, and they update the hotel's central system. The clerk then reads back the entire updated reservation to confirm. Every interaction is a formal transaction. You can queue multiple requests (candidate config) and commit them all at once. The front desk uses a dedicated phone line (SSH) and speaks a formal protocol. Now consider the hotel's concierge app (RESTCONF). You use a web browser or a mobile app (HTTP/HTTPS) to send a GET request to see your bill, or a PUT request to change your room service order. The app responds with a simple JSON or XML snippet — just the data you asked for, not the whole hotel database. There's no formal transaction; each request is independent. The front desk is powerful but heavyweight; the app is lightweight and easy to integrate. In networking, NETCONF is the front desk — transactional, session-based, using SSH for transport. RESTCONF is the app — stateless, using HTTP verbs, and returning only what you need. Both use YANG as the common language (the hotel's data model), but they speak it differently. Cisco tests both because real networks use both: NETCONF for bulk configuration changes and RESTCONF for monitoring and quick API integrations.
NETCONF (Network Configuration Protocol, RFC 6241) and RESTCONF (RFC 8040) are both network management protocols that use YANG (RFC 7950) as the data modeling language. They were created to replace the error-prone, fragile method of screen-scraping CLI output. Instead of sending human-readable text and hoping the parser works, you send structured data (XML or JSON) that the device validates against a YANG model.
Cisco 200-301 objective 6.6 covers: "Compare NETCONF and RESTCONF." The exam expects you to know the transport protocol, data format, operations, and architectural differences.
How NETCONF Works
NETCONF uses a client-server model over SSH (port 830). The client establishes a persistent SSH session, then the two exchange XML-encoded messages. The session goes through these states:
Hello: Both sides send a <hello> message listing their capabilities (YANG modules).
Operational: The client sends operations like <get>, <get-config>, <edit-config>, <copy-config>, <commit>, <lock>, <unlock>, etc.
Locking: To prevent conflicting changes, the client can lock the candidate or running datastore.
Candidate config: NETCONF supports a candidate configuration datastore. You can make multiple edits, then commit them atomically with <commit>. If something goes wrong, you can discard with <discard-changes>.
Confirmed commit: You can set a timeout; if the commit isn't confirmed within that time, the device automatically rolls back.
Example NETCONF <edit-config> message:
<rpc message-id="101">
<edit-config>
<target>
<running/>
</target>
<config>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<interface>
<GigabitEthernet>
<name>1</name>
<description>WAN Link</description>
</GigabitEthernet>
</interface>
</native>
</config>
</edit-config>
</rpc>The device replies with an <rpc-reply> containing <ok> or an error.
How RESTCONF Works
RESTCONF uses HTTP/HTTPS (port 443 or 80) and follows REST principles. It uses standard HTTP verbs:
GET – retrieve data (operational state or configuration).
POST – create a new data resource.
PUT – replace or create a resource.
PATCH – partial update (not all implementations support it).
DELETE – delete a resource.
Data can be encoded in XML or JSON (JSON is more common). The URL path maps directly to the YANG data tree. For example:
GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1RESTCONF is stateless – each request is independent. It does not support locking or candidate configurations natively. It uses standard HTTP status codes (200 OK, 201 Created, 204 No Content, 400 Bad Request, etc.).
Key Differences for the Exam
Transport: NETCONF = SSH (port 830). RESTCONF = HTTP/HTTPS (port 443/80).
Session: NETCONF is session-based (long-lived). RESTCONF is stateless (each request is separate).
Data format: NETCONF uses XML only. RESTCONF uses XML or JSON.
Transaction support: NETCONF supports candidate config and commit/rollback. RESTCONF does not have a built-in transaction mechanism (you must use YANG patch or handle errors manually).
Operations: NETCONF has defined RPCs (get, get-config, edit-config, etc.). RESTCONF uses HTTP verbs and URL paths.
Security: NETCONF relies on SSH. RESTCONF relies on HTTPS (TLS) and can use HTTP authentication (Basic, Token, etc.).
Verification Commands
On a Cisco IOS XE device, you can check which YANG models are supported:
Router# show netconf-yang datastores
Router# show netconf-yang sessions
Router# show netconf-yang schemaFor RESTCONF, you can test with a curl command:
curl -k -u admin:password https://192.168.1.1/restconf/data/ietf-interfaces:interfacesInteraction with Related Protocols
Both protocols rely on YANG models. Cisco publishes YANG models for IOS XE (e.g., Cisco-IOS-XE-native). They also integrate with telemetry (model-driven telemetry uses YANG paths). NETCONF and RESTCONF are both used in orchestration systems like Cisco NSO, Ansible, and Python scripts.
Important Timers and Defaults
NETCONF SSH port: 830 (default).
RESTCONF HTTPS port: 443 (default).
NETCONF session idle timeout: default 5 minutes (configurable).
NETCONF confirmed commit timeout: default 600 seconds (configurable).
RESTCONF does not have session timers (stateless).
Enable NETCONF on IOS XE
First, enable NETCONF on the device. Use the global configuration command `netconf-yang`. This enables the NETCONF server on port 830. Optionally, you can set the SSH port with `netconf-yang ssh port <port>`. Verify with `show netconf-yang sessions` to see active sessions. Example: ``` Router(config)# netconf-yang Router(config)# end Router# show netconf-yang sessions ``` If you see no sessions, the server is ready to accept connections.
Enable RESTCONF on IOS XE
RESTCONF requires HTTPS. Enable the HTTP/HTTPS server first: `ip http secure-server` (for HTTPS) or `ip http server` (for HTTP, not recommended). Then enable RESTCONF with `restconf` in global config. Verify with `show restconf` to see the URL prefix (default /restconf). Example: ``` Router(config)# ip http secure-server Router(config)# restconf Router(config)# end Router# show restconf ``` The output shows the RESTCONF API root.
Explore YANG models on device
List available YANG models using `show netconf-yang schema` or `show netconf-yang schemas list`. This shows the module names and revisions. For RESTCONF, you can browse the schema via GET requests. Example: ``` Router# show netconf-yang schemas list ``` This helps you know which data models you can use in your NETCONF/RESTCONF operations.
Perform NETCONF get-config operation
Use a NETCONF client (e.g., Python's ncclient) to retrieve the running configuration. The client opens an SSH session to port 830, sends a `<hello>`, then sends `<rpc><get-config><source><running/></source></get-config></rpc>`. The device replies with the full config in XML. Example Python snippet: ```python from ncclient import manager m = manager.connect(host='192.168.1.1', port=830, username='admin', password='password', hostkey_verify=False) config = m.get_config(source='running').data_xml print(config) m.close_session() ```
Perform RESTCONF GET request
Use curl or a REST client to send an HTTP GET to the RESTCONF API. The URL is `https://device/restconf/data/yang-module:container`. For example, to get all interfaces: ``` curl -k -u admin:password https://192.168.1.1/restconf/data/ietf-interfaces:interfaces ``` The response is JSON (or XML if you set Accept header). This returns only the interfaces data, not the entire config.
Compare transaction support
NETCONF supports the candidate datastore. You can edit the candidate, validate, and commit. If the commit fails, you can discard changes. RESTCONF does not have a candidate; each PUT/PATCH is applied directly to the running config. To simulate transactions, you can use YANG patch (RFC 8072) which allows multiple edits in one request, but it's not atomic. For exam: remember that NETCONF has candidate and confirmed commit; RESTCONF does not.
In a large enterprise, you might manage hundreds of routers and switches. Using CLI for each device is impractical. NETCONF and RESTCONF enable automation at scale.
Scenario 1: Bulk configuration change via NETCONF. A network engineer needs to add a new VLAN to all access switches. They write a Python script that connects to each switch via NETCONF, locks the candidate config, adds the VLAN, commits, and unlocks. If one switch fails, the script logs the error and continues. The script uses ncclient and iterates over a list of IPs. The benefit: atomic commit ensures that if a switch rejects the change (e.g., invalid VLAN ID), the config is not applied partially. Performance: each NETCONF session is a separate SSH connection; for 100 switches, the script can use threading to parallelize, but each session consumes device resources. Misconfiguration: forgetting to unlock the candidate can leave the device locked for other users.
Scenario 2: Monitoring with RESTCONF.
A NOC dashboard needs to display interface utilization every 30 seconds. The dashboard uses RESTCONF GET requests to fetch operational data like interfaces-state. RESTCONF is perfect here because it's stateless and lightweight. The dashboard sends a GET every 30 seconds for each device, parses the JSON, and updates graphs. No sessions to maintain. Scalability: RESTCONF can handle many short-lived requests, but too many requests can overwhelm the device's HTTP server. Misconfiguration: if HTTPS is not properly configured (e.g., self-signed certificates), clients may reject the connection.
Scenario 3: Orchestration with Cisco NSO. NSO uses NETCONF to communicate with network devices. It maintains a candidate config for the entire network. When an engineer makes a change in NSO, NSO pushes the config to devices via NETCONF. If a device fails to accept, NSO rolls back the entire change. This is only possible because NETCONF supports transactions. RESTCONF is used by NSO for northbound APIs (e.g., exposing device state to external systems).
Common pitfalls: using the wrong port, forgetting to enable the protocol, not verifying YANG model support, and assuming RESTCONF has transactions.
The 200-301 exam objective 6.6 is "Compare NETCONF and RESTCONF." This means you need to know the differences, not deep configuration. Expect multiple-choice questions that give a scenario and ask which protocol to use.
Common Wrong Answers and Why Candidates Choose Them:
"NETCONF uses HTTP, RESTCONF uses SSH." – Wrong. It's the opposite. Candidates confuse the two because both start with 'N' and 'R'. Remember: NETCONF = SSH (secure shell), RESTCONF = HTTP (web).
"RESTCONF supports candidate configuration." – Wrong. Only NETCONF supports candidate and commit. RESTCONF is stateless. Candidates assume RESTCONF has similar capabilities because it's newer.
"NETCONF uses JSON." – Wrong. NETCONF uses XML only. RESTCONF can use XML or JSON. Candidates see JSON everywhere and assume NETCONF supports it.
"Both use port 830." – Wrong. NETCONF uses 830; RESTCONF uses 443 (HTTPS) or 80 (HTTP).
Specific Values to Memorize: - NETCONF port: 830 (TCP) - RESTCONF port: 443 (TCP) for HTTPS, 80 for HTTP - NETCONF transport: SSH - RESTCONF transport: HTTP/HTTPS - NETCONF data format: XML - RESTCONF data format: XML or JSON - NETCONF operations: get, get-config, edit-config, copy-config, commit, lock, unlock, etc. - RESTCONF verbs: GET, POST, PUT, PATCH, DELETE
Decision Rule for Scenario Questions: If the scenario requires:
Transactional changes (commit/rollback) → NETCONF
Candidate configuration → NETCONF
Locking → NETCONF
Streaming telemetry or simple monitoring → RESTCONF
Integration with web applications → RESTCONF
Lightweight, stateless operations → RESTCONF
Both can be used for configuration, but NETCONF is more robust for changes.
Also be aware that Cisco supports both on IOS XE, but not all devices support both. For example, older IOS devices may not support NETCONF/RESTCONF at all.
NETCONF uses SSH (port 830) and XML only.
RESTCONF uses HTTP/HTTPS (port 443/80) and supports XML and JSON.
NETCONF is session-based and supports candidate config, commit, rollback, and locking.
RESTCONF is stateless and uses standard HTTP verbs (GET, POST, PUT, PATCH, DELETE).
Both use YANG as the data modeling language.
Cisco IOS XE enables NETCONF with 'netconf-yang' and RESTCONF with 'restconf'.
Show commands: 'show netconf-yang sessions', 'show restconf'.
For transactional changes, use NETCONF; for monitoring and simple API access, use RESTCONF.
These come up on the exam all the time. Here's how to tell them apart.
NETCONF
Transport: SSH (port 830)
Data format: XML only
Session-based (persistent connection)
Supports candidate config and commit
Defined RPCs (get, edit-config, etc.)
RESTCONF
Transport: HTTP/HTTPS (port 443/80)
Data format: XML or JSON
Stateless (each request independent)
No candidate config; direct writes
Uses HTTP verbs (GET, PUT, POST, DELETE)
Mistake
NETCONF uses JSON because it's modern.
Correct
NETCONF is defined in RFC 6241 and uses XML exclusively. RESTCONF (RFC 8040) supports JSON.
Candidates assume newer protocols use JSON, but NETCONF predates JSON's popularity in networking.
Mistake
RESTCONF uses SSH for security.
Correct
RESTCONF uses HTTPS (TLS) for security, not SSH. NETCONF uses SSH.
Both are secure, but candidates mix up the transport layers.
Mistake
NETCONF and RESTCONF are interchangeable for all tasks.
Correct
They have different strengths: NETCONF for transactional config, RESTCONF for stateless read/write.
Candidates think both do the same thing, but the exam tests their differences.
Mistake
RESTCONF supports candidate configuration via the 'candidate' query parameter.
Correct
RESTCONF does not support candidate configuration. Some implementations may have extensions, but it's not standard.
Candidates see 'candidate' in NETCONF and assume RESTCONF has it too.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
NETCONF uses SSH (port 830) and XML only. It is session-based and supports candidate config, commit, and rollback. RESTCONF uses HTTP/HTTPS (port 443/80) and supports XML or JSON. It is stateless and uses HTTP verbs. For the exam, remember: NETCONF is for transactional config, RESTCONF for lightweight API access. Tip: associate 'N' in NETCONF with 'SSH' (both have 'S'?) Actually, just memorize: NETCONF = SSH, RESTCONF = HTTP.
Yes, RESTCONF can be used to configure devices using PUT, POST, PATCH, and DELETE. However, it does not support transactions. Each request is applied directly to the running config. If you need atomic commits, use NETCONF. On the exam, if the question mentions 'commit' or 'rollback', choose NETCONF.
Cisco publishes YANG models for IOS XE, such as Cisco-IOS-XE-native (native model), ietf-interfaces, and ietf-routing. You can view them with 'show netconf-yang schemas list' or browse them via RESTCONF. For the exam, you don't need to memorize model names, but know that YANG is the data modeling language for both protocols.
Use the global configuration command 'netconf-yang'. Optionally, change the SSH port with 'netconf-yang ssh port <port>'. Then verify with 'show netconf-yang sessions'. On the exam, know the command and that it enables the NETCONF server.
RESTCONF uses HTTPS on port 443 by default, or HTTP on port 80 if you enable HTTP (not recommended). You can also configure a custom port with the 'ip http port' or 'ip http secure-port' commands. For the exam, remember 443 for RESTCONF and 830 for NETCONF.
No, RESTCONF does not support candidate configuration. That is a feature of NETCONF. RESTCONF writes directly to the running datastore. Some implementations may have extensions, but it's not standard. On the exam, if a question mentions 'candidate', the answer is NETCONF.
No, NETCONF only supports XML. RESTCONF supports both XML and JSON. If you need JSON, use RESTCONF. This is a common trick question on the exam.
You've just covered NETCONF and RESTCONF — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?