gRPC, gNMI and Model-Driven Telemetry for Network Engineers

Introduction

Imagine you are responsible for monitoring five thousand switches across a large enterprise campus. Polling each device with SNMP every five minutes gives you stale data, missed events, and an overwhelmed management station. There is a better way. gRPC gNMI and model-driven telemetry replace legacy polling with a high-performance, streaming approach that delivers real-time operational data straight from the network device to your collector. Combined with YANG data models, these technologies form the backbone of modern network programmability on platforms such as IOS XE.

This article walks you through the complete picture: what gRPC and gNMI are, how model-driven telemetry works, the role of YANG models, the differences between dial-in and dial-out telemetry, gNOI operational microservices, gRPC tunnel architecture, and hands-on configuration examples you can use in your own lab. Whether you are preparing for a certification exam or building production automation, this guide gives you the depth you need.

What Are gRPC and gNMI?

Before diving into telemetry workflows, it is essential to understand the two protocols that make everything possible.

gRPC: The Messaging Framework

gRPC is a high-performance, open-source universal Remote Procedure Call (RPC) framework. It uses Protocol Buffers (protobuf) as its serialization mechanism. Protocol buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data. In the context of IOS XE, gRPC provides the messaging framework used to send protobuf-encoded data. The data is structured and serialized into a key-value pair string, often referred to as kvGPB (key-value pair Google Protocol Buffers).

gRPC runs over HTTP/2, which enables multiplexed streams, header compression, and bidirectional communication over a single TCP connection. This makes it significantly more efficient than older polling-based protocols.

gNMI: The Network Management Interface

gNMI stands for gRPC Network Management Interface. It is a specific API built on top of gRPC, designed for network device configuration and telemetry. While NETCONF and RESTCONF have been supported since IOS XE Release 16, continued investment brought full gNMI API support as part of IOS XE Release 17.

gNMI is fast becoming the preferred API for both configuration management and telemetry use cases. It supports standard operations including:

GET -- retrieve configuration or operational data
SET -- update, replace, or delete configuration
SUBSCRIBE -- stream telemetry data from the device
Capabilities (CAP) -- exchange and list all supported YANG modules

Pro Tip: gNMI natively uses Protocol Buffers, but it also supports JSON_IETF encoding. The PROTO encoding option uses a binary format for both path and value, increasing the efficiency of telemetry data transfer.

How Do gRPC gNMI Fit into the IOS XE Programmability Stack?

The NETCONF, RESTCONF, and gNMI interfaces are programmatic interfaces that provide additional methods for interacting with an IOS XE device. Just like the CLI, SNMP, and WebUI are used for configuration changes and operational metrics, so can these programmatic interfaces.

The key difference is that all three programmable interfaces use YANG data models to define the data available for configuration and streaming telemetry. This creates a unified, structured approach to device management across the entire lifecycle:

Lifecycle Phase	Purpose	Technologies
Day 0	Device Onboarding	Zero Touch Provisioning (ZTP), iPXE, Guest Shell + Python
Day 1	Device Configuration	NETCONF, RESTCONF, gNMI, Ansible, Terraform, YANG Suite
Day 2	Device Monitoring	Model-Driven Telemetry (gRPC Dial-Out, gNMI Dial-In), On-Change support
Day N	Device Optimization	gNOI (cert/os/reset proto), Software Image Management

Comparing the Three Programmatic Interfaces

The following table summarizes the differences between NETCONF, RESTCONF, and gNMI as configuration management interfaces:

Feature	NETCONF	RESTCONF	gNMI
Minimum IOS XE Version	16.6	16.7	16.8
Recommended Version	17.6	17.6	17.7
Default Port	830	443	9339
Operations	`<get>`, `<get-config>`, `<edit-config>`, `<establish-subscription>`	GET, POST, PUT, PATCH, DELETE	GET, SET, SUBSCRIBE
Encoding	XML	XML or JSON RFC7951	JSON_IETF + PROTO
Security	SSH + PKI certificate or password	HTTPS user/pass	TLS certificate with user authentication
Transport Protocol	SSH	HTTPS	HTTP/2
Content	YANG	YANG	YANG + Protobuf

API Operations Mapping

Understanding how the operations map across the three interfaces is critical for choosing the right tool:

Action	NETCONF	RESTCONF	gNMI
Read	`<get-config>`, `<get>`	GET	GET
Create	`<edit-config>` operation="create"	PUT, PATCH	SET = update
Update	`<edit-config>` operation="replace"	POST	SET = replace
Delete	`<edit-config>` operation="delete"	DELETE	SET = delete
Telemetry	`<establish-subscription>`	--	SUBSCRIBE

What Are YANG Models and Why Do They Matter for gRPC gNMI?

YANG data models are the API definitions for IOS XE, defined by RFC 7950. They describe the structure of configuration and operational data available on the device. There are 10 types of data models, including configuration, operational, actions, and deviations.

The YANG modules are available for download directly from the running IOS XE device's NETCONF, RESTCONF, or gNMI API. They are also published on GitHub for offline reference.

Key YANG Module Naming Conventions

Module Pattern	Description
`Cisco-IOS-XE-native`	Running configuration
`Cisco-IOS-XE-{feature}-cfg`	Feature configuration
`Cisco-IOS-XE-{feature}-oper`	Feature operational data
`Cisco-IOS-XE-{feature}-rpc`	Actions
`Cisco-IOS-XE-{feature}-events`	Telemetry events
`OpenConfig-{feature}`	Abstraction for config and oper

When working with gNMI, you reference YANG models using xpaths. For example, the interface operational data lives under Cisco-IOS-XE-interfaces-oper:interfaces/interface. Understanding these paths is essential for constructing GET, SET, and SUBSCRIBE requests.

Pro Tip: The Cisco-IOS-XE-mdt-capabilities-oper YANG model describes which xpaths support periodic and on-change subscriptions. Query this model to understand what telemetry data your device can stream.

Understanding Model-Driven Telemetry: Dial-In vs. Dial-Out

Model-driven telemetry (MDT) is the modern approach to network monitoring. Instead of a management station polling devices at intervals, the device itself streams structured data to a collector. There are two fundamental architectures for delivering this telemetry.

Dial-In Telemetry

With dial-in telemetry, the collector establishes a connection to the device and then subscribes to telemetry data. This follows a publication/subscription (pub/sub) model. The collector is the client, and the IOS XE device is the server.

Supported via gNMI SUBSCRIBE and NETCONF
Configuration is dynamic, per session
The collector decides what data it wants and how often

Dial-Out Telemetry

With dial-out telemetry, data is pushed from the device to the collector based on static configuration on the device. The IOS XE device is the client, and the collector is the server.

Supported via gRPC dial-out
Configuration is static, defined on the device
The device pushes data at configured intervals

Telemetry Interface Comparison

Feature	NETCONF	gRPC (Dial-Out)	gNMI
Minimum IOS XE Version	16.6	16.10	Dial-In: 16.12, gRPC Tunnel: 17.11
Recommended Version	17.9	17.9	Dial-In: 17.9, gRPC Tunnel: 17.11
Telemetry Direction	Dial-In (IOS XE is server)	Dial-Out (IOS XE is client)	Dial-In (IOS XE is server)
Configuration	Dynamic per session	Static per configuration	Dynamic per session
Encoding	XML	KV GPB	JSON_IETF + PROTO
Security	SSH + PKI certificate or password	mTLS or plain-text	mTLS cert only, or mTLS cert + user/pass
Transport	SSH	HTTP/2	HTTP/2

gNMI also supports dial-out architecture through the gRPC Tunnel feature, where the device initiates a connection to a remote tunnel server. This gives you the best of both worlds: the dynamic subscription flexibility of dial-in with the firewall-friendly outbound connection of dial-out.

How to Configure gRPC Dial-Out Model-Driven Telemetry

Configuring gRPC dial-out telemetry on IOS XE involves creating a telemetry subscription that defines what data to stream, how often, and where to send it. Here is an example that collects CPU utilization data:

configure terminal
telemetry ietf subscription 1
 encoding encode-kvgpb
 filter xpath /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization
 stream yang-push
 update-policy periodic 60000
 receiver ip address 10.1.1.3 57500 protocol grpc-tcp

Let us break down each component:

telemetry ietf subscription 1 -- creates a subscription with ID 1
encoding encode-kvgpb -- uses key-value pair Google Protocol Buffer encoding
filter xpath -- specifies the YANG xpath for the data to collect (CPU utilization in this case)
stream yang-push -- uses the YANG push stream mechanism
update-policy periodic 60000 -- sends data every 60,000 centiseconds (10 minutes)
receiver ip address 10.1.1.3 57500 protocol grpc-tcp -- sends data to the collector at 10.1.1.3 on port 57500 using gRPC over TCP

Periodic vs. On-Change Telemetry

Model-driven telemetry supports two publication modes:

Periodic: Time-based publication at a configured interval. The minimum interval is 100 centiseconds (1 second).
On-Change: Event-driven notifications triggered when monitored data changes. This is ideal for detecting state transitions such as interface flaps, failed logins, optic faults, and configuration modifications.

On-change support has expanded significantly over successive IOS XE releases. As of IOS XE 17.14, NETCONF, gRPC, and gNMI have xpath feature parity for on-change subscriptions. Supported on-change xpaths include:

Interface operational data
VLAN state
CDP neighbor details
Platform components and PSU state
Stacking operational data
PoE operational data
Transceiver operational data
TrustSec SGT maps and SXP connections
High availability state
DNS operational data
Boot integrity
App hosting operational data
Telemetry configuration and operational data

Pro Tip: OpenConfig models do not support on-change over NETCONF as of IOS XE 17.10+. If you need on-change with OpenConfig, use gNMI.

How to Configure gNMI on IOS XE

Enabling the gNMI API on IOS XE involves configuring the gNXI subsystem. The CLI commands were renamed from gnmi to gnxi starting in IOS XE 16.12 to reflect the consolidated gRPC-based microservices umbrella.

Enabling gNMI in Secure Mode

gnxi
gnxi secure-init
gnxi secure-password-auth
service internal
gnxi secure-allow-self-signed-trustpoint

This configuration:

Enables the gNXI subsystem
Initializes certificates with secure-init (run this once to create the trustpoint)
Enables username/password authentication over the secure API
Allows self-signed trustpoints (useful for lab environments but not recommended for production)

Enabling gNMI in Non-Secure Mode

gnxi
gnxi server

This starts the gNMI server without TLS. This is acceptable for testing in isolated lab environments but should never be used in production.

Creating a Read-Only User with NACM

For telemetry-only use cases, you can create a read-only user restricted by NACM (Network Access Control Model):

username ro privilege 1 secret 0 Lab@123

Then populate the NACM read-only rules:

request platform software yang-management nacm populate-read-rules privilege 1

This restricts privilege-1 users to read operations only, blocking create, update, delete, and exec operations. The NACM infrastructure was connected to gNMI in IOS XE 17.9.1.

Full Production gNMI Configuration

A production-ready gNMI configuration considers authentication, authorization, read-only restrictions, and gNOI control:

service internal
gnxi
gnxi secure-allow-self-signed-trustpoint
gnxi secure-password-auth
gnxi secure-init
gnxi secure-server

For a read-only telemetry deployment where gNOI should be disabled:

gnxi read-only
no gnxi enable-gnoi

The gnxi read-only command disables all gNMI SET operations at the broker level, independent of NACM policy. The no gnxi enable-gnoi command blocks all gNOI RPCs including certificate management, OS image management, and factory reset. Any gNOI RPCs attempted against a device with gNOI disabled will return a gRPC UNIMPLEMENTED error.

gNMI Best Practices

When deploying gNMI in production, consider these five areas:

Authentication -- Use TLS certificates for authentication rather than username/password alone
Login Authorization -- Integrate with upstream TACACS/RADIUS for centralized credential management
Model-Based Authorization -- Apply NACM policies to restrict operations based on user privilege
ACL Protection -- Protect the gNMI service with an IP access control list
Role Separation -- Use low-privilege read-only users for telemetry subscriptions and admin privilege-15 users for configuration management

gNMI Subscribe Operations and Encoding for Streaming Telemetry

The gNMI SUBSCRIBE operation is the primary mechanism for model-driven telemetry in dial-in mode. Understanding subscription construction is critical for building effective telemetry pipelines.

gNMI Operations Deep Dive

Each gNMI operation uses specific parameters:

Operation	Parameters	Purpose
CAP	--	Capabilities exchange, lists all supported YANG modules
GET	Prefix, Paths, Data Type (OPER, CONFIG, ALL)	Retrieve configuration or operational data
SET	Prefix, Paths, Type (Update, Replace, Delete)	Modify device configuration
SUBSCRIBE	Prefix, Path, Mode, Encoding	Stream telemetry data

The Prefix parameter is a shortcut when multiple paths share the same root. Paths define exactly what information is gathered.

Sample Subscription: Interface Operational Data

A gNMI subscribe request for interface operational data using periodic sampling looks like this:

{
  "subscribe": {
    "subscription": [
      {
        "path": {
          "origin": "rfc7951",
          "elem": [
            { "name": "Cisco-IOS-XE-interfaces-oper:interfaces" },
            { "name": "interface" }
          ]
        },
        "mode": "SAMPLE",
        "sampleInterval": "30000000000"
      }
    ],
    "encoding": "JSON_IETF"
  }
}

The sampleInterval is specified in nanoseconds. A value of 30000000000 equals 30 seconds. The mode of SAMPLE indicates periodic collection.

On-Change Subscriptions

Starting with IOS XE 17.14, gNMI on-change subscriptions support the same xpaths as NETCONF and gRPC. Previously, gNMI SUBSCRIBE only supported a very limited set of on-change models. You can query the Cisco-IOS-XE-mdt-capabilities-oper YANG model to determine which xpaths support on-change for your specific platform and software version.

PROTO Encoding

In addition to JSON_IETF encoding, IOS XE 17.11 introduced PROTO encoding support for gNMI periodic subscriptions. The PROTO encoding uses binary format for both path and value, increasing the efficiency of telemetry data transfer. With JSON_IETF, aggregated data is sent to the collector, while PROTO encoding provides more granularity in the transmitted data.

The sync_response Mechanism

When a collector subscribes to telemetry, the device begins streaming the requested data. The device sends a sync_response once all existing data for the subscription has been transmitted at least once. This provides an indication to the client that the initial data load is complete and subsequent updates represent changes or periodic refreshes. This feature was introduced in IOS XE 17.14.

The workflow is:

Build the subscribe request
Send the request to the device
Receive and decode responses
The device sends sync_response after all initial data has been delivered
Continue receiving periodic or on-change updates

What Is gNOI and How Does It Extend gRPC gNMI?

gNOI (gRPC Network Operations Interface) is a set of gRPC-based microservices used for executing operational commands on network devices. While gNMI handles configuration and telemetry, gNOI handles operational workflows such as certificate management, OS upgrades, and factory resets.

gNOI operations are executed against the gNMI API interface. gNOI is defined and implemented on a per-proto basis, with different protos maturing at different rates.

gNOI Proto Summary

Protobuf RPC	Use	Related CLI	IOS XE Release
cert.proto	TLS Certificate management	`crypto pki...`	17.3
os.proto	Network Operating System management	`install add file...`	17.5
reset.proto	Factory Reset and secure wipe	`write erase...`	17.7
file.proto	Not implemented on IOS XE	Use YANG copy, delete	N/A
system.proto	Not implemented on IOS XE	Use YANG reload, set boot	N/A

gNOI cert.proto -- Certificate Management

The certificate management service exports two main RPCs: Install and Rotate. These are used for installing new certificates and rotating existing certificates on a device. Supported operations include provision, install, rotate, revoke, get, and check.

This can be used instead of the traditional crypto pki CLI or the Cisco-IOS-XE-crypto-RPC.YANG model for programmatic certificate lifecycle management.

gNOI os.proto -- Operating System Management

The OS service provides an interface for software image management. The client progresses through three RPCs:

Installation -- provide the target device with the OS package
Activation -- activate an installed OS package
Verification -- verify the installed and activated version

You can check the status using:

show gnxi os summary

Pro Tip: Bundle mode installations will be automatically converted to install mode at reboot when using gNOI os.proto.

gNOI reset.proto -- Factory Reset

Factory reset via a single API call is used for RMA, re-provisioning, security, and ZTP workflows. The reset.proto supports the start RPC operation, which programmatically triggers a factory-reset all (or factory-reset switch all all for stacks).

