NETCONF vs RESTCONF vs gNMI: Pick the Right API

CLI scripting is brittle and SNMP cannot write configuration, which is why modern network devices expose model-driven management APIs. All of them are built on YANG data models, but the three dominant protocols - NETCONF, RESTCONF and gNMI - differ sharply in transport, capabilities and purpose. NETCONF is the mature, transactional configuration protocol; RESTCONF is its lightweight REST cousin; gNMI is the gRPC-era protocol built for streaming telemetry and high-rate configuration. Choosing the right one for an automation project means understanding those differences, and this guide gives you the comparison table and the enable commands for the major vendors.

The Three Protocols Side by Side

Read the table by column. NETCONF's superpower is the candidate datastore plus atomic commit; RESTCONF's is simplicity and HTTP reach; gNMI's is streaming. Almost every real decision falls out of which of those three properties your project actually needs.

NETCONF: Transactional Configuration

NETCONF sessions run over SSH with XML payloads. Its decisive features are the candidate datastore and commit workflow - you edit a copy of the config, validate it, and commit atomically - plus datastore locking so two automation systems cannot fight over the same device. That makes it the protocol of choice for infrastructure-as-code where a half-applied change is unacceptable.

A NETCONF session is a conversation of RPCs. You open the session, exchange <hello> messages that advertise YANG capabilities, then issue named operations. The lifecycle of a change looks like this: lock the candidate, edit-config the candidate in merge or replace mode, optionally validate, then commit, then unlock. If anything fails, you discard-changes and the running config is untouched - the device never saw a partial state. That is the property a REST API cannot give you, and it is why serious configuration pipelines still prefer NETCONF even in a JSON world.

RESTCONF: Web-Friendly and Stateless

RESTCONF maps YANG data to ordinary HTTP resources under a REST API, so any HTTP client - curl, Python requests, Postman - can read and write configuration with JSON. The trade-off: it is stateless, cannot lock datastores, and has no two-phase commit, so it suits read operations and simple, idempotent configuration changes rather than complex transactions.

What makes RESTCONF attractive is that it needs nothing exotic on the client. There is no session, no XML parser, no SSH library - just HTTPS and JSON, which every language and every CI runner already speaks. URL paths follow the YANG tree: a data node called interfaces inside ietf-interfaces under config is reachable at a path like /restconf/data/ietf-interfaces:interfaces. The cost is that a multi-step change is a sequence of independent HTTP calls with no rollback, so you must design idempotency and error handling yourself.

gNMI: Built for Telemetry

gNMI runs over gRPC with compact Protocol Buffers and defines only four RPCs: Capabilities, Get, Set and Subscribe. Its Subscribe RPC streams operational state to collectors in near-real time - dial-in (collector connects) or dial-out (device dials the collector, which survives firewalls). Modern telemetry stacks use gNMI precisely because polling thousands of switches with SNMP delivers stale data, while gNMI streams interface counters and state changes the moment they happen.

Four RPCs may sound thin, but each is powerful. Capabilities tells you which YANG models the device supports and which encodings it can use. Get reads a subtree once. Set writes with replace, update and delete semantics. Subscribe is the reason the protocol exists - it supports ON_CHANGE (send when the value changes), SAMPLE (send at a fixed interval) and TARGET_DEFINED modes, with the device pushing data as it is produced rather than waiting for a poll. Paths are expressed with the same YANG paths used elsewhere, so a subscription to /interfaces/interface/state/counters reads like the model it comes from.

Worked Examples: Reading the Same Data Three Ways

The clearest way to see the trade-offs is to read one thing - the interface list - with all three protocols.

# NETCONF: XML over SSH, session-based
<rpc message-id="1">
  <get>
    <filter type="subtree">
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
    </filter>
  </get>
</rpc>

# RESTCONF: one HTTP GET, JSON back
$ curl -k -u admin:pass -H "Accept: application/yang-data+json" \
    https://switch/restconf/data/ietf-interfaces:interfaces

# gNMI: gRPC Get with a YANG path
$ gnmic -a switch:57400 -u admin -p pass --insecure \
    get --path /interfaces/interface/state/counters

The NETCONF example is verbose and stateful, the RESTCONF example is a single familiar HTTP request, and the gNMI example is a one-line call that scales to a subscription by swapping get for subscribe. That progression captures the practical character of each protocol far better than any feature list.

Enabling the APIs on Common Platforms

! Cisco IOS XE
Router(config)# netconf-yang
Router(config)# restconf

! Cisco NX-OS
switch(config)# feature netconf
switch(config)# feature grpc

! Arista EOS
switch(config)# management api netconf
switch(config)# management api gnmi

! Junos
user@host# set system services netconf ssh
user@host# set system services restconf

