Cisco Streaming Telemetry: A Practical Guide for IT Teams

Cisco streaming telemetry is a push-based way of monitoring. Network devices send configuration and operational data to a collector continuously, instead of waiting to be asked. Cisco’s implementation is called model-driven telemetry (MDT), and it is available across IOS XE, IOS XR and NX-OS platforms. This guide explains how it works, where it beats SNMP polling, what a sensible rollout looks like and which mistakes cost the most time.

Re-solution

Build a clearer view of your network

Re-Solution provides Cisco network solutions, infrastructure audits and network surveys to help teams assess their network needs.

Explore Cisco network solutions

TL;DR

Streaming telemetry pushes data from the device to a collector at set intervals or on change. SNMP and CLI scraping pull it on request.
Model-driven telemetry describes what to send using YANG data models, so you choose precise paths rather than whole MIBs.
Dial-out subscriptions live in the device configuration and survive reloads. Dial-in subscriptions belong to a session and must be recreated.
The hard part is not configuration but governance: choosing which data you need, and securing and storing it.
Start with a small set of high-value sensor paths, prove the pipeline, then widen it.

What Cisco streaming telemetry actually is
Streaming telemetry versus SNMP polling
Dial-in and dial-out subscriptions
Choosing the right data to stream
A rollout plan that works
Where streaming telemetry pays off
Common mistakes
Our perspective
How Re-Solution can help
FAQ
Sources

What Cisco streaming telemetry actually is

Cisco’s model-driven telemetry white paper describes MDT as a mechanism for streaming data from a capable device to a destination receiver, using a push model rather than periodic polling. The Cisco IOS XE programmability guide puts it in similar terms: model-driven telemetry lets devices continuously stream real-time configuration and operating state information to subscribers.

Three ideas make up the whole feature:

A data model. YANG models define the structure of the data, for example interface counters, CPU use or wireless client state. Each piece of data has a path, called a sensor path or XPath.
A subscription. This states which paths to send, how often (periodic) or when (on change), and where to send them.
A transport and encoding. Data usually travels over gRPC, and is encoded as JSON or Google Protocol Buffers (GPB). The NX-OS telemetry documentation on Cisco DevNet describes pushing data off the device as JSON or GPB at a much higher frequency and more efficiently than older approaches.

The collector then stores the stream in a time-series database and a dashboard or alerting engine reads from it. A commonly used open-source pattern is a collector feeding a time-series database with a dashboard on top. A community example on GitHub builds such a stack with Telegraf, InfluxDB and Grafana, using native and OpenConfig YANG models, and generates self-signed certificates for TLS transport.

Streaming telemetry versus SNMP polling

SNMP is not going away, and for many estates it remains the baseline. But it asks a question at intervals and records the answer. Anything that happens between polls is invisible, and a large estate generates a lot of polling load on both the monitoring server and the devices.

Cisco’s own IOS XR documentation makes the contrast directly: legacy SNMP polling does not give the same real-time visibility or flexibility as enhanced streaming telemetry.

Aspect	SNMP polling	Streaming telemetry (MDT)
Direction	Collector pulls from device	Device pushes to collector
Data definition	MIB objects	YANG models and sensor paths
Granularity	Limited by poll interval and load	Short intervals or on-change updates
Encoding	BER-encoded SNMP	JSON or GPB over gRPC
Setup effort	Low, widely understood	Higher: models, collectors, certificates
Best for	Basic availability and capacity	Fast-moving metrics, wireless and capacity analysis, automation inputs

The practical conclusion is that most organisations run both for a time. SNMP and syslog keep covering basic availability while telemetry takes over the metrics where timing matters. For a broader view of how these methods fit together, see our overview of network monitoring techniques and our guide to types of IT monitoring systems.

Dial-in and dial-out subscriptions

The choice between the two subscription types shapes your design more than any other setting.

According to the IOS XE guide, dynamic subscriptions are created by clients that connect into the device, so they are dial-in, while configured subscriptions make the device initiate connections to receivers, so they are dial-out. The same page notes that a dial-in subscription lasts only as long as the session that created it and has to be reinitiated after a reload, while a dial-out subscription is part of the running configuration until you remove it.

In practice:

Dial-out (configured) suits permanent monitoring. The subscription survives reloads and switchovers, and devices behind firewalls only need an outbound path to the collector.
Dial-in (dynamic) suits ad hoc investigation and automation tools that want to open a session, ask for data and close it, without changing device configuration.

For a standing monitoring service across many sites, dial-out is normally the better default. It keeps the intended state in your configuration management and your audit trail.

Choosing the right data to stream

The most common failure we see in telemetry projects is not a broken pipeline. It is a working pipeline that collects far too much. Cisco’s own white paper material stresses that understanding YANG data models is essential to collecting the correct information. Without that understanding, administrators risk gathering large volumes of irrelevant data that obscure network health rather than clarify it.

A useful method is to work backwards from decisions. Ask which question each metric answers, and who acts on the answer. The same discipline applies to any event-driven data design, a point made well in this piece on choosing useful data and avoiding excess in event-driven systems.

A sensible first set for a campus or multi-site network:

Interface state, errors, discards and utilisation on uplinks and core links.
CPU, memory and temperature on switches, routers and controllers.
Routing protocol neighbour state, so adjacency flaps are seen as they happen.
Wireless controller data: access point status, client counts, channel utilisation and roaming failures.
Environmental and power state where devices support it.

Start with a handful of paths and keep a short register: the path, the interval, the owner, the alert it feeds and the retention period. If a path has no owner and no alert, do not stream it yet.

