ACE Journal

gRPC streaming telemetry replacing SNMP in carrier networks

Who this is for: network engineers and SRE teams operating carrier-grade infrastructure (Tier-1/2 ISP, large enterprise WAN, cloud backbone) who are evaluating or mid-migration from SNMP-based NOC tooling. You should already understand BGP, interface counters, and what a MIB is. Familiarity with Protobuf or gRPC helps but is not required. If you are running a small campus network where SNMP polling at 5-minute granularity is fine, this is overkill.

Thirty years of polling

SNMP entered RFC in 1988 and became the operational glue of network management almost immediately. SNMPv2c (1993) added GetBulk and improved error handling. SNMPv3 (2004) brought authentication and privacy. None of these versions changed the fundamental model: the management station asks, the device answers.

That model was appropriate when a carrier’s network was a few hundred routers and acceptable granularity was 5 minutes. It is increasingly inappropriate when a modern Tier-1 operates tens of thousands of line cards, when a BGP session flap and restoration can complete in under a second, and when microburst-driven queue drops last milliseconds. At those timescales the polling model has two structural problems.

The first is granularity. A 30-second poll interval, already generous by SNMP standards at scale, means a transient queue event that starts and clears in 15 seconds is invisible. You see a normal counter at T=0 and a normal counter at T=30; the event happened between samples and left no trace. Dropping to 10-second polling helps, but it multiplies the second problem.

The second is management-plane load. SNMP polls are synchronous per-OID requests. Bulk collection helps but does not eliminate the per-poll round trip. At a large carrier, polling thousands of routers at 30-second intervals for interface counters, BGP neighbor state, and queue statistics generates sustained CPU pressure on device management planes that compete with control-plane processes. Operators routinely set artificial floors on poll frequency to keep management-plane utilization acceptable, which is the operational feedback loop confirming that the model does not scale.

SNMPv3’s encryption and HMAC authentication address the security gap, but they add processing cost per PDU on both sides. Many operators still run SNMPv2c on isolated management-plane VRFs rather than pay that cost, accepting the security trade-off because the alternative is heavier.

How model-driven telemetry works

The conceptual shift is simple: instead of the management station asking for data repeatedly, the device sends it continuously. The device subscribes to a set of data paths and streams updates on a schedule or when values change. The management station is now a collector, not a poller.

The protocol stack under gNMI looks like this: gRPC as the transport (HTTP/2, persistent connections, multiplexed streams), Protobuf as the primary encoding for the data payload, and YANG as the data model that defines what paths exist and what their types are.

Figure 1 shows the relationship between these layers and how they map to the traditional SNMP components.

graph TD
    subgraph gNMI stack
        Y[YANG data model<br/>OpenConfig / vendor] --> P[gNMI paths]
        P --> PB[Protobuf encoding]
        PB --> G[gRPC / HTTP2<br/>persistent stream]
    end
    subgraph SNMP stack
        M[MIB / SMIv2] --> O[OID tree]
        O --> B[BER encoding]
        B --> U[UDP request-response]
    end
    Y -. equivalent role .-> M
    G -. replaces .-> U

Figure 1. Protocol stack comparison between gNMI and SNMP. The left side shows gNMI’s layered stack; the right shows the SNMP equivalent. Notice that YANG and MIBs serve the same modelling role, but gRPC’s persistent stream replaces UDP’s stateless request-response.

Dial-in vs dial-out

gNMI supports two connection directions. In dial-in mode, the collector establishes a gRPC connection to the device and sends a SubscribeRequest. This is the more common mode and the one covered by the OpenConfig gNMI specification [1]. The device manages the stream on top of the collector’s initiated connection.

In dial-out mode, the device initiates the connection to a collector endpoint. This is sometimes called “model-driven telemetry dial-out” in Cisco IOS-XR documentation and Juniper documentation. Dial-out matters in environments where devices are behind firewalls that permit only outbound connections, or where you want to reduce the number of inbound TCP sessions a collector needs to manage.

Most new deployments use dial-in because it is simpler operationally: the collector holds one persistent gRPC channel per device and drives all subscription management. Dial-out shifts state management to the device, which adds complexity.

Subscription modes: sample vs on-change

Two subscription modes cover most use cases.

Sample subscriptions deliver counter values at a fixed interval regardless of whether the value changed. This mirrors the SNMP polling semantics but without the per-sample round trip. Sample intervals as low as 10ms are spec-compliant and practically achievable for interface counters on modern router management planes, though “achievable” and “advisable” are different questions addressed in the hard-part section. Typical production deployments use 10 to 30-second sample intervals for high-frequency metrics like interface utilization and queue drops, matching or beating SNMP poll floors while consuming less management-plane CPU per sample.

