A link error spike began and cleared between two 5-minute SNMP polls, leaving no trace in the monitoring record. Streaming telemetry would have exposed it as it unfolded. That kind of missed event is why collection method matters, but it does not make a wholesale migration the right answer.
SNMP and streaming telemetry serve different purposes across different devices and time scales. The sensible choice starts with the signal you need, the hardware that can provide it, and the resolution required to act on it. In most production fleets, that means using both methods.
SNMP's Role
SNMP v2c and v3 remain available on nearly every managed device made over the last 20 years. Its MIB coverage includes interface counters, routing table size, CPU and memory utilization, and much protocol state. The workflow is straightforward: send a GET or GETBULK request, receive the values, then calculate rates between polls.
Slow-moving metrics rarely need second-level detail. Routing table size, BGP peer count, and CPU utilization over 5-minute intervals are usually useful at that cadence. Polling every 5 minutes supplies enough history for capacity planning and routine health checks.
SNMP traps add event-driven coverage for selected conditions. Interface transitions, BGP peer changes, and hardware faults can generate near-real-time notices without polling every OID at high frequency.
SNMP does have clear limits. A 1-minute or 5-minute schedule can miss an event that begins and ends between polls, and frequent requests consume management-plane capacity, especially on older hardware sharing CPU with control functions. SNMP v2c also lacks authentication and encryption. Those tradeoffs matter, but they do not eliminate SNMP from a mixed-vendor fleet.
Where Streaming Telemetry Helps
Streaming telemetry, particularly gRPC-based model-driven telemetry built on YANG data models, addresses the timing limits of polling. The device sends updates when values change or on a subscription schedule, which can reach 1 second for counter data.
That timing changes fault visibility. A rate that rises from normal to critical in 90 seconds appears with 30-second telemetry subscriptions, yet can disappear entirely between 5-minute SNMP polls. A sudden BGP prefix drop is likewise preserved in a second-level stream but may never appear in sampled polling.
For fast-changing metrics, the push pattern can also reduce management-plane work. A device sending one update every 30 seconds follows a known cadence, rather than repeatedly answering SNMP GETBULK requests at that same rate.
YANG telemetry carries useful structure with the value: interface identity, counter name, device timestamp, and related counters can arrive together. With SNMP OID polling, the collector must identify each OID and assemble those pieces afterward.
Device Support Limits
Support varies by platform. Cisco IOS-XR and NX-OS have offered gRPC telemetry since 2016 and 2017 respectively. Arista EOS supports OpenConfig gRPC telemetry, while Juniper Junos added gRPC telemetry around the same period.
Cisco IOS-XE support varies by release and is narrower in many campus deployments than in IOS-XR. Some IOS-XE switches lack gRPC telemetry or expose only limited functions. FortiOS and PAN-OS also vary by platform and firmware. Older access and edge devices may offer no streaming telemetry at all.
Fleets running for more than three years commonly include devices without usable gRPC telemetry. An architecture built entirely around streaming telemetry is not the goal; the goal is matching the collection method to each device's capability. A streaming-only migration may require hardware replacement or leave unsupported devices with collection gaps.
Use Both Collection Methods
In a mixed fleet, use streaming telemetry where it fits, SNMP polling elsewhere, and SNMP traps for supported event conditions.
A practical split by device type:
For modern core routers and switches running IOS-XR, NX-OS, or Arista EOS, subscribe to streaming telemetry for interface counters, BGP state, and metrics needing sub-60-second resolution. Keep SNMP polling as a fallback for values absent from YANG models.
For campus switches on IOS-XE or older firmware, poll counters every 60-second and use SNMP traps for interface changes and hardware faults. The resulting counter lag is an accepted limitation.
For firewalls, WAN routers, and access concentrators with uneven support, compare the firmware with the vendor telemetry matrix first. Use SNMP as the baseline, then add streaming subscriptions only after confirming availability on that platform and release.
Collectors therefore need two paths: a gRPC/YANG receiver for streams and an SNMP poller for remaining devices or metrics. Both outputs must enter a shared schema before correlation and alerting. In our experience, that normalization work creates more operational complexity than receiving the data.
What We Use in Practice
At PhysicalLayer, we ingest through both SNMP and streaming telemetry. During onboarding, we test a device's gRPC connection and check whether the required YANG paths exist. Supported devices receive gRPC subscriptions; others use SNMP polling at a configurable interval.
This gives us near-real-time counters on capable devices and adequate polling coverage elsewhere. On supported hardware, error spikes and BGP prefix changes can appear at sub-60-second resolution. On unsupported hardware, they wait for the next SNMP poll. We show that difference in the device view instead of presenting both data sources as equally timely.