We all know SNMP: poll every five minutes and hope you caught it. gNMI: subscribe once and let the switch stream the updates. That’s the difference. It’s bigger than it looks.
SNMP dates back to 1988. It was built for a world where humans managed networks and checked on them periodically. Your monitoring system asks every device the same question, “Anything changed?”, and asks again 60 seconds later, or 300. A human watched the dashboard and reacted. That model was fine for years.
Then we built software that has to react faster than a human. Automation does not want a dashboard. It wants fresh state so it can make a decision, and it wants that state as soon as it changes, not whenever the next timer fires. This is the part that matters, and it isn’t that gNMI is newer than SNMP. It’s that the conversation is reversed.
With SNMP the collector owns the conversation. It asks, the switch answers, repeat forever. SNMP traps can push notifications too, but they do not replace polling for collecting structured operational state. If something changes between two polls, nobody knows until the next request. You either poll more often and burn more CPU on every device, or you accept stale data. With gNMI the client subscribes once and the switch keeps the session open. The client asks once. After that, the switch keeps talking.
gNMI names three subscription modes. ONCE returns the state and closes the RPC. POLL keeps the RPC open but still waits for the client to ask each time. STREAM is the one people mean, and it splits again, per path: on-change sends an update only when the value moves, sample sends it every interval you name, and target-defined hands the choice to the device leaf by leaf. The top-level mode covers the whole subscription. The per-path mode does not, so one subscription can sample a counter and watch a link state on-change at the same time. Subscribing does not automatically mean streaming, and streaming does not automatically mean on-change. A 10-second sampled interface counter is a different purchase from an on-change link state.
Telemetry is only half the story. gNMI also writes configuration through the same modeled interface. Get reads data. Subscribe streams it. Set writes configuration. A single Set request can group updates, replacements, and deletions into one transaction. OpenConfig can give that data a shared, vendor-neutral shape.
And the data model is the quiet upgrade. SNMP hands you OIDs that your application maps back to MIB definitions. gNMI hands you a path that already describes the object:
/interfaces/interface[name=ethernet-1/1]/state/countersThe model is part of the API, and the model is shared. OpenConfig is an operator-led set of vendor-neutral data models built around how operators see the device, so the same modeled path can describe the same object on a Nokia box and an Arista one.
AI infrastructure makes stale state more expensive. A link can degrade while a distributed job is still running. By the time a five-minute polling cycle reports it, the useful response window is already gone.
If you want to feel the difference instead of taking my word for it, install gnmic, the gNMI client now maintained under OpenConfig. Subscribe to an interface counter, unplug a cable, and watch the switch tell you. Watching the update arrive makes the reversed conversation obvious. You can point it at modern network operating systems such as SR Linux, SONiC, EOS, Junos, and supported NX-OS platforms.
Now the honest other side. gNMI is not free, and SNMP is not dead.
SNMP runs on everything. Switches, routers, firewalls, UPS units, PDUs, printers, a temperature probe, a ten-year-old box in a closet. gNMI runs mostly on newer platforms. If your job is one pane of glass over a mixed estate, SNMP is still the only thing that answers on all of it.
The tooling gap is real. Nearly four decades of SNMP mean that most established NMS platforms speak it out of the box: Zabbix, LibreNMS, PRTG, Observium. gNMI often means more integration work. A collector, a time-series database, dashboards, certificates. More control, more parts to own.
The vendor-neutral promise also leaks. Major vendors still expose native models alongside OpenConfig, and OpenConfig coverage is often incomplete. A box can be fully gNMI and barely OpenConfig. You will still run into vendor-specific YANG.
And streaming is not always the answer. A link going up or down, or a closet temperature, does not need millisecond telemetry. Polling it every 60 seconds is fine, and cheaper than standing up a pipeline that ingests, stores, and ages out a firehose of samples nobody reads.
The real line is speed. Where change is fast and software has to act on it, gNMI earns the complexity.
SNMP is not going anywhere. It stays as the floor. It answers on almost any box out there, and a five-minute-old number is still a true number for most of what it watches. gNMI goes where a machine consumes the state and acts on it, which today means the fabric and not much else. Two systems, running in parallel. The SNMP half of that is fifteen years of running it. The fabric half is a lab and other people’s published designs, not a cluster I have operated.
The cost of a wrong call runs both directions. Build the streaming pipeline for an environment that changes slowly and you pay for something the old system already did. Skip it where software has to react and your blind spot is exactly one polling interval wide.
And if you build your own automation, the programming language was never the missing piece. Point a small Go client at gNMI instead of the CLI, and the tool inherits structure instead of fragility.
Polling is checking your mailbox every minute to see whether a letter arrived. Subscribing is waiting for the notification that one did. Once you see telemetry that way, poll-and-hope starts to feel like what it is. A timer standing in for the thing you actually wanted: to be told.
When software watches software and has to move, the side that gets told wins. Everywhere else, poll away.