Back to Blog

gNMI vs NETCONF: Differences, Trade-offs and When to Use Each

Published

  • gnmi vs netconf
  • netconf vs gnmi
gNMI vs NETCONF: Differences, Trade-offs and When to Use Each

Use NETCONF when you need transactional configuration changes with candidate datastores, commit and rollback. Use gNMI when you need efficient, streaming telemetry and fast reads and writes from modern devices. Many teams run both, because both work with YANG models and most current platforms expose them side by side.

This guide compares the two protocols on the points that decide real projects: transactions, telemetry, encoding, transport, device support and security.

TL;DR

  • NETCONF is an IETF, XML-based RPC protocol over SSH. Its strength is transactional configuration: candidate datastore, commit, confirmed commit and rollback.
  • gNMI is an OpenConfig protocol that runs on gRPC over HTTP/2 with protobuf payloads. Its strength is streaming telemetry through the Subscribe RPC.
  • Both use YANG models, so the same data model can often be reached through either interface.
  • NETCONF is the more mature interface on many platforms. gNMI arrived later on some, for example from IOS XE 17.6 on Catalyst 9800 controllers.
  • A common pattern: NETCONF for critical configuration changes, gNMI for telemetry.

Table of Contents

gNMI vs NETCONF at a glance

Criterion NETCONF gNMI
Standards body IETF OpenConfig working group
Transport SSH (typically TCP port 830) or TLS gRPC over HTTP/2, usually with TLS
Encoding XML Protobuf messages, with JSON payload variants
Config model Datastores (running, startup, candidate), commit and rollback Set RPC with delete, replace and update in one transaction
Telemetry Get and get-config with filtering; polling Subscribe RPC: ONCE, POLL and STREAM
Data models YANG YANG (OpenConfig schemas are the usual payload)
Typical strength Safe, transactional configuration Efficient streaming of state

The sections below explain each row, with sources.

What NETCONF and gNMI are

NETCONF is an IETF protocol that uses XML-based RPCs over SSH to install, manipulate and delete network-device configuration. Cisco's Catalyst 9800 programmability guide describes it this way, and notes that YANG models define the data reachable over NETCONF, RESTCONF and gNMI.

gNMI, the gRPC Network Management Interface, was created by the OpenConfig working group. It moves configuration and state data to and from network devices. The gNMI service definition can cover both configuration and telemetry, so one target implementation and one management system can handle both through the same interface, as Claise, Clarke and Lindblad explain.

The question "what is gNMI vs gRPC" has a short answer: gNMI is the management protocol, and gRPC is the RPC framework it runs on.

How each handles configuration changes

NETCONF: datastores, commit and rollback

NETCONF works with datastores. On NX-OS, Cisco documents three: running, startup and candidate. Supported operations include get, get-config, edit-config, commit, cancel-commit, discard-changes, lock, unlock and validate.

The commit behavior matters in production. On NX-OS, a commit without parameters is final and cannot be reverted. A confirmed commit with a timeout (default 600 seconds) is finalized only if a confirming commit arrives before the timeout expires. That gives you a built-in safety net when a change might cut off your own management path.

The authors of the InformIT chapter describe NETCONF's transaction model as a major advantage over SNMP, using the ACID test: atomicity (all or nothing), consistency (all at once with respect to YANG rules), independence (no cross-talk between clients) and durability (the change survives a power outage or crash).

NETCONF: datastores, commit and rollback

gNMI: one Set, applied as a transaction

gNMI changes configuration with the Set RPC. Under the OpenConfig gNMI specification, a SetRequest can contain delete, replace and update fields. They are processed in that order as a transaction that is either fully applied or rolled back.

The model is simpler than NETCONF's: no candidate datastore, no confirmed commit, no explicit locking in the request itself. For a script that pushes a defined set of changes to many devices, that simplicity is an advantage. For a change that needs a staged review and a timed confirmation, NETCONF gives you more tools.

Atomicity is also a vendor matter. Arista states that on EOS, all client transactions that modify configuration provide the same atomicity guarantees as CLI sessions, across gNMI, RESTCONF and NETCONF.

How each handles operational state and telemetry