Defaults matter when you enable these. NETCONF listens on TCP 830, but the SSH daemon it rides on may need its own trust configuration. RESTCONF usually needs an HTTPS server enabled (or uses the existing management web server) and typically requires a local user with the right privilege level and an accepted certificate - many first attempts fail on a self-signed certificate, which is why the curl example above uses -k. gNMI uses vendor-specific ports by default and, on some platforms, needs a dedicated gRPC user and TLS certificate provisioned separately from the SSH credentials.

YANG Models: The Common Foundation

All three protocols are model-driven, which is the point of the whole exercise. The device does not expose an arbitrary hierarchy; it exposes a schema, and the protocol is only a way to read and write that schema. Two model families dominate. Standard models - IETF models such as ietf-interfaces, ietf-routing and ietf-system, and OpenConfig models for routing, interfaces and telemetry - are portable across vendors. Native models mirror a vendor's own CLI and expose the features standard models do not cover.

Standard models are what make automation reusable: the same script can touch a Cisco, an Arista and a Juniper if they all implement ietf-interfaces. Native models are what you fall back to when a feature has no standard representation. The pragmatic strategy is to use standard models wherever they cover your need and isolate the unavoidable native paths into a small vendor-specific layer, so the bulk of your code stays portable.

Which One Should You Use?

• Transactional, multi-step config changes with rollback needs: NETCONF.
• Simple REST-style CRUD from scripts or CI/CD: RESTCONF.
• Streaming telemetry, high-rate state collection or OpenConfig-aligned greenfield: gNMI.

In practice you rarely pick just one. A common production pattern is NETCONF (or RESTCONF) for configuration and gNMI for telemetry, because the strengths that make each protocol good at its job are exactly the weaknesses of the other. Configuration wants atomicity and locking; telemetry wants streaming and low overhead. Pairing the right protocol with each job is the whole game.

Migrating from SNMP Polling to Model-Driven Telemetry

The most common real migration is replacing SNMP polling with gNMI streaming. SNMP is pull-based, so a fast-changing counter is sampled at whatever interval the poller can afford - by the time you see a microburst it is over, and the poller's own capacity limits how many devices you can add. gNMI inverts that: the device pushes changes as they occur, so you get higher fidelity at lower collector cost, and the same YANG paths you read once with Get become a streaming subscription without rewriting the data model layer.

Start the migration with a small, high-value set of leaf counters - interface errors, queue drops, CPU - and expand once the collector pipeline is stable. Keep the SNMP polling running during the transition so you can compare both feeds; once gNMI has proven itself, retire the polls. For export-based telemetry that predates gNMI, the comparison in sFlow vs NetFlow vs IPFIX explains where flow export still fits.

The Tooling You Will Actually Use

Each protocol has a mature client ecosystem, and knowing which tool to reach for saves a lot of grief. For NETCONF, ncclient in Python wraps the SSH session, capability exchange and RPC framing so you only build the XML payload; Ansible's netconf_* modules and vendor-specific modules use it underneath. For RESTCONF, any HTTP library works, so requests or curl plus a YANG-aware JSON payload is usually enough - there is nothing to install. For gNMI, gnmic is the workhorse: it can browse capabilities, run one-shot gets, and hold a subscription open, and pygnmi gives the same capability to Python scripts.

# NETCONF with ncclient
from ncclient import manager
m = manager.connect(host="sw1", port=830, username="admin",
                    password="pw", hostkey_verify=False)
print(m.get_config(source="running").xml)

# gNMI subscribe with gnmic
$ gnmic -a sw1:57400 --insecure subscribe \
    --path /interfaces/interface/state/counters --mode sample --sample-interval 10s

Model browsing matters as much as the client. Before you write a path, confirm the device actually implements the model you intend to use - ncs, yangsuite, or a simple Capabilities call against gNMI will tell you. Guessing a path from vendor documentation instead of confirming it against the device is the most common reason a first script fails with an "unknown element" error.

Intended State, Operational State and the NMDA Datastores

The NETCONF world formalised the split between what you configured and what the device is actually doing through the Network Management Datastore Architecture (NMDA). Instead of a single running datastore that mixes configuration and operational data, NMDA defines intended and operational datastores, and separates configuration-only from state-only subtrees within the same model.

This matters for automation more than it sounds. When you read a leaf that has a default applied but no explicit configuration, you want the operational value, not the absence of a configuration statement. When you want to detect configuration drift, you want the intended value. gNMI reflects the same philosophy with its convention of grouping state under a state container, which is why subscription paths so often end in /state/. Understanding the split stops the classic automation bug where a script reads a value it never set and concludes the device is broken.

Related articles

gNMI streaming telemetry: dial-in vs dial-out, NAPALM getters and config diff, Prometheus SNMP exporter for network monitoring and SNMPv3 configuration on Cisco and Junos.

原文链接：https://figigexams.com/learn/ccnp-encor-netconf-restconf-gnmi