ExamFinch.com My Study

Study guide

10.3 Model-Driven Telemetry and Programmable Interfaces: NETCONF and RESTCONF Verification

Practice this exam

Cisco ENCOR 350-401 CCNP Enterprise Core

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

0.1 Cisco 350-401 ENCOR Exam Logistics, Blueprint Structure, and Certification Paths 0.2 Preparation Strategy, Lab Environment Setup, and Practical Test Pacing

2 Enterprise Campus Architecture and High Availability

1.1 Enterprise Network Design: Two-Tier, Three-Tier, Fabric, and Cloud Architectures 1.2 High Availability Architecture: Device Redundancy, FHRPs, and Stateful Switchover (SSO) 1.3 Quality of Service (QoS) Architecture, Classification, Queuing, and Configuration Interpretation

3 Cisco Software-Defined Architecture: SD-WAN and SD-Access

2.1 Cisco Catalyst SD-WAN: Control, Management, and Data Planes 2.2 Cisco SD-Access Architecture: Control Plane, Data Plane, and Fabric Node Roles 2.3 SD-Access Campus Interoperability: Integrating Traditional Networks with Fabric

4 Device and Network Virtualization Technologies

3.1 Device Virtualization: Type 1/2 Hypervisors, Virtual Machines, and Virtual Switching 3.2 Data Path Virtualization: VRF-Lite, GRE Tunneling, and IPsec VPN Fundamentals 3.3 Network Virtualization Overlays: LISP and VXLAN Encapsulation Mechanics

5 Layer 2 Infrastructure: Trunking, EtherChannel, and Spanning Tree

4.1 802.1Q Trunking, Native VLAN, and Dynamic Trunking Protocol Troubleshooting 4.2 EtherChannel Bundling: Static, LACP, and PAgP Implementation and Verification 4.3 Spanning Tree Architecture: RSTP, MST, and STP Protection Mechanisms

6 Layer 3 Routing: OSPF Multi-Area and Protocol Comparison

5.1 Enterprise Routing Principles: Distance Vector vs. Link-State, EIGRP, and OSPF 5.2 OSPFv2 and OSPFv3 Multi-Area Architecture: LSAs, Area Types, and Summarization 5.3 Policy-Based Routing (PBR) Architecture, Configuration, and Route-Maps

7 Exterior Routing: BGP Peering and Path Selection

6.1 External BGP (eBGP) Peering, States, Neighbor Adjacencies, and Timers 6.2 BGP Path Attributes and the Step-by-Step Best Path Selection Algorithm

8 IP Services and First-Hop Redundancy

7.1 Time Synchronization: Network Time Protocol (NTP) and Precision Time Protocol (PTP) 7.2 Network Address Translation: Static NAT, Dynamic NAT, and PAT/Overload 7.3 First Hop Redundancy Protocols: HSRP and VRRP Implementation and Failover

9 IP Multicast Architecture and Protocols

8.1 Multicast Addressing, IGMPv2/v3 Host Membership, and the RPF Check 8.2 Protocol Independent Multicast Sparse Mode (PIM-SM) and Rendezvous Point Discovery 8.3 Anycast RP with MSDP, Source-Specific Multicast (SSM), and Bidirectional PIM

10 Network Diagnostics, Monitoring, and Telemetry

9.1 Network Diagnostic Tools: Conditional Debugging, Traceroute, SNMPv3, and Syslog Logging 9.2 Flexible NetFlow (FNF) Architecture: Flow Records, Exporters, and Monitors 9.3 Switched Port Analyzer: Local SPAN, Remote SPAN (RSPAN), and Encapsulated RSPAN (ERSPAN)

11 Performance Monitoring and Model-Driven Assurance

10.1 IP Service Level Agreements (IP SLA) Probes, Responder, and Route Tracking 10.2 Cisco Catalyst Center: Assurance Dashboards, AI Analytics, and Machine Reasoning Workflows 10.3 Model-Driven Telemetry and Programmable Interfaces: NETCONF and RESTCONF Verification

12 Device Access Control and AAA Architecture