Key considerations:

The device must be installed using install mode, not legacy bundle mode
The current operating system image files are preserved and used to boot the device after reset
An optional zero_fill flag securely writes zeros to the disks for security compliance
Zero fill is supported on C9300, C9400, C9500, C9500/H, and C9800 platforms

How Does gRPC Tunnel Work for Network Streaming Telemetry?

The gRPC Tunnel is an implementation of TCP-over-gRPC, similar to the commonly used SSH tunnel concept. It was introduced in IOS XE 17.9 and addresses a significant operational challenge: what happens when network devices have dynamic IP addresses or sit behind firewalls and NAT?

The Problem gRPC Tunnel Solves

Without gRPC tunnel, the gNMI client must connect directly into the IOS XE device's gNMI listening port. This requires the client to know the device's IP address and have network reachability to the device's management port. In environments with firewalls, NAT, or dynamic addressing, this is often impractical.

How gRPC Tunnel Works

With gRPC tunnel, the IOS XE device creates a secure outbound connection to a tunnel server. From there, the gNMI client connects into the device through the tunnel. The key architectural points are:

The device initiates the connection outward (firewall-friendly)
Many devices can connect into a single tunnel server, increasing operational efficiency
Tunnels can be opened to any number of servers -- the device is not limited to a single tunnel
gNMI Subscribe, GET, SET, and all gNOI operations can be sent within the tunnel
TLS and mTLS are supported for tunnel security

gRPC Tunnel Configuration

Here is a complete quick-start configuration for gRPC tunnel:

Step 1: Enable gNMI API on IOS XE (17.11+)

configure terminal
gnxi
gnxi secure-init
service internal
gnxi secure-allow-self-signed-trustpoint

Step 2: Configure and enable gRPC tunnel destination

gnxi grpc-tunnel dest ubuntuvm
 address 10.1.1.3
 port 4000
 source-vrf Mgmt-vrf
 enable
gnxi grpc-tunnel target GNMI_GNOI
 enable

The port number (4000 in this example) must match between the tunnel server configuration and the device's grpc-tunnel configuration. Update the IP address and VRF as needed for your environment.

Step 3: Verify the tunnel

show gnxi grpc tunnel destinations
show run | section gnxi

The tunnel server software recommended for testing and validation is gNMIc, which natively supports the gRPC tunnel server role.

Pro Tip: gRPC Dial-Out has seen wide adoption because of its dial-out architecture. gNMI Subscribe now also supports dial-out through the gRPC tunnel proto, giving you the dynamic subscription flexibility of gNMI with the outbound connection model that works through firewalls.

Evolution of gRPC gNMI Microservices on IOS XE

Understanding the release timeline helps you plan which features are available on your software version. The gRPC-based microservices on IOS XE have evolved significantly:

IOS XE Release	Feature Added
16.8	gRPC Dial-Out MDT (yang-push), gNMI Network Management
16.10	gNMI Subscribe, gNMI user/pass authentication, gRPC Dial-Out Telemetry
16.12	CLI renamed from `gnmi` to `gnxi`
17.2	gRPC Dial-Out + TLS
17.3	gNOI cert.proto, gNXI consolidated microservices
17.5	gNOI os.proto
17.7	gNOI reset.proto, IPv6 support, NACM, granular logging and counters
17.9	gRPC Tunnel
17.9.1	NACM infrastructure connected to gNMI
17.11	PROTO encoding for GET/SET, gRPC Tunnel support for gNMI Subscribe
17.12	PROTO encoding for Subscribe
17.13	Syslogs for gNMI RPCs and states
17.14	sync_response, on-change parity across NETCONF/gRPC/gNMI
17.15/17.12.4/17.9.6	`gnxi read-only` and `no gnxi enable-gnoi` enhancements
17.16	Show tech enhancements for gNMI details

Monitoring and Troubleshooting gNMI

Several show commands and logging features help you monitor and troubleshoot gNMI operations:

show gnxi state
show gnxi state detail
show gnxi state stats
show gnxi os summary
show gnxi os internal history
show gnxi grpc tunnel destinations
show tech-support yang-management

Starting in IOS XE 17.7, gNMI and gNOI maintain counters per RPC and message, viewable with show gnxi state stats. Starting in 17.13, syslog messages are generated for:

gNMI RPC received and completed (GET, SET, Subscribe)
Telemetry dial-out connection and disconnection from receiver
gRPC Tunnel connection to server
gRPC Tunnel target registration
gNOI Certificate Management and OS Install events

For deeper debugging, use the trace mechanism:

set platform software trace gnmi switch active r0

Available trace components include gnmi, gnmib-cert, gnmib-grpc, gnmib-infra, gnmib-os, gnmib-reset, and gnxi.

Using YANG Suite for gNMI Testing and Validation

YANG Suite is a YANG API testing and validation environment that lets you construct and test YANG-based API calls over NETCONF, RESTCONF, gRPC, and gNMI. It supports IOS XE, IOS XR, and NX-OS platforms and runs as a Docker container.

The YANG Suite gNMI plugin provides a fully functional gNMI client that helps build, test, and validate gNMI YANG payloads. It supports Capabilities, GET, SET, and Subscribe RPCs with JSON, JSON_IETF, and PROTO encoding.

What You Can Do with YANG Suite's gNMI Plugin

gNMI GET for native hostname using Cisco-IOS-XE-native:native
gNMI SET to change hostname
gNMI GET for OpenConfig hostname using openconfig:system/config
gNMI GET for IETF interfaces
gNMI Subscribe to native interface operational data
gNMI Subscribe to OpenConfig interface data

YANG Suite also supports certificate authentication for secure gNMI connections, Ansible integration for generating playbooks from YANG payloads, and gRPC telemetry with TLS support.

Example: gNMI SET for Hostname

A gNMI SET payload to change the hostname using the native YANG model:

{
  "update": [
    {
      "path": {
        "origin": "rfc7951",
        "elem": [
          { "name": "Cisco-IOS-XE-native:native" }
        ]
      },
      "val": {
        "jsonIetfVal": {
          "hostname": "lab-switch-01"
        }
      }
    }
  ]
}

The same operation using the OpenConfig model:

{
  "update": [
    {
      "path": {
        "origin": "openconfig",
        "elem": [
          { "name": "system" },
          { "name": "config" }
        ]
      },
      "val": {
        "jsonIetfVal": {
          "hostname": "lab-switch-01"
        }
      }
    }
  ]
}

Notice how the native model uses a flat path (Cisco-IOS-XE-native:native) while the OpenConfig model uses a hierarchical path (system/config). Both achieve the same result but use different data model structures.

Zero Touch Provisioning with gNMI Bootstrapping

An often-overlooked capability is bootstrapping gNMI as part of the Day 0 Zero Touch Provisioning (ZTP) workflow. When an IOS XE device boots without configuration, it issues a DHCP request on both the management port and front panel ports. If the DHCP response contains option 67 with a Python script path, ZTP is initiated.

The device starts Guest Shell -- an embedded CentOS 8 container with fault and resource isolation, a secure Linux shell environment, Python interpreter, pip, and Bash. Guest Shell provides Python API and NETCONF API access into IOS XE.

ZTP Workflow

Device powers on and checks for existing configuration
If no configuration is present, ZTP starts on management and front panel ports
Device sends DHCP request on all Layer 3 interfaces
If DHCP option 67 is present, the device fetches and executes the Python script
Guest Shell is started and the script runs
After ZTP completes, Guest Shell is automatically unconfigured

Python API Modules for ZTP

Three Python modules provide the API between Guest Shell and the IOS XE device:

cli.cli(command) -- runs an IOS command through the parser and returns the text
cli.execute(command) -- executes a single EXEC command and returns the output without printing
cli.configure(command) -- configures the device and returns a list of named tuples with command and result

Each function also has a p variant (cli.clip, cli.executep, cli.configurep) that prints the output to stdout rather than returning it.

Enabling gNMI via ZTP

You can enable gNMI as part of ZTP using the Python API. The following sequence enables both secure and non-secure gNMI, creates certificates, enables user/password authentication, creates a read-only user, and applies NACM rules:

cli.configurep(["gnxi", "gnxi secure-init", "gnxi secure-password-auth", "service internal", "gnxi secure-allow-self-signed-trustpoint", "end"])
cli.configurep(["gnxi", "gnxi server", "end"])
cli.configurep(["username ro privilege 1 secret 0 Lab@123"])

