What is gNMI and how is it different?

gNMI is the gRPC Network Management Interface, from the OpenConfig project rather than the IETF. It carries Protocol Buffers over gRPC on HTTP/2 and defines four RPCs: Capabilities, Get, Set and Subscribe. Subscribe is what sets it apart - it is the mechanism behind streaming model-driven telemetry, where the device pushes updates as they happen instead of a collector polling for them.

Do NETCONF, RESTCONF and gNMI all use YANG?

Yes. YANG is the modelling language that describes the data; all three are just different ways to reach that data. The same interface described by a YANG model can be read through NETCONF as XML, through RESTCONF as JSON, or through gNMI as protobuf. If you understand this separation, most exam questions on the topic resolve themselves.

NETCONF vs RESTCONF vs gNMI: What's the Difference?

Q: What is the difference between NETCONF and RESTCONF?

NETCONF runs over SSH on TCP port 830 and exchanges XML inside RPC messages. RESTCONF runs over HTTPS on TCP port 443 and uses ordinary HTTP verbs with JSON or XML. The deeper difference is capability: NETCONF is session-based and supports datastore locking, a candidate datastore, and commit or discard of a whole change set. RESTCONF is stateless and exposes only a subset of NETCONF - each request stands alone, with no locking and no multi-message transaction.

Q: What port does NETCONF use?

TCP port 830 over SSH. RESTCONF uses TCP port 443 over HTTPS. gNMI uses gRPC over HTTP/2, with 9339 registered with IANA, though Cisco platforms commonly expose it on 57400.

Q: Is gNMI on the CCNP ENCOR exam?

The 350-401 blueprint names NETCONF and RESTCONF explicitly and covers model-driven telemetry as a concept. gNMI is not called out by name in the same way, but it is the protocol that streaming telemetry actually runs on, so understanding it is what makes the telemetry objectives make sense rather than being memorised.

By Moussa BENALI, Senior Network & Security Engineer · CCNP ENCOR 350-401 · Domain 6.0 Automation (~15%)

The short answer: all three do the same job - read and change configuration described by a YANG model - and they differ in how they get there. NETCONF uses SSH on port 830 with XML and can lock and commit a whole change set. RESTCONF uses HTTPS on port 443 with JSON or XML and ordinary HTTP verbs, but is stateless and cannot lock. gNMI uses gRPC over HTTP/2 with Protocol Buffers, and is the one that streams telemetry.

💡

The idea that makes the rest easy: YANG is the model, not a protocol. It describes what data exists and how it is structured. NETCONF, RESTCONF and gNMI are three transports for reaching that same data. The same interface configuration can be read as XML through NETCONF, as JSON through RESTCONF, or as protobuf through gNMI - the model underneath is identical. Once that separation is clear, most exam questions on this topic answer themselves.

Your free ENCOR exam code

Automation is ~15% of the exam. Where are you actually losing marks?

A full-length ENCOR 350-401 practice exam on the v1.2 blueprint, with an explanation on every item and a coach that names the domains costing you marks. Create an account on the next screen and the code applies itself.

CCNP-EXAM-FULL Take the free exam

Already have an account? Log in to start · Or keep reading - there are 5 free practice questions at the end.

Side by side

	NETCONF	RESTCONF	gNMI
Defined by	IETF, RFC 6241	IETF, RFC 8040	OpenConfig (not IETF)
Transport	SSH	HTTPS	gRPC over HTTP/2
Port	830	443	9339 (IANA); often 57400 on Cisco
Encoding	XML only	JSON or XML	Protocol Buffers (binary)
Operations	RPCs: `get`, `get-config`, `edit-config`, `lock`, `commit`…	HTTP verbs: GET, POST, PUT, PATCH, DELETE	4 RPCs: Capabilities, Get, Set, Subscribe
Session model	Session-based (stateful)	Stateless	Session-based
Datastore locking	✅ Yes	❌ No	❌ No
Candidate datastore + commit	✅ Yes	❌ No	❌ No
Streaming telemetry	Limited (notifications)	❌ No	✅ Yes - this is the point
Data model	YANG - all three

NETCONF: the one that can hold a lock

NETCONF is the oldest of the three and the most capable when it comes to making changes safely. It opens an SSH session to port 830 and exchanges XML documents wrapped in RPC messages.

What makes it different is the datastore model. A device can expose running (the live config), candidate (a scratch copy) and startup. With a candidate datastore you can:

lock the datastore so nobody else edits underneath you,
send several edit-config operations building up a change,
commit them as a single unit - or discard-changes and walk away,
unlock.

That is a transaction. If step 2 fails halfway through, nothing has been applied to the running configuration. This is the capability that keeps NETCONF relevant even though RESTCONF is easier to work with.

RESTCONF: the same data, over ordinary HTTP

RESTCONF exposes YANG-modelled data as a REST API over HTTPS on port 443. Instead of RPCs you use HTTP verbs against a URL that mirrors the model's structure, and you can ask for JSON instead of XML - which is why it is far more pleasant to script against.

