Hands-On Lab: Configuring Model-Driven Telemetry

This hands-on lab configures a router to stream interface statistics continuously to a collector using model-driven telemetry, contrasting this push-based approach against the pull-based polling every prior monitoring method in this series relied upon.

Model-Driven TelemetryDial-Out SubscriptionPush-Based Streaming

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure a dial-out telemetry subscription on a router streaming interface statistics to a collector at a regular interval, verify data arrives continuously without the collector needing to request it, and compare this push-based model against the pull-based polling used by SNMP in an earlier lab.

Lab Purpose

SNMP, covered earlier in this series, requires a management station to actively poll a device for updated statistics, meaning data is only ever as fresh as the last poll interval and every poll consumes device CPU cycles to respond. Model-driven telemetry inverts this relationship entirely: the device itself proactively pushes data to a collector on a schedule, without the collector needing to request anything.

Lab Topology

R1 ---- Gi0/0: 192.168.255.1/24

Telemetry collector: 192.168.255.200,
listening on TCP port 25000

Task 1: Define a Telemetry Subscription

Create a telemetry subscription specifying the YANG path for interface statistics to stream.

Task 2: Configure the Destination Collector

Point the subscription at the collector's address and port using the dial-out model.

Task 3: Set the Streaming Interval

Configure how frequently updates are pushed to the collector.

Task 4: Verify the Subscription Is Active

Confirm the router shows the subscription as established and actively streaming.

Task 5: Verify Data Arrives at the Collector Without Polling

Confirm the collector receives a continuous stream of updates without ever sending a request of its own.

Solution and Verification

R1(config)# telemetry ietf subscription 100
R1(config-mdt-subs)# encoding encode-kvgpb
R1(config-mdt-subs)# filter xpath /interfaces-state/interface/statistics
R1(config-mdt-subs)# source-address 192.168.255.1
R1(config-mdt-subs)# stream yang-push
R1(config-mdt-subs)# update-policy periodic 3000

-- "periodic 3000" pushes updates every
-- 3000 centiseconds (30 seconds) --
-- entirely initiated by the router itself
-- on this schedule, unlike SNMP where the
-- manager decides when to ask

R1(config-mdt-subs)# receiver ip address 192.168.255.200 25000 protocol grpc-tcp

-- Dial-out means R1 initiates the
-- connection TO the collector, rather than
-- the collector connecting to R1 as an
-- SNMP manager would

R1# show telemetry ietf subscription 100 detail

Subscription ID: 100
Type: Configured
State: Valid
Stream: yang-push
Filter: /interfaces-state/interface/statistics
Update policy: Periodic (3000 centiseconds)
Receiver: 192.168.255.200:25000, State: Connected
-- "Connected" confirms R1 has established
-- the outbound session to the collector
-- and is actively pushing data

-- On the collector (conceptual verification):

[10:00:00] Received update: Gi0/0 stats,
           in-octets: 184532102
[10:00:30] Received update: Gi0/0 stats,
           in-octets: 184601288
[10:01:00] Received update: Gi0/0 stats,
           in-octets: 184670445
-- New data arrives every 30 seconds without
-- the collector ever sending a request --
-- a continuous, unsolicited stream, unlike
-- SNMP's request-then-respond pattern

Key Takeaway

The dial-out push model shifts responsibility for initiating data flow entirely to the device — R1 decides when to send updates based on its own configured schedule, freeing the collector from managing polling intervals across potentially thousands of devices and reducing the latency between an actual state change and when a collector learns about it, since streamed telemetry can update far more frequently than a typical SNMP polling interval would tolerate without overwhelming the network.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue