YANG Overview

Introduction

In this blog post we’ll be looking at YANG data modelling and exploring some of the YANG model types that are out there.  However, before we get into all of that let’s have a quick reminder of how things were done before and why YANG data models are so helpful.

The traditional way of managing network devices, is by using CLIs for configuration (configuration commands) and operational data (show commands). For network management, SNMP is widely used, especially for exchanging management information between various network devices. Although CLIs and SNMP are heavily used, they have several restrictions. CLIs are highly proprietary, and human intervention is required to understand and interpret their text-based specifications. SNMP does not distinguish between configuration and operational data.
 
The solution to this problem lies in adopting a programmatic and standards-based way of writing configurations to all network devices, replacing the process of manual configuration. This is where YANG comes in; it is the accepted data modelling language for the creation of data models used by networking vendors and amusingly stands for "Yet Another Next Generation". Multi-vendor devices such as Cisco, Juniper, Arista and others support the automation of configuration for multiple devices across the network using YANG data models. 
 
YANG data models are abstract entities that organize elements of the data and standardize how the elements relate to each other. Network engineers interact with data models indirectly on a daily basis, as they navigate a command line to change or retrieve information. Knowing the structure and capabilities of these data models is crucial to unlocking the maximum potential of these new digital-ready network devices. 

Example of IETF Interface YANG model

In the following example you can see the tree view of the IETF interface YANG model for network interfaces. The tree structure shows that all interface configuration data is part of a container named interfaces that includes the list of all interfaces. Every interface in that list has a name, description, type, and it can either be enabled or disabled. The tree structure also shows interface operations stats such as name, admin status whether interface is admin up and down, operation status, speed and what is the physical address (MAC) of the interface.   

In summary, it presents configuration and statistics parameters of interface. 

interface Loopback0
 ipv4 address 1.1.1.1 255.255.255.255
 ipv4 address 1.1.1.2 255.255.255.255 secondary
 ipv4 address 1.1.1.3 255.255.255.255 secondary
!
interface MgmtEth0/RP0/CPU0/0
 ipv4 address 198.18.1.101 255.255.255.0
!
interface GigabitEthernet0/0/0/0
 cdp
 ipv4 address 10.1.4.1 255.255.255.0
!
interface GigabitEthernet0/0/0/1
 cdp
 vrf 1
 ipv4 address 10.1.7.1 255.255.255.0
!

interfaces {                            
    fxp0 {                              
        unit 0 {                        
            family inet {               
                dhcp {                  
                    vendor-id Juniper-vmx-VM65F2E8B78F;
                }                       
            }                           
            family inet6 {              
                dhcpv6-client {         
                    client-type stateful;
                    client-ia-type ia-na;
                    client-identifier duid-type duid-ll;
                    vendor-id Juniper:vmx:VM65F2E8B78F;
                }                       
            }                           
        }                               
    }                                   
    lo0 {                               
        unit 0 {                        
            family inet {               
                address 172.16.255.1/32;
            }                           
        }
    }                              
}  

Cisco Configuration model and operational state model

The following use case represents Cisco IOS-XR configuration and representation of relative unified YANG model representation. Cisco IOS-XR BGP configuration includes BGP neighbour and VRF details and its converted output into YANG data representation.

RP/0/RP0/CPU0:xr1#show run router bgp
router bgp 1
 bgp router-id 1.1.1.1
 address-family vpnv4 unicast
 !
 neighbor 5.5.5.5
  remote-as 1
  update-source Loopback0
  address-family vpnv4 unicast
  !
 !
 vrf 1
  address-family ipv4 unicast
   redistribute connected
  !
  neighbor 10.1.7.7
   remote-as 7
   address-family ipv4 unicast
    route-policy PASS in
    route-policy PASS out
   !
  !
 !
!

Output shows that module used is Cisco-IOS-XR-um-router-bgp-cfg module.

RP/0/RP0/CPU0:xr1#show run router bgp | xml unified-model 
<data>
 <router xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-um-router-bgp-cfg">
  <bgp>
   <as>
    <as-number>1</as-number>
    <bgp>
     <router-id>1.1.1.1</router-id>
    </bgp>
    <address-families>
     <address-family>
      <af-name>vpnv4-unicast</af-name>
     </address-family>
    </address-families>
    <neighbors>
     <neighbor>
      <neighbor-address>5.5.5.5</neighbor-address>
      <remote-as>1</remote-as>
      <update-source>Loopback0</update-source>
      <address-families>
       <address-family>
        <af-name>vpnv4-unicast</af-name>
       </address-family>
      </address-families>
     </neighbor>
    </neighbors>
    <vrfs>
     <vrf>
      <vrf-name>1</vrf-name>
      <address-families>
       <address-family>
        <af-name>ipv4-unicast</af-name>
        <redistribute>
         <connected/>
        </redistribute>
       </address-family>
      </address-families>
      <neighbors>
       <neighbor>
        <neighbor-address>10.1.7.7</neighbor-address>
        <remote-as>7</remote-as>
        <address-families>
         <address-family>
          <af-name>ipv4-unicast</af-name>
          <route-policy>
           <in>PASS</in>
           <out>PASS</out>
          </route-policy>
         </address-family>
        </address-families>
       </neighbor>
      </neighbors>
     </vrf>
    </vrfs>
   </as>
  </bgp>
 </router>
</data>

The following method shows how to retrieve operational stats for interface using YANG operation data model. Output shows operation data such as packets-received and sent, drops, errors, queues and buffers.

RP/0/RP0/CPU0:xr1#show yang operational infra-statsd-oper:infra-statistics interfaces interface latest generic-counters 
infra-statistics
 interfaces 
  interface 
   interface-name GigabitEthernet0/0/0/0
   latest 
    generic-counters 
     packets-received 70621
     bytes-received 6477215
     packets-sent 72818
     bytes-sent 6601853
     multicast-packets-received 60233
     broadcast-packets-received 1
     multicast-packets-sent 60172
     broadcast-packets-sent 1
     output-drops 0
     output-queue-drops 0
     input-drops 0
     input-queue-drops 0
     runt-packets-received 0
     giant-packets-received 0
     throttled-packets-received 0
     parity-packets-received 0
     unknown-protocol-packets-received 0
     input-errors 0
     crc-errors 0
     input-overruns 0
     framing-errors-received 0
     input-ignored-packets 0
     input-aborts 0
     output-errors 0
     output-underruns 0
     output-buffer-failures 0
     output-buffers-swapped-out 0
     applique 0
     resets 0
     carrier-transitions 1
     availability-flag 0
     last-data-time 1710680497
     hardware-timestamp 0
     seconds-since-last-clear-counters 0
     last-discontinuity-time 1710503650
     seconds-since-packet-received 0
     seconds-since-packet-sent 0
    !
   !
  !
 !
!

Juniper Configuration model and operational state model

The following use case represents Junos BGP Configuration in XML format output and its relative unified YANG model representation. Junos XML output uses BGP group level hierarchy configuration and relative output in YANG data representation shows it uses Junos-conf-root YANG model in tree format.

lab> show configuration protocols bgp | display xml 
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/23.2R1.13/junos">
    <configuration junos:commit-seconds="1710430166" junos:commit-localtime="2024-03-14 15:29:26 UTC" junos:
commit-user="lab">
            <protocols>
                <bgp>
                    <group>
                        <name>PE1</name>
                        <type>external</type>
                        <export>adv_direct</export>
                        <peer-as>65412</peer-as>
                        <neighbor>
                            <name>172.16.1.2</name>
                        </neighbor>
                    </group>
                </bgp>
            </protocols>
    </configuration>
    <cli>
        <banner></banner>
    </cli>
</rpc-reply>

#pyang -f tree junos-conf-root\@2023-01-01.yang junos-conf-protocols\@2023-01-01.yang --tree-depth=5
--tree-path=/configuration/protocols/bgp/group
junos-conf-root@2023-01-01.yang:10: warning: imported module "junos-common-types" not used
module: junos-conf-root
  +--rw configuration
     +--rw jc-protocols:protocols
        +--rw jc-protocols:bgp
           +--rw jc-protocols:group* [name]
              +--rw jc-protocols:name                                  string
              +--rw jc-protocols:apply-groups*                         string
              +--rw jc-protocols:apply-groups-except*                  string
              +--rw jc-protocols:apply-macro* [name]
              |     ...
              +--rw jc-protocols:type?                                 enumeration
              x--rw jc-protocols:protocol?                             enumeration
              +--rw jc-protocols:traceoptions
              |     ...
              +--rw jc-protocols:description?                          string
              +--rw jc-protocols:metric-out
              |     ...
              +--rw jc-protocols:multihop!
              |     ...
              +--rw jc-protocols:ebgp-community-cleanup!
              |     ...
              +--rw jc-protocols:route-server-client?                  empty
              +--rw jc-protocols:accept-remote-nexthop?                empty
              +--rw jc-protocols:preference?                           union
              +--rw jc-protocols:local-preference?                     union
              +--rw jc-protocols:local-address?                        jt:ipaddr
              +--rw jc-protocols:local-interface?                      union
              +--rw jc-protocols:forwarding-context?                   string
              +--rw jc-protocols:hold-time?                            union
              +--rw jc-protocols:minimum-hold-time?                    union
              +--rw jc-protocols:passive?                              empty
              +--rw jc-protocols:advertise-inactive?                   empty
              +--rw (jc-protocols:advertise-peer-as-choice)?
              |     ...
              +--rw jc-protocols:advertise-external!
              |     ...
              +--rw jc-protocols:keep?                                 enumeration
              +--rw jc-protocols:rfc6514-compliant-safi129?            empty
              +--rw jc-protocols:no-aggregator-id?                     empty
              +--rw jc-protocols:mtu-discovery?                        empty
              +--rw jc-protocols:enforce-first-as?                     empty
              +--rw jc-protocols:out-delay?                            union
              +--rw jc-protocols:ttl?                                  enumeration
              +--rw jc-protocols:log-updown?                           empty
              +--rw jc-protocols:damping?                              empty
              +--rw jc-protocols:import*                               jt:policy-algebra
              x--rw jc-protocols:nlri*                                 enumeration
              +--rw jc-protocols:bgp-error-tolerance!
              |     ...
              +--rw jc-protocols:family
              |     ...

The following method shows how to retrieve operational stats for interface using YANG operation data model. Output shows operation data of fxp0.0 in XML rpc format to retrieve RPC information. RPC name retrieved is get-interface-information. Pyang tool is then used to get output interface statistics in tree format with help of get-interface-information RPC.

lab> show interfaces fxp0.0 statistics detail | display xml rpc 
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/23.2R1.13/junos">
    <rpc>
        <get-interface-information>
                <statistics/>
                <detail/>
                <interface-name>fxp0.0</interface-name>
        </get-interface-information>
    </rpc>
    <cli>
        <banner></banner>
    </cli>
</rpc-reply>

#pyang -f tree junos-rpc-interfaces\@2023-01-01.yang --tree-depth=3 --tree-path=get-interface-information
module: junos-rpc-interfaces

  rpcs:
    +---x get-interface-information
       +---w input
       |  +---w no-forwarding?                        empty
       |  +---w (chassis-selector)?
       |  |     ...
       |  +---w (re-selector)?
       |  |     ...
       |  +---w (lr-selector)?
       |  |     ...
       |  +---w (tenant-selector)?
       |  |     ...
       |  +---w (vc-selector)?
       |  |     ...
       |  +---w routing-instance?                     string
       |  +---w satellite-device?                     string
       |  +---w ifl-class?                            enumeration
       |  +---w get-interface-smart-sfp-statistics?   empty
       |  +---w get-interface-smart-sfp-defects?      empty
       |  +---w aggregation-device?                   empty
       |  +---w level?                                enumeration
       |  +---w level-extra?                          enumeration
       |  +---w snmp-index?                           union
       |  +---w interface-name?                       string
       +--ro output
          +--ro interface-information
                ...

Summary

YANG stands for "Yet Another Next Generation". It:

• is a data modelling language designed to allow us to programmatically represent configuration and operational stats of data
• uses modern transport layer protocols such as NETCONF and RESTCONF
• explicitly and precisely defines data
• defines models for data and NETCONF transports that data
• isn't tied to a particular transport protocol.

If you'd like to learn more about YANG data models along with NETCONF and RESTCONF protocols check out our webinar recording Fundamentals of Network Programmability.  We are also running a training course on Network Automation which is free of charge to Service Providers and those who run their own network.  More details and sign up button below: