NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

Why NETCONF Exists Alongside REST APIs

The REST API approach discussed earlier in this series regarding network automation fundamentals works well for many use cases, but it was originally designed for general web services rather than network device configuration specifically. NETCONF (Network Configuration Protocol) was purpose-built from the ground up specifically for configuring network devices, with capabilities that address gaps a generic REST API does not inherently provide.

Key Capabilities NETCONF Provides Natively

Transactional configuration changes: NETCONF
  supports a "candidate" configuration datastore,
  separate from the running configuration --
  changes can be built up, validated, and only
  committed as a single atomic transaction once
  confirmed correct, rather than applying
  changes immediately and individually

Built-in rollback capability: NETCONF supports
  the ability to automatically revert to a
  previous configuration if a change does not
  get explicitly confirmed within a set time
  window, protecting against a configuration
  change that unexpectedly breaks connectivity
  to the device itself

Structured data validation: configuration data
  is validated against a formal schema (YANG,
  discussed next) before being applied, catching
  many configuration errors before they ever
  reach the device

These capabilities directly address real operational risks that plain REST-based configuration changes do not inherently protect against -- the rollback capability in particular solves a classic and painful problem: a configuration change sent remotely that breaks the very management connectivity needed to fix it.

YANG: The Data Modeling Language Underlying NETCONF

YANG (Yet Another Next Generation) is a data modeling language that formally defines exactly what a piece of configuration or operational data looks like -- its structure, valid values, and constraints -- providing the schema that NETCONF uses to validate data.

Simplified YANG model example, defining an
interface's configuration structure:

container interface {
  leaf name {
    type string;
  }
  leaf enabled {
    type boolean;
    default true;
  }
  leaf mtu {
    type uint16 {
      range "68..9216";
    }
  }
}

-- This YANG model defines that an interface has
-- a name (text), an enabled state (true/false,
-- defaulting to true), and an MTU value that
-- must fall within a specific valid range --
-- an attempt to set MTU to 100000 would be
-- rejected immediately as invalid according
-- to this schema, before ever reaching the
-- device's actual configuration

This formal schema definition is what allows tooling to validate configuration data automatically and provide meaningful, specific error messages when something is wrong -- a significant improvement over discovering a configuration mistake only after a device rejects a malformed command with a generic error.

A NETCONF Configuration Exchange

Simplified NETCONF RPC (Remote Procedure Call)
requesting an interface configuration change:

<rpc>
  <edit-config>
    <target><candidate/></target>
    <config>
      <interface>
        <name>GigabitEthernet0/1</name>
        <description>Uplink to Core</description>
        <enabled>true</enabled>
      </interface>
    </config>
  </edit-config>
</rpc>

-- NETCONF uses XML rather than the JSON commonly
-- used in REST APIs, discussed earlier in this
-- series, though the underlying YANG data model
-- can also be represented in JSON when using
-- the related RESTCONF protocol, which applies
-- NETCONF/YANG concepts over a more familiar
-- REST-style interface

Using Python to Interact with Network Devices

Python has become the dominant programming language for network automation, both for direct NETCONF interaction and for working with the REST APIs discussed earlier in this series, largely due to mature libraries that handle the underlying protocol details.

Simplified Python example using the ncclient
library for NETCONF:

from ncclient import manager

with manager.connect(host='192.168.1.1', port=830,
                      username='admin', password='cisco',
                      hostkey_verify=False) as m:
    config = m.get_config(source='running')
    print(config)

-- This connects to a device via NETCONF and
-- retrieves its full running configuration
-- as structured data, which can then be
-- parsed, modified, and validated
-- programmatically, rather than manually
-- parsing raw CLI text output the way a
-- traditional screen-scraping automation
-- script would need to

Simplified Python example using the requests
library for a REST API call, connecting the
concepts covered earlier in this series
regarding automation fundamentals to actual
working code:

import requests

response = requests.get(
    'https://192.168.1.1/restconf/data/interfaces',
    auth=('admin', 'cisco'),
    verify=False
)
print(response.json())

Why Structured Data Beats Screen-Scraping

Older automation approach (screen-scraping):
Send a normal CLI command like "show interfaces",
then write fragile text-parsing code to extract
specific values from the human-readable output
-- this breaks whenever a software update
changes spacing, wording, or output format
even slightly

Modern approach (NETCONF/RESTCONF):
Receive already-structured data (XML or JSON)
directly, with values in clearly labeled fields
-- immune to formatting changes, since the
data structure itself, not visual layout, is
what the automation code relies on

This distinction is not merely a matter of convenience -- screen-scraping automation is notoriously fragile in production environments, since even a minor cosmetic change to CLI output formatting in a software update can silently break automation scripts that were working correctly for months, a failure mode that structured data formats are specifically designed to eliminate.

Why This Level of Automation Sophistication Matters

The shift from basic REST/JSON automation, covered earlier in this series, toward NETCONF/YANG represents a maturation in how seriously network configuration is treated as a software engineering problem -- with formal data validation, transactional safety, and automatic rollback capabilities that mirror best practices from software deployment more broadly. Understanding both approaches, and specifically why NETCONF's additional structure and safety mechanisms matter for production network changes at scale, is essential knowledge for anyone designing automation for networks where a failed configuration change carries genuine operational risk.