Then enable the read-only RBAC/NACM rules for privilege 1 users:

request platform software yang-management nacm populate-read-rules privilege 1

The NETCONF interface is also accessible from within Guest Shell at Day 0, requiring no interface configuration or IP connectivity. The ncclient Python library can connect to the NETCONF interface for programmatic configuration using either CLI or YANG.

Frequently Asked Questions

What is the difference between gRPC and gNMI?

gRPC is a general-purpose, high-performance RPC framework that provides the underlying messaging transport. gNMI is a specific network management interface built on top of gRPC, designed specifically for network device configuration management and telemetry. Think of gRPC as the highway and gNMI as the specific vehicle designed to travel on it for network management purposes. On IOS XE, the consolidated suite of gRPC-based microservices -- including gNMI, gNOI, and gRPC Tunnel -- is referred to as gNXI.

When should I use dial-in vs. dial-out telemetry?

Use dial-out (gRPC) when you want static, always-on telemetry configured on the device that pushes data regardless of collector state. Use dial-in (gNMI Subscribe or NETCONF) when you want dynamic, on-demand subscriptions controlled by the collector. If your devices are behind firewalls or have dynamic IPs, consider gRPC Tunnel (available from IOS XE 17.11) which combines dial-in flexibility with outbound connection establishment.

What IOS XE version do I need for gNMI?

The minimum version for basic gNMI is IOS XE 16.8, and the recommended version is 17.7 or later. For gRPC Tunnel support, you need 17.11 or later. For on-change subscription parity with NETCONF and gRPC, you need 17.14 or later. For PROTO encoding on subscriptions, you need 17.12 or later. For the gnxi read-only and no gnxi enable-gnoi security enhancements, you need 17.15, 17.12.4, or 17.9.6.

How do I verify gNMI is working on my device?

Use the show gnxi state and show gnxi state detail commands to check the status of gNMI services, ports, and certificate configuration. Use show gnxi state stats (available from 17.7) to view RPC counters. For gRPC Tunnel, use show gnxi grpc tunnel destinations. For OS management operations, use show gnxi os summary and show gnxi os internal history.

Can I restrict gNMI users to read-only access?

Yes. There are two mechanisms. First, use NACM (Network Access Control Model) by creating a privilege-1 user and populating read-only rules with request platform software yang-management nacm populate-read-rules privilege 1. This blocks create, update, delete, and exec operations while allowing read. Second, use the gnxi read-only command (available from 17.15/17.12.4/17.9.6) to disable all gNMI SET operations at the broker level, independent of NACM policy.

What encoding should I use for telemetry -- JSON_IETF or PROTO?

JSON_IETF is human-readable and easier to debug, making it ideal for development and testing. PROTO (binary Protocol Buffer encoding) is more efficient for data transfer and provides more granularity in transmitted data, making it better for production deployments with high telemetry volumes. Both Telegraf and YANG Suite support PROTO encoding. PROTO encoding for gNMI subscriptions requires IOS XE 17.12 or later.

Conclusion

gRPC, gNMI, and model-driven telemetry represent a fundamental shift in how network engineers monitor and manage infrastructure. By replacing SNMP polling with streaming telemetry, you gain real-time visibility into device state with lower overhead and richer data. The gNMI API unifies configuration management and telemetry into a single interface, while gNOI extends the framework to operational tasks like certificate management, OS upgrades, and factory resets. The gRPC Tunnel capability closes the architectural gap for devices behind firewalls or with dynamic addressing.

The key takeaways from this guide are:

gNMI provides GET, SET, and SUBSCRIBE operations over gRPC with YANG model-based data
Model-driven telemetry supports both periodic and on-change streaming with dial-in, dial-out, and gRPC Tunnel architectures
YANG data models define all available configuration and operational data
gNOI microservices handle certificate, OS, and factory reset operations programmatically
NACM and read-only modes provide granular access control for production deployments
ZTP integration allows gNMI to be bootstrapped automatically on Day 0

Mastering these technologies is essential for any network engineer working toward advanced certifications or building production automation. Explore the courses available at NHPREP to deepen your hands-on skills with network programmability, automation, and telemetry.