A rollout plan that works

1. Check platform and software support

MDT support differs between IOS XE, IOS XR and NX-OS, and between releases and hardware families. Read the configuration guide for your exact platform and software version before you design anything. Some features, such as particular transports or on-change support for specific paths, are only available in certain releases. SD-WAN deployments also need separate consideration: in a community discussion, practitioners noted that the telemetry configuration in SD-WAN can be retrieved from the manager or the device but not streamed in the way a classic router would, so check current documentation for your controller version rather than assuming parity. If SD-WAN is on your roadmap, our Cisco SD-WAN design guide covers the decisions to make before rollout.

2. Build the collector pipeline

You need a receiver that terminates gRPC, decodes GPB or JSON, and writes into a time-series store. Size it for the number of devices multiplied by paths multiplied by frequency. Test with a few devices first and watch ingestion rates before enrolling the estate.

3. Secure the transport

Telemetry carries detailed information about your network, including topology, addressing and usage patterns. Use TLS, manage certificates properly, restrict which sources can reach the collector, and apply least-privilege accounts for any dial-in access. Treat the collector as a sensitive system in your security and compliance scope.

4. Start with periodic subscriptions, then add on-change

Periodic subscriptions give predictable data volumes and simple trending. On-change subscriptions are efficient for state such as interface up or down, but only for paths that support them. Mix the two once the baseline is stable.

5. Define alerts and baselines

Streaming data does nothing until someone or something acts on it. Set baselines over a few weeks, then alert on deviation from normal rather than on arbitrary thresholds. Our guide on automating network SLA monitoring shows how to tie alert thresholds to service commitments.

6. Review and prune

Revisit the register quarterly. Remove paths nobody uses, and adjust intervals where storage costs are growing faster than insight.

Where streaming telemetry pays off

The feature earns its keep most clearly in environments where conditions change quickly or where many sites share a standard design.

Education campuses. Wireless load shifts hour by hour with timetables and term dates. Controller and access point telemetry shows channel utilisation and client density while a problem is still happening. See our campus network design principles.
Warehousing and logistics. Roaming handheld scanners are sensitive to short wireless glitches that a five-minute poll would average away. Our warehouse wireless briefing covers what to ask a supplier.
Hospitality and shared workspaces. Guest and tenant experience depends on capacity at peak times. Trend data on uplinks and wireless utilisation supports sensible upgrade decisions.
Manufacturing. Segmented operational networks benefit from fast detection of link and neighbour changes, alongside careful VLAN design. Our IoT VLAN checklist is a good companion.

Common mistakes

Streaming everything. High-frequency subscriptions on many paths create storage cost and noise. Begin narrow.
Ignoring software versions. A path that works on one release may be absent on another. Test on the release you will run.
No owner for the collector. The pipeline becomes a production system. Give it monitoring, backups and change control.
Weak transport security. Unencrypted telemetry reveals the shape of your network.
Skipping a baseline. Without a record of normal, new data produces anxiety rather than decisions.
Assuming telemetry replaces everything. Keep syslog, flow data and basic availability checks. Each answers questions the others do not.

Our perspective

We have worked on Cisco infrastructure for more than 35 years, and the pattern is consistent: the organisations that benefit from new monitoring capability are the ones that first know what they want to see. Telemetry is a strong tool, but it is a means to an end. For an IT director at a school group, a logistics operator or a hotel business, the end is fewer incidents, faster diagnosis and evidence for investment decisions.

Our advice is to treat telemetry as part of a wider design, not a standalone project. Audit what you have, confirm which platforms and releases support what you intend to stream, decide the handful of questions the data must answer, and only then build the pipeline. In multi-site estates, consistency matters more than sophistication. A modest set of paths applied identically across every site beats a rich set that exists in three places.

We also believe the operational load should be considered honestly. Running collectors, certificates and dashboards takes skills and time. Some teams want to own that. Others prefer a managed model where the monitoring is delivered as part of the service, and that is a legitimate choice.

— Jacob

How Re-Solution can help

If you want streaming telemetry without building and running the whole platform yourself, we can help at each stage. A network audit establishes what you run, which platforms and releases support model-driven telemetry, and where the gaps are. Our managed services cover ongoing monitoring and support of Cisco estates, and our Network as a Service offer suits organisations that prefer a subscription model. For design and implementation work, see our professional services. Pricing is agreed per engagement, so contact us with a short description of your sites and we will advise on the right starting point.

FAQ

Is streaming telemetry the same as model-driven telemetry?

In Cisco’s world, the terms are used almost interchangeably. Streaming telemetry is the general idea of pushing data continuously, and model-driven telemetry is Cisco’s YANG-based implementation of it. Some platform guides use both names for the same feature.

Do I need to replace SNMP to use it?

No. Most teams run both side by side. SNMP continues to cover basic availability and legacy devices, while telemetry handles the metrics where timing and granularity matter. Retire SNMP polling only where telemetry fully replaces its use.

Which Cisco platforms support it?

Support exists across IOS XE, IOS XR and NX-OS, but the available paths, transports and subscription types vary by platform and software release. Always check the configuration guide for your exact device family and version before planning. A network audit can list what your estate supports.

What do I need besides the devices?

You need a collector that receives gRPC streams, a time-series database, a visualisation or alerting layer, and a certificate process for TLS. You also need someone responsible for running that pipeline over time.

Should I use dial-in or dial-out?

Use dial-out for permanent monitoring, because the subscription is held in the device configuration and continues after a reload. Use dial-in for temporary troubleshooting or for automation tools that open a session on demand.