 Hello everyone, I am Abhinav Modi, I am a Technical Marketing Engineer with Cisco, working on data center products, there is a class of switches called Nexus switches, Nexus 3K to the 9K. We have been hearing a lot about infrastructure application where I thought it would be good to have some amount of information around what is happening on the networking side. The topic I am going to cover today is how do you manage a switch using Ansible. I would like to spend some time getting stock of what is the scene today in network management and programming. We will look at some existing protocols which have been used for a while for manageability. I will give a quick intro into NXAPI which is a REST-like API implemented on the Nexus switches. We will then take a look at how Ansible is tied to NXAPI and I will have a demo on how we can manage multiple switches using Ansible and NXAPI. So I mean you folks are all aware of this, so I am just preaching to the choir here. But evolution of the server configuration scene has been a magnificent and the 90s when you had a CD drive to manage each switch to today when you have virtualized infrastructure but you also have the tools available to be able to manage it, configuration management, deployment, all of that stuff whether it is on AWS or on your private data centers. However, if you look at the network configuration, networks have grown a lot, however the switches and the configuration is still done primarily using CLIs. So it is all a matter of typing in your command lines which is called command line interface and doing copy paste of that. What this leads to is errors, cost overruns, you need multiple people to manage your network and it is not very efficient. So what we really need is to get some of the sysadmin culture and the sysadmin tools into network management as well and get some more programmability around network devices. That is not to say that network management has not been there. How many of you know about SNMP? So you have been using it but I am sure it is a bit complex to use that, right? Especially for configuration, it is also not very secure given as SNMP v2, of course SNMP v3 is solving that. Because of the standards, because of the fact that you have multiple proprietary features which each one does not want to showcase. So similarly you have NetCon which uses SSH and XML as the data language. XML of course is a bit difficult to parse. We are going towards more of the website, we are using Gison. That is what a lot of vendors, a lot of the integrators really want. So that you can have multiple pieces of the management solution be able to talk to each other using open APIs. This is where NX API comes in. This is on the Nexus switches. What it simply is is a REST like interface using HTTP or HTTPS. You have an NGINX server running on the switch and you have Gison RPC as the RPC, Gison or XML as the data interchange format. Using Gison ensures that you have a lot easier parsing available to you. You also have something which is very useful for developers who want to get into network programming. This is a sandbox which is available on the switch. So as soon as you have an NXOS running on a Nexus switch, you enable the feature NX API, you get the sandbox. What this does is you don't need to look into any code or any documentation. You provide input in the top left corner. For example, I have given show version which is the basic fact gathering command. You get the request which you want to send and you get the response. So you don't need to touch through multiple API calls or documentation to get to what you want to automate with. This is also very useful not just for the programmers but the network guys who want to get into programming. On the networking side, we have two classes of folks. One who are the programmers who don't know networking. The other are the network guys who have to automate these stuff. So this is sort of a very useful tool available for both of them to speak the same language. So let's take a look at how we use this for configuration management and for managing the Nexus switch. So we all know about configuration management. We had a very great session from Mike earlier on Solstack. The fact that configuration management is used primarily because it is programmable. You are able to do multiple tasks granularly and you have a bunch of crowd sourced open source modules available to do whatever you want. So if I have written something for let's say a Cisco switch and a potential GitHub which we are doing, anybody else could leverage that, add to it and modify that as they want. Some of the typical use cases where you want to do network administration is gather some facts and operational data for your knock, for monitoring. The other is of course provisioning features, let's say you want to deploy a large number of switches at one go. It would be a pain doing it without something like a configuration management software. And of course it helps in troubleshooting so that you could just have some modules which are able to collect more data once you get some operational data which triggers some alarms. In this talk I am taking a look at Ansible and the value of Ansible for network management. The fact that Ansible is agentless ensures that any of the networking switches does not require any binary on that. So it's good to go from day one. We have support for multiple scripting languages as long as you have JSON as the data interchange format for Ansible. If you are a Perl shop you could also automate in Perl. Python of course is the de facto language used. It also allows for orchestration in the sense that you could use Ansible with REST APIs and tie it to some other tool which you have been using so that that tool drives Ansible and your playbooks to manage the network switches. And it is very simple for again for the network programmers to comprehend given that it uses YAML which is very easy to read and human readable like. So how many of you know Ansible terminology? So I will just go through it just for the others who don't know. Inventory is just a list of hosts which you want to manage. You could group them for example some particular data center could be one group, another data center could be other group or even within the data center certain notes could be a third group. A task is a granular work item which you would want to do. For example if you are managing a Ubuntu server you would be doing abdicate install right. So that is a task in Ansible parlance. Play and playbook are concepts from soccer and you know the American sport scene. So what this does is it is a set of strategies which you want to or a set of tasks which you want to run one after another to achieve what you want to do. So what you would be doing in a particular play is running multiple tasks, getting some data out of the switches using that to either provision or manager switches. Item importance is something which was covered in Salt Slack as well. But what it means is that if Ansible actually checks whether the desired state is there on the switch for the particular task. If it is there it doesn't do anything it's a no op for it. That saves resources and it ensures that external input actions are not present. So Ansible typically works by running on a server. There is a server station where you have the Ansible playbook code or the Ansible modules, the inventory file, the playbooks which you want to run. There is also a requirement typically of SSH being available on the managed devices. So for example the Linux server or the switch you would want to manage should have an SSH stack and you need some access to slash TMP or the file system to be able to copy the files over to the managed device and then run it. Even though there is no agent running on that but you still need some amount of access to the switch and some requirements around it. With Nexus which is what we do and this is what happens with a lot of these networking devices not just Cisco is that you may not have Python running or you may not want to expose the file system. So what we are doing over here is that we are running Ansible in local mode. What this means is that you are connecting via NXAPI. So you are actually making NXAPI calls to the switch. There are a couple of open source modules which have been written, a couple of them funded by Cisco, couple have been by independent contractors in fact. So PyC SEO is one which could be used to leverage NXAPI with or without Ansible and you have Ansible modules on GitHub already available. For example, to provision a VLAN or to check what interfaces status is or to see what features are available on the Nexus switches. So what this does is it eliminates the need of Python completely on the managed device. So let's take a look at a demo to see how we are managing VLANs, right? So it is there under Cisco and the data center slash NXOS Ansible as well. So I'll give you a brief history of what happened. There is a gentleman called Jason Edelman. He has been working on that and he has also been contracted by Cisco to develop it. So he has put that as under his name as well as under data center Cisco. Yes, absolutely. So you could see it under data center slash this thing as well. I have it in the reference line. So we'll look at a demo of how this all comes together and how we are using it for a very simple use case. Where I have a few switches and I want to see do some operations on a particular VLANs. So if you see on the left side is a couple of switches which I have. The Nexus 5000 and the 6000. The right side is the leaves which there is a group called leaf. This is the inventory file. And we look at the playbook which is a set of tasks which we are doing. You know, ensuring that a particular VLAN 50 exists or change the name of the VLAN or in fact change the name of a or ensure that one does not exist. In the sense that you remove the VLAN if it is present. So as you can see, we're not saying that, you know, do this work. It just says what is the desired state of that property, of that attribute. The one which is highlighted now are some variables which are, which we're using to iterate the last playbook. So let's run that on the switches. As you can see on the left side, currently we don't have much happening on the VLAN side, we just have one VLAN available. This is on the, all the switches. So I have three switches where we're going to run this in parallel. Running this is very simple. It's just ansible playbook and give it the name of the playbook and the name of the inventory file. So this spawns all the processes in parallel. The yellow lines are where the, where ansible actually change something on the particular switch. You'll see some cases where they are green. In which case, the state was already present and there was no operation required by ansible. You also have a very good summary in the end. And if there are any failures, that will be flagged over here. So in this case, everything succeeded. The number of changes are three in this case because one was a no op. If you see over here, everything got done. You see that the VLAN 70 is not present, which was what we had mentioned in the playbook. So this is just a very simple example. We use a module called NXOS VLAN, which is again present in the, on GitHub. There are multiple other simple modules available already, which interface with NXOS across all the products and you're able to use it. So in summary, APIs and REST like APIs are becoming de facto on networking devices. There is a need to have more transparent and more open standard based APIs, which is what is a lot of which is being driven through all the virtualization interaction with the web space. What we should do is leverage best practices from configuration management from the sysadmin world, which has been leaps and bounds ahead. And from the DevOps model to be able to manage all the infrastructure which we have. So I have some references as you were mentioning in terms of where all this is available. There is a general's block which has a lot of this information and it's a very good way to get started on Ansible and with NXOS. There are a couple of code samples at data center NXOS and on the particular switches as well. And of course the modules are there, Pi CSU and NXOS. Yes, what do you mean by SDN interface? SDN is a very loaded terms, right? So typically that is what should happen. So you have an orchestrator which manages a switch. And for example, there is a tool called Cisco Prime DCNM for the NXOS, right? So what it does is that it should internally use these APIs to actually provision the switch. So that is the model we are going towards. Otherwise, it's just that you change the level of indirection. Yes, so this is at a programmability level where you may not want to do all the SDN stuff or the orchestration stuff. So not everybody wants that. If you're a small shop, right? You are good with only having this level of automation. If you want to go further ahead, there is open stack plugins. There is SDN available, sorry, Vblocks between Cisco. So there we are using Nexus, I believe Nexus 5000. Nexus 5000 has NXOS, NXAPI coming in the next release. So you should be able to use that. But then again, Vblocks are its own management infrastructure, right? So that is what you would want to use rather than this. Yes, I mean, that is always the case. Because you have already spent money on Vblocks for managing your compute network and storage together. Yeah, automation of switches is also a very good concept. And thanks for that talk. And my question comes here is the one which you have showed in the slide is connection equal to local. Yes. So if you can remember that Ansible 1.5, most of the modules have been bifurcated, not on the main repo. They have differentiated on 1.9 sub-module repos. So in that, if you can see with this particular NXOS, even the DSL of Ansible has been changed like local action of this how to be on local host. So I think you are doing the same thing where you're trying to do it. So I would like to know which version of Ansible you're trying to do that. And whether this NXOS integration of this thing can be handled on the latest versions of it and any updates are happening on this so that we can handle some of the networking switches we have in-house. So that we even work on this NSX from VMware. So even that we need to do some sort of an automation. But Cisco with this kind of an automation which have a plug-in or something like that will really help us out. So I would like to know in detail that which version you're trying to use there. And is it a recent video or an old video? This is not very old. This is pretty recent. But I think Ansible would be 1.5 in this case. But to your question about what more is being done. Yeah, so I mean is it the same DSL if I can use it. Does the functionality is the same or we have any X functionalities that is getting updated with the plug-in internally with the modules of Ansible. So this uses very basic Ansible modules. We just use the local module, the local connection. Everything is done via the NXAPI code. So the NXOS Ansible modules themselves are able to work whether it is 1.5 or 1.9. Okay, so a general question. So how do you relate VMware NSX with the Cisco this thing? So that is a completely different topic. Yeah, I mean I. But in terms of, so what VMware NSX does is that it provides you with a different kind of virtualization in terms of an application centric view. In case of whatever we are doing over here is more of having the networking devices themselves be able to leverage, you know, and build out the network. We also have something called ACI, Application Centric Infrastructure, which actually is complimenting our, you know, the comparison point with NSX. So we can talk about it. Yeah, okay, thanks a lot.