LogoفارسیFA

Hands-On Lab: Configuring NETCONF for Programmatic Device Access

This hands-on lab enables NETCONF on a router and uses it from a management station to retrieve interface configuration as structured XML data, demonstrating the model-driven programmability approach that complements traditional CLI-based management.

NETCONF ConfigurationYANG Data ModelStructured XML Retrieval

~3 min read · Updated Sep 26, 2026

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:


  
    
      
        GigabitEthernet0/0
        
        true
      
    
  

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


  
    
    
      
        
          GigabitEthernet0/0
          Configured via NETCONF
        
      
    
  



-- The router accepted and applied the
-- change, confirmed by the simple 
-- 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.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue
Previous ArticleNext Article