# NETCONF and YANG: Building Programmable Networks 

# What is YANG?

YANG ( Yet Another Next Generation) is a data modeling language that defines the structure, semantics, and constraints of configuration and state data for network devices and services. YANG modules outline the hierarchical schema, including nodes, types, constraints, RPCs, and notifications. YANG has become the networking industry standard for data modeling because it is human readable, extensible and easy to learn

A YANG model defines a tree structure and data is mapped into this tree.  A model is defined in a text file and comprises a module and, optionally, submodules, which when compiled together form the tree.

YANG is a way to enforce constraints on data inputs. These may inputs used from an API encoded as XML and JSON. The device will check if the data adheres to the underlying model

## YANG Module Definition

**module** `nokia-types-bgp`

```json
module nokia-types-bgp {


yang-version "1.1";

namespace "urn:nokia.com:sros:ns:yang:sr:types-bgp";

prefix "types-bgp";

import nokia-sros-yang-extensions     { prefix "sros-ext"; }
import nokia-types-sros               { prefix "types-sros"; }

sros-ext:sros-major-release "rel22";

revision "2022-05-03";

typedef llgr-family-identifiers {
    type enumeration {
        enum "ipv4"                         { value 1; }
        enum "vpn-ipv4"                     { value 2; }
        enum "ipv6"                         { value 3; }
        enum "vpn-ipv6"                     { value 5; }
        enum "l2-vpn"                       { value 6; }
        enum "flow-ipv4"                    { value 10; }
        enum "route-target"                 { value 11; }
        enum "flow-ipv6"                    { value 14; }
        enum "label-ipv4"                   { value 17; }
        enum "label-ipv6"                   { value 18; }
        enum "flow-vpn-ipv4"                { value 23; }
        enum "flow-vpn-ipv6"                { value 24; }
    }

}
```

A `module name` is specified in the module `nokia-types-bgp` section, with `nokia-types-bgp` as the name of the new YANG module. A `yang-version` indicates the version number of the YANG definition used by the author, not the module itself. This is typically 1.0 or 1.1. For new modules, it's recommended to start with the latest version.

A `prefix` is a short name used within YANG modules for quick reference to the modules. An `import` is used alongside the module name of the YANG module being imported.

A `revision number` is formatted as a date and should be updated whenever the module changes. A `type definition (typedef)` defines custom types using standardized YANG elements.

## Exploring YANG in Depth

### YANG STATEMENTS

Leaf Nodes

*   Simple data such as an integer or a string
    
*   Represents a single value
    
*   No children
    

```python
# YANG

leaf host-name { 
     type string;
     description "Hostname for this system"; 
}

# NETCONF XML 

<host-name>codednetwork.com</host-name>
```

Leaf-List Nodes

*   This is just like leaf statement but there can be multiple instances
    
*   one value of a particular type per leaf
    

```python
# YANG

leaf-list name-server { 
type string; 
description "List of DNS servers to query"
}

# NETCONF XML
 
<name-server>8.8.8.8</name-server>
<name-server>4.4.4.4</name-server>
```

List Nodes

*   It allows you to create a list of leafs or leaf-lists
    
*   Each entry is structure or a record instance
    

```python
# YANG

list vlan { 
   key "id";
     leaf id { 
       type int; 
       range 1..4094; 
     } 
     leaf name { 
        type string;
     } 
}

# NETCONF XML 

<vlan> 
  <id>100</id>
  <name>web_vlan</name>
</vlan>
<vlan> 
  <id>200</id>
  <name>app_vlan</name>
</vlan>
```

Container Nodes

*   It is used to group nodes in a subtree
    
*   It only contains child nodes and has no value
    
