Model-Driven Telemetry

Objective

In this lesson you will configure model‑driven telemetry on an IOS‑XE router to demonstrate both dial‑in and dial‑out telemetry subscriptions. You will enable NETCONF and RESTCONF (dial‑in interfaces), configure a gRPC/gNMI-style dial‑out destination, create a model‑driven subscription that streams interface operational state, and verify the telemetry streams. This matters in production because streaming telemetry provides high‑frequency, structured operational data with far lower CPU and collection overhead than polling via SNMP — useful for real‑time monitoring, capacity planning, and automated analytics pipelines.

Real‑world scenario: An enterprise operates hundreds of campus and branch devices. A central telemetry collector must receive interface counters and state changes in near real time. You will configure the device to (a) accept programmatic clients (NETCONF/RESTCONF) for on‑demand reads and (b) push streaming telemetry (gRPC/gNMI‑style dial‑out) to a central collector.

Topology (quick visual recap from Lesson 1)

ASCII diagram showing the router and collector used in this lesson. Each interface shows the exact IP used in the lab.

R1 is the IOS‑XE device that will host NETCONF/RESTCONF and the telemetry subscription. COLLECTOR is a telemetry server (gRPC/gNMI receiver).

[R1 IOS-XE] GigabitEthernet0/0 10.0.0.1/24 ----- GigabitEthernet0 10.0.0.2/24 [COLLECTOR Linux]

Device Table

Device	Hostname	Interface	IP Address
Router	R1	Gi0/0	10.0.0.1
Server	COLLECTOR	Gi0	10.0.0.2

Tip: In production you would register multiple collectors (for redundancy) and secure transport with TLS/mTLS. Here we use a single collector to keep the lab focused on telemetry mechanics.

Key Concepts (theory before hands‑on)

• Model‑driven telemetry vs. polling: Model‑driven telemetry uses YANG models to represent data and streams that data on subscriptions. It is event/period driven and more efficient than periodic SNMP polling. In IOS‑XE this is available via several transports (gNMI/gRPC dial‑out is common).
• Dial‑in vs. Dial‑out patterns:
  • Dial‑in means external clients connect to the device’s management APIs (NETCONF on port 830, RESTCONF on 443). The device must have the protocol enabled and authentication configured. The client initiates the session.
  • Dial‑out means the device initiates a connection and sends telemetry to configured destinations (gRPC/gNMI, gNOI). This is commonly used to traverse NATs/firewalls where devices can reach a central collector.
• Encoding & transport: Telemetry encodings can be JSON, GPB‑KV (protobuf) or other forms. Transport examples include gRPC for gNMI (port 9339) and NETCONF over SSH (port 830). Encodings and transports affect bandwidth and parsing on the collector.
• YANG models and sensor paths: Subscriptions reference YANG model paths (for example, the interface operational-state model). The collector must understand the YANG modules used by the device to decode the streamed data.
• Security: NETCONF uses SSH and can leverage PKI or passwords. RESTCONF uses HTTPS. gRPC/gNMI commonly uses TLS/mTLS (mutual TLS) for authentication. In production, always use certificates and secure transport.

Step‑by‑step configuration

Step 1: Enable NETCONF and RESTCONF (dial‑in)

What we are doing: Enable the device to accept programmatic management sessions via NETCONF (SSH on port 830) and RESTCONF (HTTPS on 443). This allows external tooling (YANG Suite, Postman, ncclient) to perform model‑driven reads and edits.

configure terminal
netconf-yang
restconf
end

What just happened:

• netconf-yang instructs IOS‑XE to enable the NETCONF server (NETCONF over SSH) so clients can connect to port 830 and use YANG/NETCONF operations (get, get-config, edit-config, establish-subscription where supported).
• restconf enables the RESTCONF HTTP API on HTTPS port 443 so clients can perform RESTful GET/POST/PUT/PATCH/DELETE against YANG data. Enabling both gives management systems flexibility to use XML (NETCONF) or JSON/REST (RESTCONF).

Real‑world note: In production, you should configure AAA and certificates for NETCONF/RESTCONF, and restrict access via management VRF or ACLs to management stations only.

Verify:

show netconf-yang status

Expected output:

Netconf-yang server status
  Server: Enabled
  Listening for SSH connections on port 830
  Active sessions: 0

show restconf

Expected output:

Restconf server status
  Server: Enabled
  Listening on HTTPS port 443
  TLS: Not showing certificate configuration in this lab
  Active sessions: 0

Step 2: Configure a telemetry destination (dial‑out)

What we are doing: Define a telemetry destination group that points to the collector (10.0.0.2). For dial‑out streaming the router will initiate a connection to this host and push telemetry. Destination configuration includes the collector IP and transport/port.

configure terminal
telemetry model-driven
 destination-group COLLECTOR
  destination 10.0.0.2 port 50051
  encoding gpblite
  transport grpc-tcp
 exit
end

What just happened:

• telemetry model-driven enters the telemetry configuration context.
• destination-group COLLECTOR creates a named group so subscriptions can reference it. Grouping is useful to apply the same collector parameters to multiple subscriptions.
• destination 10.0.0.2 port 50051 adds the collector IP and port (gRPC default collector port often used by telemetry collectors).
• encoding gpblite sets protobuf-based compact encoding, which reduces bandwidth compared to JSON.
• transport grpc-tcp selects gRPC over TCP as the transport for the dial‑out stream.

Real‑world note: Use TLS/mTLS port numbers and certificates for secure dial‑out. Many collectors listen on 50051 for gRPC; tools like gnmic can accept these streams.

Verify:

show telemetry model-driven destination-group

Expected output:

Telemetry Model-Driven Destination Groups
Group Name: COLLECTOR
  Destination: 10.0.0.2
  Port: 50051
  Encoding: gpblite
  Transport: grpc-tcp
  Status: Ready

Step 3: Create a model‑driven subscription (interface operational state)

What we are doing: Create a subscription that streams interface operational state using a YANG sensor path. The subscription references the destination group so the router knows where to send the pushed data.

configure terminal
telemetry model-driven
 subscription SUB_INTERFACES
  sensor-path Cisco-IOS-XE-interfaces:interfaces/interface/state
  period 10000
  destination-group COLLECTOR
 exit
end

What just happened:

• subscription SUB_INTERFACES defines a named telemetry subscription.
• sensor-path Cisco-IOS-XE-interfaces:interfaces/interface/state tells the device which YANG data to stream — here, the operational state of each interface using the IOS‑XE interfaces model. The payload will follow the YANG schema.
• period 10000 defines the collection interval in milliseconds (10 seconds). The device will sample the specified sensor path every 10 seconds and stream changes.
• destination-group COLLECTOR binds this subscription to the previously defined destination so the router knows where to deliver the telemetry.

Real‑world note: In production, choose appropriate polling intervals and consider event triggers (on-change) for state that only needs to be sent on changes to reduce traffic.

Verify:

show telemetry model-driven subscription

Expected output:

Telemetry Model-Driven Subscriptions
Subscription Name: SUB_INTERFACES
  Sensor Path: Cisco-IOS-XE-interfaces:interfaces/interface/state
  Period: 10000 ms
  Destination-Group: COLLECTOR
  Status: Active
  Last Sent: 00:00:07 ago

Step 4: Observe active NETCONF/RESTCONF sessions (dial‑in) and telemetry streams

What we are doing: Confirm that NETCONF/RESTCONF are listening and show active sessions; also view telemetry stream status to verify the router is successfully connecting to the collector and sending data.

show netconf-yang sessions

Expected output:

Netconf-yang active sessions:
Session ID: 0
Total sessions: 0

If a client connects, you would see an entry like:

Session ID: 1
Client: 10.0.0.100:54123
Username: telemetry_user
Transport: SSH
Start Time: 2026-04-02 10:12:34
Last Activity: 2026-04-02 10:12:40

show telemetry model-driven stream statistics

Expected output:

Telemetry Model-Driven Stream Statistics
Subscription: SUB_INTERFACES
  Destination: 10.0.0.2:50051
  Sent Samples: 6
  Last Sample Sent: 2026-04-02 10:12:40
  Connection State: Up
  Bytes Sent: 4820

What just happened:

• The show netconf-yang sessions command displays active NETCONF clients; zero indicates no dial‑in clients are currently connected.
• The telemetry stream statistics show the subscription is active and that samples have been sent to the collector (Sent Samples and Connection State confirm successful dial‑out).

Real‑world note: If the connection state is Down, verify collector reachability, firewall rules, and that the collector accepts the gRPC/TLS connection on the configured port.

Step 5: Perform an on‑demand RESTCONF read (example)

What we are doing: Demonstrate a RESTCONF GET of the interface operational data to show dial‑in behavior. Typically this would be performed from an external client (Postman, curl). For lab clarity we show the expected device output when a RESTCONF read occurs.

! On the collector or management host you would run (example curl command):
curl -k -u admin:Lab@123 https://10.0.0.1/restconf/data/Cisco-IOS-XE-interfaces:interfaces/interface=GigabitEthernet0/0/state

Expected output (JSON, abbreviated to show structure but complete for the interface):

{
  "Cisco-IOS-XE-interfaces:state": {
    "name": "GigabitEthernet0/0",
    "oper-status": "up",
    "admin-status": "up",
    "oper-speed": "1000mbps",
    "in-octets": 1234567,
    "out-octets": 7654321
  }
}

What just happened:

• RESTCONF GET retrieves live operational data for the specified YANG resource. This is a dial‑in operation: the client initiated the connection to the router RESTCONF endpoint on HTTPS/443 and received structured JSON data modeled by the YANG module.

Real‑world note: Use clients that understand YANG models so the JSON can be translated into meaningful metrics in monitoring systems.

Verification Checklist

• Check 1: NETCONF is enabled and listening on port 830 — verify with show netconf-yang status and confirm server is Enabled and port 830 is listed.
• Check 2: RESTCONF is enabled and listening on port 443 — verify with show restconf and confirm server is Enabled and listening on HTTPS port 443.
• Check 3: Dial‑out telemetry destination and subscription are Active — verify show telemetry model-driven destination-group shows the collector and show telemetry model-driven subscription / show telemetry model-driven stream statistics show Active/Up and Sent Samples.

Common Mistakes

Symptom	Cause	Fix
Telemetry subscription Status: Down / Connection State: Down	Collector unreachable (routing, firewall) or wrong destination IP/port	Verify IP reachability (ping), ACLs, firewall rules; correct destination-group config and port
No data arriving at collector even though subscription is Active	Collector not accepting gRPC (wrong protocol/encoding) or TLS mismatch	Ensure collector listens on configured port/protocol, matches encoding (gpblite/JSON) and TLS settings (certificate trust)
NETCONF/RESTCONF clients cannot authenticate	AAA not configured or wrong credentials	Configure local/AAA users or certificates for NETCONF/RESTCONF, verify username/password or PKI
Subscription shows Sent Samples but collector shows parse errors	Collector lacks YANG models or uses wrong decoding	Ensure collector has the device YANG models (Cisco-IOS-XE modules) or use a parser that supports GPB/JSON encodings
High CPU on device after enabling frequent subscriptions	Subscription period too small or too many sensors	Increase period, reduce sensor paths, or move heavy telemetry to event/on-change to reduce load

Key Takeaways

• NETCONF (port 830) and RESTCONF (port 443) provide dial‑in mechanisms for model‑driven reads and writes; enable them to allow programmatic management. Always secure them with AAA and certificates in production.
• Dial‑out telemetry lets the device push data to a collector (gRPC/gNMI) and scales well for large fleets because devices initiate the connection to central collectors. Use destination groups and subscriptions to organize streams.
• Choose encoding and period carefully: protobuf/gpblite is bandwidth efficient; JSON is human‑friendly. Use on‑change streaming for state changes to reduce unnecessary samples.
• Verification commands (show netconf-yang, show restconf, show telemetry model-driven subscription/destination-group/stream statistics) confirm the device is accepting clients and successfully sending telemetry; always check both device and collector logs to troubleshoot.

Final real‑world insight: In production telemetry deployments you will pair these device configurations with a robust collector (that supports YANG modules and the chosen transport), certificate management for mTLS, and pipeline tooling for decoding and storing the streamed telemetry (time‑series DBs, analytics engines). Monitoring both the device telemetry stats and the collector health is essential to maintain reliable observability.