Using OpenDaylight

okay well good afternoon everyone thanks for sticking around happy to see you here my name is Charles and today's session is called using open daylight the idea is to focus a little bit more on like a bit of an introduction to open daylight and then show you how to install it and operate it more from the point of view of a user of it as opposed to say a developer who would be contributing code to it although maybe it'll help a little bit for that as well just to get an idea from the audience how many of you are pretty familiar with open daylight already okay not too many of you and that's that's a good thing actually because this is a pretty pretty introductory course hopefully there'll be some stuff you find interesting as well so what we're going to do is start with just a very quick discussion of what is what is Sdn just to kind of level the playing field there and then we'll talk a bit about open daylight then I want to spend some time with network programmability probably because it's a it's a really important topic and also I think one of the things I want to impress on you is that open daylight is a great platform for network programmability and for building network aware applications then we'll jump into the stuff that's a little bit more hands-on I'll show you how to download and install open daylight it's fairly easy so what we're going to do it you know live here - it doesn't take very much time and I'll show you how to bring it up how to install some features on it and then we'll go through some use cases where we look at some example networks that you might attach to because open daylight doesn't do anything on its own basically it needs to have a network underneath it so we'll look at some different scenarios there and then try a relatively straightforward use case that you can do on your own where we use mini net to create a network with some switches and have open daylight control that and then at the end we'll wrap up with some additional resources where I'll show you pointers to where you can do everything that that I showed you here today as well as some additional information that we have for you within within dev net and elsewhere within cisco sound okay anyone something you were really hoping to hear that not at all listed up here and maybe I can work into the agenda well please do ask questions at any point in time you know I'd like for it to be interactive you can wait till the end but you know if you have a question you know just wave your hand a lot and all I'll find you and then try to answer it as best I can all right so what is Sdn so you know Sdn what first came out really the core thing with Sdn and when everyone thinks about Sdn is well it's the separation of the control plane from the data plane right and with the pure I would say definition of Sdn it's not only that but you use open flow to control which is we're a typically white box you know switches and that was kind of the the initial definition and it is a valid definition of Sdn but I think or at least a use case of Sdn but I think you're kind of missing a lot of what Sdn has to offer there's actually I prefer to think of a broader definition of Sdn where it's not just that but it's we want to really take advantage of all the information that's in the network it's not just about configuring the network which is very useful in Sdn can do but it's about being able to have access to all the information that the network has to query it and then make some intelligent decisions on top of it and that's where network programmability and network aware applications come into play and to me at that programmability that that's really the power and the excitement that I think Sdn brings us let's you have this clicker cool so just to talk about this broader definition of Sdn a little bit more you know I have this picture and there is this separation of the control plane and the forwarding of the data plane in this case we are even mentioning open flow being used there but there's a lot more and this was as I mentioned there's a lot of information that's down here that the network knows about and if we're able to programmatically access that information get the real-time information do some analysis on it that's the application level and then feed that back into our decisions of how we want to configure our network then I think it's much more powerful see it's not just like a configure and forget about it it's let's configure let's monitor let's make changes on the fly and because it's all programmatic you have you know instantaneous programmatic access to your entire network so it's reasonable for you to be able to do this so thinking of that definition what is it that we we need or that we expect from an SDN controller then I mean obviously it needs to be able to you know configure and control our network but that's just that's just the start of things really want it to be a platform on which we control we can deploy Sdn applications so not just configure our switches but write those higher-level applications and plug them into our network we really want it to provide a good application development environment for us and so now there are some critical things we need for it to do that one we need api's if we're going to be able to access this information we need api's we need those API is to be consistent we need them to be developer friendly we'll talk later on about rest comps and and how that came into be but that's one example we also want to be able to abstract away from the application developer the details of the network we don't want them to have to care that about the network topology we don't want them to have to care about what underlying protocols we're using on the Network whether we're using say for example open flow or maybe we're using a BGP LS and P set or maybe we're using net comp to configure everything we don't want at the application level we don't want to worry about that we just want to worry about harvesting the information from the network and then making intelligent decisions based on that notice that this isn't all about open flow at that point and you don't you really even use open flow in that definition of what we need so now let's look at open daylight so open daylight it's a controller for Sdn and it's an open source controller now initially when it came into being it was targeted at that.that a very simple definition of Sdn that I mentioned let's separate the control on the data plane and you can see down here in the left hand corner there is support for open flow and that was what initially shipped with open daylight and it supports that quite well but fortunately it does a lot more than that basically in the in the middle here it has all the functionality that you would expect of a controller all your you know your network functionality but as we saw with the requirements of our Sdn controller base platform API sortie and it does have api's it has standard api is defined through net comp and rest comp and it also has rest based other recipes api's that it supports and those are all available to applications so they can get access to everything that's in the network to configure the network and to get information back from the network and then really key to open daylight is that it not only supports open flow but it supports a whole bunch of other network protocols that we can use this is great if we have existing legacy equipment and we already have a network and we're already using these other protocols open daylights kind of like the the Swiss Army nights of us controllers it can talk to just about any network element you have and if I was a vendor and I had a network device that it wasn't able to control yet because it's an open source project I could actually create my own plugin to enable opendaylight to control it and that's part of why it's been so successful because everyone can contribute to it and make it work with with their their network elements or with their applications better so I mentioned before that opendaylight is an open source project and whenever you look at any open source project it's really important to look at the community behind it because in the long run the open source project is only going to be good as the community that stands behind it it's really important with an open source project that you don't want all the contribution coming from just say one company or one university or any one entity or even just one or two you really want to broad-based the support behind it of contribution to it so open daylight was founded in 2013 and it's run within the Linux Foundation and Linux Foundation in addition to doing Linux obviously does a whole lot of other open-source projects and they're really great at running open source projects and they've you know lended a lot of support and guidance and help to the open daylight community to have it grow everything within open daylight is licensed under the eclipse public license and the code base initially that open daylight started around it basically came from when 15 different founding companies came together notice it's not just one or two or three it's actually 15 companies and they contributed significant amounts of code and props more importantly software development resources to to get all this up and running and working together and the project's grown significantly since then - now there's well over 600 contributors contributing code this isn't people using it this is people actually writing code and contributing to open daylight in all and this is a little bit of a dated piece of information as well two and a half million lines of code so it's a large code base in large part because of all those plugins that I showed but at the same time what I maybe didn't mention is that it's very modular because if you're not using all those plugins you don't need to include them in your build or your installation of opendaylight and we'll go into that a bit more later on and how you do that let's see Java so most of the code is Java there's probably some exemptions but from you know by and large it's all Java the very first release that came out came out in early 2014 and it was called hydrogen and the second release was called helium came out about eight months later and ever since then they've kept up this sort of eight month cadence of coming out with releases in case you haven't noticed that there's a bit of a trend there the release names are all named named after elements in the periodic table so if you want to figure out how old the release is yeah you can look that up and maybe learn a little bit about or you know remember back to your chemistry days the current release is called boron and kind of remember when the first release of boron came out I think it was maybe it was around October time frame and then once the release comes out if there's a reason that there's to do like what they call a service release that's what the SR stands for perhaps there's a security vulnerability or a major bug or something that gets found they come out with these service releases so there was an SR 1 and then SR 2 came out back in December so that's if you want to look at what the latest stable release of opendaylight as of today is it would be this boron SR 2 and the next release which has been in the works for about Mohamed el 5 months now is the carbon release so if you were to talk to opendaylight developers they're almost all focused on carbon now actually very few people are working on boron anymore and the carbon release is due to come out in May of this year all right now I want to talk a little bit more about the software architecture of open daylight as I mentioned it's Java that they kind of just chose that that language to use across the board maven is the build system that's used for Java what's more important I think from a user perspective and that you would actually get involved with would be this use of carafe and the OSGi model that's supported underneath that the idea with carafe or the benefit that it brings is that it's really good at dynamically loading in bundles or what an open daylights kind of refer to maybe more as features and you can load these features at runtime and have them registered into the system and have them take effect without taking the server down or without taking the controller down so as you'll see when we start up open daylight we'll have a very minimal feature set on it and then we'll start adding features to it so it can do what we want to do and that's obviously very important because you don't want to be taking your controller down you want to be able to overtime enable new features upgrade features make changes to it and the framework that's put in place here works very well for them any questions so far that's kind of the very high-level stuff and now I'm going to shift gears to network programmability so if you had a question about Sdn or open daylight we'll get into more detailed stuff later on but before I jump into network programmability just wanted to check ok so the reason why I think we should talk about Network programmability is that's actually where a lot of a lot of you are assumed our network engineers right how many our network engineers just about everyone hey okay how many of you consider yourself a software developer also okay well when we talk about network programmability it's much much more important to be a network engineer than it is to be a software developer the amount of networking knowledge I think that you need to know to do network programmability really well it's pretty high it's somewhat daunting challenge fortunately you guys have that that hard part down the amount of programming skills that you need for a network programmability really isn't that tough if you wanted to go in and start writing code for opendaylight that's pretty challenging if you want to make use of the api's that opendaylight provides and write you know code with that like some Python coding or to use those rest-based API you use rest conf net comp I'm going to show you that it's not really that hard and in fact we have some great classes here in the definit own that help you with that so you guys are in good shape a software developer that has no networking background would have a much much more difficult time stepping into this so when it comes to the expenses with the network the other thing to look at is that the real cost is not so much in the equipment even though I think we still charge a fair amount of money for Cisco gear and have good margins but that's not really where the cost is the cost is more on the time to operate and maintain and configure and do all this stuff with the network and it's not only a cost in that sense but also to deploy you spend a lot more time deploying your network configuring it and that type of thing than you do say spinning up new servers for compute and other things in your environment so when I talk about network programmability the there's a couple of different ways to think about it but I'm speaking more from the point of view if you take a look at your virtual or physical infrastructure that you have and some API is that it provides now you could from an application make use of those api's directly and call in to say a switch and it will have API to let you query to get the configuration from it to make changes from it to see counters to do those types of things you can do all that you could also have a controller like opendaylight that sits in the middle and abstract some of that away from you so then you could use the VAP eyes of open daylight and have it take care of the lower-level details of the physical and virtual network infrastructure unfortunately it's not really like it's an either/or you could be and a lot of people will be using these things in parallel for the most part you'd be going to your controller like open daylight but where it makes sense you might go directly to the device or you could query the device specific information directly through open daylight and it'll pass it through so it's not like it's you know a one or the other and a real difficult trade-off you can get the best of both worlds okay so when talking about network programmability it's important to talk about net comp so back I just was about fifteen years ago now there were some folks within the IETF and the the internet architecture board sorry if that's a little bit hard to read but basically they came together to take a look at the state of things with networking and how people were doing network configuration and they have a lot of equipment vendors there they had a lot of operators there people who operated large networks and they asked so how many of you are using SNMP for doing configuration yeah a lot of people are using SNMP but very few were really using it for doing a configuration and if they are it's probably only for a limited amount of configuration so what are you using SNMP to configure to set up VLANs and set up the description of those VLANs you are saying okay well that's actually more than I hear from most people by and large people are using CLI or we're using CLI and it's probably still true today using CLI for the bulk of their configuration and that just didn't sound right because SNMP had been useful for perhaps querying and people using mids to take a look at the state of some of their network but as a configuration tool it really hadn't met that challenge so the IETF thought UK we really need to do something better and what they came up with was Netcom stands for network configuration protocol and there's been a couple different revisions the first one came out in 2006 and what that really did was that took everything that you would do through CLI and allowed you to do it over SSH so it's really just still focused on configuration CLI based configuration but allowing it to finding ways you could do that over SSH in a programmatic fashion so it was an improvement but there was really no standard say data modeling behind it no consistency behind it and with RFC 6241 that came out about five years later that really started to change things it started to use data models as the basis and just have net cough be the transport and really the definition of what is it you're transporting what is the configuration information that you're you're sending down that's left to yang and we'll talk a bit about Yang later on too so what did this bring for us when people were doing all CLI or perhaps doing screen scraping and that type of thing for driving their configuration there was no well-defined protocols every vendor had their own thing you had to worry about those differences when we came out with a new version of router or switch we might be breaking all the scripting that you had before it was really painful to be able to automate any of your configuration tasks but now when you get net comps in there and especially with this later version with data models now you have the concept of transactions where you can say do all this configuration and if anything goes wrong then roll back and have none of it happen it's all based on the standard models so whether you're using gear from Cisco or for someone else as long as they're supporting these standard models you don't really care and their standard protocols like net comps and we'll talk about rest comp as well that you can use so this really makes sure your your your life a lot better a lot more consistent as you try to automate any of your configuration so how does net kampf work neck comp is a connection-oriented protocol almost everyone uses it over SSH you can also use it with with TLS the payload is XML and the payload is what is in the XML is defined by yang data models so now initially the way you set up a connection is over SSH you you connect to the server and you send a hello message and it will send back to you its capabilities its capabilities are basically what are the models I support because the models define the api's that you have and that the data that you're able to access through it so once you've done that then you can start to basically query in a request response type fashion to get information from a server or to change information about it you do that and then when you're done with the session you you either close or kill it to close the session there's some commands that have been defined within net comp we all except the top one has to you see it all has the word config because the origins of that was all around configuring your device get the config does what you would think right you're kind of pulling the configuration off the device edits that config is when you're going to want to make a change copy config so you basically have a good config you make a copy of it and start mucking with it and then when you're happy with it you're able to commit it in using edit config to make that the the running config and then delete config to get rid of one of those temporary data stores when you don't need it anymore and as we talked about the beginning though there's a lot more value to network programmability than just getting static configuration and that comes from being able to interact with the operational data and so they deal with operational data that's where the get command comes in it not only gives you config but it gives you all the operational data all the state information of the box as well as defined by the model the yang model that it's supporting okay so I've been mentioning yang a lot I should probably talk about it in a bit more detail as to what it is so it's important to get this distinction between what is the data model and what is the network management protocol so in this case think of yang as being your data model and Netcom is an example of a network management protocol that you could use so the data model that's going to define all the syntax the semantics the rules behind your your data so like what does an ipv4 address looks like what's the structure of that what are the valid values that's all captured in the data model and Netcom or the transfer the network management protocol that's just defining things like you know the the commands like the edit config and the get config and using TLS and how is the data marshaled when it's on the wire you know the fact that you're using XML so that's the separation between describing the data and it's format syntax semantics and then just how do you transport it so the notice here yang the RFC for yang is 60 20 it's a little bit lower than that net comp one that revision of net comp I put it probably sure to use like a timeline or something but the way it worked in the ITF was first you had net comp and then you had yang and then you had the new version of net cough that makes use of yang so it's kind of somewhat logical progression in time another important thing to remember with Yang is that much like net cough yang is really meant to be a modeling language whereas net comp is a protocol for network configuration yang is a modeling language that had network configuration in mind so built into it it has this concept of different data stores you have configuration data stores but you also have those operational data stores that we talked about and when you interact with yang you have that concept of transactions and also notifications when something changes where you kind of talked about this that yang provides those constraints right what's say the the format or when you look at an ipv4 address this is an example what's it have to look like but also it has a lot of reusable structures that are built into it actually it leverages a bit from C++ as a programming language in that sense but it also there's rfcs that have been defined they could define the basic yang types in addition to what what's an ipv4 address what's an ipv6 address what's an interface all these things are now standard things that have been defined in yang and that you can use those as building blocks when you're defining higher-level configurations and it's all very extensible and modular in that sense so the structure that's defined within yang at the top level you have containers and within a container you can have a bunch of things you could have another container you could have lists and you can also have end elements an end element is something that's actually going to have a value and typically called a leaf so I mentioned that a container could have a list when you look at a list you could also similarly have a list of lists or a list of leaf elements which is quite common to have a list of leaf elements and so eventually what you're going to do is traverse this until you get to your end elements and those end elements are the things that you can actually query and said now showing you how these things work together if we think about network management we start with the definition of the data that's what the yang model is in the case of net comp will be encoding it as XML and then we have the net comp operations to work on it and the net comp operations actually use an RPC mechanism as we talked about before request response and then it's encoded using SSH primarily or like I mentioned some people used TLS key thing that I want to point out here though is this thing down here that's depicted you can think of this as your network element this could be a router or switch it is it's on that switch that these data stores actually exist and it's the the switch or the router that's acting as the net comp server it's not the controller that's acting as a net comp server in this case the controller open daylights actually acting as an Sdn I'm sorry as a net comp client in this case so it's talking to the server and the server saying here's what my configuration looked like here's the yang models that I support that let you interact with my configuration and my operational State and much like you're used to seeing on a router or switch it would have these different data stores the actual running configuration the startup configuration and this candidate configuration which is something you could be working on and tweaking and eventually make it the running configuration when you look at yang models there's a lot of standardization going on in the industry around yang models but not all yang models have been standardized the reason for that is we want to have as much in common as possible right so there's kind of large debates as you can imagine when you get a bunch of different vendors with different equipment and they say okay hey what should we're talking about the configuration of a entire router or switch what should that look like there are some differences of opinion right and there's differences that are even necessary because there's differences in capabilities so everything that can be standardized is essentially being standardized and we're building up more and more building blocks that are our standard so if you if you think of that it's defining maybe about 80% of your configuration now if you go with a vendor like Cisco they have a bunch of equipment we have a bunch of equipment and we have some common models that in yang speak they augment the standard models so we support the standard model plus some additional stuff that we support across all of Cisco networking equipment that's what we would capture in this common model and then say we have some very specific functionality that's only supported on say the ASR 9k just as making up an example that might have a device specific model to let you get access to it so at the end of the day you still have the access to everything that the device has a lot of it is per standard model some of its persist Oh common model and some of its purchased a device specific model and the way yang I'm yeah the way yang works are able to layer these things by extending a model or augmenting it as you that's the term that's used in yang so what does the yang model look like this is just a small snippet they can't get pretty large this is a pretty well-defined one because you see they have a really nice long description but because of that it means I can't put too much on the screen but if you remember when we looked at the for my other structure of a yang model you have the container within the container you have a list one or more lists perhaps and then you have leaf elements within the list so that's just giving you example of what it would look like if you were to use VI or your favorite editor to to take a look at one the good thing is it is it is human readable it was meant to be human readable the gate yang model fortunately it's very easy almost all the yang models that people are using are on github by and large if you go to github slash yang model slash yang you'll find just about everything there you'll find models that the AI ATF's working on that open config projects working on you'll also find the cisco specific yang models under like a vendor portion and so this is a great resource and don't worry about getting the urls down or anything it's the slides are available and you can you can grab them within dev net we do have some yang models I would say these are probably a little bit more experimental or you know they're there for a certain purpose I don't see any reason why they wouldn't migrate into the other repository when when the time is good for that because it's much easier to find if they're on the same github repository I mentioned and we saw that yang models are human readable but they can also get to be quite large so it's nice if you have some tools to help deal with with them these are a few tools that are very handy P yang have any of you used or heard of P n okay yeah and you're also familiar with open daylight so P yang it started out as being a Yang Bala dater so I have a large yang model how can I make sure that it's well defined and and that's what P n can do but it also has some other cool things to help you as a command line tool to help you look at the yang model and we'll look at that in a little bit more detail yang Explorer is a graphical tool a browser-based tool that basically lets you look at your yang models as well and then drill down into them this is just kind of a screenshot depicting what's happening and notice this is that same ietf interfaces a file that I looked at before that we showed a using VI and then open daylight has yang tools and this is a really cool feature of open daylight that with these tools what open daylight able to do is read in a model like when a network device is he here's my yang model open daylight can pull it in and generate code that supports that API right so basically all the request response mechanisms that need to be in place that all gets generated and if there's already existing code within open daylight to deal with it like when someone does make a request and to say some higher-level logic that's needed an open daylight it all just automatically work if it doesn't you might still need to write some code in the controller but all the interface level all the API handling stuff all gets generated on the fly and gets linked in okay and here's an example of using pee egg you can use pee yang with - s tree and what that's going to do is in addition to validate it give me a tree like structure of what my yang model looks like and so you can see here it's putting out the list which is it's a list of interfaces and all the interfaces that we have and the one that's read right that's because it's configuration data that you can actually change and the one that's read-only that's because it's a it's the operational State and it's just there for you to query but you can't change it another cool example of PN you can actually output it use this js3 option and then what it's going to do is put out a an HTML page that you can navigate to and just like we saw with the previous tool you can click on these things and it'll expand and you can traverse your your yang model that way so it really makes it a lot easier to work with yang models the fact you can get them all off github and then you can use these tools to reverse them and understand them a bit better now let me quickly talk about rest comps so we already had net comps and you might ask why do we need another protocol the idea with rest comp is I think if I have a better picture well when I think of net comp it's really good for like device level communication so like from the controller to talk to the underlying devices more like automated type configuration information it's a great interface for that but for application developers especially like web application developers they are really much more used to using rest-based API and so net comp looks a little funny to them they also to them XML is very old-school they did they don't think they hate that they like JSON so rest comp was really developed as I'd say a simplified version or like a does it gives you a subset of what you get with Netcom but basically provided a rest like interface to which you can do a lot of the same things you could do with rest comps so and it uses JSON instead of HTML I sorry instead of XML and it uses HTTP for transport in SATA SSH so if you're a web app developer it's going to be much more intuitive to you to use restaurants and with restaurants basically what ends up happening is you define a URL that is used to access the data and the structure of that URL is what I'm showing here and it's basically you start with the host which would be the name of your network element or your opendaylight controller and then top is going to be like API or rest comp that's just like the head of your API and then you would go into it and it's a it would be like interfaces and interface and then what's the name of the interface you basically construct this if you're familiar with rest you construct this URL in order to access the information that you're looking for and this is just a picture of what that would look like you can see this would be like the IP address and port on which my controllers using this is top is API I'm accessing the running datastore and I want to get the interfaces and if I was to do a get request with that I'd get back all the interfaces on the device and as you might expect since it's a rest-based API these are all the normal rest operations that you would expect and so basically rest comp commands have been mapped to these rest-based API ok now I'm just going to go through this very quickly because I want to save some time for the demo stuff and the idea here being that you can use rest comps you can use Netcom you may hear some people using G RPC you can use opendaylight to to generate your api's regardless of what you're using and what the underlying transport is the thing the key thing is that they all fall back to and support and make use of these yang models so you can see why the yang models are so critical because they drive they the format of the data that it really is at the heart of all these is the yang model and then these are just different ways to encapsulate and transport them I'm going to skip through that and show you here this might be good to walk through so the idea is when let's say I want opendaylight to control this network so I start out with with this set opendaylight doesn't know anything about the underlying network except that say I tell us the IP address and the credentials it's going to need to SSH into it and then what it would do is through net conf it would go out query the device it would pull in it would add it to its inventory and then it would have no all the yang models that that device supports and it would add those into its cache then it would go talk to the next element which happens to support the same yang model it would also add it into its inventory but now there's nothing for it to add into its cache so it goes to the next network element adds it into in its its inventory and now does open wrt has a different set of yang models or at least some of them are different so it adds those into its cache - so now opendaylight has an understanding of yang models that are needed to interact with these devices which means there's also generated code to deal with the api's that are involved there to talk with them all using that comp okay got about ten minutes and I'm going to jump into the installation aspects now so yeah we're going to get a little bit more hands-on now and the idea being that I mentioned before the current release is boron s r2 so if you wanted to start using opendaylight to control a network today you would go here you would download that you take a couple minutes and then to start up open daylight's as easy as this you just type you just unzip that type bin carafe and you should be up and running and when you first start running open daylight it's going to have very few features in vault installed actually I'm going to switch from it's probably easier just to show you so I'm going to try this if this doesn't work I'll use the slides instead but hopefully it does work and then this will be much more informative I think that big enough can you guys see so what I did here was I pulled down this zip file for boron release sr2 I'm just going to unzip it whoops I need to give it the name sorry doesn't take too long to unzip all right and now I can do bin / carafe whoops oh sorry I need to go into the directory of it and now here you bin slash carafe and these commands are in the the slides without the typos so they should be pretty easy to follow and that's how quick it is to start up open daylight so now open daylight's running and I can see what features are running on it by doing a feature list - I and actually have very few features running that's why it started up so fast I can also do a query to see all the features that exist and if I do this you can see I got a much longer list actually scrolled way off my screen so those are all the features that exist so I have opened a light up and running now what I want to do is attach it to a network and in the interest of time I'm just going to show you the simplest network that I can attach to and that would be this one so how many of you have heard of mini net okay many that's an easy way to spin up a very small network and I'm going to use that because I'm going to run it right here on my laptop and there's a couple other things take a look at the slides because I didn't leave myself enough time to cover this but these are just other example networks that you can connect to using VPP or using because I mentioned opendaylight can be used with a lot of different network elements this is an example using bgp LS and P sub but for the point of getting something you can work with right away I'm going to stick to this simple mini net example so what I'm going to do you already saw me install opendaylight I'm also going to go and install mini net which is listed at the top step there I'm going to start up mini net and within mini net I'm going to bring up a network of three switches and then I'm going to have opened a light connect to that so let's go ahead and do that get out of slide mode Oh the other really important thing that I didn't mention is and it's it's mentioned in this slide is I need to enable some features on opendaylight in order for it to be able to do all this and here's the list of features that I need to enable this feature whoops feature install is how I do it I need to enable these features so I'm going to get that going on my opendaylight let's go back to opendaylight here and I'm going to do a feature install rest comp so that's one feature I need because I want to be able to interact with it using rest comp and I'll show you once it's up and running how we do that but then I also need the l2 switch and this is something if there were any errors it would tell me as I'm entering these otherwise it's just going ahead and installing them the l2 switch is what I'm going to need when I start up mini net it's going to spin up three different nodes which are running open flow as open flow nodes and I'm going to use OBS DB to interact with them so that's what that's why I need this layer 2 switch functionality and then I also want to be able to use the graphical user interface that comes with open daylight and that's called deluxe and so I'm going to go ahead and install that as well and just to give you an idea of what deluxe looks like while I'm waiting for that to install when you first install open daylight you will get a screen that looks like that looks like this this is deluxe this is the the UI that ships with open daylight and will go ahead and take a quick look at that as well so let's see did my l2 mile to switch is still installing you can see it was very fast to start up open daylight at the beginning but it does take a little bit of time to install features but once they're installed then they run really fast so ok so those are all the features I should need now I should have an open daylight instance up and running that I can go to it's running on my local host so I'll browse to it and I can log in and the credentials are just admin admin and I can see my whole network and that is my whole network because I have not started a network yet so to start a network I'm going to use mini net so let me start mini net okay I log into mini net the credentials for that or mini net mini net and I have a script in here that will start a three node network so I just ran that so now I have a three node Network up and running if I look at opendaylight and do a reload now you can see it it sees those switches so those switches exist I also have some hosts but I don't haven't run any traffic yet so I'm going to do a ping all sorry this is probably real small and hard to read but let me make that'll just a little bit bigger so if I do a ping all okay so I was able to ping from hosts to all my switches and from one host to another so now I've generated some traffic on opendaylight or in the network and because I generated some traffic if I come back here I should be able to reload and sure enough so now I can see my host - alright so now that's kind of cool I can also go and look at the my nodes and I can see all the connections so for example these are my three switches open flow one two and three if I look at connectors I can see how they are each connected so switch two is connected to three to itself to one okay that's all great - but this is about network programmability so let me go to the yang UI so there's a reason why I loaded this if I go to the yang UI this shows me all of the yang models that have been loaded into opendaylight and you can see there's quite a few and if you remember what opendaylight does it generates code for all these yang models so now I should be able to go and use these yang models for example we just loaded in a switch like three different switches that we know about so if I go to the inventory where is that the inventory model and I say show me all the nodes that are configured within opendaylight I can do a get and I get an error why do I get in there exactly that's the config and as we saw at the beginning there was no network I have no configuration I'm picking this all up this is all operational data if I go to operation and click on node and instead and this command down here this is this is the rest comp command that you would be using if you were writing say python or something else now it works now I can go and I can look at what it returns and you can see it returns me open flow one two three and some details about it not only that but if I want to drill a little bit deeper I could and I could request a specific node for example give me only open flow because the ID for that is you know open flow one two three give me only open flow two and do a send and now I can get that and now I'm getting just the node with ID open flow too so this is just to show you how easy it is with open daylight both to find out what ap eyes are supported and then to make use of those AP eyes I'm doing it using the GUI but I could be including it in some code that I wrote very easily as well okay so now let me get out of this and we will wrap up okay so in terms of additional resources if you go into dev net we have something called our open source step center and that's where you'll find information not just about open daylight but about all the open source projects where Cisco's contributing significantly and using it in our products so open daylight OpenStack other things like that all the information is there there's a whole microsite is that's what we call them dedicated to open daylight where you can see what's going on within Cisco I mentioned it's a great platform for writing Network aware applications this is just a sampling of some network aware applications that we've written applications that all run on top of and with open daylight source codes all available you can download them start playing with them that will give you a really good idea of how to write your own applications and maybe you'll even find exactly what they do useful for your needs already we have a sandbox this is where you can run open daylight with a more interesting network instead of using mini net you can actually spin it up and have it work with a bunch of Cisco gear that we have in that sandbox this is where you can go to get some help if you have problems with using open daylight the spark room I'll be watching that if you have any questions you think of in the next few days join that spark room send them to me I'll answer them as best I can please do fill out your evaluation that's very very useful to me even if you hated what you saw today that's good for me to know and I'll try to fix it for next time and if you loved it I'm happy to hear that too and then to continue your education here you can go and check out this link I know it's pretty late and Cisco live but that's all the open source related sessions we have you can become a member of dev net and just the link for the open source dead center so again everything I did here you should be able to get access to and that's it I have one minute for questions yeah north oh what's that yeah rest comp yeah there's there's an API for the northbound interface that is well you have to authenticate like for example if you were using rest comp you have to authenticate through rest comp if you were using I'm trying to get back to the picture I have near the beginning that shows those interfaces because it was pretty early on out here so yeah you would have to authenticate if it's a rest-based interface it's going to have some authentication mechanism if it's rest comp I think it's using HTTP basic authentication you would hopefully encrypt it over HTTP so that it's useful Oh to only give them access to part of the data that's there that's a good question I don't know there may be some way to restrict that in yang I'm not sure that's actually a really good question so you want them to have access to some of the information but not to all of it yeah I don't know let me let me look into that I don't know that one off the top of my head sorry about that if you sent a question in the spark room I'll make sure to find an answer for you okay well thank you very much I got to make room for the next speaker you

Channel: Cisco DevNet

Views: 27,851

Rating: 4.9288888 out of 5

Keywords: DevNet, CLEUR, OpenStack, OpenDaylight, OPNFV, FD.io, Open Source, APIs, Cisco, dev, developers, network engineers

Id: rAm48gVv8_A

Length: 57min 35sec (3455 seconds)

Published: Thu Feb 23 2017