The trade is capability. RESTCONF implements a subset of NETCONF and it is stateless: every request stands on its own. That means no locking and no candidate datastore. You are editing the running configuration directly, one request at a time. If two people PATCH the same interface at the same moment, nothing protects you.

⚠️

The distinction the exam leans on: if a question involves reserving the configuration so nobody else can change it mid-edit, or applying several changes together as one unit that can be rolled back, the answer is NETCONF. RESTCONF simply cannot do it. Everything else about the two is largely a matter of taste and tooling.

gNMI: the one built for telemetry

gNMI comes from OpenConfig rather than the IETF, and it is a different shape. It runs gRPC over HTTP/2 and encodes with Protocol Buffers - a binary format, so payloads are far smaller than XML or JSON. It defines only four RPCs:

Capabilities - what models and encodings does this device support?
Get - read state or config, once.
Set - change config (update, replace, delete).
Subscribe - the reason gNMI exists.

Subscribe is streaming telemetry. Rather than a collector asking "what is the interface counter now?" every thirty seconds, the device pushes updates over a long-lived connection. Subscriptions come in three modes - ONCE, POLL and STREAM - and a STREAM subscription can be SAMPLE (every n milliseconds) or ON_CHANGE (only when the value actually moves).

That is the whole argument for model-driven telemetry over SNMP polling. Polling is a fixed cost whether anything changed or not, it scales badly across thousands of devices, and it always shows you a slightly stale picture. ON_CHANGE streaming sends data only when there is something to say.

📡

Dial-in versus dial-out. A useful distinction that shows up in telemetry questions. Dial-in: the collector initiates the connection and subscribes - that is gNMI Subscribe. Dial-out: the device is configured with the collector's address and initiates the session itself. Dial-in is easier to manage centrally; dial-out survives a collector that cannot reach the device through a firewall.

Which one would you actually use?

In practice, and this is worth knowing because it makes the exam answers feel less arbitrary:

Changing configuration safely across many devices - NETCONF, for locking and commit. Most vendor automation tooling still leans on it.
Quick scripted reads or simple changes - RESTCONF. A curl command and a JSON response is hard to beat for a one-off.
Monitoring at scale - gNMI Subscribe. Nobody builds a modern telemetry pipeline on SNMP polling by choice.

What ENCOR actually asks

Being straight about scope: the 350-401 v1.2 blueprint names NETCONF and RESTCONF explicitly and covers model-driven telemetry as a concept. gNMI is not called out by name the way the other two are. It is worth learning anyway, because telemetry objectives stop being memorisation once you know what is carrying the stream.

The distinctions that reliably turn into questions:

Port 830 (NETCONF, SSH) versus 443 (RESTCONF, HTTPS).
XML only versus JSON or XML.
RESTCONF cannot lock and has no candidate datastore.
All three consume YANG models - YANG is not a protocol.
Streaming telemetry means push, not poll, and gNMI Subscribe is the mechanism.

Practice questions (5 free)

Same style as the full ENCOR exam - an explanation on every option, not just the right one.

Your free ENCOR exam code

Five questions is a taster. A full exam is a diagnosis.

Automation is only one of six domains. A complete ENCOR practice exam shows you which of them are actually costing you marks - then the pack adds the rest, as a one-time purchase with lifetime access rather than an annual licence.

CCNP-EXAM-FULL Take the free ENCOR exam

Already have an account? Log in to start

Frequently asked questions

What is the difference between NETCONF and RESTCONF?

Transport and capability. NETCONF is SSH on port 830 with XML; RESTCONF is HTTPS on port 443 with JSON or XML and standard HTTP verbs. More importantly, NETCONF is session-based and supports datastore locking, a candidate datastore and commit or discard of a whole change set. RESTCONF is stateless - each request stands alone, with no locking and no transaction.

What port does NETCONF use?

TCP 830 over SSH. RESTCONF uses TCP 443 over HTTPS. gNMI runs gRPC over HTTP/2 - 9339 is registered with IANA, though Cisco platforms commonly expose it on 57400.

Can RESTCONF lock the configuration?

No. Locking and the candidate datastore are NETCONF features. RESTCONF edits the running datastore directly, one stateless request at a time. Any question about reserving the config or committing several changes as one unit points to NETCONF.

Do all three use YANG?

Yes, and this is the point most explanations bury. YANG is the modelling language describing the data; the three protocols are different ways to reach it. The same interface can be read as XML over NETCONF, JSON over RESTCONF, or protobuf over gNMI.

Is gNMI on the CCNP ENCOR exam?

The blueprint names NETCONF and RESTCONF explicitly and covers model-driven telemetry as a concept; gNMI is not called out by name in the same way. Learn it anyway - it is what telemetry actually runs on, and knowing that turns the telemetry objectives from memorisation into understanding.

Why is streaming telemetry better than SNMP polling?

Polling costs the same whether anything changed or not, scales badly across thousands of devices, and always shows a slightly stale picture bounded by the poll interval. A gNMI ON_CHANGE subscription sends data only when a value actually moves, so you get fresher data and less load at the same time.