*   May contain number of child nodes of any type (including leafs, lists, containers and leaf-lists
    

```python
# YANG

container system {
    container login-control {
       container pre-login message {
              leaf message {
                   type (*); 
                   description
                   "Message displayed prior to the login prompt";
       }
    }
}

# NETCONF XML 

<system> 
      <login-control>
           <pre-login message>
                      <message> Learning Yang is cool </message>
           </pre-login message>
      </login-control>
</system>
```

# What is NETCONF ?

## Overview

NETCONF is a standardized IETF configuration management protocol specified in RFC 6241, known as *Network Configuration Protocol (NETCONF)* . It is secure, connection-oriented, and runs on top of the SSHv2 transport protocol as specified in RFC 6242 . NETCONF is an XML-based protocol that can be used as an alternative to CLI or SNMP for managing an SR OS router

NETCONF uses RPC messaging for communication between NETCONF client and NETCONF server running on SROS. An RPC message and configuration or state data is encapsulated within an XML document. The SR OS NETCONF interface supports configuration, state and various router operations

```python
Client                                      Server  
|=== TRANSPORT ================================| 
|<--- TCP SYN -------------------------------->|
|<-- TCP SYN-ACK ----------------------------->|
|--- SSH handshake + userauth ---------------->| 
|<-- SSH userauth success ---------------------|
|--- SSH subsystem "netconf" request --------->| 
|<-- SSH channel success ----------------------|
|                                              | 
|=== SESSION ==================================|
|<--<hello> session-id=42, capabilities -------|
|---<hello> capabilities --------------------->| 
|                                              |
|=== OPERATIONS ===============================|
|--- <rpc> get-config(running) --------------->|
|<--<rpc-reply> <data>…<data> -----------------|
|                                              |
|=== TEARDOWN =================================| 
|--- <rpc> close-session --------------------->| 
|<--<rpc-reply> <ok/> -------------------------| 
|--- SSH channel close ----------------------->|
```

*message exchange*

## Protocol Stack

![](https://cdn.hashnode.com/uploads/covers/68933f4690103a1d4a8d7df7/c3ad2ba7-9aad-4565-b0ba-ceec9b781169.png align="center")

| **Content** | **yang formatted information** |
| --- | --- |
| **Operations** | **Specific functions that operators can do on the server (get-config, edit-config)** |
| **Messages** | **three main message types - *Remote Procedure Calls (RPCs)* : Instructions /requests formatted in XML . *Notification* : information provided from the server not in direct response to a RPC. *Hello* : Special message used in communication setup and capabilities discovery** |
| **Secure Transport** | **NETCONF is not a transport layer. It is layered on top of a secured-orientated transport protocol eg SSH , HTTP/TLS** |

## Enabling NETCONF Nokia SROS

```shell
# Step 1 - Ensure model-driven mode is enabled 

A:R1# configure system management-interface configuration-mode model-driven

# Step 2 - Enable NETCONF and Auto-save 

(gl)[configure system management-interface]
A:admin@R1# 
    netconf { 
    admin-state enable
    auto-config-save true 
    }

# Step 3 - Select the YANG Modules 

(gl)[configure system management-interface]
A:admin@R1#
    yang-modules { 
       nokia-modules false 
       nokia-combined-modules true
    }

# Step 4 - Create user with NETCONF access 

(gl)[configure local-user { 
        user "netconf" { 
            password "<password-here>" 
            access { 
                netconf true 
            } 
            console { 
               member ["administrative"] 
            } 
        } 
} system security user-params]

# Step 5 - Grant lock and kill permissions 

(gl)[configure system security aaa local-profiles profile "administrative"] A:admin@R1#
    netconf { 
        base-op-authorization {
            kill-session true 
            lock true
        }
    }
```

## NETCONF - Base Operations

![](https://cdn.hashnode.com/uploads/covers/68933f4690103a1d4a8d7df7/7c40db98-434b-481d-a70d-1370cf411d61.png align="center")

## NETCONF - Interacting with Nokia SROS

### Connect with SSH

The simplest and the easiest way to interact with a router is by using SSH.

```python
ssh admin@<host-ip> -p 830 -s netconf
```

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text"><strong><em>&lt;hello&gt; </em></strong><em>returned with router capabilities</em></div>
</div>

```xml
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
       <capability>urn:ietf:params:netconf:base:1.0</capability>
       <capability>urn:ietf:params:netconf:base:1.1</capability>
       <capability>urn:ietf:params:netconf:capability:candidate:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1
       </capability>
       <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:notification:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:interleave:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:validate:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:validate:1.1
       </capability>
       <capability>urn:ietf:params:netconf:capability:startup:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:url:1.0
       scheme=ftp,tftp,file<</capability>
       <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
       </capability>
       <capability>urn:nokia.com:sros:ns:yang:sr:major-release:24
       </capability>
       <capability>urn:ietf:params:xml:ns:yang:iana-if-type?module=iana-if-   
       type&revision=2014-05-08</capability>
       <capability>urn:ietf:params:netconf:capability:yang-library:1.0?    
        revision=2016-06-21&module-set-id=gOPkB60aiVyk5<
       </capability>
    </capabilities>
     </session-id>57677<session-id>
</hello>
```

*truncated capabilities*

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text">Send a hello (mandatory first step) finish the message with ]]&gt;]]&gt;</div>
</div>

```xml
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabalities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>
]]>]]>
```

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text">&lt;get-config&gt; retrieving the services from the configuration datastore</div>
</div>

```xml
# Retrieve the services
 
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source><candidate/></source> 
    <filter>
      <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
        <service>
        </service>
      </configure>
    </filter>
  </get-config>
</rpc>
]]>]]>

# RPC-REPLY with services 

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0>
   <data>
       <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
           <service>
               <epipe>
                   <service-name>test</service-name>
                   <admin-state>enable</admin-state>
                   <service-id>10</service-id>
                   <customer>1</customer>
                   <spoke-sdp>
                      <sdp-bind-id>10:10</sdp-bind-id>
                      <admin-state>enable</admin-state>
                   </spoke-sdp>
                </epipe>
                <sdp>
                  <sdp-id>10</sdp-id>
                  <admin-state>enable</admin-state>
                  <description>pysros-example</description>
                  <delivery-type>mpls</delivery-type>
                  <far-end> 
                      <ip-address>10.10.10.2</ip-address>
                  </far-end>
                  <lsp>
                    <lsp-name>PE1-to-PE2</lsp-name>
                  </lsp>
                </sdp>
         </service>
       </configure>
   </data>
</rpc-reply>
```

### Connect with netconf-console2

`netconf-console2` is a console application built to interact with network devices using NETCONF. It allows engineers and automation systems to send NETCONF Remote Procedure Call (RPC) operations to a device. It can run in two modes:

*   **Command-line mode:** Used to execute one or more RPC operations in a single shell command.
    
*   **Interactive (console) mode:** Provides an interactive session where a user can issue multiple commands sequentially, with limited support for tab-completion
    

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text">In this below example we just show retrieving configuration using &lt;get-config&gt;</div>
</div>

```python
# Install netconf-console2 
pip install netconf-console2 

# Retrieve configuration 

netconf-console2 --host=<host-ip> -u <username> -p <password> --port=830 --get-config

# Configuration results 

<?xml version='1.0' encoding='UTF-8'?> 
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
            <groups>
                <group> 
                    <name>test</name>
                    <router>
                       <router-name> Base </router-name>
                       <interface>loop</interface>
                       <ip-mtu>444</ip-mtu>
                       </interface>
                    </router>
                <group>              
            </groups>
            <card>
                <slot-number>1</slot-number>
                <card-type>iom-1<card-type>
                <mda>
                   <mda-slot>1</mda-slot>
                   <mda-type>me12-100gb-qsfp28</mda-type>
                </mda>
            </card>

............. [output truncated]
```

### Connect with NETCONF client for Visual Studio Code

This extension adds an interactive NETCONF client to Visual Studio Code, connecting to NETCONF servers such as NOKIA IP routers (SR OS and SRLinux). It brings NETCONF into the editor so you can manage modern network equipment directly from VS Code using the standard NETCONF protocol.

If you're not familiar with Python or using libraries like NAPALM and ncclient to interact with a router running NETCONF, this VS Code extension is perfect for you. The interface is user-friendly and easy to navigate.

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text">Download the extension on VS Code Marketplace. Add the router with the correct NETCONF user and password before interaction</div>
</div>

![](https://cdn.hashnode.com/uploads/covers/68933f4690103a1d4a8d7df7/7bf98c06-2182-4d8c-99f9-778a5e7af3bd.jpg align="center")

*Create the connect-name , host-ip and enter the credentials*

![](https://cdn.hashnode.com/uploads/covers/68933f4690103a1d4a8d7df7/9c49d629-4121-4398-8837-10e00a6469fc.jpg align="center")

*Click connect icon to start interacting with the Nokia SROS*

![](https://cdn.hashnode.com/uploads/covers/68933f4690103a1d4a8d7df7/1e94783d-280f-479b-bef2-2287a9c9edb7.jpg align="center")

*Base operations options*

# Other Tools

## PYANG

pyang is a YANG validator and converter that checks YANG modules for correctness and generates documentation or code stubs.

`Convert YANG into a tree diagram`

```python
# Execute the below command 

pyang -f tree nokia-state.yang > nokia-state.tree
```

![](https://cdn.hashnode.com/uploads/covers/68933f4690103a1d4a8d7df7/7e8f7529-54f9-47c0-b812-761fd5ec0e04.png align="center")

*nokia-state tree structure sample*

`Generate html/javascript tree`

```python
# Execute the below command 

pyang -f jstree nokia-state.yang > nokia-state.jstree
```

Then you can browse the YANG on a web browser

![](https://cdn.hashnode.com/uploads/covers/68933f4690103a1d4a8d7df7/fee9ed1a-3f8a-4aaf-b58d-c236de07f50d.jpg align="center")

# Conclusion

The CLI era gave network engineers power and flexibility, but at the cost of machine-readability, validation, and safe rollback. Every vendor implemented their own syntax, every script was fragile, and every change carried the risk of an unrecoverable typo. NETCONF and YANG fundamentally transform the way network configurations are managed , the device exposes a schema, accepts structured configuration, validates every change before it is deployed, and can roll back automatically.

That shift — from text scraping to model-driven management — is not just a technical improvement. It is what makes large-scale network automation reliable enough to trust in production. When your automation toolchain uses YANG, it knows what a valid interface configuration looks like before it ever touches a router. When it uses *confirmed commit*, a misconfiguration cannot disable a device permanently. When it subscribes to NETCONF notifications, it reacts to events rather than polling every 60 seconds hoping nothing changed.

> *" The combination of a strongly-typed schema language, a transactional RPC protocol, and a mandatory encrypted transport is not accidental — it is a deliberate architecture designed for the scale and reliability demands of modern network operations "*