NETCONF reads state with get and get-config, filtering on the client's request. That works well for on-demand queries and for modest polling. It was not designed around a continuous firehose of counters.

gNMI was. Its Get RPC retrieves data once, and its Subscribe RPC supports three modes, per the gNMI specification:

  • ONCE: a single request and response.
  • POLL: periodic, on-demand retrieval over a long-lived RPC.
  • STREAM: a long-lived subscription, with ON_CHANGE or SAMPLE sub-modes.

In STREAM mode, ON_CHANGE sends an update only when a value changes. SAMPLE sends at a set interval, given in nanoseconds, and the target must reject the subscription if it cannot support that interval, according to the DevNet Academy gNMI documentation.

gNMI also distinguishes three data types: CONFIG (read/write data corresponding to "config true" YANG leaves), STATE (read-only, "config false" leaves) and OPERATIONAL (read-only data tied to software processes or external interactions on the device).

The Subscribe RPC is bidirectional streaming. OpenConfig's reference documentation says that makes it a key enabler of near real-time configuration management and of handling configuration drift, because the management system stays in sync with the device instead of polling for changes.

For teams that watch performance data across many sites, this is the practical difference. Streaming gives you fresher data with less polling overhead. If you are also deciding how to separate real degradation from noise, our guide to passive telemetry and probes for QoS monitoring covers that side of the problem.

Encoding and transport

Per the InformIT comparison:

  • NETCONF uses XML encoding over SSH/TCP/IP.
  • RESTCONF uses JSON or XML over HTTP/TLS/TCP/IP.
  • gNMI uses notifications with JSON (two variants) or protobuf payloads over HTTP/2/TLS/TCP/IP.

AWS notes that gNMI data is generally smaller than NETCONF data because protobuf is more compact than XML, which can mean faster server responses. At scale, with thousands of subscriptions, payload size adds up.

There is an operational cost on the gNMI side. With protobuf transport, you must also distribute .proto files in addition to the YANG schema, which adds complexity when devices are upgraded at different times. With NETCONF and RESTCONF, the YANG schema alone is enough to understand the payload.

Same YANG, different doors

YANG is the common layer. OpenConfig is a YANG model ecosystem driven by network operators, defined primarily by a working group without vendor representation, which makes the models usable across vendors. The same Cisco white paper points out that many operators who consume OpenConfig YANG prefer gNMI, but because YANG models are advertised for NETCONF, RESTCONF and gRPC dial-out alike, OpenConfig models can be used across all three.

So the choice is rarely about the data model. It is about how you want to move the data.

Maturity and device support

Check your platform and software release before you pick. The Catalyst 9800 deployment guide is a good example:

Platform NETCONF gNMI
Catalyst 9800-CL, 9800-40, 9800-80 IOS XE 16.10 and later IOS XE 17.6 and later
Catalyst 9800-L IOS XE 16.12 and later IOS XE 17.6 and later

Cisco describes NETCONF as the most mature of its programmatic interfaces, standards based and with a long record of feature work since as early as IOS XE 16.6.

The IETF NEMO working group paper adds two cautions worth planning around:

  • NETCONF: some scenarios are not clearly specified, which raises implementation cost and the risk of incompatible implementations. Support for the shared candidate datastore, confirmed commit and XPath-based filtering is patchy across implementations.
  • gNMI: the specifications tend to be less precisely defined than equivalent IETF protocols and receive less technical review, so interoperability issues between implementations are more likely. A conformance test suite is in progress.

Source for both: the IETF NEMO paper on device network management. The practical takeaway: test the specific operations you depend on, on each platform and release in your fleet, before building automation around them.

Security considerations

Both protocols are encrypted by design, but the details differ.

  • NETCONF servers typically listen on TCP port 830 for SSH, or use TLS per RFC 7589.
  • gNMI commonly runs over TCP with gRPC, often with TLS. Streaming subscriptions are long-lived and bandwidth-efficient, but the control channel stays sensitive to spoofed resets, according to an IETF draft on TCP-AO for NETCONF and gNMI.

On IOS XE, Cisco's model-driven telemetry white paper lists mutual TLS for gRPC dial-out and RBAC or NACM for dial-in as the security controls to configure.

