Programmable Interfaces: NETCONF, RESTCONF, YANG, gRPC

6.1 Introduction

The transition from manual Command Line Interface (CLI) management to programmatic network automation is a cornerstone of NetDevOps. This shift is driven by the increasing complexity of modern networks, the demand for agility, and the need for consistency and error reduction. At the heart of this transformation are standardized, machine-readable interfaces and data models that allow applications and automation tools to interact directly with network devices.

This chapter delves into the core programmable interfaces: NETCONF (Network Configuration Protocol), RESTCONF, and gRPC (gRPC Remote Procedure Call), alongside their common data modeling language, YANG. These technologies provide the mechanisms for Infrastructure as Code (IaC) principles to be applied to network infrastructure, enabling seamless configuration, operational state retrieval, and telemetry collection across multi-vendor environments.

What this chapter covers:

• The fundamental concepts and architectures of YANG, NETCONF, RESTCONF, and gRPC/gNMI.
• The advantages and use cases of each protocol in a NetDevOps context.
• Multi-vendor configurations for enabling these interfaces on Cisco, Juniper, and Arista devices.
• Practical automation examples using Python and Ansible for configuration and operational state management.
• Critical security considerations, best practices, and troubleshooting techniques.
• Performance optimization strategies for high-scale automation and telemetry.

Why it’s important:

As network engineers, understanding these programmable interfaces is no longer optional; it’s a fundamental skill for operating and automating modern networks. Mastery of these concepts enables you to move beyond screen scraping and brittle CLI automation, embracing robust, model-driven, and scalable solutions.

What you’ll be able to do after this chapter:

• Explain the role of YANG, NETCONF, RESTCONF, and gRPC/gNMI in network automation.
• Configure network devices (Cisco, Juniper, Arista) to expose these programmatic interfaces.
• Develop Python scripts and Ansible playbooks to interact with these interfaces for configuration and data retrieval.
• Implement security best practices for network device APIs.
• Troubleshoot common issues encountered when using programmable interfaces.

6.2 Technical Concepts

6.2.1 YANG Data Models: The Language of Network Configuration

YANG (Yet Another Next Generation) is a data modeling language used to define the configuration, state data, Remote Procedure Call (RPC) operations, and notifications for network devices. It provides a standardized, hierarchical, and human-readable way to describe network elements and their attributes, ensuring interoperability between different vendors’ equipment.

Detailed Technical Explanation:

• Structure and Hierarchy: YANG models are organized into modules and submodules. Modules define a data tree structure using nodes, which can be containers, lists, leaf nodes, or leaf-list nodes.
  • Containers: Group related data nodes.
  • Lists: Ordered sequences of list entries, each identified by a unique key.
  • Leafs: Individual data items (e.g., interface name, IP address).
  • Leaf-lists: Sequences of leaf values.
• Data Types: YANG supports various built-in data types (e.g., string, int32, boolean, enumeration, identityref) and allows for the definition of custom types.
• Augmentations and Deviations: YANG allows vendors to extend (augment) or modify (deviate) standard models without altering the original model, providing flexibility for vendor-specific features while maintaining a common base.
• Schema and Data: A YANG model defines the schema (the structure and rules), while the actual device configuration or operational state is the data that conforms to this schema.
• Benefits:
  • Standardization: Enables a common understanding of network configuration and state across vendors.
  • Interoperability: Facilitates multi-vendor automation.
  • Validation: Tools can validate configuration payloads against the YANG schema before applying them to devices, preventing syntax errors.
  • Clarity: Provides a clear and unambiguous representation of network data.

RFC/Standard References:

• RFC 6020: “YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)” (Original)
• RFC 7950: “The YANG 1.1 Data Modeling Language” (Current)

Network Diagram: Simplified YANG Module Structure

This diagram illustrates a conceptual YANG module for managing an interface, showing the hierarchical structure.

@startuml
skinparam handwritten true
skinparam style strict
skinparam backgroundColor white

package "interface-module.yang" {
  component "module interface-module" {
    cloud "container interfaces" as C1 {
      component "list interface" as L1 {
        folder "key name" as K1
        component "leaf name (string)" as Lf1
        component "container config" as C2 {
          component "leaf enabled (boolean)" as Lf2
          component "leaf description (string)" as Lf3
          component "leaf type (identityref)" as Lf4
          component "leaf mtu (uint16)" as Lf5
        }
        component "container state" as C3 {
          component "leaf oper-status (enumeration)" as Lf6
          component "leaf last-change (yang:date-and-time)" as Lf7
        }
      }
    }
  }
}

C1 [label="> L1 : contains
L1"] K1 : keyed by
L1 [label="> Lf1 : contains
L1"] C2 : contains
C2 [label="> Lf2 : contains
C2"] Lf3 : contains
C2 [label="> Lf4 : contains
C2"] Lf5 : contains
L1 [label="> C3 : contains
C3"] Lf6 : contains
C3 --> Lf7 : contains

note left of C1 : Defines a root container for all interfaces
note right of L1 : Represents individual interfaces (e.g., GigabitEthernet0/1)
note right of C2 : Configuration parameters
note right of C3 : Operational state parameters
@enduml

6.2.2 NETCONF: The Network Configuration Protocol

NETCONF is an XML-based protocol designed for managing network devices. It provides mechanisms for installing, manipulating, and deleting configuration data, and for retrieving operational state data. NETCONF separates configuration data from operational state data, and uses a transaction-based approach, which is crucial for reliable automation.

Detailed Technical Explanation:

• XML-based: All data and operations in NETCONF are encoded in XML.
• RPC (Remote Procedure Call): NETCONF operates using RPCs. A client sends an <rpc> element to a server, which responds with an <rpc-reply>.
• Operations: Key NETCONF operations (RFC 6241) include:
  • <get>: Retrieves configuration and state data from the device.
  • <get-config>: Retrieves only configuration data from a specified datastore.
  • <edit-config>: Loads new configuration data to a specified datastore.
  • <copy-config>: Copies an entire configuration datastore to another.
  • <delete-config>: Deletes a configuration datastore.
  • <lock> / <unlock>: Locks/unlocks a datastore to prevent simultaneous changes.
  • <commit>: Applies the candidate configuration to the running configuration.
• Data Stores: NETCONF defines several configuration datastores:
  • running: The active configuration of the device.
  • candidate: A temporary datastore where configuration changes are staged before being committed. This allows for validation and rollback.
  • startup: The configuration loaded when the device boots (optional).
• Transport Mappings: NETCONF typically runs over SSH (RFC 6242), leveraging its secure channel for authentication and encryption. Other transports like TLS or SOAP are also defined but less common.
• Capabilities: Devices advertise their supported capabilities (YANG modules, protocol versions, operations, datastores) during session establishment.

Control Plane vs. Data Plane: NETCONF primarily operates in the control plane of a network device, managing configurations that influence how the data plane forwards traffic. It is not directly involved in data forwarding itself.

RFC/Standard References:

• RFC 6241: “Network Configuration Protocol (NETCONF)”
• RFC 6242: “Using the NETCONF Protocol over Secure Shell (SSH)”
• RFC 8341: “Network Configuration Access Control Model (NACM)”

Network Diagram: NETCONF RPC Exchange Flow

digraph NETCONF_Flow {
    rankdir=LR;
    node [shape=box, style="filled", fillcolor="#CCEEFF"];

    subgraph cluster_client {
        label="NETCONF Client (Automation Tool/Engineer)";
        color=blue;
        Client [label="NETCONF Client"];
    }

    subgraph cluster_server {
        label="Network Device (NETCONF Server)";
        color=green;
        Server [label="NETCONF Server"];
        Datastore [label="Configuration Datastores (candidate, running)"];
    }

    Client -> Server [label="1. Establish SSH/TLS Session"];
    Server -> Client [label="2. Exchange Capabilities"];
    Client -> Server [label="3. <rpc> <lock> candidate </lock> </rpc>"];
    Server -> Client [label="4. <rpc-reply> <ok/> </rpc-reply>"];
    Client -> Server [label="5. <rpc> <edit-config> candidate data </edit-config> </rpc>"];
    Server -> Client [label="6. <rpc-reply> <ok/> </rpc-reply>"];
    Client -> Server [label="7. <rpc> <commit/> </rpc> </rpc>"];
    Server -> Client [label="8. <rpc-reply> <ok/> </rpc-reply>"];
    Client -> Server [label="9. <rpc> <unlock> candidate </unlock> </rpc>"];
    Server -> Client [label="10. <rpc-reply> <ok/> </rpc-reply>"];
    Client -> Server [label="11. <rpc> <get-config> running filter </get-config> </rpc>"];
    Server -> Client [label="12. <rpc-reply> <data> </data> </rpc-reply>"];

    {rank=same; Client; Server;}
}

Packet Diagram: Simplified NETCONF over SSH

This diagram provides a conceptual view of how NETCONF messages are encapsulated within an SSH session.

packetdiag {
  colwidth = 32
  node_height = 48

  0-31: Ethernet Frame
  32-63: IP Header
  64-95: TCP Header
  96-127: SSH Protocol Header (Key Exchange, Authentication)
  128-159: SSH Encrypted Channel
  160-191: NETCONF Message (XML RPC)
  192-223: ...
  224-255: ...
  256-287: End of NETCONF Message
}

6.2.3 RESTCONF: RESTful API for YANG

RESTCONF is an HTTP-based protocol that provides a RESTful interface for accessing data defined by YANG models. It maps YANG data trees and operations to HTTP methods (GET, POST, PUT, DELETE) and URIs. RESTCONF simplifies interaction by leveraging common web technologies, making it accessible to a broader range of developers and tools.

Detailed Technical Explanation:

• HTTP/HTTPS-based: RESTCONF operates over HTTP or, more commonly, HTTPS for secure communication.
• RESTful Principles: Adheres to Representational State Transfer (REST) architectural style, using resources, HTTP methods, and stateless communication.
• URI Mapping: YANG modules, containers, lists, and leaf nodes are mapped to unique URIs. For example, /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1/config/description.
• Data Formats: Supports JSON (preferred) and XML for representing configuration and state data in request bodies and responses.
• Operations:
  • GET: Retrieves data from a resource.
  • POST: Creates a new resource or invokes an RPC/action.
  • PUT: Creates or replaces an existing resource.
  • PATCH: Modifies parts of an existing resource.
  • DELETE: Deletes a resource.
• Datastores: Typically interacts with the running datastore directly or uses a candidate datastore via a dedicated operations URI for transactional control (e.g., /restconf/operations/ietf-netconf:candidate/commit).
• Notifications: RESTCONF supports server-initiated event notifications, allowing clients to subscribe to changes in operational state or configuration.

RFC/Standard References:

• RFC 8040: “RESTCONF Protocol”

Network Diagram: RESTCONF Request/Response Flow

digraph RESTCONF_Flow {
    rankdir=LR;
    node [shape=box, style="filled", fillcolor="#CCFFCC"];

    Client [label="RESTCONF Client\n(Automation Script/Tool)"];
    RESTCONF_Server [label="Network Device\n(RESTCONF Server)"];
    YANG_Data_Model [label="YANG Data Model\nRepresentation"];
    Running_Config [label="Running Configuration"];
    Operational_State [label="Operational State"];

    Client -> RESTCONF_Server [label="1. GET /restconf/data/ietf-interfaces:interfaces", style="bold", color="blue"];
    RESTCONF_Server -> YANG_Data_Model [label="2. Maps URI to YANG Data"];
    YANG_Data_Model -> Running_Config [label="3. Retrieves Config Data"];
    YANG_Data_Model -> Operational_State [label="4. Retrieves State Data"];
    RESTCONF_Server -> Client [label="5. HTTP 200 OK\nJSON/XML Payload", style="bold", color="blue"];

    Client -> RESTCONF_Server [label="6. PATCH /restconf/data/ietf-interfaces:interfaces/interface=Loopback0\n(JSON Payload to update description)", style="bold", color="red"];
    RESTCONF_Server -> YANG_Data_Model [label="7. Maps URI & Payload to YANG"];
    YANG_Data_Model -> Running_Config [label="8. Applies Configuration Change"];
    RESTCONF_Server -> Client [label="9. HTTP 204 No Content\n(or 200 OK for POST/PUT)", style="bold", color="red"];

    {rank=same; Client; RESTCONF_Server;}
    {rank=same; YANG_Data_Model; Running_Config; Operational_State;}
}

6.2.4 gRPC and gNMI: High-Performance Telemetry and Management

gRPC (gRPC Remote Procedure Call) is an open-source, high-performance RPC framework developed by Google. It uses Protocol Buffers (Protobuf) as its Interface Definition Language (IDL) and transport format, enabling efficient, language-agnostic communication between services. gRPC is particularly well-suited for high-volume, low-latency communication, making it ideal for network telemetry and management.

Detailed Technical Explanation:

• Protocol Buffers: Data is serialized into a highly efficient binary format, significantly reducing payload size and parsing overhead compared to XML or JSON.
• HTTP/2: gRPC builds on HTTP/2, providing multiplexing, header compression, and full-duplex streaming capabilities.
• Language Agnostic: protoc (the Protocol Buffer compiler) generates client and server stubs in multiple programming languages (Python, Go, Java, C++, etc.).
• Streaming: Supports four types of service methods:
  • Unary: Traditional request-response.
  • Server Streaming: Client sends a request, server sends back a stream of responses. Ideal for telemetry.
  • Client Streaming: Client sends a stream of requests, server sends back a single response.
  • Bidirectional Streaming: Both client and server send a stream of messages simultaneously.
• gNMI (gRPC Network Management Interface): gNMI is a specific gRPC-based protocol developed by OpenConfig for network device management and telemetry. It leverages YANG models to define the data structures and uses gRPC for transport.
  • Capabilities: Advertises supported YANG models.
  • Get: Retrieves current configuration or operational state.
  • Set: Modifies configuration.
  • Subscribe: Establishes a streaming subscription for telemetry data, allowing devices to push updates to collectors in real-time or on-change.
  • Notifications: gNMI notifications can include UPDATE (new data) and DELETE (removed data).

Control Plane vs. Data Plane: Similar to NETCONF/RESTCONF, gRPC/gNMI primarily operate in the control plane for configuration and management plane for operational state and telemetry. Model-driven telemetry with gNMI offers unprecedented visibility into the network’s operational state with high granularity and low latency.

RFC/Standard References:

• gRPC: Not an RFC, but an open standard by Google. Refer to grpc.io.
• gNMI: Developed by OpenConfig, specifications available on openconfig.net.

Network Diagram: gRPC/gNMI Client-Server Interaction for Telemetry

@startuml
skinparam handwritten true
skinparam style strict
skinparam backgroundColor white

box "Network Device (gRPC Server)" #LightBlue
  node "gNMI Agent" as Agent
  storage "Operational Data (YANG)" as OpData
  Agent --> OpData : Reads
end box

box "Telemetry Collector (gRPC Client)" #LightGreen
  node "gNMI Client" as Client
  database "Time-Series Database" as TSDB
  Client [label="> TSDB : Stores Data
end box

Agent <"] Client : Bidirectional gRPC Stream (HTTP/2 + Protobuf)

Client -[hidden]-> Agent
Client [label="> Agent : Subscribe Request (YANG Path, Mode, Interval)
Agent"] Client : Stream of Telemetry Updates (on-change or periodic)
@enduml

6.3 Configuration Examples (Multi-vendor)

Enabling these programmatic interfaces is the first step in adopting NetDevOps. Below are configuration examples for Cisco, Juniper, and Arista devices.

6.3.1 Cisco IOS XE/XR/NX-OS

Cisco devices extensively support NETCONF, RESTCONF, and gRPC/gNMI. The configuration will vary slightly between platforms (IOS XE, IOS XR, NX-OS), but the core principles remain.

Enable NETCONF and RESTCONF (IOS XE Example)

! Configure NETCONF over SSH
! Ensure SSH is already configured and enabled
! e.g., 'crypto key generate rsa modulus 2048' and 'line vty 0 4', 'transport input ssh'
username automation privilege 15 secret 0 YourStrongPassword
netconf-yang
 netconf ssh
!
! Configure RESTCONF over HTTPS
! Ensure HTTPS server is enabled and a valid SSL/TLS certificate is configured
! e.g., 'ip http secure-server' and 'crypto pki trustpoint YourTrustpoint', 'ip http client authenticate trustpoint YourTrustpoint'
ip http secure-server
restconf
!
! Verify NETCONF/RESTCONF status
! show netconf-yang session
! show restconf
! show ip http server status

Verification Commands:

show netconf-yang session
show restconf
show ip http server status

Expected Output (NETCONF session example):

Number of current NETCONF sessions: 0

No entries found.

(This output indicates no active sessions, which is normal if no client is connected yet. You’d see session details if a client was connected.)

Expected Output (RESTCONF status example):

RESTCONF:             Enabled
HTTP  authentication: Local
HTTPS authentication: Local
HTTP URL path:        /restconf
HTTPS URL path:       /restconf
HTTP port:            80
HTTPS port:           443

Enable gRPC/gNMI (Model-Driven Telemetry - IOS XE Example)

For gRPC-based telemetry (gNMI on Cisco platforms), you typically configure a telemetry ietf subscription.

! Configure a gRPC Telemetry collector
! ip scp server enable (if using SCP for file transfer, for gRPC this is not direct)
!
! Create a telemetry subscription for an interface
! Note: The destination IP should be your telemetry collector
telemetry ietf
  subscription 100
    encoding encode-json
    filter xpath /ietf-interfaces:interfaces/interface/statistics
    stream cisco-push-i
    update-policy on-change
    receiver ip 192.168.1.100 57000 protocol grpc tls-enable
!
! Ensure gRPC is enabled (often part of netconf-yang)
netconf-yang
  grpc tls-enable
!
! Generate an RSA key pair if not already present for TLS
crypto key generate rsa modulus 2048 label MY-GRPC-KEY
!
! Configure an authentication method for gRPC (optional but recommended)
! In a production environment, you'd integrate with AAA or use client certificates
! For simplicity, local user with shared secret
username grpc_user secret 0 grpc_secret_password
!
! Verification: Show active telemetry subscriptions and status
! show telemetry ietf subscription all
! show netconf-yang grpc status

Verification Commands:

show telemetry ietf subscription all
show netconf-yang grpc status

Expected Output (Telemetry subscription example):

Telemetry subscription: 100
  Type:       Telemetry
  State:      Valid
  Stream:     cisco-push-i
  Filter:
    Type:     xpath
    Xpath:    /ietf-interfaces:interfaces/interface/statistics
  Update policy: on-change
  Encoding:   encode-json
  Receivers:
    Receiver: 192.168.1.100:57000
      Protocol: grpc
      TLS:      Enabled
      Profile:  Default

6.3.2 Juniper JunOS

Juniper JunOS has robust support for NETCONF and RESTCONF, which are integral to its automation capabilities.

Enable NETCONF and RESTCONF

# Ensure SSH is configured
# set system services ssh

set system services netconf ssh
set system services netconf traceoptions flag all
set system services netconf rfc-compliant
set system services rest http
set system services rest https
set system services rest enable-explorer
set system services rest http-port 8080
set system services rest https-port 8443
set system services rest enable-execute-rpc
set system services rest allow-uri-encoding
set system services rest access-profile junos-rest-api-profile
commit
!
! Add a user for automation (replace with your user and password)
set system login user automation class super-user authentication plain-text-password
# Enter password at prompt
!
! Create a firewall filter for REST/NETCONF access (security best practice)
set firewall family inet filter MGMT_ACCESS term NETCONF from port 830
set firewall family inet filter MGMT_ACCESS term NETCONF then accept
set firewall family inet filter MGMT_ACCESS term REST from port 8080
set firewall family inet filter MGMT_ACCESS term REST then accept
set firewall family inet filter MGMT_ACCESS term REST_HTTPS from port 8443
set firewall family inet filter MGMT_ACCESS term REST_HTTPS then accept
set firewall family inet filter MGMT_ACCESS term DENY_ALL then discard
set interfaces ge-0/0/0 unit 0 family inet filter input MGMT_ACCESS # Apply to management interface

! Verification:
! show system services
! show configuration | display set | match "netconf|rest"

Verification Commands:

show system services
show system services rest
show system services netconf

Expected Output (System services example):

ssh;
netconf {
    ssh;
    traceoptions {
        flag all;
    }
    rfc-compliant;
}
rest {
    http;
    https;
    enable-explorer;
    http-port 8080;
    https-port 8443;
    enable-execute-rpc;
    allow-uri-encoding;
    access-profile junos-rest-api-profile;
}

6.3.3 Arista EOS

Arista EOS also provides excellent support for programmatic interfaces, including NETCONF and eAPI (which is REST-like and often preferred for simpler interactions, but RESTCONF is also supported).

Enable NETCONF and RESTCONF

! Configure NETCONF over SSH
! Ensure SSH is already configured and enabled
! e.g., 'management ssh'
!
! Enable NETCONF
management api netconf
  transport ssh
!
! Configure RESTCONF (eAPI uses /api, for standard RESTCONF use the following)
! Arista's eAPI is a robust RESTful API often preferred. Standard RESTCONF is also available.
! For eAPI (recommended for general RESTful automation on Arista):
management api http-enable
!
! For explicit standard RESTCONF if desired (requires more specific configuration for port etc,
! often covered by general HTTP server with appropriate URI paths)
!
! If using standard HTTP/HTTPS, ensure it's enabled and has a cert.
! management https protocol tls-1.2
! management https server
!
! Verification:
! show management api netconf
! show management api http-enable
! show management https

Verification Commands:

show management api netconf
show management api http-enable

Expected Output (NETCONF API example):

NETCONF:                   Enabled
Transport:                 SSH

Expected Output (eAPI/HTTP API example):

Http API:                  Enabled
HTTPS server:              Enabled

6.4 Automation Examples

Now that the devices are configured to accept programmatic connections, let’s explore how to automate tasks using Python and Ansible.

6.4.1 Python for NETCONF with ncclient

ncclient is a Python library that provides a client-side implementation of the NETCONF protocol. It simplifies sending RPC requests and parsing XML responses.

Example: Get an Interface Configuration and Set a Description

This example will connect to a Cisco IOS XE device, fetch the configuration for a specific interface, and then update its description.

import sys
from ncclient import manager
from ncclient.xml_ import new_ele, sub_ele

# Device details
DEVICE_IP = "192.168.1.10"
USERNAME = "automation"
PASSWORD = "YourStrongPassword"
NETCONF_PORT = 830

# Interface to configure
INTERFACE_NAME = "Loopback0"
INTERFACE_DESCRIPTION = "Configured by NetDevOps Python"

def connect_netconf(host, user, password, port):
    """Establutshes a NETCONF session."""
    try:
        conn = manager.connect(
            host=host,
            port=port,
            username=user,
            password=password,
            hostkey_verify=False,  # Set to True in production with proper host keys
            device_params={'name': 'iosxe'},
            look_for_keys=False,
            allow_agent=False,
        )
        print(f"--- Connected to {host} via NETCONF ---")
        return conn
    except Exception as e:
        print(f"Error connecting to NETCONF device: {e}")
        sys.exit(1)

def get_interface_config(conn, interface_name):
    """Retrieves the configuration for a specific interface."""
    filter_xml = f"""
    <filter>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>{interface_name}</name>
        </interface>
      </interfaces>
    </filter>
    """
    print(f"\n--- Getting configuration for {interface_name} ---")
    try:
        result = conn.get_config(source='running', filter=filter_xml)
        print(result.data_xml)
        return result.data_xml
    except Exception as e:
        print(f"Error getting interface config: {e}")
        return None

def set_interface_description(conn, interface_name, description):
    """Sets the description for a specific interface using edit-config."""
    config_payload = f"""
    <config>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>{interface_name}</name>
          <description>{description}</description>
        </interface>
      </interfaces>
    </config>
    """
    print(f"\n--- Setting description for {interface_name} ---")
    try:
        # Using default-operation="merge" to update only specified fields
        # Using ncclient's edit_config and commit operations
        conn.edit_config(target='running', config=config_payload, default_operation="merge")
        print(f"Successfully updated description for {interface_name} to '{description}'")
        # For devices supporting candidate datastore, you'd use:
        # conn.edit_config(target='candidate', config=config_payload)
        # conn.commit()
    except Exception as e:
        print(f"Error setting interface description: {e}")

if __name__ == "__main__":
    netconf_conn = None
    try:
        netconf_conn = connect_netconf(DEVICE_IP, USERNAME, PASSWORD, NETCONF_PORT)
        if netconf_conn:
            # First, get the current config
            get_interface_config(netconf_conn, INTERFACE_NAME)

            # Then, set a new description
            set_interface_description(netconf_conn, INTERFACE_NAME, INTERFACE_DESCRIPTION)

            # Verify the change by getting the config again
            get_interface_config(netconf_conn, INTERFACE_NAME)

    finally:
        if netconf_conn:
            print("\n--- Closing NETCONF session ---")
            netconf_conn.close_session()

6.4.2 Ansible for NETCONF and RESTCONF

Ansible provides modules for interacting with NETCONF (netconf_config, netconf_get), as well as vendor-specific modules (e.g., cisco.ios.ios_netconf, cisco.ios.ios_restconf).

Example: Ansible Playbook for NETCONF Configuration (Cisco IOS XE)

This playbook will use cisco.ios.ios_netconf to configure a VLAN on a Cisco IOS XE device.

---
- name: Configure VLAN using NETCONF on Cisco IOS XE
  hosts: cisco_iosxe_devices
  gather_facts: false
  connection: local

  vars:
    ansible_user: automation
    ansible_password: YourStrongPassword
    ansible_port: 830
    ansible_network_os: cisco.ios.ios

  tasks:
    - name: Ensure VLAN is configured with NETCONF
      cisco.ios.ios_netconf:
        xml: |
          <config>
            <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
              <vlan>
                <vlan-list>
                  <id>10</id>
                  <name>AUTOMATION_VLAN_10</name>
                </vlan-list>
              </vlan>
            </native>
          </config>
        commit: true # Commit changes immediately
      register: vlan_config_result

    - name: Print NETCONF configuration result
      debug:
        var: vlan_config_result

    - name: Get VLAN configuration with NETCONF for verification
      cisco.ios.ios_netconf:
        rpc: |
          <get-config>
            <source><running/></source>
            <filter>
              <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
                <vlan>
                  <vlan-list>
                    <id>10</id>
                  </vlan-list>
                </vlan>
              </native>
            </filter>
          </get-config>
      register: vlan_get_result

    - name: Print NETCONF GET result
      debug:
        var: vlan_get_result.stdout[0]

Example: Ansible Playbook for RESTCONF Data Retrieval (Cisco IOS XE)

This playbook will use the generic uri module to fetch interface data from a Cisco IOS XE device via RESTCONF.

---
- name: Get Interface Data using RESTCONF on Cisco IOS XE
  hosts: cisco_iosxe_devices
  gather_facts: false
  connection: local

  vars:
    ansible_user: automation
    ansible_password: YourStrongPassword
    ansible_httpapi_use_ssl: true
    ansible_httpapi_validate_certs: false # Set to true in production with valid certs
    ansible_httpapi_port: 443

  tasks:
    - name: Fetch interface operational state via RESTCONF
      ansible.builtin.uri:
        url: "https:///restconf/data/ietf-interfaces:interfaces-state"
        method: GET
        user: ""
        password: ""
        headers:
          Accept: "application/yang-data+json"
        status_code: 200
        force_basic_auth: true
      register: interfaces_state_data

    - name: Print interface state data
      debug:
        var: interfaces_state_data.json

6.5 Security Considerations

Programmable interfaces expose network devices to a new attack surface. Implementing robust security measures is paramount for a secure NetDevOps environment.

Attack Vectors:

• Unauthorized Access: If credentials are compromised, an attacker can gain full control over the network device.
• Malicious Payloads: Sending malformed or intentionally harmful configuration payloads can cause device instability or denial of service.
• Denial of Service (DoS): Flooding the API with requests can exhaust device resources.
• Information Leakage: Unsecured API endpoints can expose sensitive network information.
• Privilege Escalation: Exploiting vulnerabilities in the API or underlying OS to gain higher privileges.

Mitigation Strategies and Security Best Practices:

1. Secure Transport:
   • Always use encryption: NETCONF over SSH (RFC 6242), RESTCONF over HTTPS (TLS 1.2+), gRPC over TLS. Disable plaintext protocols.
   • Ensure robust TLS/SSH configurations (strong ciphers, key exchange algorithms).
2. Strong Authentication and Authorization:
   • AAA Integration: Integrate programmable interfaces with existing AAA (Authentication, Authorization, Accounting) systems (RADIUS, TACACS+).
   • Role-Based Access Control (RBAC): Implement granular access control. For NETCONF, use the Network Configuration Access Control Model (NACM - RFC 8341) to define which users can access or modify which parts of the YANG data tree.
   • Dedicated Automation Accounts: Use unique, non-interactive accounts for automation tools, with minimum necessary privileges.
   • Key-based Authentication: Prefer SSH keys for NETCONF over passwords.
3. Input Validation:
   • Leverage YANG’s schema validation to prevent invalid configurations from being applied. Automation tools should pre-validate payloads locally before sending.
4. Rate Limiting and Session Management:
   • Configure device rate limiting for API connections to prevent DoS attacks.
   • Implement session timeouts for inactive API sessions.
5. Audit and Logging:
   • Enable comprehensive logging for all API interactions (who, what, when, outcome).
   • Integrate logs with a SIEM for analysis and alerting.
6. Software Updates:
   • Keep device firmware and API implementations updated to patch known vulnerabilities.
7. Network Segmentation:
   • Restrict API access to management networks or specific trusted IP addresses using access control lists (ACLs) or firewall rules.
8. Vulnerability Management:
   • Regularly scan network devices for vulnerabilities, especially those related to API endpoints.

Security Configuration Example (Cisco IOS XE - NACM):

This example demonstrates how to configure a basic NACM rule to allow a specific user (or group) to modify only the interface descriptions.

! Ensure NETCONF-YANG is enabled and AAA is configured for users
!
! Define a NACM group for automation users
netconf-yang cisco-iaaaa-model
 nacm
  group automation-group
   user automation
  !
  ! Define a rule-list for interface descriptions
  rule-list interface-description-rule-list
   group automation-group
   rule 10 allow-interface-description
    module-name ietf-interfaces
    path /ietf-interfaces:interfaces/interface/description
    access-operations create update delete
    action permit
   !
   ! Deny all other access by default
   rule 20 deny-all-else
    action deny
   !
  !
  ! Assign the rule-list to the group (implicit here, but explicit in full config)
  ! global-rule-list default-rule-list (This is default)
  !
! Verification
! show netconf-yang nacm status
! show netconf-yang nacm rules
!
! Security Warning: NACM can be complex. Ensure thorough testing and validation.
! A misconfigured NACM can lock out legitimate access.
! For critical production environments, start with "audit" mode if available,
! or initially use a very restrictive "deny all" default, then add "permit" rules.

6.6 Verification & Troubleshooting

Effective verification and troubleshooting are crucial for successful automation with programmable interfaces.

6.6.1 Verification Commands

Use these commands to check the status of your programmable interfaces and the configuration changes applied.

Cisco IOS XE/NX-OS:

# Verify NETCONF sessions
show netconf-yang session

# Verify RESTCONF status
show restconf

# Verify gRPC/Telemetry subscriptions
show telemetry ietf subscription all

# Verify applied configuration (specific to the YANG path or CLI equivalent)
show running-config interface Loopback0

Juniper JunOS:

# Verify NETCONF sessions
show netconf sessions

# Verify REST configuration
show system services rest

# Check configuration changes (compare candidate with running)
show | compare

Arista EOS:

# Verify NETCONF status
show management api netconf

# Verify eAPI/HTTP API status
show management api http-enable

# Verify applied configuration (CLI equivalent)
show running-config interface Loopback0

6.6.2 Troubleshooting

6.7 Performance Optimization

For large-scale deployments and real-time monitoring, optimizing the performance of programmable interfaces is critical.

1. Efficient YANG Design:
   • Minimize Data Retrieval: Only request the specific data you need using filters (NETCONF) or specific URI paths (RESTCONF/gRPC). Avoid fetching entire configuration trees if only a small part is required.
   • Optimize Lists: Use keys for lists to access specific entries directly rather than iterating through entire lists.
2. Bulk Operations:
   • When making multiple related configuration changes, send them in a single edit-config (NETCONF) or PATCH (RESTCONF) operation rather than individual RPCs. This reduces overhead and ensures transactional integrity.
3. Telemetry Subscription Tuning (gRPC/gNMI):
   • Update Policy: Use on-change subscriptions where possible to reduce unnecessary data transmission.
   • Sample Interval: For periodic updates, choose an appropriate sample-interval to balance granularity with bandwidth/CPU usage.
   • Filters: Apply granular XPath filters to stream only the relevant data.
   • Encoding: Use efficient encodings (e.g., encode-protobuf for gNMI, encode-json for RESTCONF) over verbose XML.
4. Transport Optimization:
   • gRPC/Protobuf: Leverage the binary efficiency of gRPC and Protocol Buffers for high-volume data like telemetry.
   • HTTP/2: gRPC’s use of HTTP/2 improves efficiency through multiplexing and header compression.
   • Keep-alive: For long-lived sessions, use keep-alive mechanisms to avoid the overhead of re-establishing connections.
5. Client-Side Concurrency:
   • Implement concurrent connections or asynchronous operations in your automation scripts (e.g., using Python’s asyncio or Ansible’s parallelism) to manage multiple devices or API calls simultaneously.
6. Network and Device Resources:
   • Ensure the network path between your automation tools and devices has sufficient bandwidth and low latency.
   • Monitor device CPU and memory usage, especially under heavy API load, to identify bottlenecks.

6.8 Hands-On Lab

This lab guides you through enabling NETCONF/RESTCONF, fetching capabilities, and configuring an interface description using Python.

Lab Topology:

nwdiag {
  network Management_Network {
    address = "192.168.1.0/24"
    Automation_Host [address = "192.168.1.100"];
    Cisco_IOSXE_R1 [address = "192.168.1.10", description = "Target Device"];
  }
}

Objectives:

1. Enable NETCONF and RESTCONF on the Cisco IOS XE device.
2. Connect to the device using Python ncclient.
3. Fetch the device’s NETCONF capabilities (supported YANG modules).
4. Configure an interface description using NETCONF.
5. Read interface operational state using RESTCONF (via Python requests).

Pre-requisites:

• A Cisco IOS XE virtual machine (e.g., CSR1000V or Catalyst 8000V) accessible from your Automation Host.
• Automation Host (Linux preferred) with Python 3, pip, ncclient, and requests installed.
• Basic device configuration (hostname, IP address, SSH enabled, local user automation with privilege 15 and a strong password).

  hostname Cisco_IOSXE_R1
  interface Loopback0
   ip address 1.1.1.1 255.255.255.255
   no shutdown
  interface GigabitEthernet1
   ip address 192.168.1.10 255.255.255.0
   no shutdown
  ip domain name lab.local
  crypto key generate rsa modulus 2048
  username automation privilege 15 secret 0 YourStrongPassword
  line vty 0 4
   transport input ssh
   login local
  

Step-by-step Configuration:

Step 1: Configure Cisco IOS XE Device

1. Access Cisco_IOSXE_R1 via console or SSH.
2. Enter global configuration mode.
3. Enable NETCONF:

   netconf-yang
    netconf ssh
   

4. Enable RESTCONF:

   ip http secure-server
   restconf
   

5. Save the configuration: write mem or copy run start.
6. Verify services are enabled:

   show netconf-yang session
   show restconf
   show ip http server status
   

Step 2: Prepare Automation Host

1. Install Python libraries:

   pip install ncclient requests
   

2. Create a Python script (e.g., lab_programmable_interfaces.py):

   import sys
   from ncclient import manager
   

import requests import json from requests.auth import HTTPBasicAuth

DEVICE_IP = “192.168.1.10” USERNAME = “automation” PASSWORD = “YourStrongPassword” NETCONF_PORT = 830 RESTCONF_PORT = 443 # Default HTTPS port

def connect_netconf(host, user, password, port): “““Establishes a NETCONF session.””” try: conn = manager.connect( host=host, port=port, username=user, password=password, hostkey_verify=False, # CAUTION: Set to True in production with proper host keys device_params={’name’: ‘iosxe’}, look_for_keys=False, allow_agent=False, ) print(f"— Connected to {host} via NETCONF —") return conn except Exception as e: print(f"Error connecting to NETCONF device: {e}") sys.exit(1)

def get_netconf_capabilities(conn): “““Retrieves and prints NETCONF capabilities.””” print("\n— Device NETCONF Capabilities —") for capability in conn.server_capabilities: print(f"- {capability}")

def set_interface_description_netconf(conn, interface_type, interface_name, description): “““Sets the description for a specific interface using NETCONF.””” config_payload = f""" {interface_type}{interface_name} {description} """ print(f"\n— Setting description for {interface_type}{interface_name} via NETCONF —") try: conn.edit_config(target=‘running’, config=config_payload, default_operation=“merge”) print(f"Successfully updated description for {interface_type}{interface_name} to ‘{description}’") except Exception as e: print(f"Error setting interface description via NETCONF: {e}")

def get_interface_state_restconf(host, user, password, port, interface_type, interface_name): “““Retrieves interface operational state via RESTCONF.””” url = f"https://{host}:{port}/restconf/data/ietf-interfaces:interfaces-state/interface={interface_type}{interface_name}" headers = { “Accept”: “application/yang-data+json” } print(f"\n— Getting operational state for {interface_type}{interface_name} via RESTCONF —") try: response = requests.get(url, auth=HTTPBasicAuth(user, password), headers=headers, verify=False) # CAUTION: verify=False in production only if certs are trusted response.raise_for_status() # Raise an exception for HTTP errors print(json.dumps(response.json(), indent=2)) except requests.exceptions.RequestException as e: print(f"Error getting interface state via RESTCONF: {e}")

if name == “main”: netconf_conn = None try: # NETCONF operations netconf_conn = connect_netconf(DEVICE_IP, USERNAME, PASSWORD, NETCONF_PORT) if netconf_conn: get_netconf_capabilities(netconf_conn) set_interface_description_netconf(netconf_conn, “Loopback”, “0”, “NETCONF Configured Loopback”)

    # RESTCONF operations
    get_interface_state_restconf(DEVICE_IP, USERNAME, PASSWORD, RESTCONF_PORT, "Loopback", "0")

finally:
    if netconf_conn:
        print("\n--- Closing NETCONF session ---")
        netconf_conn.close_session()

```

Step 3: Run the Python Script

python lab_programmable_interfaces.py

Verification Steps & Expected Output:

1. NETCONF Connection: Script should print “— Connected to 192.168.1.10 via NETCONF —”

2. NETCONF Capabilities: A list of capabilities, including various YANG models, should be printed.

3. Interface Description Update (NETCONF): Script should print “Successfully updated description for Loopback0 to ‘NETCONF Configured Loopback’”.

4. Interface State (RESTCONF): A JSON output showing the operational state of Loopback0, including the newly set description, should be displayed.

   {
     "ietf-interfaces:interface": {
       "name": "Loopback0",
       "type": "iana-if-type:softwareLoopback",
       "admin-status": "up",
       "oper-status": "up",
       "last-change": "2026-01-24T10:00:00.000000000Z",
       "description": "NETCONF Configured Loopback",
       // ... other statistics and details
     }
   }
   

5. On Device Verification:

   Cisco_IOSXE_R1#show running-config interface Loopback0
   interface Loopback0
    description NETCONF Configured Loopback
    ip address 1.1.1.1 255.255.255.255
    no shutdown
   

Challenge Exercises:

1. Modify the Python script to use edit-config to configure an IP address on a different interface.
2. Adapt the Ansible playbook (from section 6.4.2) to fetch all interfaces’ running configuration using NETCONF and print it.
3. Implement basic error handling for the requests library in the Python script for different HTTP status codes.

6.9 Best Practices Checklist

Applying these best practices will help build robust, secure, and maintainable automation leveraging programmable interfaces.

• YANG Model Management: Version control all custom YANG modules and track vendor-specific deviations.
• Secure Transport: Always use NETCONF over SSH and RESTCONF/gRPC over TLS (HTTPS). Disable insecure alternatives.
• Granular Access Control: Implement NACM for NETCONF and RBAC for RESTCONF/gRPC to ensure least privilege.
• Dedicated Automation Accounts: Use unique, non-human accounts with strong credentials (SSH keys preferred) for automation tools.
• Input Validation: Validate all configuration payloads against the YANG schema before sending them to the device.
• Idempotency: Design automation scripts and playbooks to be idempotent, meaning running them multiple times produces the same result without unintended side effects.
• Transactional Configuration (NETCONF): Utilize the candidate datastore, lock/unlock, and commit operations for safe and reliable configuration changes.
• Error Handling and Rollback: Implement robust error handling in automation logic and define clear rollback procedures.
• Comprehensive Logging: Log all API interactions (requests, responses, errors) on both the client and device sides. Integrate with a SIEM.
• Performance Optimization: Use filtering, bulk operations, and efficient encodings to minimize data transfer and processing overhead.
• Vendor Interoperability: Leverage OpenConfig YANG models where possible for cross-vendor consistency.
• Continuous Testing: Regularly test automation scripts against different device versions and configurations to ensure continued compatibility.
• Documentation: Document the YANG models used, API endpoints, and automation workflows.

6.10 Reference Links

• RFC 7950: The YANG 1.1 Data Modeling Language - https://datatracker.ietf.org/doc/html/rfc7950
• RFC 6241: Network Configuration Protocol (NETCONF) - https://datatracker.ietf.org/doc/html/rfc6241
• RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH) - https://datatracker.ietf.org/doc/html/rfc6242
• RFC 8040: RESTCONF Protocol - https://datatracker.ietf.org/doc/html/rfc8040
• RFC 8341: Network Configuration Access Control Model (NACM) for NETCONF - https://datatracker.ietf.org/doc/html/rfc8341
• Cisco DevNet: Standard Network Devices (NETCONF/RESTCONF/gRPC) - https://developer.cisco.com/site/standard-network-devices/
• Cisco YANG Suite: Tools to explore and test YANG interfaces - https://developer.cisco.com/yangsuite/
• gRPC Official Site: High-performance RPC framework - https://grpc.io/
• OpenConfig: Specifications for gNMI and YANG models - https://openconfig.net/
• ncclient GitHub: Python library for NETCONF clients - https://github.com/ncclient/ncclient
• Ansible Network Automation: Official documentation for network modules - https://docs.ansible.com/ansible/latest/network/index.html

6.11 What’s Next

This chapter has equipped you with a foundational understanding of the programmatic interfaces NETCONF, RESTCONF, YANG, and gRPC – the bedrock of modern NetDevOps. You’ve learned how these protocols, especially when combined with the structured nature of YANG, provide a robust and standardized approach to network configuration, operational state retrieval, and high-fidelity telemetry.

We’ve covered how to enable these interfaces across multi-vendor platforms, demonstrated practical automation with Python and Ansible, and discussed the critical security and performance considerations for deploying these technologies in a production environment.

In the next chapter, we will build upon this foundation by exploring Infrastructure as Code (IaC) principles and tools in depth. We will specifically focus on how to manage your network configurations, inventory, and automation logic using Git, incorporating CI/CD pipelines, and leveraging tools like Terraform alongside Ansible and Python for a truly declarative and version-controlled network infrastructure.