Hands-On Lab: Configuring NETCONF for Programmatic Device Access

Lab Objective

Enable NETCONF on a router, connect to it from a management station using an SSH-based NETCONF session, retrieve interface configuration as structured XML rather than CLI text output, and make a configuration change via NETCONF, verifying it takes effect identically to a CLI-based change.

Lab Purpose

Every configuration task throughout this entire series has used the traditional CLI, which produces human-readable but not reliably machine-parseable text output. NETCONF exposes the same underlying configuration through structured, YANG-modeled XML data, enabling automation tools to interact with the device programmatically rather than screen-scraping CLI output.

Lab Topology

R1 ---- Gi0/0: 192.168.255.1/24

Management station: 192.168.255.100,
running a NETCONF client tool

Task 1: Enable NETCONF on R1

Enable the NETCONF-over-SSH service on the router.

Task 2: Verify NETCONF Is Listening

Confirm the NETCONF subsystem is active and accepting connections.

Task 3: Establish a NETCONF Session and Retrieve Configuration

From the management station, connect via NETCONF and retrieve the running configuration for a specific interface as XML.

Task 4: Make a Configuration Change via NETCONF

Using a NETCONF edit-config operation, change the interface's description.

Task 5: Verify the Change Took Effect via the CLI

Confirm, using the traditional CLI, that the description was actually applied.

Solution and Verification

R1(config)# netconf-yang

R1# show netconf-yang status

netconf-yang admin state: Enabled
netconf-yang oper state: Enabled
netconf-yang ssh state: Enabled
-- Confirms NETCONF is active and listening
-- for connections, typically on port 830

ManagementStation> ssh -p 830 [email protected] -s netconf

-- After the standard NETCONF hello exchange,
-- sending a get-config request for
-- interfaces:

<rpc-reply>
  <data>
    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
      <interface>
        <name>GigabitEthernet0/0</name>
        <description></description>
        <enabled>true</enabled>
      </interface>
    </interfaces>
  </data>
</rpc-reply>
-- The exact same interface information a
-- "show running-config interface gi0/0"
-- would show, but as structured XML a
-- script can reliably parse without regex
-- or text-scraping

-- Sending an edit-config RPC:

<rpc>
  <edit-config>
    <target><running/></target>
    <config>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>GigabitEthernet0/0</name>
          <description>Configured via NETCONF</description>
        </interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>

<rpc-reply><ok/></rpc-reply>
-- The router accepted and applied the
-- change, confirmed by the simple <ok/>
-- response

R1# show running-config interface gigabitethernet0/0

interface GigabitEthernet0/0
 description Configured via NETCONF
 ip address 192.168.255.1 255.255.255.0
-- The description set via NETCONF is
-- fully visible and effective through the
-- traditional CLI, confirming both
-- interfaces manage the exact same
-- underlying configuration

Key Takeaway

NETCONF and the CLI are two different interfaces to the identical underlying router configuration — a change made through one is immediately visible and effective through the other, since neither is a separate configuration store — and NETCONF's structured, YANG-modeled XML output is specifically what makes reliable programmatic automation practical, replacing the fragile screen-scraping of CLI text that automation scripts historically had to rely on.