18.4 Model-Driven Telemetry (MDT) & NETCONF/RESTCONF Operations

18.4 Model-Driven Telemetry (MDT) & NETCONF/RESTCONF Operations

Core Blueprint Focus: Cisco 350-401 ENCOR v1.2 topic 4.6 (configure and verify NETCONF and RESTCONF) requires candidates to configure, verify, and troubleshoot network programmability protocols and streaming telemetry. Candidates must master NETCONF (RFC 6241 over SSH port 830, XML encoding, RPC operations, and datastores), RESTCONF (RFC 8040 over HTTPS port 443, JSON/XML encoding, URI roots, and query parameters), and Model-Driven Telemetry (Dial-In vs. Dial-Out, Periodic vs. On-Change subscriptions, and gRPC/GPB transport).

Traditional network management relied on CLI screen-scraping for configuration and SNMP polling for monitoring. Modern network architectures replace these brittle mechanisms with NETCONF and RESTCONF for configuration management, and Model-Driven Telemetry (MDT) for real-time streaming assurance.

+---------------------------------------------------------------------------------------------------+
|                         PROGRAMMATIC MANAGEMENT PROTOCOL ARCHITECTURE                             |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  [ MANAGEMENT APPLICATION / COLLECTOR ] (Catalyst Center / InfluxDB / Prometheus / Python)        |
|         |                                      |                                    |             |
|         | 1. NETCONF (RFC 6241)                | 2. RESTCONF (RFC 8040)             | 3. MDT gRPC |
|         |    - SSH Port 830                    |    - HTTPS Port 443                |    - Port   |
|         |    - XML Encodings                   |    - JSON / XML Encodings          |      25103  |
|         |    - <rpc> Operations                |    - REST CRUD (GET/POST/PUT/PATCH)|   (Cat Ctr) |
|         v                                      v                                    v             |
|  ================================== CISCO IOS-XE DEVICE ========================================= |
|  |                                                                                              | |
|  |  +----------------------------------------------------------------------------------------+  | |
|  |  |                                   YANG DATA MODELS                                     |  | |
|  |  |   - Native (Cisco-IOS-XE-native)  - IETF (ietf-interfaces)  - OpenConfig (openconfig)  |  | |
|  |  +----------------------------------------------------------------------------------------+  | |
|  |          |                                   |                                   |           | |
|  |          v                                   v                                   v           | |
|  |  +-------------------+               +-------------------+               +----------------+  | |
|  |  | Running Datastore |<==============|Candidate Datastore|               |Operational DB /|  | |
|  |  | (Active Running)  |   <commit>    | (Staged Changes)  |               | Hardware ASICs |  | |
|  |  +-------------------+               +-------------------+               +----------------+  | |
|  ================================================================================================ |
+---------------------------------------------------------------------------------------------------+

1. NETCONF Protocol Architecture (RFC 6241)

NETCONF operates across a standardized four-layer stack:

+---------------------------------------------------------------------------------------------------+
|                             NETCONF 4-LAYER PROTOCOL STACK                                        |
+---------------------------------------------------------------------------------------------------+
|  Layer          | Implementation & Functions                                                      |
| :-------------- | :------------------------------------------------------------------------------ |
| **1. Transport**| **SSH (Secure Shell)** on **TCP Port 830** (Mandatory); TLS optional.           |
| **2. Messages** | **`<rpc>`** (Client-to-Server request), **`<rpc-reply>`** (Server-to-Client response),|
|                 | **`<notification>`** (Asynchronous event stream).                               |
| **3. Operations**| Standardized RPCs: `<get>`, `<get-config>`, `<edit-config>`, `<copy-config>`,     |
|                 | `<delete-config>`, `<lock>`, `<unlock>`, `<commit>`, `<discard-changes>`, etc.  |
| **4. Content**  | Data modeled using **YANG schemas** and encoded in **XML**.                     |
+---------------------------------------------------------------------------------------------------+

NETCONF Datastores

A datastore is a conceptual database storing configuration information on the network device:

1. running: Contains the active, operational configuration currently running on the device. All NETCONF devices must support the running datastore.
2. candidate: A staging datastore where configuration changes can be prepared, edited, and validated without immediately affecting the live network. Changes become active only when the client issues a <commit> RPC.
3. startup: Non-volatile configuration loaded when the device reboots (equivalent to startup-config in NVRAM).

