Dial-In Telemetry

Objective

In this lesson you will configure and verify dial-in (collector-initiated) telemetry concepts and practice with a dynamic telemetry subscription example on an IOS XE device. You will learn why a collector-initiated model matters in production (for large monitoring platforms, firewalled device groups, and centralized certificate-based authentication), how the device and collector interact at the protocol level, and how to validate the telemetry session from both sides.

In production networks, dial-in telemetry is used when management/monitoring platforms (collectors) centrally control subscriptions and pull telemetry from devices (for example, in an NOC where the collector initiates secure connections to many devices across administrative domains). This lesson shows the mechanics and verification steps you will encounter when the collector establishes a gNMI/gNOI session and when a device is configured for dynamic telemetry behavior.

Quick Recap

Refer to the topology from Lesson 1 for the general network layout (device under test is an IOS XE router/switch). This lesson adds the collector and demonstrates collector-initiated interactions and a dynamic subscription example.

ASCII topology (new elements shown):

[Telemetry Collector]
eth0 10.1.1.3:57500
|
| (IP network)
|
[IOS XE Device / gNMI server]
mgmt 10.85.134.92:9339

• The collector listens on 10.1.1.3 port 57500 for push, and may also initiate gNMI/gNOI sessions to the device at 10.85.134.92:9339.
• All IPs used in this lesson are taken directly from the reference material.

Key Concepts

• Dial-in vs Dial-out telemetry

  • Dial-out (push): device opens a connection to a collector and sends telemetry (device-initiated).
  • Dial-in (collector-initiated): collector opens a management session (e.g., gNMI/gNOI) to the device and requests telemetry subscriptions. This is useful when collectors must control subscription lifetime, content, or when devices are behind strict ingress filtering.
  • In production: use dial-in when the monitoring platform controls subscription lifecycle or when you need centralized certificate-based authentication.

• gNMI / gNOI basics

  • gNMI (gRPC Network Management Interface) is used for configuration and telemetry over HTTP/2 with protobuf encoding on devices that support it. Default port seen in the reference: 9339.
  • gNOI provides microservices (for OS install, file operations, certificates) that are invoked over the gRPC channel to a device. The gNOI client example in the reference connects to a target at 10.85.134.92:9339 to verify OS details.

• IETF model-driven telemetry vs encoding

  • Telemetry subscriptions use YANG data models; encoding can be protobuf (GPB) or JSON_IETF. The example here uses GPB (encode -kvgpb) and the YANG stream (stream yang).
  • Update policies include periodic and on-change; periodic has minimum interval granularity mentioned: 100 centiseconds (1 second).

• Transport and security

  • gNMI/gNOI use TLS (mTLS recommended) over HTTP/2/gRPC. The client may present a certificate; the device validates it. For lab verification the client example from the reference shows certificate usage and an -insecure flag option.

Analogy: Think of dial-in telemetry like a news reporter (collector) calling a newspaper (device) to request a live feed; the reporter controls when the feed starts/stops and what sections to receive. Dial-out is the newspaper calling the reporter and sending updates without the reporter asking each time.

---

Step-by-step configuration

Step 1: Create a periodic IETF telemetry subscription (device side)

What we are doing: We configure a sample IETF telemetry subscription on the IOS XE device that collects CPU utilization and targets a receiver. This demonstrates how a dynamic subscription is defined; although this example configures a push receiver, it also illustrates the YANG stream, encoding, filter, and periodic update-policy fields you will see when a collector requests subscriptions via dial-in protocols.

configure terminal
telemetry ietfsubscription 1 encoding encode -kvgpb filter xpath/process-cpu-ios-xe-oper:cpu-usage/cpu-utilization stream yang -push update-policy periodic 60000 receiver ipaddress 10.1.1.3 57500 protocol grpc-tcp
end

What just happened:

• configure terminal enters global configuration mode.
• telemetry ietfsubscription 1 creates subscription ID 1.
• encoding encode -kvgpb selects protobuf encoding (GPB) for compact telemetry; this matters for collector compatibility and bandwidth.
• filter xpath/...cpu-utilization selects the CPU utilization path from the IOS XE operational YANG model; this reduces payload size by focusing only on CPU usage.
• stream yang -push states the data stream format (YANG stream) and configures the subscription for push delivery (device will send data to receiver), illustrating the same content that a collector might request via dial-in.
• update-policy periodic 60000 requests periodic updates every 60000 milliseconds (60 seconds). Note the minimum allowed granularity is 100 centiseconds (1 second) per the device YANG capability.
• receiver ipaddress 10.1.1.3 57500 protocol grpc-tcp tells the device the collector endpoint and port. grpc-tcp indicates the transport used to send the data.

Real-world note: In production you will often define these fields using a collector control-plane (gNMI client) rather than writing static config on the device. Here we show the config-line equivalent so you understand the subscription parameters.

Verify:

show telemetry ietf subscription 1
Subscription ID: 1
Encoding: encode -kvgpb
Filter: xpath/process-cpu-ios-xe-oper:cpu-usage/cpu-utilization
Stream: yang
Delivery: push
Update-policy: periodic 60000
Receiver: 10.1.1.3 port 57500 protocol grpc-tcp
State: active
Last-update-time: 00:00:30

• The above output confirms the subscription parameters are set, the receiver IP/port are correct, and the subscription is active. The Last-update-time shows the last telemetry transmit time.

---

Step 2: Explain collector-initiated (dial-in) flow and prepare collector

What we are doing: We describe how a collector would initiate a session to the device (dial-in) using gNMI/gNOI and show the client-side verification command pattern used in the reference. This step does not change device config, but demonstrates the client operation and confirms reachability to the device's gRPC endpoint.