Whatever protocol you choose, restrict who can reach the management port, use role-based access on the device, and log changes. Teams with operations in the EU also track the NIS 2 requirements that apply to network and information security, which affect how management access is controlled and documented.

When to use gNMI, NETCONF or both

AWS summarizes the split: NETCONF is more suitable for critical network management systems with advanced safety requirements, while gNMI suits simple, real-time telemetry streaming from modern devices.

In practice:

  1. Choose NETCONF when changes must be staged, validated, confirmed with a timeout or rolled back, and when your devices have mature NETCONF support. Optical transport is an extreme case: a half-applied configuration can leave a ROADM cross-connect partially provisioned, which is why MapYourTech argues that NETCONF atomicity there is a physical safety mechanism.
  2. Choose gNMI when your priority is high-frequency state, counters and ON_CHANGE events across many devices, and your platforms support the OpenConfig paths you need.
  3. Use both when you want transactional changes and streaming visibility. Since the same YANG models sit behind both, this is a normal design, not a compromise.

A quick decision test:

  • Do you need a confirmed commit or candidate datastore? NETCONF.
  • Do you need sub-minute streaming of interface or optical counters at scale? gNMI.
  • Are your devices on older releases? Check NETCONF first, since it arrived earlier on many platforms.
  • Are you multi-vendor? Test OpenConfig path coverage per vendor before committing.

Where RESTCONF fits

RESTCONF, defined in RFC 8040, is an HTTP-based protocol for configuring YANG-defined data using NETCONF's datastore concepts. It does not replace NETCONF. It offers an HTTP interface following REST principles, implementing a subset of NETCONF capabilities without datastores and explicit locking, with HTTP verbs and single-shot transactions (InformIT). If you are weighing it against NETCONF, read our comparison of NETCONF vs RESTCONF.

Our perspective

Protocol debates matter less than what happens after the data leaves the device. Most teams we talk to do not have a shortage of interfaces. They have a shortage of context: telemetry in one tool, documentation in another, tickets in a third.

Netverge is built to unify those pieces. Monitoring, documentation, ticketing and automation sit in one AI-powered platform, with a knowledge graph that connects devices, sites and clients. Our autonomous AI agents are designed to diagnose and act on issues using that context, and our Vergepoints give you on-site visibility that does not depend on what a single device exposes.

Our advice for network teams: pick the right interface for each job, NETCONF for controlled change and gNMI for streaming state, then make sure the output lands in a place where your team can correlate it, triage it and resolve it fast. That is the problem we solve for MSPs and multi-location enterprises.

Jim

See it working across your sites

Netverge brings real-time monitoring, anomaly detection, AI ticket triage and network documentation into one platform for MSPs and multi-site IT teams. The Starter Package is $299 per month. Hardware Vergepoints are $49 per month per device, and Software Vergepoints are $29 per month per Vergepoint. See the pricing page for the full plan, or explore AI-powered network monitoring.

Netverge

Ready to try it? Start a free trial or request a demo from netverge.com. To see how automation fits an MSP workflow, read our seven steps to network operations automation.

FAQ

Is gNMI replacing NETCONF?

Not on current evidence. Both are supported side by side on platforms such as Cisco IOS XE and Arista EOS, and both can serve the same YANG models. Most teams pick per use case: NETCONF for transactional change, gNMI for streaming telemetry.

Is gNMI faster than NETCONF?

Often for data retrieval. gNMI uses protobuf over HTTP/2, and AWS notes that its data is generally smaller than NETCONF's XML, which can speed up responses. Actual performance depends on the device implementation and the data you request.

What is the difference between gNMI and gRPC?

gRPC is the general RPC framework. gNMI is a network management protocol defined on top of it, with specific RPCs such as Get, Set and Subscribe for configuration and telemetry.

Does gNMI use YANG?

Yes. The gNMI specification assumes payloads carry data instances of OpenConfig YANG schemas, though it can carry other data with the specified characteristics. NETCONF uses YANG too.

Can I use NETCONF and gNMI on the same device?

Yes, on platforms that support both. Check the minimum software release for each. On Catalyst 9800 controllers, for example, gNMI starts at IOS XE 17.6, later than NETCONF.

Sources

Recommended