11.1 Device Line Protection: Console, Aux, VTY, Local Authentication, and Privilege Levels 11.2 AAA Architecture: Comparing RADIUS vs. TACACS+ and Method List Configuration

13 Infrastructure Security: ACLs, CoPP, and API Security

12.1 IPv4 and IPv6 Access Control Lists (ACLs): Standard, Extended, and Named Rules 12.2 Control Plane Policing (CoPP): Protecting the Route Processor with MQC 12.3 REST API Security: Token Authentication, TLS Transport, and Rate Limiting

14 Enterprise Network Security Design: ISE, TrustSec, and MACsec

13.1 Endpoint Security Architecture: 802.1X, Cisco ISE Posture, and Profiling 13.2 Next-Generation Firewalls (FTD) and Enterprise Threat Defense Design 13.3 Cisco TrustSec (Security Group Tags) and MACsec (802.1AE) Layer 2 Encryption

15 Network Automation Fundamentals: Python, JSON, and YANG

14.1 Python Fundamentals for Network Engineers: Data Types, Control Flow, and Libraries 14.2 JSON Data Encoding: Syntax, Formatting Rules, and Python Serialization 14.3 YANG Data Modeling: Modules, Tree Structures, and Data Representation

16 Controller REST APIs and RESTCONF Implementation

15.1 Cisco Catalyst Center Intent APIs and Authentication Workflows 15.2 Cisco Catalyst SD-WAN Manager (vManage) REST APIs and Device Interaction 15.3 RESTCONF Protocol Operations: HTTP Verbs, Datastores, and Response Codes

17 Event-Driven Automation and Infrastructure Orchestration

16.1 Cisco Embedded Event Manager (EEM) Applet Architecture and Event Detectors 16.2 Configuration Management: Comparing Ansible, Puppet, Chef, and SaltStack 16.3 Infrastructure as Code (IaC) Principles with Terraform in Enterprise Networks

10.3 Model-Driven Telemetry and Programmable Interfaces: NETCONF and RESTCONF Verification

Key Takeaways Explain This Topic AI

Model-driven programmability replaces brittle CLI screen scraping and high-overhead SNMP polling with structured, standardized YANG data models (RFC 6020/7950) that explicitly separate operational state from configuration data.

Model-Driven Telemetry (MDT) utilizes a push-based streaming model over gRPC, NETCONF, or HTTP dial-out/dial-in connections, supporting continuous periodic cadence subscriptions and real-time on-change event triggers.

NETCONF (RFC 6241) operates over secure SSH transport on TCP port 830 using XML-encoded Remote Procedure Calls (RPCs), providing atomic configuration transactions across candidate, running, and startup datastores.

RESTCONF (RFC 8040) delivers a stateless, web-friendly HTTP/HTTPS interface on TCP port 443 with JSON or XML payloads, accessing YANG-modeled resources via structured URIs (/restconf/data/... and /restconf/operations/...).

HTTP verbs in RESTCONF directly map to NETCONF RPC capabilities: GET retrieves data, POST creates resources or invokes RPCs, PUT creates or replaces resources, PATCH performs partial in-place merges, and DELETE removes resources.

Last updated: October 2026

Model-Driven Telemetry and Programmable Interfaces: NETCONF and RESTCONF Verification

For over three decades, enterprise network management relied on two primary mechanisms: Command-Line Interface (CLI) screen scraping over Telnet/SSH and the Simple Network Management Protocol (SNMP) . While effective for small networks, these legacy technologies represent major bottlenecks in large-scale modern enterprise environments.

CLI scraping relies on unstructured text formatted for human terminal display. A minor software update that alters whitespace, reorders output columns, or modifies prompt syntax immediately breaks custom Python or Perl parsing scripts. Furthermore, SNMP operates on a periodic pull model : a central network management station (NMS) sequentially polls hundreds of devices over UDP port 161. In large campuses, polling intervals are restricted to 5, 10, or 15 minutes to avoid exhausting router CPU cycles. This coarse polling interval creates vast temporal blind spots, hiding microbursts, transient interface drops, and short-lived routing flaps.

To solve these challenges, modern network engineering implements Model-Driven Programmability and Model-Driven Telemetry (MDT) . By decoupling data models from transport protocols using YANG (RFC 6020/7950) , network devices expose deterministic, machine-readable interfaces via NETCONF (RFC 6241) and RESTCONF (RFC 8040) , providing robust automation, continuous streaming observability, and atomic configuration control.

Model-Driven Telemetry (MDT) Architecture

Model-Driven Telemetry transforms network monitoring from an inefficient 'pull' model to an event-driven, high-speed 'push' model . Instead of waiting for an external NMS to request statistics, the network device itself streams operational and state metrics directly to external collectors as data is generated. +-------------------------------------------------------------+

  • | TRADITIONAL PULL (SNMP) |
  • | NMS Collector ====== Polling Request (UDP 161) =====> Switch |
  • | NMS Collector <===== Response (High CPU Overhead) == Switch |
  • | (Coarse intervals: 5-15 mins; High control plane latency) |
  • +-------------------------------------------------------------+
  • +-------------------------------------------------------------+
  • | MODEL-DRIVEN TELEMETRY PUSH (MDT) |
  • | Telemetry Collector <====== Continuous Stream ======= Switch |
  • | (Sub-second intervals; Periodic cadence or On-Change) |
  • | (gRPC / TCP / Protocol Buffers) |
  • +-------------------------------------------------------------+
  • Subscription Modes: Periodic vs. On-Change

Telemetry collection pipelines support two distinct subscription models based on data volatility:

Periodic (Cadence-Based) Subscriptions: The device streams telemetry samples continuously at configured, fixed time intervals (e.g., every 500 ms, 5 seconds, or 30 seconds). Periodic streaming is ideal for continuous, non-binary statistical counters such as interface byte/packet rates, CPU and memory utilization, optic laser power levels, and buffer queue depths.

On-Change Subscriptions: The device streams data only when an operational state change or threshold transition occurs . If an interface transitions from Up to Down, an OSPF neighbor relationship drops, or a power supply experiences a fault, telemetry is pushed immediately. When the state remains static, zero data is transmitted, drastically reducing network bandwidth consumption and collector storage requirements.

Session Architecture: Dial-In vs. Dial-Out

Model-Driven Telemetry sessions are established using two topological modes:

Operational Characteristic Dial-In Telemetry Mode Dial-Out Telemetry Mode

Connection Initiator External collector connects inbound to device Network device initiates outbound connection to collector

  • Transport Protocols NETCONF (SSH port 830) or gNMI over gRPC gRPC over TCP or TLS
  • Encoding Format XML or Google Protocol Buffers (protobuf) Google Protocol Buffers (compact binary) or JSON

Session Persistence Maintained by collector; terminates if dropped Managed by device; automatically reconnects to backup

Firewall & NAT Traversal Difficult; requires opening inbound device ports Seamless; outbound traffic permitted by stateful firewalls

Scalability Lower; collector must track device reachability Exceptional; optimal for hyperscale enterprise monitoring

NETCONF Protocol Architecture (RFC 6241)

Standardized by the IETF in RFC 6241, the Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete configurations on network devices. Unlike SNMP, NETCONF provides strict transaction safety, configuration rollbacks, and explicit separation between configuration and operational data.

The NETCONF Four-Layer Protocol Stack

NETCONF organizes communication into four distinct layers: +-------------------------------------------------------------+

  • | Layer 4: CONTENT | YANG Data Models (Cisco IOS-XE, |
  • | | OpenConfig, IETF) encoded in XML |
  • +-------------------------------------------------------------+
  • | Layer 3: OPERATIONS | <get>, <get-config>, <edit-config>, |
  • | | <copy-config>, <lock>, <commit> |
  • +-------------------------------------------------------------+
  • | Layer 2: MESSAGES | <rpc>, <rpc-reply>, <hello> |
  • +-------------------------------------------------------------+
  • | Layer 1: TRANSPORT | Secure Shell (SSH) on TCP Port 830 |
  • +-------------------------------------------------------------+

Secure Transport Layer: Operates primarily over SSH on TCP port 830 (or TLS). Authentication leverages existing SSH keys or AAA credentials, ensuring encrypted, authenticated transit.

Messages Layer: Encapsulates Remote Procedure Calls (RPCs) within <rpc> and <rpc-reply> XML tags, providing request-response transaction tracking via message IDs ( <rpc message-id='101'> ). During session establishment, devices exchange <hello> messages listing their supported capabilities and YANG namespaces.

Operations Layer: Defines standardized primitives executed by the client:

<get-config> : Retrieves all or part of a specified configuration datastore.

<get> : Retrieves running configuration data and non-configurable operational state (equivalent to show commands).

<edit-config> : Modifies a configuration datastore. Supports operations including merge, replace, create, and delete.

<copy-config> : Copies an entire configuration datastore to another (e.g., copying running to startup ).

<delete-config> : Deletes a non-running target datastore ( startup or candidate ).

<lock> / <unlock> : Locks a datastore to prevent simultaneous modifications by other management sessions.

<close-session> / <kill-session> : Gracefully terminates or aborts a NETCONF session.

Content Layer: The actual data payload, modeled strictly in YANG and encoded exclusively in XML format.

NETCONF Datastores

NETCONF defines logical abstractions representing complete device configurations:

running : Contains the active, operational configuration running on the device. All devices support this datastore.

startup : Contains the configuration loaded upon device boot (equivalent to NVRAM startup-config ).

candidate : A scratchpad staging datastore supported by modern modular operating systems. An engineer or automation controller pushes multiple <edit-config> changes into the candidate datastore, validates the syntax, and executes an atomic <commit> . If an error occurs, the candidate changes are discarded without impacting production traffic.

RESTCONF Protocol Architecture (RFC 8040)

While NETCONF provides robust transactional safety, web developers and automation engineers frequently prefer lightweight, RESTful architectures using HTTP semantics and JSON. Standardized in RFC 8040, RESTCONF is an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using NETCONF concepts.

Core Protocol Differences: NETCONF vs. RESTCONF

Transport: RESTCONF operates over HTTP or HTTPS (TCP port 443) rather than SSH port 830.

Data Encodings: While NETCONF strictly mandates XML, RESTCONF supports both JSON ( application/yang-data+json ) and XML ( application/yang-data+xml ).

Session State: NETCONF maintains stateful, persistent SSH sessions with locking mechanisms. RESTCONF is stateless , making it ideal for microservices and cloud automation pipelines.

Datastores: RESTCONF does not natively expose a candidate datastore; configuration edits applied via RESTCONF take effect immediately in the running datastore.

RESTCONF Root URI Structure

RESTCONF maps YANG models into standard, predictable Uniform Resource Identifiers (URIs). The root resource path begins at /restconf : https://<device-ip>:<port>/restconf/<root-resource>/<data-path>?<query-parameters>

The root path partitions into three primary entry points:

/restconf/data/ : The entry point for all configuration and operational state data. Corresponds directly to YANG data trees.

Example: https://10.1.1.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1

/restconf/operations/ : The entry point for invoking Remote Procedure Call (RPC) operations defined within YANG data models (such as executing a device reboot or clearing dynamic route tables).

/restconf/yang-library-version : Exposes the specific version of the IETF YANG module library supported by the network device.

HTTP Verbs Mapped to NETCONF RPC Operations

RESTCONF maps standard HTTP methods directly to corresponding NETCONF operational primitives:

  • HTTP Verb RESTCONF Functional Action Corresponding NETCONF RPC Success Status Code
  • GET Retrieve configuration and operational state data <get-config> , <get> 200 OK
  • POST Create a new resource or invoke an RPC operation <edit-config> (create) 201 Created

PUT Replace a resource, or create if non-existent <edit-config> (replace) 201 Created (new) / 204 No Content (replaced)

  • PATCH Partially update/merge fields of an existing resource <edit-config> (merge) 200 OK / 204 No Content
  • DELETE Remove an existing resource <edit-config> (delete) 204 No Content
  • Protocol Comparison: SNMP vs. NETCONF vs. RESTCONF

Dimension Simple Network Management Protocol (SNMPv3) Network Configuration Protocol (NETCONF) RESTCONF Protocol

  • Standard RFC 3411–3418 RFC 6241 RFC 8040
  • Transport Layer UDP port 161 (polling), UDP 162 (traps) SSH (TCP port 830) or TLS HTTPS (TCP port 443 / 80)

Data Modeling Structure of Management Information (SMIv2 / MIBs) YANG (RFC 6020 / RFC 7950) YANG (RFC 6020 / RFC 7950)

  • Data Encoding Basic Encoding Rules (BER / ASN.1 binary) XML exclusively JSON and XML
  • Session State Stateless UDP datagrams Stateful persistent SSH session Stateless HTTP request/response

Configuration Safety No transaction safety; non-atomic SNMP Set Full atomic transactions; <commit> , <lock> Atomic per-request; immediate execution

Data Separation Weak distinction; mixed in MIB trees Explicit ( <get-config> vs <get> ) Explicit ( ?content=config vs ?content=nonconfig )

Enabling and Verifying NETCONF and RESTCONF on Cisco IOS-XE

Modern Cisco enterprise switches and routers (such as the Catalyst 9000 family and ISR/ASR/Catalyst 8000 routers) run Cisco IOS-XE with integrated model-driven subsystems. Enabling programmable interfaces requires a few concise global configuration commands.

  • Step 1: Enable NETCONF-YANG Device# configure terminal
  • Device(config)# netconf-yang

Executing netconf-yang automatically spawns the internal YANG management process, binds the NETCONF subsystem to the underlying SSH server, and opens TCP port 830 .

  • Step 2: Enable RESTCONF Device# configure terminal
  • Device(config)# ip http secure-server
  • Device(config)# restconf

restconf activates the RESTCONF subsystem inside the embedded web server, enabling HTTPS listeners on TCP port 443 .

Note

NETCONF and RESTCONF on IOS XE authenticate against AAA and require a privilege-15 user. A minimal lab setup is aaa new-model , aaa authentication login default local , aaa authorization exec default local , and username admin privilege 15 secret <password> .

  • CLI Verification Commands
  • 1. show netconf-yang sessions

Displays active client sessions connected to the NETCONF agent, detailing session IDs, client source IPs, and authentication credentials: Device# show netconf-yang sessions

  • Rcvd Rate: 0 pkts/s
  • Sent Rate: 0 pkts/s

Number of sessions : 1

  • session-id transport username source-host login-time
  • -----------------------------------------------------------------------
  • 42 netconf-ssh admin 192.168.100.50 2026-10-07T14:22:10
  • 2. show netconf-yang statistics

Provides detailed operational counters regarding incoming RPC requests, dropped transactions, and global message throughput: Device# show netconf-yang statistics

  • Global RPCs received : 1240
  • Global RPC errors : 0
  • Global notifications : 86
  • Active sessions : 1
  • 3. show platform software yang-management process

Validates that the underlying operating system daemons responsible for model-driven programmability (such as confd , nesd , ncsshd , dmiauthd , and nginx , which serves RESTCONF) are running in a healthy operational state: Device# show platform software yang-management process

  • State of YANG management processes
  • confd : Running
  • nesd : Running
  • syncfd : Running
  • ncsshd : Running
  • dmiauthd : Running
  • nginx : Running
  • Programmatic RESTCONF Verification with cURL

Engineers validate RESTCONF functionality externally from any administrative workstation using standard command-line HTTP clients such as curl .

  • To retrieve operational interface statistics formatted in JSON: curl -k -u 'admin:Cisco123!' \
  • X GET 'https://192.168.1.1/restconf/data/ietf-interfaces:interfaces' \
  • H 'Accept: application/yang-data+json'

Key parameters in this transaction include:

-k ( --insecure ): Bypasses self-signed SSL/TLS certificate warnings in test lab environments.

-u 'admin:Cisco123!' : Passes HTTP Basic Authentication credentials.

-H 'Accept: application/yang-data+json' : Informs the RESTCONF server that the client expects a JSON-encoded response matching YANG schema definitions.