As network engineers are bombarded with more and more terms like NETCONF, RESTCONF, YANG, REST APIs every day, it’s becoming increasingly important to understand the basics of these terms if not in-depth for all network engineers. To begin this series of uncovering the meaning and relevance of these terms for network engineers, let’s start by demystifying What is YANG For Network Engineers.
YANG is a data modeling language and it stands for Yet Another Next Generation. Now the very immediate question is What does data modeling language mean?
Think of YANG as an architectural blueprint where the architect clearly mentions the overall view and tiny details like dimensions and types of individual building blocks. Think of YANG like classes in Object Oriented Programming languages. Let’s try to take an example that is closer to the field of network engineering.
The YANG model defines how the CLI of the devices will behave. So for a device that supports NETCONF, it will also support a YANG model which essentially means, if two devices are based on same YANG model, they will have similar CLI fields and expected fields in the command outputs.
Think of YANG data model as SNMP MIB so if devices of multiple vendors support same MIBs, you can safely predict the response and behaviour of that device via monitoring tools.
https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/1761
Let’s take a look at the CISCO YANG model for the operational state data of BGP.
This YANG model above defines
- What you see in cisco CLI for BGP operational state
- When you hit ?, the autocomplete options that you see are modelled after this datamodel.
- The validation errors that you get when you type unexpected value is also due to the parameters that are coded in the above YANG model. Take a look at this small excerpt from this huge yang model.
leaf as {
type uint32;
description
"BGP neighbor AS number";
}
leaf local-port {
type uint32;
description
"Local TCP port used for TCP session";
}
leaf local-host {
type inet:ip-address;
description
"Local address used for the TCP session";
}
leaf foreign-port {
type uint32;
description
"Remote port used by the peer for the TCP session";
}
leaf foreign-host {
type inet:ip-address;
description
"Remote address of the BGP session";
}If you look closely, it clearly specifies that the AS number is of type uint32 ( unsigned integer 32 bytes ) which in other means you can’t put a string there, it has to be a number otherwise the CLI will throw an error. Similarly, you can’t put any random number in the local-host field, it has to comply with the ip-address data format. So if you put anything that is not an ip address, you would have noticed CLI throughs an error. All these are validated by YANG DataModels for the devices that support YANG Models. Older CLI devices did not use YANG but pure programming logic to achieve this.
YANG Resources:-
