Model-Driven Telemetry on IOS XE Routers: gRPC Dial-Out in Practice

SNMP polling is how the network has been monitored for thirty years, and it is showing every one of them. You ask the device "what is your interface counter?" every 30 or 60 seconds, it answers, and you have a sampled, delayed, request-heavy view of a network that changes far faster than your poll interval. Model-driven telemetry inverts the model: the device streams data to you, continuously, the moment it changes, over an efficient transport. It is the difference between checking your watch every minute and watching a live clock.

This article covers model-driven telemetry (MDT) on IOS XE - the subscription model, dial-in vs dial-out, and the honest platform picture. It closes the automation series. It extends the network automation guide.

Why SNMP polling is not enough anymore

The scaling problem is the killer. A modern network with thousands of interfaces, polled every 30 seconds for dozens of metrics each, generates enormous request-response volume and still gives you a stale, coarse picture. MDT streams the same data continuously, in one efficient pipe, at a granularity SNMP cannot touch. For analytics, capacity planning, and fast fault detection, this is the difference between guessing and knowing.

The subscription model

MDT is built on YANG models and subscriptions. You subscribe to a data path in a YANG model (say, interface statistics), specify how you want it (periodic every N centiseconds, or on-change), and where to send it (a collector). The device then streams that data per the subscription.

telemetry ietf subscription 101
 encoding encode-kvgpb
 filter xpath /interfaces-state/interface/statistics
 source-address 192.168.99.1
 stream yang-push
 update-policy periodic 1000        ! every 1000 centiseconds = 10 seconds
 receiver ip address 192.168.99.100 57500 protocol grpc-tcp

Read the pieces:

• filter xpath - which YANG data path to stream (here, interface statistics).
• stream yang-push - the mechanism (yang-push is the standard).
• update-policy - periodic (every N centiseconds) or on-change (stream only when the value changes - the most efficient of all).
• receiver - the collector's address, port, and transport (gRPC here).
• encoding - how the data is serialised (kvGPB, a compact protobuf-based format, or JSON/XML).

Dial-in vs dial-out

Dial-out is the common production choice - the device is configured once with its subscriptions and streams to a known collector, which is easy to scale and survives collector restarts (the device keeps trying). Dial-in suits dynamic, exploratory monitoring where the collector decides on the fly what to pull.

The collector side

The stream has to land somewhere. A typical telemetry stack is:

• A collector (Telegraf with the cisco_telemetry plugin, or a purpose-built gRPC receiver) that terminates the stream and decodes the kvGPB/JSON.
• A time-series database (InfluxDB, Prometheus) that stores the metrics.
• A visualisation layer (Grafana) that turns them into dashboards.

This TIG/TICK-style stack is standard, and the beauty of MDT is that the router pushes clean, model-structured data straight into it - no SNMP MIB wrangling, no polling loops.

The honest platform picture

Here is where we are straight with you, as throughout this cluster. Model-driven telemetry depends on the Data Management Infrastructure (DMI) - the same YANG-management stack that NETCONF and RESTCONF need. And that stack is not present on the lightweight virtual IOS (IOL) we use for fast routing labs:

R1(config)#telemetry ietf subscription 101
              ^
% Invalid input detected at '^' marker.

The telemetry command does not exist on IOL, because there is no DMI process to serve it - the same reason netconf-yang is configured but its port never opens, and iox (Guest Shell) is rejected. The heavier virtual platforms that do carry the DMI stack (cat8000v, csr1000v) have their own DMI-initialisation problems in a virtualised lab.

So we are not going to show you invented telemetry datapoints from a platform that cannot produce them. The configuration above is the real, current IOS XE MDT syntax, presented as a documented reference. On a physical Catalyst or ASR - or a cloud router with a working DMI - it streams exactly as described, into a Telegraf/InfluxDB/Grafana stack. What is real and captured in this cluster is the automation that works everywhere: EEM, and the Jinja2 + Netmiko pipeline. MDT is the direction the industry is moving, and understanding its model is the point - but the honest position is that our lab's platforms cannot boot the DMI, and we say so.

MDT vs the alternatives

• vs SNMP: MDT is push not pull, near-real-time not sampled, one stream not per-OID requests. For scale and granularity, it wins decisively. SNMP persists because it is universal and simple, but it is legacy.
• vs syslog: different job - syslog is discrete events, MDT is continuous metrics. Use both.
• vs NETCONF get: NETCONF pull is a snapshot on demand; MDT is a continuous stream. MDT is what you want for monitoring; NETCONF get for a point-in-time query.

Key takeaways

• Model-driven telemetry streams data from the device continuously, near-real-time, over an efficient transport - replacing SNMP's slow, heavy, sampled polling.
• It is built on YANG models and subscriptions: subscribe to a data path, choose periodic or on-change, and stream to a collector, typically with gRPC and kvGPB encoding.
• Dial-out (device streams to a known collector) is the common production model; dial-in (collector requests dynamically) is for exploratory monitoring.
• The collector stack is typically Telegraf → InfluxDB/Prometheus → Grafana - the router pushes clean model-structured data straight in.
• MDT needs the DMI stack, which the lightweight virtual IOS (IOL) lacks - telemetry is an invalid command there, as are netconf-yang sessions and iox. We present the real syntax as documented reference and are honest that our lab cannot stream it.
• The fully-captured automation in this cluster is EEM and the Jinja2 + Netmiko pipeline - which work on every platform. MDT is the future; understanding its model is the goal.

That closes the automation series, and with it the CCIE Automation and Programmability domain. The full cluster index lives on the network automation pillar.