YANG is a data model language used by NETCONF, RESTCONF, and gNMI to automate network configuration, maintenance, and troubleshooting.
However, before we use YANG with various automation protocols throughout the course, in this section we will review and explore the YANG data model to better understand it.
YANG data model Fundamental
What is YANG and why we do use YANG data mode?
As you know different vendors of network devices have different command syntax and they are natively not programmable.
However, YANG is a data model that represents a different way to configure, monitor, and troubleshoot network devices that is natively programmable.
You can think of YANG data model as something like SNMP MIB data structure, but in the SNMP unlike YANG, objects are mostly non-configurable and it is typically used for monitoring purposes.
As with the SNMP protocol, YANG data model has standard and also vendor based data structures.
With the standards-based YANG data structure, there is the opportunity that we can configure network devices with different vendors in the same way without having to worry about different command syntax.
YANG Repository
If you search “yang github” on the web, the first output is the link to the YANG repository in github, which contains a collection of YANG modules, including standard and vendor-based YANG models.
Inside the “vendor” folder you can see the YANG data model of some famous vendors like Cisco, Juniper, Huawei, Fujitsu and Nokia.
Inside the “cisco” folder, YANG models of different Cisco device types “xe”, “xr” and “nx” are listed.
In the “xe” folder, YANG models of different versions of IOS XE devices are listed.
At the time of writing, the latest version of the IOS XE YANG data model is 17.9.1 which is listed in the folder “1791 “.
In this folder, YANG data model “Cisco-IOS-XE-native.yang” is the most well-known Cisco YANG data model, which we will refer to many times throughout the course.
As an example of a standard YANG data model, let’s go to “standard” folder, then “ietf”, then “RFC”. Here “ietf-interfaces.yang“is the most well-known standard YANG data model, which we’ll cover many times throughout the course.
Explore YANG data model through the WEB
If we look inside “ietf-interfaces.yang”, it points to the 2018 version. There are two versions of the YANG data mode of ietf-interfaces. One refers to the year 2014 and the other to 2018.
If we look at inside ietf-interface Version 2018, “ietf-interfaces@2018-02-20.yang”, here is a namespace that is a unique name for each YANG data model.
There are some metadata information such as organization, contact, description and revision which are mainly used for the documentation.
Then there is an “interfaces” container, which is like a folder. Inside the container is a list of interfaces. The name of the interfaces is also the key and must therefore be unique.
For each interface there is a “name” with the type of the “string”, a “description” with the type of the “string”, “type” of the type of “identityref” and it is mandatory. “enabled” of the type of “Boolean”, “link-up-down-trap-enable”, of “enumeration” type with two “enabled” or “disabled” values, “admin-status”, of “enumeration” type with “up” and “down” values, and many other parameters, some for configuration and some for monitoring purposes.
module ietf-interfaces {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
prefix if;
import ietf-yang-types {
prefix yang;
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"...";
description
"...";
revision 2018-02-20 {
description
"...";
reference
"...";
}
...
}
typedef interface-ref {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
description
"...";
}
identity interface-type {
description
"...";
}
feature arbitrary-names {
description
"...";
}
feature pre-provisioning {
description
"...";
}
feature if-mib {
description
"...";
reference
"...";
}
/*
* Data nodes
*/
container interfaces {
description
"...";
list interface {
key "name";
description
"...";
leaf name {
type string;
description
"...";
}
leaf description {
type string;
description
"...";
reference
"...";
}
leaf type {
type identityref {
base interface-type;
}
mandatory true;
description
"...";
reference
"...";
}
leaf enabled {
type boolean;
default "true";
description
"...";
reference
"...";
}
leaf link-up-down-trap-enable {
if-feature if-mib;
type enumeration {
enum enabled {
value 1;
description
"...";
}
enum disabled {
value 2;
description
"...";
}
}
description
"...";
reference
"...";
}
leaf admin-status {
if-feature if-mib;
type enumeration {
enum up {
value 1;
description
"...";
}
enum down {
value 2;
description
"...";
}
enum testing {
value 3;
description
"...";
}
}
config false;
mandatory true;
description
"...";
reference
"...;
}
...
Explore YANG data model through “pyang”
There is also a better way to explore the YANG data model, which is done through the “pyang” Python library.
To explore YANG data models through the pyang tool, we need to clone YANG data models from the Github source community to the local repository and also install the pyang python library.
Use “git clone https://github.com/YangModels/yang.git” command to download YANG data models to local repository.
git clone https://github.com/YangModels/yang.gitAnd use “python3 -m pip install pyang” command to install python pyang library.
python3 -m pip install pyangIf you look into the “yang” folder you can see the exact structure that we have already seen in GitHub over the web.
As an example, let’s go to the “yang/standard/ietf/RFC/” folder and then use pyang with the “pyang -f tree ietf-interfaces.yang” command to explore the YANG data model, “ietf-interfaces”.
pyang -f tree ietf-interfaces.yangThe output of the command shows the structure of the YANG data model “ietf-interfaces”, which is much easier to read than the web version.
majid@devnet:~/yang/vendor/cisco/xe/1791$ cd ~/yang/standard/ietf/RFC/ majid@devnet:~/yang/standard/ietf/RFC$ pyang -f sample-xml-skeleton ietf-interfaces.yang <?xml version='1.0' encoding='UTF-8'?> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <interface> <name/> <description/> <type/> <link-up-down-trap-enable/> <admin-status/> <oper-status/> <last-change/> <if-index/> <phys-address/> <higher-layer-if> <!-- # entries: 0.. --> </higher-layer-if> <lower-layer-if> <!-- # entries: 0.. --> </lower-layer-if> <speed/> <statistics> <discontinuity-time/> <in-octets/> <in-unicast-pkts/> <in-broadcast-pkts/> <in-multicast-pkts/> <in-discards/> <in-errors/> <in-unknown-protos/> <out-octets/> <out-unicast-pkts/> <out-broadcast-pkts/> <out-multicast-pkts/> <out-discards/> <out-errors/> </statistics> </interface> </interfaces> <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <interface> <name/> <type/> <admin-status/> <oper-status/> <last-change/> <if-index/> <phys-address/> <higher-layer-if> <!-- # entries: 0.. --> </higher-layer-if> <lower-layer-if> <!-- # entries: 0.. --> </lower-layer-if> <speed/> <statistics> <discontinuity-time/> <in-octets/> <in-unicast-pkts/> <in-broadcast-pkts/> <in-multicast-pkts/> <in-discards/> <in-errors/> <in-unknown-protos/> <out-octets/> <out-unicast-pkts/> <out-broadcast-pkts/> <out-multicast-pkts/> <out-discards/> <out-errors/> </statistics> </interface> </interfaces-state> </data>
The name of the module is “ietf-interfaces“. It has two main sections, “interfaces” which is “rw” or “read/wrire” and therefore can be used to configure the interfaces, and “interfaces-state” which is “ro” or “read only” which is used for monitoring purposes.
Under “Interfaces” and next to “Interface” is a “*” sign, which means a list of interfaces and it’s unique based on the name of the interface.
For each interface, there are many leaf parameters like “name”, “description”, “type”, “enabled”, “link-up-down-trap-enable”, “admin-status” and many other parameters.
Beside each leaf, if it is written “rw”, it means that is configurable and if it is “ro”, that means it is read only.
If there is a question mark “?” beside a leaf, It mean that it is optional and if there is nothing, It means mandatory.
The type of each leaf is also written in the right section of the leaf parameter. If it is, for example, “string“, “identityref“, “boolean” or “enumeration“.
discover supported YANG data models in network devices
The next question that may arise, how we know which YANG data models are supported in our devices.
To know that, first we need to enable SSH in the network device. This is because NETCONF uses SSH to send RPC commands to network devices to read or write in the YANG data model.
Also make sure that the device already has an IP address and also a username with privilege 15 to connect to the device.
Then we need to enable YANG in the network device.
As an example, the commands “netconf-yang” and “netconf-yang feature candidate-datastore” are used to enable YANG in the Cisco IOS XE router.
# give IP address
# enable SSH
# then
username rayka privilege 15 secret rayka-co.com
netconf-yang
netconf-yang feature candidate-datastore
Then we use SSH to connect to the device using port 830, which is the NETCONF default port and “-s” option to request the network device’s “netconf” subsystem.
ssh rayka@192.168.2.91 -p 830 -s netconfWith running this command, all supported YANG data models by the nework device will be displayed on your screen.
<pre style="background-color: #34495E; color: white; padding: 5px; border-radius: 5px;"><code><font size="-1">majid@devnet:~$ ssh rayka@192.168.2.91 -p 830 -s netconf rayka@192.168.2.91's password: <?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.0</capability> <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability> <capability>urn:ietf:params:netconf:capability:xpath: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: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> ...</font></code></pre>
You can use the “grep” option to limit the output lines to specific keywords like “ief-interfaces”. It shows all supported YANG models with the name including the keyword “ietf-interfaces” that we have already discussed.
majid@devnet:~$ ssh rayka@192.168.2.91 -p 830 -s netconf | grep "ietf-interfaces" rayka@192.168.2.91's password: <capability>urn:ietf:params:xml:ns:yang:ietf-interfaces?module=ietf-interfaces&revision=2014-05-08&features=pre-provisioning,if-mib,arbitrary-names</capability> <capability>urn:ietf:params:xml:ns:yang:ietf-interfaces-ext?module=ietf-interfaces-ext</capability>
As you can see, “ietf-interfaces” YANG data model is supported in this network device.
Which YANG data model?
The other question that can arise is: what data model is used to configure or monitor a feature in a network device?
The answer to this question will be demonstrated in the next sections.
But generally the Idea is that we configure the feature inside the network device through the command. Then we use netconf to read YANG version of the configuration.
The output of the command shows which YANG data model or data models are used to configure that particular feature. The exact path of the feature inside the YANG data model can also be seen in the output.
As I have said earlier, this will be demonstrated in the next sections.
Extract XML structure of a YANG data model
As we will show in the next sections, one way to modify a specific part of the configuration is to take a XML structure example of that part of the configuration and modify that section.
To get the XML structure of a specific part of the configuration, usually we use netconf to connect to the network device to get that specific configuration section in the XML format.
But sometimes it is also possible to get XML structure of a YANG data model without connecting to the device and just through traversing yang data model locally.
This is done through “pyang -f sample-xml-skeleton” command and then the name of the YANG data model.
majid@devnet:~/yang/vendor/cisco/xe/1791$ cd ~/yang/standard/ietf/RFC/ majid@devnet:~/yang/standard/ietf/RFC$ pyang -f sample-xml-skeleton ietf-interfaces.yang <?xml version='1.0' encoding='UTF-8'?> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <interface> <name/> <description/> <type/> <link-up-down-trap-enable/> <admin-status/> <oper-status/> <last-change/> <if-index/> <phys-address/> <higher-layer-if> <!-- # entries: 0.. --> </higher-layer-if> <lower-layer-if> <!-- # entries: 0.. --> </lower-layer-if> <speed/> <statistics> <discontinuity-time/> <in-octets/> <in-unicast-pkts/> <in-broadcast-pkts/> <in-multicast-pkts/> <in-discards/> <in-errors/> <in-unknown-protos/> <out-octets/> <out-unicast-pkts/> <out-broadcast-pkts/> <out-multicast-pkts/> <out-discards/> <out-errors/> </statistics> </interface> </interfaces> <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <interface> <name/> <type/> <admin-status/> <oper-status/> <last-change/> <if-index/> <phys-address/> <higher-layer-if> <!-- # entries: 0.. --> </higher-layer-if> <lower-layer-if> <!-- # entries: 0.. --> </lower-layer-if> <speed/> <statistics> <discontinuity-time/> <in-octets/> <in-unicast-pkts/> <in-broadcast-pkts/> <in-multicast-pkts/> <in-discards/> <in-errors/> <in-unknown-protos/> <out-octets/> <out-unicast-pkts/> <out-broadcast-pkts/> <out-multicast-pkts/> <out-discards/> <out-errors/> </statistics> </interface> </interfaces-state> </data>
Hi,
I have a question regarding YANG models available on the routers. I noticed that available YANG models on different routers even with same version of OS, may differ in terms of revision. Since the revisions are different, the models structure for configuration may be different too. I am wondering if there is any way to upload YANG models to the routers, or select a specific revision from the YANG models.
This problem came from the point where I want to do some testing before pushing the configuration to the router. I want to have a test router on an emulator like EVE-NG with exact same YANG models. But even with the same OS version, there are some differences.
Thanks
Hi Hamed,
you don’t have to worry about revesion numbers since they are mostly comptaible and you can not only start your test but also in production network without any worriness.