# On the collector (example command shown in reference format)
# change directories to where certificates are stored and run the gNOI client to verify OS info
cd ~/certs
gnoi_os -insecure -target_addr 10.85.134.92:9339 -op verify -target_name c9300 -alsologtostderr -cert ./client.crt -ca ./rootCA.pem -key ./rootCA.key

What just happened:

• The collector runs a gNOI client (gnoi_os) targeting the device at 10.85.134.92 on port 9339. This demonstrates a collector dialing into the device's gRPC interface.
• The -insecure flag in the example relaxes TLS verification for lab purposes; in production you should use proper certificate validation (mTLS).
• The client performs the verify operation which queries installed/active OS information from the device — proving a successful gRPC control connection.

Real-world note: In production, collectors use gNMI to create subscription requests dynamically over the same secure channel rather than relying on static device-side push configuration.

Verify:

# Expected client output (example)
Running OS version: 17.05.01.0.144.1617180620
Verification: success

• The output above indicates the collector successfully connected to 10.85.134.92:9339 and received OS information via gNOI. A similar gNMI client create-subscription would return success and streaming data if the collector initiated telemetry subscriptions.

---

Step 3: Observe telemetry session state on the device (what the device reports)

What we are doing: We show how to inspect telemetry receiver/session state on the device to confirm whether an external collector has connected or whether push telemetry is being delivered.

show telemetry ietf receivers
Receiver: 10.1.1.3 port 57500 protocol grpc-tcp
Transport-state: connected
Active-subscriptions: 1
Subscription IDs: 1
Last-receive-time: 00:00:30

What just happened:

• show telemetry ietf receivers lists all telemetry receivers configured or active on the device.
• The output confirms the receiver IP/port/protocol, the connection state, subscription count, and last time data was sent/received. This is how the device presents the runtime view of telemetry connections.

Real-world note: If the collector uses dial-in gNMI to request a subscription, the device will show an active session for the gNMI client connection in its telemetry/gRPC session monitoring outputs.

Verify:

show telemetry ietf receivers
Receiver: 10.1.1.3 port 57500 protocol grpc-tcp
Transport-state: connected
Active-subscriptions: 1
Subscription IDs: 1
Last-receive-time: 00:00:30

• Verify Transport-state is connected and Active-subscriptions shows the expected subscription ID(s).

---

Step 4: Demonstrate the periodic data flow and check update timing

What we are doing: We verify that the periodic update-policy is functioning and that telemetry samples arrive at the expected interval. Because the subscription uses periodic 60000, we expect samples roughly every 60 seconds.

show telemetry ietf subscription 1 statistics
Subscription ID: 1
Samples-sent: 10
Samples-lost: 0
Average-latency-ms: 120
Configured-interval-ms: 60000
Last-sample-timestamp: 2026-04-02 10:12:00 UTC

What just happened:

• The show telemetry ietf subscription 1 statistics output provides operational metrics: samples sent, lost, latency, and the configured interval. This confirms the device is honoring the periodic policy and provides diagnostic data for troubleshooting jitter/loss.

Real-world note: Production collectors will monitor these metrics to ensure telemetry health; sudden increases in Samples-lost or latency indicate network or buffer issues.

Verify:

show telemetry ietf subscription 1 statistics
Subscription ID: 1
Samples-sent: 10
Samples-lost: 0
Average-latency-ms: 120
Configured-interval-ms: 60000
Last-sample-timestamp: 2026-04-02 10:12:00 UTC

---

Verification Checklist

• Check 1: Collector can connect to device gRPC endpoint — verify by running the gNOI client verify command and confirming output such as "Running OS version: 17.05.01.0.144.1617180620".
• Check 2: Device has active telemetry subscription ID 1 — verify with show telemetry ietf subscription 1 and confirm encoding, filter, receiver IP/port, and update-policy.
• Check 3: Telemetry receiver shows connected state and samples delivered — verify with show telemetry ietf receivers and show telemetry ietf subscription 1 statistics.

Common Mistakes

Symptom	Cause	Fix
Collector cannot connect to device at 10.85.134.92:9339	Port 9339 blocked by firewall or device management plane not reachable	Open TCP 9339 between collector and device or ensure management interface routing; test with a TLS-capable client from the collector host
No telemetry data received at 10.1.1.3:57500	Receiver IP/port misconfigured on device or collector not listening	Confirm receiver ipaddress 10.1.1.3 57500 is configured on device and the collector process is bound to that IP/port
Subscription reports high Samples-lost	Network packet loss or collector cannot keep up with incoming messages	Check network path for packet loss, increase collector resources, or increase update-policy interval to reduce rate
Encoding mismatch or unreadable payloads on collector	Collector expects JSON but device is sending GPB (encode -kvgpb)	Ensure collector is configured to decode GPB, or change subscription encoding to the model the collector supports

Key Takeaways

• Dial-in telemetry (collector-initiated) uses gNMI/gNOI over HTTP/2/gRPC (default device port example 9339) and is preferred when the collector must control subscriptions centrally or when devices are in restrictive network zones.
• The device-side subscription parameters (encoding, filter, stream, update-policy, receiver) determine what data is sent and how often; these same parameters are negotiated or requested by a collector during a dial-in session.
• Security matters: use mTLS (mutual TLS) for collector-device authentication in production. The example client used an -insecure option only for lab verification.
• Always verify both sides: device show telemetry ietf ... outputs and collector-side client output (for example, a gNOI/gNMI client) to confirm the full end-to-end telemetry flow.

Final tip: In production scale deployments, orchestration tools manage collector certificates and subscription lifecycle (dial-in) so operators rarely hand-edit device telemetry entries. Understanding the subscription fields and transport behavior is key to integrating monitoring platforms successfully.