Introduction In this blog we will be looking at a NETCONF overview and its practical use case for...
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 bgprouter 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/groupjunos-conf-root@2023-01-01.yang:10: warning: imported module "junos-common-types" not usedmodule: 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-informationmodule: 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:
