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

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:

1. 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.
2. 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:

---

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   |
+-------------------------------------------------------------+

1. 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.
2. 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.
3. 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.
4. 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:

1. /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
2. /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).
3. /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:

Protocol Comparison: SNMP vs. NETCONF vs. RESTCONF

---

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.

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.