Glossary

gNMI

gRPC Network Management Interface

What is gNMI

gNMI (gRPC Network Management Interface) is an open-source management protocol built on top of gRPC, published and maintained by OpenConfig, for querying state, modifying configuration, and streaming telemetry from network devices. gRPC itself is Google's high-performance RPC framework released in 2015, built on HTTP/2 and Protocol Buffers for interface definition and binary data encoding; gNMI is essentially a set of data-manipulation operations defined in Protocol Buffers on top of that framework.

Like NETCONF, gNMI models device data as a tree structure, and the de facto standard for that data model is YANG. gNMI clients and servers exchange this YANG-modeled data (commonly encoded as JSON) to carry out configuration and monitoring operations.

Compared with the two other mainstream machine-facing management interfaces — SNMP and NETCONF — gNMI occupies a specific niche. SNMP's MIB-based data model has poor readability, doesn't support nested structures well, and is costly for configuration changes, so its role has narrowed mostly to lightweight monitoring. NETCONF, standardized by the IETF together with YANG, exchanges XML-encoded YANG data and supports batch configuration changes. In routine state queries and configuration changes, gNMI and NETCONF offer largely comparable capability — but gNMI is the stronger fit specifically for network telemetry, thanks to its higher transmission efficiency, richer data interaction patterns, and better extensibility.

How gNMI Works

gNMI runs on gRPC's client-server model: the managed device acts as the server (referred to as the "target"), and the entity issuing management requests is the client.

A typical gNMI session proceeds as follows: after establishing a secure connection, the client sends a Capabilities request to learn what the target supports. The client then separately obtains the specific data models it needs — for example from the device vendor's published YANG model repository — and uses gNMI's defined operations to act on the target's data; the gRPC framework handles converting gNMI requests and responses to and from binary transport automatically.

gNMI defines four services:

  • Capabilities: retrieves what the target supports — its gNMI version, supported data encodings, and supported YANG data models.

  • Get: retrieves the target's current state and configuration data. A GetRequest can query one or more subtrees of the data model at once, and is intended for retrieving comparatively small, point-in-time snapshots of data rather than very large datasets (for those, a Subscribe in ONCE mode is recommended instead).

  • Set: pushes or modifies configuration on the target. A single SetRequest can bundle delete, replace, and update operations together (processed by the target in that fixed order), and gNMI implements transaction-level semantics — every operation in a SetRequest either takes effect together, or none of them do.

  • Subscribe: subscribes to data, and is gNMI's most heavily used service, particularly for telemetry. A SubscribeRequest defines a subscription mode that governs the target's push behavior: ONCE returns one complete dataset and then closes, similar in effect to a Get but delivered over a streaming connection; POLL lets the client request data on demand over an already-established RPC; and STREAM has the target continuously push data according to configured triggers — either ON_CHANGE (push only when a value changes, after an initial full push) or SAMPLE (push at a fixed interval defined by sample_interval).

All four services' top-level data structures support vendor-defined extension fields, and gNMI (via gRPC) supports passing credentials such as a username and password through metadata carried in HTTP/2 headers, which the target can use for authentication, authorization, and auditing.

Why gNMI is Beneficial

The core value of gNMI lies in combining a modern, efficient RPC transport with telemetry-first design:

· High-throughput, low-overhead transport: Built on gRPC's HTTP/2 and Protocol Buffers foundation, gNMI's binary encoding and multiplexed streaming are significantly more efficient than XML-over-SSH, which matters at telemetry data rates.

· Purpose-built streaming telemetry: The Subscribe service's ON_CHANGE and SAMPLE modes let a client receive exactly the update cadence it needs — event-driven or fixed-interval — without constantly re-polling the device.

· Transactional configuration changes: Like NETCONF, a gNMI SetRequest is applied as a single transaction — all bundled delete/replace/update operations succeed together or none do — avoiding partially-applied configuration states.

· Vendor extensibility without breaking compatibility: Every gNMI service supports vendor-defined extension fields at the top level, letting vendors add capability without diverging from the base protocol behavior.

At Asteraix

What We Can Do at Asteraix

AsterNOS implements gNMI as a high-throughput telemetry and configuration interface for data center switches:

· Rich telemetry coverage: AsterNOS already supports gNMI subscription for a broad range of device data, including configuration information (such as routing protocol configuration), system state (CPU load, memory usage, board temperature, fan speed), and statistics (per-port forwarding counters, ACL hit counters, key resource utilization).

· YANG-modeled interface statistics: AsterNOS exposes a YANG model (asternos-interfaces) with per-interface counters — inbound/outbound octets, unicast/broadcast/multicast packets, discards, and errors — that gNMI clients can query directly by interface name.

· Streaming counters via Subscribe: A monitoring server can issue a SAMPLE-mode Subscribe request against a specific interface (for example Ethernet1) with a defined sample_interval, and AsterNOS will stream back timestamped counter updates at that cadence for as long as the subscription is active.

· Integration with standard monitoring stacks: Because AsterNOS's gNMI responses carry structured, timestamped data, they plug directly into time-series pipelines such as Prometheus and Grafana for dashboards, alerting, and traffic analysis.

· Typical deployment: In a leaf-spine data center fabric, a monitoring server deployed alongside the core network establishes gNMI connectivity to every switch and issues subscription requests to continuously pull configuration, counter, and system-state data — supporting device health monitoring, traffic counter tracking, and downstream anomaly alerting or traffic analysis.