NETCONF and YANG Tutorial part 1a: NETCONF and YANG Overview

welcome to part one of the net convenient tutorial this is a 30-minute session we will firstly in a couple of minutes define Medical Phineas then we will step back and look at the requirements put forward by operators and service providers why there was a need for a new standard for doing configuration management we will deep dive a little bit into transactions since this was a fundamental requirement we will wrap up the session by doing some live network management using a net accompanying enable device and various management tools to actually do management in a standardized way first of all here is the two-minute elevator explanation of net company egg what is it and why is it useful if you simplify things from a technical standpoint we have management applications and a metric management systems OSS systems Network automation systems and such they need to be able to remotely read the configuration data in the devices be able to remotely bright and change that configuration across several devices so that boys down to we need a remote protocol we need something that can read and write data over tcpip so that's the actual protocol how do I read how you write how do I perform actions that's that's the protocol but a protocol is nothing without a formal definition of its payload so if not called lets me read an interface or change an interface what are the attributes of an interface so that corresponds to the yang models so every every device is described by yang data models and so in this case I have three devices if they're different they obviously have different data models and so the management application has the yang data models everybody know when they read the interface they understand the data that is retrieved also when the need change in interface based on the angle station know which attributes can be changed on an interface so the net call that's the protocol it's a remote protocol and the yang models tells what the data can be read and written so I'm carefully saying it's data model and what is a data model data model is it's very concrete it defines exactly which data can be read and can be written described it explicitly precisely the structure of the data to syntax and semantics of the data and this is of course the data that is externally visible for a management system for a client so it's not a model of the software inside the box or anything like that it's if you see the device is a black box what can be read what can be written and it's a complete model everything that can be rather written should be there and it's consistent so good modeling characteristics and then the protocol obviously needs to have remote primitives to view and manipulate that data and protocols also defines the DNA encoding it makes sense to compare Netcom with something well known as SNMP so protocol we all know about the SNMP protocol with gets and sets and get next and there's the level one network protocol lives at the different set of operations with different characteristics based on requirements we talked about previously data models well there were both Andes mid modules in yang you talked about yang module so a set of yang modules makes up the data model for the device and sometimes there is a bit of confusion between information models and data models I'm generalizing a little bit but information models are more targeting humans they're targeting the problem of domain experts being able to discuss and share knowledge between each other information models are not necessarily targeting automation software parsers and tools so that's the thing and typically you start with an information model that sometimes see its graphical sometimes not based on that you make it precise you make it exact into a data model so information models are useful starting point for data model but information models are not precise enough to be used by software protocol there's sometimes a bit of confusion between people saying what why do we need a snap call can't we just have soap or rest or everything and what you tend to forget then is that net conf is Adam and Pacific protocol knows about network management that understands configuration management and that leaves honored general RPC mechanism in this case as a sage and the next ml RPC whereas soap arrest or general-purpose or pcs you could in theory being the good management protocol on top or top arrest but there is no guarantee and more important there there now standards so remember net comp is a full ITF standard you can interrupt test a device claiming that conf and it will enable plug-and-play directly with management systems taking general are busy mechanisms can never be interrupts ested and will always assume a lot of integration work so that was the introduction Netcom protocol yang data model where does it come from what's the background actually made this thing happen there is a very good reading I strongly recommend all of you to read or see 35 35 it's an RFC the step describes actually a meeting there was a workshop in 2002 where network operators were brought into the room to discuss meet ITF around what's the focus for ITF regarding network management in the future and the conclusion was was quite easy to see as an MP is in place and it's useful for monitoring but when it comes to configuring it's not being used there were some attempts to have as an MP word for configuration but that failed so if you look at how its configuration performs J it's it's Eli's cryptic and of course vendor-specific see lie scripting and that was the debate take from the operators we need some thing that is standardized for doing configuration management and they put together a number of requirements in this document so not designing any protocols or anything just collecting what are the most important requirements for operators when it comes to a standardized management interface and ease of use number one you seduce is a very sloppy requirement or hard to test but what it means in this context is if you are an operator and you buy an equipment you should be able without having 15 integrators there for three months being able to receive the alarms and even more important being able to configure the box that the standard must apply easy to use pluggable interface from the management system to the devices that must be easy and be able to automate not requiring humans for doing everything not requiring large software projects for supporting your new device and not our very important characteristics which is nothing new every good seal eye has a clear distinction between how to retrieve the config versus to seeing statistics show running config shows you the configurable variables how they are configured currently that's one thing in contrast to operational state and statistics so for CLI engineers this is obvious but on the other hand if you look in the SNMP world there is no clear distinction you can't ask it an SNMP box for give me your country you can walk the mill but you get all the variables firstly you don't know what is config what is operational data and the latest thing is if you fetch that there is no way to easily copy and paste that into another box so clear separation between concrete data and operation data that should be clearly denoted for every single piece of item in the data model is config or operational data and you should easily be able to compare so you should be able to get the country one device get the comb through another device and compare that to see how they are different requirement number four and five it's very interesting operators said that we need to be able to configure the network as a whole not just peeking in poking variables in single devices but to be able to provision say a VPN across the devices and think about that as an atomic transaction so not required transactions configuring network services rather than just bits and pieces in individual devices and this puts transactions in the focal point transactions across devices ordering ordering it is a tricky thing of them many less useful configuration interfaces if I need to set a and B in a device it's very tricky to know if do I need to set a B or these to the device require me to do beyond a this shouldn't actually be something that the imaginal system needs to know anything about the management system should be able to say set these variables and you device you figure out the ordering it's not up to me to fix that so that's the ordering thing and secondly connecting back to previous slides have being able to clearly distinction between config and operational data you should be able to in a very simple way pull the config from one device push it to another and I think this is a very useful litmus test come across various home route management interfaces for device vendors currently that experimented with RPC mechanisms or various kinds and many of them surprisingly enough forget the basics is there a trail running config can I in one operation get the complete configuration can I have that in a file and paste that into another system so that this is a very easy test can I get the config store it push it to another device because this is the way operators typically work maybe get the config editor couple variables and then push it to another device and it's very important that it's true daddy to get to complete so get any conflict for long box to another should make the other box being a complete copy of the other bringing it into the accept same state no hidden things that are not visible all the configuration should be able to get and be able to push down to another one remember that little litmus test go back to your lab can you do that with all your devices consistency is important of course when it comes to the configuration should be able to prepare a configuration should be able to validate that the kinetically level is this a valid configuration will it work does it or does it violate violate any and it constraints next text based configuration its work also that goes back to previous requirement on the previous slide should be able to get the conflict and inspected text text your representation again compare of it as an ambulance binary third there's no chance you can get the SNMP variables and bring them up in an editor and you expect and change and paste into another one so text based configuration was a primary require because that opens up a whole universe of tools where you can diff text files you can have small automation script ports text and changes text so that it's a fundamental requirement in a good config management protocol clear texture print it's a representation of the confi data and also continuously comparable it doesn't end with one thing that is good with us and I'm pleased that that there is a fairly large amount of standardized MIPS then of course the question is student different vendor supports a standard nursemaids do they implement the MIPS accordingly but that's a secondary question at least there is a library of standardized nibs and the same goes here I mean if we have different vendors and all routers have interfaces could there actually be standardized interfaces data model very much like the AF me billing the SNMP world if moving on to configuration management we certainly need standardized data models for full of fundamental features on the devices so that that can be shared among vendors in in some protocols whatever you do take immediate effect if you do in SNMP set it happens immediately and will operate or sell here it's very important to distinguish between sending the configurations down to the devices is one thing activating them it is another thing because that helps you build upper orchestration sort of deployment you should go to send a config send a config and then finally committed so separation of the actual the happening and the distribution of the calculation also devices should be able to hold multiple configurations a fairly common pattern is that you have a running data store you have a candidate data store say so you can manipulate the candidate data store until you feel you're done and then you commit the candidate tool around that that's one example holding multiple configurations so if you step back or what's behind all these requirements and if we would fulfill these requirements in standard how would things change in the industry and when it comes to configuration management if we look at current situation from devices there are no well-defined protocols and data models to do in configuration management there's lack of atomic transactions meaning that when you change things some might go through some might not go through it's very hard to do rollbacks there is always tricky round ordering you never know which pieces need to be set before the other ones so going from one state to another you need to in the management system get used to watering and even harder to do the juice Traverse ordering to achieve a rollback so that creates a lot of cost and complexity for for the service provider for the operators in order to integrate devices integer management systems and this gives rooms for the huge integration text we have for every new device typed for every new service TOC slows down the whole industry because we need to kick-start a software project for every new device and every new service having that convenient in place and well implemented as well not well well implemented not just a tick box in your EFI would change the gameplay a little bit that company would put more requirements on only device vendors and would increase the cost me to go master and it requires transactions it requires the devices to fix the order and not the management system so we're pushing a bit of complexity from the LMS system to down through devices but on the other hand the value of the public devices will be much more increased so with devices with support transactions standardized data models and standardized protocols we could reduce the cost and complexity and drastically reduce the the time it would take to introduce new services devices in the Animas so this is where were these standards the solution is pushing and will help operators greatly so that was a requirement and as a result of that Ida started the working group firstly around net count and after that the the yang data modeling language that goes in hand-in-hand with calm Oh so what you will see pretty soon as that the requirements we've been looking at here are fulfilled by net convent yang together let's look at what comes from standards doesn't come from the blue needed from printers there are always human and brilliant engineers behind successful standards so starting with Netcom net conf is actually rooted in technology from juniper so with the background requirements we've been looking at Jennifer brought their technology to ITF and so that's primarily feel Shafer romance from Jennifer so would happen there is the third technology was standardizing called net Cove looking at it yang what are the routes for yangdon several routes along with the technology from juniper they also had a XML schema providing the data models that was one input we have here again that's been working with SNMP and been working on an sm ing meaning next-generation language for writing maps and all the multi Oakland from TF had a vendor specific language so those three different templates was of the routes that emerged into yang and there was also a lot of work from Ericsson David pertained it actually make it a standard happen so let's continue at this point we will move on to a quick demo rather than going more theory let's see napkin from the onion action so it's time to put theory into practice I will do a tiny demo with a tiny yang data model so let's start by looking at the module definition don't be scared about syntax at this point we will explain the details later the put individual modules into a module obviously and you give it a name and don't take this as a design pattern you shouldn't make a huge en for the complete device so rod or make small modules and the device puts together several modules to describe to complete functionality and now we can skip the administrative stuff in the beginning and get to the actual data data ice variables in the data are called leaves so here we have a simple leaf called name type string a state type in the new enumeration good or bad you can group leaves into containers so containers in this case is sort of a logical grouping word to find these two leaves if you have another container hold interfaces which has a list of individual interfaces every interface has a name and answer type and when you define list you need to specify the key and it can be one or several leaves that together makes up the key in this case the end of his name is the key in the bottom arrow we have a very useful type called the leaf ref so in this toy example we would like to denote which of the interfaces already is the management interface called Kadesh Barnea a very simple a stupid model would have made this into a string which meant it you could fubar as dimension with the interface although it didn't exist however it's a leaf ref and a specific path into the data model so the slashes here denotes a path so you see interfaces interface name so this leaf ref can only reference existing interfaces if you would try to set this to something else it would be rejected if you would try to delete an interface that is referred to by leaf ref that would also be rejected so this is a data model that describes my simple box I have a device up and running that supports this data model and I have the device supporting Netcom and C lie so when I pre configured the device a little bit let's look at the configuration so remember I had one container called properties I had another one called interfaces so it's configured with the name box 100 and state is good and a couple of interfaces and one of them being appointed as the management interface so this was using the local Xilai but net conscious about being able to have remote applications automatically configure devices so it shall be the net conf now I will start by using a browser there are various technical trousers in the market which gives you a handy tool to tool and navigate and see what's going on here we start by connecting an ssh authentication here so where i start right now I haven't loaded any Yang's or or anything this is a totally empty client I'm I just entered the IP address and load the entity net Co server in my box and when you the network client and an escrow server start talking to each other the first thing that you is hello and the hello exchange capabilities and capabilities tells already the supported feature so that the client and service can adapt this is a very interesting capability the Netcom server tells the Netcom client which data models do you have which yang modules so here you see that the server supports Acme box we will utilize that later on and other things are or the capabilities stand on that conf capabilities so this device has a writable candidate database so I do the ad is towards the candidate then I commit the candidate to the running but I can't do much without the data model in the SNMP world you had to call the vendor or try to go to some anonymous FTP sites and try to understand which maybe you should find and load to speak to the device but since I got the capability up here telling the name of the module this was an optimal feature to ask the net con server about can I please get the actual data model hold the wire that's a separate feature it's part of a yang data model called net cord monitoring I will do that now I will ask the device which data models do you have tells me I have acumen box I can take that and say download so the management system on-the-fly downloads the actual data model I got it and this means that I can update my management system with that specific data model totally online so in the browser I see the same thing here now from this name state interfaces let's start a little bit simple by the way here you see the output takes them out over the wire I got this I got data model in the yang syntax okay let's do a little bit of that cough get config net cough clearly separates configuration data from statistics and operational states the yang data model we had it didn't say anything but the default when you brought yang data models is that if you don't say anything it's considered configuration data meaning things that the management system can can write things that needs to be hard to be backup it can be restored so this data model everything was actual conflict so let's get the config read the running data store the capabilities told the client that there's a running data store and the can read data store but we're interested in the configuration on the running datastore so here we see the output box name box date remember exactly what we got in the CLI me the dual can also render an output tree let's check the interfaces stick down 6ml see the various interfaces its name its type etc no magic so remember what happened here when I started the client it was totally empty no clue what about the capabilities the actual data models but due to net Cove first of all hello exchange where I discover the capabilities such as running in candidate also supported data models but by the device supporting network monitoring I could on the wire download the correct data model and now I know the individual fields that I can configure and read so I can't immediately start inspecting the individual I could interpret it so this is reading config and let's go on and do a little bit of editing here maybe change the name change name to box zero so let's look at this part the whole operation is an edit config operation and we are targeting the candidate database again repeating myself when we did the hello the server told me that it has a candidate and running so I will write the candidate database later on I will commit the candidate to the running and what goes in the config tags here then must adhere to the specific data model for this specific device so here you see the namespace I'm referring to a specific name space here that must exist in the data model so look up here the admin box had this name space that's what's appearing here and it has a container properties and a leaf called name now I'm setting that to box Cyril validated alright and let's go send us our PC so I'm sending the edit config or PC to the box I got response back okay so at this point I've started a transaction towards the candidate database in the box I can continue edit under parts and then do a final commit which will commit the candidate to drowning and in this case I will commit immediately so commit this means copy candidate to running if everything worked fine here we can go back to the device and expect that we actually change the box 9 to box serial so previously it was box 100 let's see what we have now box zero surprisingly enough it worked right so that was using a tool but remember that one of the requirements for Burnett Campos to use text based representation I mean this sort of looked SS and SNMP me browser abut me browsers needs to the decode and encode binary data but everything in that conf is XML plain text so I can do the same thing with the text based not compliant I have one here called Netcom console first let's do the hello you see the same thing here and let's to read the interfaces so here I'm saying should actually not say get to be correct on a tutorial we should actually do they get config get gives you both config and operation data and this would be the same in this specific example because the complete data model is conflict data if I would have stated something in that data model s conflict false the get conflict would not receive pretty that but the gap would actually have retreat that as well so get me all the configuration that is available on very specific path so minus X here stands for below this X path expression so give you all the interfaces here we record interfaces again let's do the same with properties throughout the properties so I hope you got a little bit hang of that convent yang in practice here we will now take several step backwards and start from the beginning explaining the linear code protocol and the yang data modeling language and in more carefully

Channel: Tail-f Systems

Views: 62,477

Rating: 4.916955 out of 5

Keywords: NETCONF, YANG

Id: Vr4kB1_6fLQ

Length: 33min 9sec (1989 seconds)

Published: Sat Oct 18 2014