On-change subscriptions deliver an update only when a value changes. This is ideal for event-driven state: BGP session up/down, interface operational state, OSPF neighbor transitions. A BGP session flap that lasts 800ms produces exactly one “down” update and one “up” update, timestamped at the device. SNMP would report both states only if polls happened to land during the outage window; otherwise the event is invisible. On-change subscriptions make transient events first-class, durable signals.

YANG models: OpenConfig vs vendor

YANG (YANG: A Data Modeling Language, RFC 7950) defines the schema for every gNMI path. Two model lineages coexist in production.

OpenConfig models (maintained at github.com/openconfig/public) define vendor-neutral schemas for common features: interfaces, BGP, ISIS, LLDP, MPLS, and others. A collector configured with OpenConfig paths can in principle subscribe to an interface counter on a Cisco, Juniper, or Nokia device using the same path string. This normalization is the major operational benefit: one set of collection pipelines, one set of Grafana dashboards, regardless of vendor mix.

Vendor-specific YANG models (Cisco’s native models for IOS-XR, Juniper’s Junos schema, Nokia’s SR OS models) provide deeper coverage for platform-specific features that OpenConfig does not model. Queue-depth statistics broken out by traffic class, segment routing SID tables, platform-specific optical power readings: these tend to live in vendor trees. Real deployments use OpenConfig where coverage is adequate and fall back to vendor paths for the gaps.

A worked example: gNMI Subscribe in practice

The gNMI proto definition for a SubscribeRequest covers both the subscription parameters and the path specification. Here is a representative subscription for interface input/output octet counters using the OpenConfig path, expressed in proto text format as you might send it using gnmic [2]:

subscribe: {
  subscription: {
    path: {
      elem: { name: "interfaces" }
      elem: { name: "interface" key: { key: "name" value: "et-0/0/0" } }
      elem: { name: "state" }
      elem: { name: "counters" }
    }
    mode: SAMPLE
    sample_interval: 30000000000
  }
  mode: STREAM
  encoding: PROTO
}

sample_interval is in nanoseconds; 30,000,000,000 ns = 30 seconds. encoding: PROTO requests Protobuf encoding; JSON_IETF is the alternative for human-readable debugging at the cost of larger payload size.

Using gnmic at the CLI, the equivalent command is:

gnmic -a router1.example.net:57400 \
  --tls-ca /etc/ssl/certs/ca-bundle.crt \
  --username telemetry --password redacted \
  subscribe \
  --path "/interfaces/interface[name=et-0/0/0]/state/counters" \
  --stream-mode sample \
  --sample-interval 30s \
  --encoding proto

The device responds with a stream of SubscribeResponse messages, each containing a Notification with a timestamp and a list of Update objects. Each Update pairs a path (the specific leaf that changed) with a value in the encoded format. The timestamp is from the device clock, not the collector, which matters for accurate event ordering across multiple routers.

For a BGP session on-change subscription to catch flaps, the path and mode change but the structure is the same:

gnmic -a router1.example.net:57400 \
  --tls-ca /etc/ssl/certs/ca-bundle.crt \
  --username telemetry --password redacted \
  subscribe \
  --path "/network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=192.0.2.1]/state/session-state" \
  --stream-mode on-change \
  --encoding proto

Figure 2 shows how a collector handles an on-change BGP flap event versus what a 30-second poller would see across the same timeline.

sequenceDiagram
    participant Router
    participant Collector
    participant SNMP Poller

    Note over Router,SNMP Poller: T=0s - BGP session up

    Router->>Collector: on-change: session-state=ESTABLISHED (T=0)

    Note over Router: T=8s - BGP session flaps down
    Router->>Collector: on-change: session-state=IDLE (T=8s)

    Note over Router: T=11s - BGP session recovers
    Router->>Collector: on-change: session-state=ESTABLISHED (T=11s)

    Note over SNMP Poller: T=30s - next poll fires
    SNMP Poller->>Router: GetBulk bgpPeerState
    Router-->>SNMP Poller: ESTABLISHED (flap happened, recovered, invisible)

Figure 2. On-change telemetry vs SNMP polling for a BGP session flap that recovers in 3 seconds. The collector receives two events with accurate device timestamps. The poller fires at T=30s and sees ESTABLISHED (the event left no trace in its record).

The hard part

The protocol specification is clean. The operational reality has edges.

Encoding overhead at high cadence. Protobuf is compact and fast to decode, which is why it is the preferred encoding in production. JSON-IETF encoding uses more bandwidth and CPU on both device and collector. At 10ms sample intervals for hundreds of interfaces, the difference is meaningful. Operators who turn on JSON-IETF for debugging and forget to switch back can observe collector-side parsing CPU climbing noticeably. Stick to PROTO encoding in production; use JSON-IETF in lab for readability.

