What is YANG? How is it implemented in Junos?

The very first time I heard about YANG I immediately thought about YIN and YANG ☯, what this tech stuff is about and who is responsible for this naming? Surprise, it does not have a connection to YIN and YANG ☯, even if we can translate YANG into an alternative XML-based syntax called YIN…or maybe I did not found a good explanation 😎 Therefore, before we start, the abbreviation means Yet Another Next Generation.

Finally, I became curious about YANG when I saw a presentation in 2016, but I discovered YANG within the last months due to blog articles, discussions, OpenConfig and research regarding SDN topics. The last two seem to be a pusher for YANG. So in my feeling, it becomes more present.

In the following, I will introduce what YANG means and how Juniper implemented it into Junos. I will cover this part with a brief example on my vMX. In the end, I will also introduce the awesomeness of YANG.

What is…Y…YANG?

YANG was published by IETF (or more specifically the Network Modeling (NETMOD) working group) in October 2010 with RFC6020. There already exists Version 1.1 through RFC7950 (August 2016) for fixing some „ambiguities and defects.“ YANG is a language developed for modeling data of network elements. First, I was a bit confused because a YANG data model is inside of a YANG module 🙂 YANG is human readable and in my opinion easy to learn as the structure is quite common if you have worked with JSON, XML or even better some programming or script languages.

„YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.“  [RFC6020]

So with YANG, you can model configuration data, operational data, RPCs or notifications. This allows the client and network device to work with the same data model. In this post, I will focus on configurations. In the end, YANG is still a newcomer – YANGstar 😆 This fact also becomes visible because standardized YANG data models are still beeing developed for all kind of stuff, especially network services. If you search for RFCs at the IETF website you will find a listing of already defined models:

  • Data Model for Interface Management (RFC7223, May 2014)
  • Data Model for System Management (RFC7317, August 2014)
  • Data Model for SNMP Configuration (RFC7407)
  • Data Model for IP Management (RFC7277, June 2014)
  • Data Model for Routing Management (RFC8022, Nov.2016)
  • Data Model for L3VPN Service Delivery (RFC8049, Feb.2017)
  • Data Model for Key Chains (RFC8177, June 2017)

But there are still a lot of YANG models in the pipe, and this reveals that network industry is working on standards, but this will take some more time (btw it’s interesting checking who is involved in different RFCs). Just a few:

  • Data Model for VxLAN Protocol (Draft, June 2017)
  • Data Model for MPLS-based L2VPN (Draft, June 2017)
  • Data Model for Routing Information Base (RIB) (Draft, July 2017)

Okay, so many words but what does a YANG module look like? „A module contains three types of statements: module-header statements, revision statements, and definition statements.“ (RFC6020):

YANG Module

Within a YANG DATA MODEL you can use four different types of nodes:

  • Container (=is a group of nodes and has no value itself)
  • Leaf (=Represents only one single value of a specific type)
  • Leaf-list (=array of leaf nodes with one value; e.g. multiple MAC addresses)
  • List (=a list with a specific structure)

Let’s create a simple YANG module which represents an access port of a customer on an L2 switch with some information we would like to have like VLAN ID or customer name:

We have a container „access-ports“ which holds a list of ports – our access interfaces. Each port needs to consist of an ID, an identifier of the customer order and the VLAN-ID as these fields are mandatory. Please do not question the structure of my YANG model as it’s only a simple demo 😉 There are some tweaking possibilities like restricting the input with ranges, length limitations or the unique constraint for the port id which I did not use here. However, I will use this YANG model later with my vMX.

Juniper Junos + YANG

But first, let’s check how Junos supports YANG. Let’s say for example we are running a Juniper MX480 with Junos 15.1R6; we can download the native YANG modules at the Juniper Download portal in the „Tools“ section:

Alternatively, you can generate YANG modules via Junos itself by entering the „show system schema“ command in operational mode. But generated YANG modules are specific to the series where you execute the command:

I have checked this command with my vMX running 16.1. The YANG module of the configuration is one single file named „configuration.yang“. If you do not set the „output-directory“, it will display the whole YANG module 😀

If you enter the „show system schema module juniper-command“ it will take some time without any text output, and all the operational YANG modules are created in the „/var/tmp“ folder by default, but you can change this if you set an output path:

Starting with Junos 14.2 Juniper provided the YANG module for the configuration schema only. With Junos 16.1 they completed the native YANG modules with adding the „juniper-command“ module for the operational level (as you can see above with e.g. „monitor.yang“).

But the biggest change here is that starting with Junos 16.1 you are now able to upload a custom (non-native) YANG model with a translation script to the device. It changes a lot because you can now create your very own CLI or you can even use the vendor-neutral data model OpenConfig.

If you are running an MX480 with Junos 15.1R6, I’m sorry, but you are not able to use OpenConfig or install your very own YANG module. Sufficient supported is YANG in Junos starting with 16.1.

Adding a custom YANG module

I transferred my YANG module which I have shown above as a file named „customer-orders.yang“ to my vMX into the „/var/tmp/“ folder. You should keep in mind that native YANG models can also be in the „/var/tmp/“ directory which could cause some confusion:

There also exists a show command for checking if there are already non-native YANG packages installed on the device:

You can now add the model via the „request system yang add“ to the system. You have to enter the path to the module file and a package name:

As you can see above, you can refresh the CLI after the installation. If we now check the configuration mode we can see that our custom configuration is pretty well integrated even with auto-complete and hints:

The prefix „customer-orders“ within the command looks a bit odd, but it’s needed so that multiple models won’t interfere themselves. We can now add our custom configurations:

At this point, Junos won’t do anything with the stuff I configure below „customer-orders:access-ports“ as it only exists in parallel to the conventional Junos configuration. Junos does not know how to deal with my non-native config 😥 If you want to translate your config into the operative configuration you need to use an additional translation script 💡

So…where is the awesomeness?

As already mentioned above you can customize your network device with YANG so that it fits your business needs. The awesomeness comes with the combination of a YANG module + a translation script. This combination gives us also the ability to insert an abstraction level on top of your typical Junos configurations. The best example here is shown with customized L2VPN configuration via YANG in Junos by Marcel Wiget.

„…hides the complexity and protocol and device related configuration…“ [Blog]

Instead of handling the routing instances and interfaces configuration of each pseudowire manually you can extend the configuration with your own YANG model abstraction:

So basically you have created a new abstract config level where you can quickly setup your L2VPN. In the end, the magical part comes with the combination of YANG with a Junos translation script – you can write this script in Python or SLAX.

Translation script

Like with the commit script, a translation script is executed with a commit and it can translate your own YANG config into the standard Junos configuration. In this example, the script creates all the routing instance and interface stuff you need for creating pseudowires in the background. That is cool, isn’t it?

Puh…the end

I have not seen (custom) YANG in the productive network wilderness yet, and I guess that ops and support would have some prejudices with non-native modules other than OpenConfig. If you have some first experiences with all this in operative business, please let me know.

There are still some open questions I would like to address. Like the comparison of the implementation different vendors or creating custom state data and translation scripts. As always: There is still much to discover 😉 Last but not least a huge thanks to Marcel Wiget for providing such interesting articles and projects. That is it for today 🙂 High five, thanks for reading this blog post.

Some links

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

© 2017 made with ♡ by stephan behrens - impress