+---------------------------------------------------------------------------------------------------+
|                         NETCONF DATASTORE STATE TRANSITIONS                                       |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|   +-------------------+        <edit-config>         +--------------------+                       |
|   |  NETCONF Client   | ---------------------------> | Candidate Datastore|                       |
|   +-------------------+                              +--------------------+                       |
|             |                                                  |                                  |
|             | <commit>                                         | Merges / Replaces                |
|             +------------------------------------------------> v                                  |
|             |                                        +--------------------+                       |
|             | <get> / <get-config>                   | Running Datastore  |                       |
|             +--------------------------------------> | (Active Config)    |                       |
|             |                                        +--------------------+                       |
|             | <copy-config>                                    |                                  |
|             | (source=running, target=startup)                 | Copies to NVRAM                  |
|             +------------------------------------------------> v                                  |
|                                                      +--------------------+                       |
|                                                      | Startup Datastore  |                       |
|                                                      +--------------------+                       |
+---------------------------------------------------------------------------------------------------+

Core NETCONF RPC Operations

• <get-config>: Retrieves configuration data only from a specified datastore (running, candidate, startup) filtered by XML subtree or XPath.
• <get>: Retrieves both configuration data and operational/state data (hardware counters, ARP tables, routing entries).
• <edit-config>: Modifies configuration in a target datastore. Supports attribute operations: operation="merge" (default), replace, create, delete, and remove.
• <copy-config>: Copies an entire datastore to another (e.g., from running to startup).
• <delete-config>: Deletes a non-running target datastore (candidate or startup).
• <lock> / <unlock>: Acquires an exclusive lock on a datastore to prevent concurrent conflicting edits by other administrators or automation scripts.
• <commit>: Atomically applies changes from the candidate datastore to the running datastore.
• <discard-changes>: Reverts the candidate datastore back to the current state of running.
• <validate>: Verifies the syntactic and semantic correctness of a datastore before committing.
• <close-session> / <kill-session>: Gracefully terminates or aborts an active NETCONF session.

Real NETCONF XML Transaction Example

<!-- 1. Client initiates <edit-config> to update Loopback100 description -->
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>Loopback100</name>
          <description>Configured via NETCONF XML RPC</description>
          <enabled>true</enabled>
        </interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>
]]>]]>

<!-- 2. Device responds with success confirmation -->
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>
]]>]]>

Enabling NETCONF on Cisco IOS-XE

! Enable NETCONF-YANG subsystem on Cisco IOS-XE (Listens on TCP Port 830)
Switch(config)# netconf-yang

! Verify NETCONF status and active sessions
Switch# show netconf-yang status
NETCONF-YANG status: enabled

Switch# show netconf-yang sessions
Rcvd-msg-id  Sent-msg-id  In-drops  Out-drops  Username  Client-IP
101          101          0         0          admin     192.168.1.100

2. RESTCONF Protocol Architecture (RFC 8040)

RESTCONF provides a REST-like programmatic interface over HTTPS to access data models defined in YANG. It operates over TCP port 443 and supports both JSON and XML data encodings.

RESTCONF Root Resource URIs

RESTCONF defines three primary root entry points located beneath the /restconf URI path:

1. /restconf/data/: Entry point for all datastore resources (both configuration and operational state data defined in YANG modules). Example: https://<ip>/restconf/data/ietf-interfaces:interfaces.
2. /restconf/operations/: Entry point for executing RPC operations defined within YANG modules. Example: https://<ip>/restconf/operations/cisco-ia:save-config.
3. /restconf/yang-library-version: Queries the specific YANG library version supported by the device server.

RESTCONF Media Types (MIME Headers)

• JSON Data: Content-Type: application/yang-data+json / Accept: application/yang-data+json
• XML Data: Content-Type: application/yang-data+xml / Accept: application/yang-data+xml
• YANG Patch: Content-Type: application/yang-patch+json

Mapping HTTP Verbs to NETCONF Operations

+---------------------------------------------------------------------------------------------------+
|                         RESTCONF VERBS TO NETCONF RPC MAPPING                                     |
+---------------------------------------------------------------------------------------------------+
|  HTTP Verb  | NETCONF RPC Equivalent   | Functional Behavior in RESTCONF                          |
| :---------- | :----------------------- | :------------------------------------------------------- |
| **GET**     | `<get-config>` or `<get>`| Retrieves configuration or operational data from target.  |
| **POST**    | `<edit-config>` (create) | Creates a child resource or invokes a YANG RPC action.   |
| **PUT**     | `<edit-config>` (replace)| Creates or completely replaces the target data resource.  |
| **PATCH**   | `<edit-config>` (merge)  | Partially updates specific fields without modifying others|
| **DELETE**  | `<edit-config>` (delete) | Deletes the targeted data resource from the datastore.   |
+---------------------------------------------------------------------------------------------------+

RESTCONF Query Parameters

• ?content=config: Retrieves configuration data only (config true).
• ?content=nonconfig: Retrieves operational/state data only (config false).
• ?content=all: Retrieves both configuration and operational state (default behavior for GET).
• ?depth=N: Limits the depth of nested child containers returned in the response.
• ?fields=...: Filters response to include only specific attributes.

Real RESTCONF Transaction Examples

# 1. Retrieve interface configuration in JSON format via cURL
curl -k -X GET "https://192.168.1.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1" \
     -u "admin:Cisco123!" \
     -H "Accept: application/yang-data+json"

# JSON Response Payload:
# {
#   "ietf-interfaces:interface": {
#     "name": "GigabitEthernet1",
#     "description": "Uplink to Distribution Switch",
#     "type": "iana-if-type:ethernetCsmacd",
#     "enabled": true,
#     "ietf-ip:ipv4": {
#       "address": [
#         {
#           "ip": "10.10.10.1",
#           "netmask": "255.255.255.0"
#         }
#       ]
#     }
#   }
# }

# 2. Modify interface description using HTTP PATCH
curl -k -X PATCH "https://192.168.1.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1" \
     -u "admin:Cisco123!" \
     -H "Content-Type: application/yang-data+json" \
     -d '{"ietf-interfaces:interface": {"description": "Updated via RESTCONF PATCH"}}'

Enabling RESTCONF on Cisco IOS-XE

! Enable RESTCONF subsystem on Cisco IOS-XE (Listens on HTTPS Port 443)
Switch(config)# ip http secure-server
Switch(config)# restconf

! Verify RESTCONF process status
Switch# show platform software yang-management process
       Process Name      State
---------------------------------
           nesd          Running
          syncfd         Running
          restconf       Running
        netconf-yang     Running

3. Model-Driven Telemetry (MDT) Architecture

Model-Driven Telemetry (MDT) replaces the legacy pull-based polling model (SNMP) with a modern, high-performance push-based streaming model.

+---------------------------------------------------------------------------------------------------+
|                         LEGACY SNMP POLLING VS. STREAMING TELEMETRY (MDT)                         |
+---------------------------------------------------------------------------------------------------+
|  Attribute             | Legacy SNMP Monitoring          | Model-Driven Telemetry (MDT)   |
| :--------------------- | :------------------------------ | :----------------------------- |
| **Data Flow Paradigm** | **Pull Model** (Manager polls)  | **Push Model** (Device streams)|
| **Data Schema**        | Unstructured MIBs / OIDs         | Structured **YANG Models**      |
| **CPU Utilization**    | High CPU overhead on walks      | Low CPU; generated at kernel/ASIC|
| **Streaming Frequency**| 5 to 15 minute polling cycles   | Sub-second to real-time stream |
| **Micro-burst Detection| Misses transient spikes & bursts| Captures micro-bursts & flaps  |
| **Transport Protocol** | UDP Port 161 (Unreliable)        | gRPC (HTTP/2), NETCONF, RESTCONF|
+---------------------------------------------------------------------------------------------------+

Dial-In vs. Dial-Out Telemetry Sessions

1. Dial-In Telemetry (Collector-Initiated):

   • The telemetry collector initiates an inbound connection to the network device over gRPC (TCP port 57500) or NETCONF (TCP port 830).
   • Subscriptions are dynamic: created via RPC and automatically terminated when the management session closes.
   • Requires opening inbound firewall ports to network devices.

2. Dial-Out Telemetry (Device-Initiated):

   • The network device initiates an outbound connection to the telemetry collector (over gRPC; the receiver port is chosen by the collector — Cisco Catalyst Center listens on TCP 25103, while open-source collectors such as Telegraf or Cisco Pipeline commonly use TCP 57500).
   • Subscriptions are configured / persistent: stored in the device configuration (running-config) and survive device reboots.
   • Firewall-friendly: Access switches in branch networks can initiate outbound sessions through stateful firewalls without requiring inbound firewall holes.

Subscription Types: Periodic vs. On-Change

• Periodic (Cadence-Based) Subscriptions: The device pushes telemetry updates at fixed, configured intervals (e.g., every 5000 centiseconds / 50 seconds). Ideal for continuous metrics like CPU utilization, memory consumption, interface byte counters, and temperature sensors.
• On-Change (Event-Driven) Subscriptions: The device pushes telemetry updates only when a state transition or threshold event occurs (e.g., an interface transitions between up and down, a BGP neighbor drops, or a CDP adjacency changes). Minimizes network bandwidth while providing instant event notification.

4. Telemetry Transports & Encodings

MDT supports multiple transport and serialization encodings:

+---------------------------------------------------------------------------------------------------+
|                         TELEMETRY ENCODING & TRANSPORT MATRIX                                     |
+---------------------------------------------------------------------------------------------------+
|  Encoding Format        | Transport Protocol | Efficiency & Performance   | Primary Use Case     |
| :---------------------- | :----------------- | :------------------------- | :-------------------- |
| **KV-GPB (Key-Value)**  | **gRPC (HTTP/2)**  | High; Compact binary with  | Production streaming |
| **Google Protobuf**     |                    | keys embedded in payload   | to TSDB / Collectors  |
| **Self-Describing GPB** | **gRPC (HTTP/2)**  | Moderate; Includes full    | Dynamic decoding      |
|                         |                    | .proto schema in stream    | without local .proto  |
| **JSON Encoding**       | RESTCONF / HTTPS   | Moderate; Human-readable   | Webhook integrations |
| **XML Encoding**        | NETCONF / SSH      | Lower; Verbose text tags   | NETCONF collectors    |
+---------------------------------------------------------------------------------------------------+

Configuring Model-Driven Telemetry on Cisco IOS-XE

! Configure Dial-Out Periodic Telemetry Subscription for Interface Statistics
Router(config)# telemetry ietf subscription 101
Router(config-mdt-sub)# encoding encode-kvgpb
Router(config-mdt-sub)# filter xpath /ietf-interfaces:interfaces-state/interface/statistics
Router(config-mdt-sub)# stream yang-push
Router(config-mdt-sub)# update-policy periodic 1000
Router(config-mdt-sub)# receiver ip address 10.100.200.50 25103 protocol grpc-tcp

! Configure Dial-Out On-Change Telemetry Subscription for Interface Operational State
Router(config)# telemetry ietf subscription 102
Router(config-mdt-sub)# encoding encode-kvgpb
Router(config-mdt-sub)# filter xpath /ietf-interfaces:interfaces/interface/oper-status
Router(config-mdt-sub)# stream yang-push
Router(config-mdt-sub)# update-policy on-change
Router(config-mdt-sub)# receiver ip address 10.100.200.50 25103 protocol grpc-tcp

Verifying Telemetry Subscriptions

! Verify all configured MDT subscriptions
Router# show telemetry ietf subscription all
  Subscription ID: 101
  Type: Configured
  State: Valid
  Stream: yang-push
  Filter: /ietf-interfaces:interfaces-state/interface/statistics
  Update Policy: periodic (1000 centiseconds)
  Encodings: encode-kvgpb
  Receivers:
    Address: 10.100.200.50  Port: 25103  Protocol: grpc-tcp  State: Connected

  Subscription ID: 102
  Type: Configured
  State: Valid
  Stream: yang-push
  Filter: /ietf-interfaces:interfaces/interface/oper-status
  Update Policy: on-change
  Encodings: encode-kvgpb
  Receivers:
    Address: 10.100.200.50  Port: 25103  Protocol: grpc-tcp  State: Connected

5. Comprehensive Protocol Comparison Matrix