Subscription cadence vs management-plane load. “10ms sample intervals are supported” does not mean “10ms sample intervals for all paths on all interfaces are free.” Management planes have finite CPU, and the serialization, scheduling, and transmission of high-frequency updates competes with control-plane processes. A BGP-heavy router simultaneously handling route churn and producing sub-second interface telemetry for 200 interfaces will show management-plane CPU impact. The practical floor for broad interface counter collection in production is 10 to 30 seconds. Sub-second rates are practical for targeted, narrow subscriptions (a handful of critical links during an incident, for example).

YANG path coverage gaps. OpenConfig coverage is solid for the common cases: Ethernet interface counters, BGP neighbor state, LLDP topology. It thins out quickly for platform-specific features. A carrier operating Nokia 7750 SR for core and Cisco ASR 9000 for aggregation will find that detailed FEC error statistics, platform optical transport metrics, and some QoS counter breakdowns require vendor-specific YANG paths. Maintaining two path namespaces in your collection pipeline (OpenConfig for shared metrics, vendor-native for the gaps) is the normal steady state, not a temporary workaround.

Path stability across software releases. Vendor YANG models evolve across software versions. A path that populates correctly on IOS-XR 7.3 may be reorganized in 7.5, silently returning empty responses until the subscription is updated. Operators need a process for validating YANG path coverage as part of router software upgrades, similar to how MIB availability was validated in SNMP workflows, but the scope of change per-upgrade can be larger.

Certificate and TLS management at scale. gNMI over gRPC assumes TLS. At a carrier operating thousands of routers, TLS certificate management (rotation, revocation, per-device versus shared certificates) becomes an operational domain in its own right. SNMP on a management-plane VRF with community strings, for all its security weaknesses, required no PKI. The security improvement of gNMI/TLS is real and worth it, but the PKI operational cost needs to be planned, not assumed away.

Integration: from device to time-series

The canonical production pipeline pairs a gNMI collector with a streaming intermediate and a time-series backend. Figure 3 shows the architecture used by operators building on open-source components.

flowchart LR
    R1[Router A<br/>gNMI dial-in] --> Col[Collector<br/>gnmic / Telegraf]
    R2[Router B<br/>gNMI dial-in] --> Col
    R3[Router N<br/>gNMI dial-in] --> Col
    Col --> K[(Kafka<br/>telemetry topics)]
    K --> TS[(InfluxDB /<br/>Prometheus / VictoriaMetrics)]
    K --> SP[Stream processor<br/>Flink / KSQL anomaly rules]
    TS --> G[Grafana<br/>dashboards + alerts]
    SP --> AL[Alertmanager /<br/>NOC ticketing]

Figure 3. A common carrier telemetry pipeline. Collectors maintain persistent gRPC sessions per router; Kafka decouples ingestion rate from storage write throughput and fans data out to both long-term storage and real-time stream processing. Refer to this when sizing: the collector tier and the Kafka partition count are the two places load scales.

Two common collector options are gnmic [2] (Nokia-maintained, purpose-built for gNMI, outputs to Kafka and InfluxDB natively) and Telegraf’s inputs.gnmi plugin [3] (more familiar in shops already running Telegraf for server metrics, fits into existing pipelines). Cisco’s pipeline collector [4] is used in IOS-XR-heavy environments.

Kafka between the collector and the storage tier serves two purposes. It absorbs bursts when storage is slow or reindexing, and it lets you fan the same raw telemetry stream to multiple consumers: long-term storage in InfluxDB or VictoriaMetrics, stream processors running anomaly detection or threshold alerting, and potentially a second analytics cluster. This fan-out is harder to achieve cleanly if you write directly from the collector to storage.

Grafana sits in front of the time-series backend for dashboards. The migration from SNMP-based dashboards typically involves rebuilding queries from SNMP OID-derived metric names to gNMI path-derived metric names, which in Influx or Prometheus follows the path element structure. Planning this translation work is usually underestimated.

NETCONF/RESTCONF targets configuration management more than operational data streaming. NETCONF operations for reading operational state (get, get-config) are request-response like SNMP. RFC 8641 defines “subscribed notifications” over NETCONF, which pushes event notifications, but the streaming telemetry use case is better served by gNMI at the rates carriers need. NETCONF and gNMI coexist in production: NETCONF for configuration management, gNMI for monitoring.

sFlow and IPFIX solve a related but distinct problem: traffic sampling and flow export. sFlow samples packets at line rate and exports sampled headers; IPFIX exports flow records. Both are push-based like gNMI telemetry, but they are specialized for traffic analytics rather than general operational state. They answer “what traffic is flowing” rather than “what is the state of BGP neighbor X.” Production networks run all three: sFlow/IPFIX for traffic engineering and capacity planning, gNMI for operational telemetry.

