ExamFinch.com My Study

Study guide

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

Practice this exam

CCNP Enterprise ENCOR 350-401

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Enterprise Architecture & Hierarchical Design

1.1 Enterprise Network Design Models & Hierarchical Campus Architecture 1.2 On-Premises, Cloud & Hybrid Infrastructure Deployment Models 1.3 Hardware Switching Architecture & Packet Forwarding

2 Chapter 2: Enterprise Quality of Service (QoS)

2.1 QoS Components: Classification, Marking & Trust Boundaries 2.2 QoS Policy: Queuing, Shaping, Policing & Interpreting MQC Output

3 Chapter 3: Software-Defined WAN (Catalyst SD-WAN)

3.1 Cisco Catalyst SD-WAN Architecture & Orchestration 3.2 SD-WAN Policies, Traffic Engineering & Application-Aware Routing

4 Chapter 4: Software-Defined Access (Catalyst SD-Access)

4.1 Catalyst SD-Access Fabric Architecture & Plane Separation 4.2 Cisco TrustSec, Security Group Tags (SGT), SXP & MACsec

5 Chapter 5: Device & Data Path Virtualization

5.1 Server & Network Device Virtualization 5.2 VRF-Lite & Virtual Routing Multi-Tenancy 5.3 GRE & IPsec Tunnel Virtualization Mechanics

6 Chapter 6: Network Virtualization & Overlay Technologies

6.1 LISP Architecture & EID-to-RLOC Mapping Mechanics 6.2 VXLAN & EVPN Overlay Architecture

7 Chapter 7: Layer 2 Infrastructure & Switching

7.1 VLANs, 802.1Q Trunking & VTPv3 7.2 Spanning Tree Protocol Mechanics 7.3 Advanced STP Protection Mechanisms 7.4 EtherChannel Link Aggregation

8 Chapter 8: Layer 3 Routing Foundations & EIGRP

8.1 IP Routing Foundations & Administrative Distance 8.2 Enhanced Interior Gateway Routing Protocol (EIGRP)

9 Chapter 9: OSPFv2 & OSPFv3 Operations

9.1 OSPFv2 Architecture & Neighbor State Machine 9.2 OSPF LSA Types & Multi-Area Design 9.3 OSPFv3 for IPv4 and IPv6 Address Families

10 Chapter 10: Border Gateway Protocol (BGP)

10.1 BGP Architecture, Neighbor States & Peering 10.2 BGP Path Attributes & Best Path Selection Algorithm

11 Chapter 11: Policy-Based Routing & Route Redistribution

11.1 Policy-Based Routing (PBR) & Route Maps 11.2 Route Redistribution & Loop Prevention

12 Chapter 12: IP Services & High Availability

12.1 First Hop Redundancy Protocols (HSRP, VRRP & GLBP) 12.2 Network Time Protocol (NTPv4) & Precision Time Protocol (PTP) 12.3 Network Address Translation (NAT/PAT) & VRF-Aware NAT

13 Chapter 13: IP Multicast Operations

13.1 IP Multicast Addressing, Group Management (IGMPv1/v2/v3) & IGMP Snooping 13.2 Protocol Independent Multicast (PIM-SM, PIM-SSM & Bidir-PIM) 13.3 Rendezvous Point (RP) Distribution Mechanisms

14 Chapter 14: Network Assurance & Monitoring

14.1 Diagnostic Utilities, Conditional Debugging & Path MTU Discovery 14.2 Syslog Architecture, Logging Facilities & Severity Levels 14.3 SNMPv1/v2c/v3 Security & Flexible NetFlow (FNF) Architecture 14.4 Switched Port Analyzer (SPAN, RSPAN, ERSPAN) & IP SLA Object Tracking

15 Chapter 15: Catalyst Center Assurance & Controller Operations

15.1 Cisco Catalyst Center (DNA Center) Assurance & AI Network Analytics 15.2 Cisco Catalyst Center Device Onboarding & Software Image Management (SWIM)

16 Chapter 16: Enterprise Security & Access Control

16.1 Device Hardening, AAA Architecture & RADIUS/TACACS+ 16.2 Access Control Lists (ACLs) for Infrastructure Security 16.3 Control Plane Policing (CoPP) & Control Plane Protection (CPPr) 16.4 Layer 2 Infrastructure Security Features 16.5 IEEE 802.1X Port-Based Authentication & MAB

17 Chapter 17: Threat Defense & API Security

17.1 Enterprise VPN Technologies (DMVPN Phase 1/2/3 & FlexVPN) 17.2 Next-Generation Threat Defense & Secure Access Service Edge (SASE)

18 Chapter 18: Network Automation, Programmability & Data Modeling

18.1 Python Fundamentals for Network Engineers & Cisco Libraries 18.2 YANG Data Modeling Language (RFC 6020/7950) & Model Types 18.3 REST API Architecture, HTTP Verbs, Security & Cisco Controller APIs 18.4 Model-Driven Telemetry (MDT) & NETCONF/RESTCONF Operations

19 Chapter 19: Orchestration, EEM & AI Operations

19.1 Configuration Management & Infrastructure as Code (Ansible & Terraform) 19.2 Cisco Embedded Event Manager (EEM) & Intent-Based Networking

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

Key Takeaways Explain This Topic AI

NETCONF (RFC 6241) operates over SSH (TCP port 830) using XML-encoded Remote Procedure Calls (RPCs) across a four-layer architecture (Transport, Messages, Operations, Content) to manage configuration and state data.

NETCONF supports atomic datastore transactions across running (active state), candidate (staging area committed via <commit>), and startup (NVRAM boot config), utilizing RPCs like <get-config>, <edit-config>, <copy-config>, and <lock>.

RESTCONF (RFC 8040) is an HTTP-based protocol (TCP port 443) providing a lightweight RESTful interface to YANG data models, supporting both JSON and XML encodings with root resource paths /restconf/data/ and /restconf/operations/.

Model-Driven Telemetry (MDT) replaces legacy SNMP polling with a high-speed, push-based streaming architecture, pushing YANG-modeled operational data over Dial-In (collector-initiated) or Dial-Out (device-initiated, firewall-friendly) sessions.

MDT subscriptions operate in periodic (cadence-based) or on-change (event-driven) modes, leveraging Google Protocol Buffers (GPB / Protobuf) over gRPC or JSON/XML over NETCONF/RESTCONF for high-throughput, compact telemetry streams.

Last updated: August 2026

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:

running : Contains the active, operational configuration currently running on the device. All NETCONF devices must support the running datastore.

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.

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:

/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 .

/restconf/operations/ : Entry point for executing RPC operations defined within YANG modules. Example: https://<ip>/restconf/operations/cisco-ia:save-config .

/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

Loading diagram... Model-Driven Telemetry Dial-In vs Dial-Out Architecture

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

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.

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

  • Operational Feature NETCONF (RFC 6241) RESTCONF (RFC 8040) MDT (Streaming Telemetry) SNMPv3 (RFC 3411)
  • Primary Role Configuration & State Configuration & State Streaming Operational State Monitoring & Traps
  • Transport Layer SSH (Port 830) / TLS HTTPS (Port 443) gRPC (HTTP/2) / NETCONF UDP (Port 161/162)
  • Data Modeling YANG (RFC 6020/7950) YANG (RFC 6020/7950) YANG (RFC 6020/7950) SMIv2 MIBs
  • Data Encoding XML JSON / XML GPB (Protobuf) / JSON ASN.1 BER

Datastore Support running , candidate , startup Direct datastore access N/A (Streams telemetry) N/A (Direct OID walk)

  • Transactions Full rollback & <commit> Single-transaction CRUD N/A None (Individual OID sets)
  • Data Flow Mode Bi-directional RPC Request / Response Push (Dial-In & Dial-Out) Pull (Polling) / Push (Traps)
  • Security SSH Keys / Passwords TLS Certificates / Basic Auth TLS / Token-based gRPC USM (AuthPriv / HMAC / AES)