NETCONF vs RESTCONF vs gNMI: Pick the Right API - 夜莺博客

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

Feature NETCONF RESTCONF gNMI
Standard IETF RFC 6241 IETF RFC 8040 OpenConfig
Transport / port SSH / 830 HTTPS / 443 gRPC over HTTP/2 / 9339 (Cisco often 57400, Arista 6030)
Encoding XML JSON or XML Protocol Buffers (or JSON_IETF)
Session model Stateful Stateless Session-based
Candidate config + commit Yes No No
Datastore locking Yes No No
Streaming telemetry Limited (notifications) No Yes - Subscribe is the core strength
Operations get, get-config, edit-config, lock, commit, copy-config GET, POST, PUT, PATCH, DELETE Capabilities, Get, Set, Subscribe

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.

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.

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.

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

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.

Related articles: Prometheus SNMP exporter for network monitoring and SNMPv3 configuration on Cisco and Junos.

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