SNMP remains appropriate for environments where infrastructure is older (management planes that do not support gNMI), where 30-second granularity is genuinely sufficient, and where the ecosystem of existing tooling (LibreNMS, Cacti, Observium, commercial NMS systems) provides the features needed without migration cost. The case for gNMI is strongest at carrier scale, at high data rates, and where sub-minute visibility is operationally necessary.

Where it breaks

Old management planes without gNMI support. gNMI requires router software that implements the gNMI agent, typically software from 2018 onward for major vendors. Routers running older releases, common in edge deployments running stable-but-old software, do not have gNMI. SNMP is the only option until the platform upgrades. A heterogeneous fleet with a long upgrade tail means running both protocols in parallel longer than expected.

On-change subscriptions for high-churn state. On-change subscriptions are efficient when state is stable and events are meaningful. For state that churns rapidly (BFD session micro-flaps, rapidly oscillating counters), on-change produces a storm of updates that can overwhelm the collector. Sample subscriptions with an appropriate interval are usually the better choice for volatile state.

Collector single points of failure. SNMP polls are stateless: if the poller restarts, the next poll resumes normally. gNMI subscriptions are stateful: a collector restart drops all subscriptions, which must be re-established. Until re-established, data gaps appear in the time series. Collector high-availability (active-standby pairs or subscription re-establishment logic) needs to be designed explicitly.

Kafka lag masking real-time alerting. Introducing Kafka between collector and alerting increases the end-to-end latency of real-time alerts. A BGP flap event that arrives in the collector milliseconds after occurrence may sit in a Kafka topic for seconds before a stream processor evaluates it. For latency-sensitive alerting, a direct path from collector to alertmanager (bypassing Kafka) is needed in parallel with the Kafka pipeline.

YANG model ambiguity between vendor implementations. OpenConfig defines a schema; vendor implementations interpret it with varying strictness. A path that returns a 64-bit counter on one platform may return a 32-bit wrapped counter on another, or may return both but label them differently. Collection pipelines that assume consistent typing across vendors will surface type errors in production. Defensive type handling in the collector or stream processor is required.

Certificate rotation at scale during maintenance windows. Rotating TLS certificates on thousands of devices requires coordination: the collector must trust the new certificate before the device presents it, or connections drop. Staggered rotation schedules and overlapping trust windows are operational procedures that need to be written and tested before they are needed under pressure.

Further reading

Start with the OpenConfig gNMI specification [1] for the authoritative protocol definition, then the gnmic documentation [2] for a practical implementation reference. Telegraf’s gNMI plugin documentation [3] covers the Influx-stack integration path. For the YANG modelling foundation, RFC 7950 [5] is the normative reference, and the OpenConfig YANG repository [6] is the practical working set. The IETF NETCONF Working Group RFC 8641 [7] covers subscribed notifications over NETCONF for comparison. NANOG presentation archives [8] have real operator presentations on gNMI deployments from NTT, Telia, and others; search for “streaming telemetry” in the presentation archive. The IETF Model-Driven Telemetry overview (RFC 8641 and companion documents) [7] provides the IETF framing of the broader space.

Written with AI assistance, editorially reviewed.

References

[1] OpenConfig Working Group, “gRPC Network Management Interface (gNMI).” https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md

[2] Nokia, “gnmic - gNMI CLI client and collector.” https://gnmic.openconfig.net/

[3] InfluxData, “Telegraf inputs.gnmi plugin.” https://github.com/influxdata/telegraf/tree/master/plugins/inputs/gnmi

[4] Cisco Systems, “Model-Driven Telemetry.” https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/telemetry/b-telemetry-cg-ncs5500-66x.html

[5] M. Bjorklund, Ed., “The YANG 1.1 Data Modeling Language,” IETF RFC 7950, August 2016. https://datatracker.ietf.org/doc/html/rfc7950

[6] OpenConfig, “OpenConfig YANG Models.” https://github.com/openconfig/public

[7] E. Voit et al., “Subscription to YANG Notifications for Datastore Updates,” IETF RFC 8641, September 2019. https://datatracker.ietf.org/doc/html/rfc8641

[8] NANOG, “Presentation Archive.” https://www.nanog.org/archives/

[9] Juniper Networks, “Model-Driven Telemetry Overview.” https://www.juniper.net/documentation/us/en/software/junos/interfaces-telemetry/topics/concept/junos-telemetry-interface-oveview.html

[10] Nokia, “SR OS Model-Driven Telemetry.” https://documentation.nokia.com/sr/22-2/books/model-driven-telemetry/model-driven-telemetry-book.html

[11] gRPC Authors, “gRPC Core Concepts.” https://grpc.io/docs/what-is-grpc/core-concepts/

[12] OpenConfig, “gNMI Path Conventions.” https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-path-conventions.md