Cisco CCNA 200-301 – Network Automation and Programmability Part 4

7. Lab Demo – Testing APIs with Postman

You’ll see how to test Rest API’s with Postman with a lab demo. So first thing that I need to do is to install Postman onto my laptop here. So I’ve gone to postman. com and you can see right on the home page there’s a link to download the app. So you can download and run the app on your machine. You can also run this as a Google Chrome plugin as well. So I’ve already done that. I’ve got Postman installed on here. Next thing is I need some kind of devices that I can interact with, with the Rest API. So I’m going to use the Cisco DevNet sandbox for that.

To find that, just go to Google and Google for Cisco DevNet sandbox. It will be the first hit. So I’ve gone to this page here, and then in here, you can click on Get started with Sandbox or look at the sandbox catalog. And that will bring you here. And you can see that in the DevNet sandbox. Cisco have got loads of different systems here which you can interact with for testing and for learning about network programmability and automation. And it’s all free. You can see that they’ll either be always on, which means they’re always accessible to everybody, or you can reserve one of the reservable lab environments as well.

So I have come in here and I’m going to be working with one of these iOS XE on CSR Labs. CSR is a virtual router which runs the iOS XE operating system, which does support Restful API. So I’m going to use that and I’m going to test how to use it with Postman. So I’ve already come in here to want to be always on Labs. I’ve opened that and then when I do that, you can see over here on the left, I can scroll down to the access details. That gives me the URL of the network device. Also I’ve got my SSH NETCONF and RESTCONF ports there as well, and the username and password to use. So I’ve got all of the information I need about the device I’m going to interact with. So let’s have a look at Postman. So this is what Postman looks like. And up here in the right, I can import environment variables in here. So I can either manually configure my own environment variables, I can also import them in from another location. So I’ve already done that. And you can see I’ve imported the DevNet sandbox variables for this particular lab environment. To see the environment variables, I click on the I symbol here and you can see that the host variable is using the URL of the device I’m interacting with. And I’ve also configured the port 9443 as well. So looking back in the information, you can see there is the URL that I’m interacting with. And I’m going to be using RESTCONF on port 9443.

So by putting that in my environment variables, it just makes it more convenient to work with postman, and let me show you how that works. Another thing that we can have in Post run as well before I come back to the environment variables is you can have collections, and this is where you can save requests that you’ve used before. So if you’re using this for testing on multiple systems and you know that you’re going to be reusing the commands again, or if you’re just coming back to the same system again and you want to run those same commands again, you can save them as a collection, and it means that they’re readily available for you to use again. So it’s very convenient. So I’ve imported this collection here for the DevNet Learning Labs, which works with this particular lab environment, and I will expand that out. And the first thing that I’m going to do is to read the list of interfaces on that device. So I’m going to click on this Get request, and it’s going to populate it over in the main window here. And here you can see the environment variable is being used.

So with the environment variable, it’s got two curly brackets there. So this is using the host variable and then report variable. And looking back at the variables again, it’s going to put in the URL for me and report for me, save me typing that whole thing in. And if I want to use this again later on a different system, I can just update the host variable and also the port as well. And then it’s going to make it very convenient for me to do that. Okay? So first thing that I’m going to do is I’m going to send in a Get request into that virtual router to get its list of interfaces. And you can see here is the URL to use here. So for this information, just check the documentation for the API for the device that you’re using, and it will tell you how to format your requests in there. So this is the URL to go to, to get a list of the information of the interfaces and the information about them. Other information that I need to enter in here, I need to authenticate. I need to have rights to get this information. So for that, I’m going to click on the authorization tab here in Postman. And for iOS XE here, it’s using Basic authentication. So I will choose that the basic off. And you can see I’ve already filled in the details here with the username and password. If I go back into my browser, you can see that information was available there as well. Okay, so that is done. I’m also going to have to fill in my headers as well. So looking at the headers I’ve specified, the content type is Application, Yang Data and JSON.

I’m going to accept Yang data and JSON back. And I’ve also got my authorization in here. This was populated from my authorization parameters. And because I’m sending a Get request, I’m requesting to get information from the virtual writer. I don’t need to have anything in the body there. Okay, so that’s everything that I need here I’ve got. My request is properly formatted according to the documentation for this API and device. So I can now click on send that is going to send the request to the device. And I have got my response here. You can see I got a status of 200. Okay, which means that the request was successful. I’ve got some headers in the information coming back and if I look in the body, I can see I’ve got the list of my interfaces on that device. So I can see I’ve got interface, gigabit ethernet one, the description, it’s IP address and subnet mask.

Also gig ethernet two, gigabit ethernet three. I’ve got a loop back on there and a virtual port group interface. Okay, so that’s how I got the information about the interfaces. But with my rest API, I can’t just get information. I can also put information onto this device as well. So let’s create a new loopback interface on it. You can see right now it’s just got one loopback interface, which is loopback zero. So I’m going to go back into my collections here and you can see I’ve already added the request into my collection post request to add a new loopback interface. So Get is going to pull information, post is going to push information to the device. I can see here this is the URL that I want to use. I’ve got my headers configured in here again as well and my authorization is going to be basic authorization with the username and password. And then I need to properly format the body. So in here I’m going to configure loopback 100. Let’s say that this is configured by flatbox and I’ll give it the IP address, 170, 216, 101, and it’s on loop back. So I want to have a 32 bit subnet mask on there. So let’s do that as well. Okay, so it’s everything properly formatted again. I would have checked the documentation to find out the syntax I need to format this in. That’s all done.

I can now click on Send. It’s going to send the request and I can see that the status I get back is 201 created. So that looks good. So if I now go back to my Get request to read information about interfaces and send this again, I can see that there is my new interfaces being created 100. The next thing I would probably want to do at this point is another post to save the configuration as well. But because I’m working on the shared lab over in the Devon’s sandbox here, I want to leave this as I found it. So what I’m going to do is I’m going to clean this up, I’m going to delete that loopback interface. I just created. So I can see here in my collection, I’ve got the request to delete the loopback interface. I will click on that and it has populated everything in here for me. It was loop back 100 I created. So I can just leave this as it is. I don’t need to edit it. I’ve got my headers configured in there. I’ve got my authorization done. So I can now click on Send, and then I’ve got a 204 no content. Now, 200 means that things are good. So even though it says no content, that’s not actually a problem.

It’s saying no content because it has deleted the loopback. Let’s just verify that again. So I’ll click back on the Get tab and send this again, and I should see that the loopback 100 interface has gone. Okay, done. Other things I can do here in Postman is I can click on the code button here, and then I can choose from all of these different popular programming languages. So it’s actually use Python, and it gives me the Python syntax that I need to use here if I wanted to create a script in Python that actually sent this command. Because with Postman, you can use it. It’s really used for testing because you can send individual commands there. So you can use it to test that the commands are working. But to have an actual useful script, you’re going to want to have a script that’s going to do multiple things, most likely. So Postman is not the tool for that. You can create your own scripts in your programming language. Postman makes it very easy to do that because it does tell you the code that you need to use for each individual request. You’re probably going to have to do a bit of editing in your programming language as well, but this just makes it very convenient for you.

Okay, so if I was doing this and I was exporting it into code for Python, well, the next step, really, I would need to know how to program in Python. And while Python is a comparatively easy programming language to learn, there’s still a pretty steep learning curve there. If you’re currently a network engineer, you’re used to working at the command line. Maybe you haven’t learned any coding before then. Learning Python would be quite a lot of work to do. But thankfully, you don’t have to go and learn a programming language to be able to make use of network programmability and automation. There’s other tools that we can use, like ansible and DNA Center, and I’m going to be covering those tools starting in the next lecture.

8. Configuration Management Tools – Ansible, Puppet and Chef

This lecture you’ll learn about configuration management tools which let you implement automation in your network without being an expert in programming. So configuration management systems are designed to make controlling large numbers of devices easy for administrators and operations teams through automation. They allow you to control many different systems in an automated way from one central location. And popular options are ansible puppet and chef. They’re all free and open source.

They do also have paid for enterprise editions available as well. The main difference between the free and the enterprise editions is that support comes with the paid for options. Your configuration management tools can automate the provisioning and deployment of servers and network devices. They require very little knowledge of programming. So you don’t need to be an experienced programmer to be able to implement automation in your network. Now, they do have established development practices including version control and testing.

So you get all the benefits that you would have with network programmability, but you can do it using these easier to use tools. First one to look at is Ansible. It can be run from any machine with Python two or three installed, so that’s Linux and Mac by default. And if you are using Ansible, typically you’ll be running it from a Linux machine. Ansible Is agentless, meaning that you don’t need to install a software plug in on the devices that you’re going to be managing. You don’t have to do anything on the devices you’re going to be managing. Everything is managed centrally from Ansible itself. It uses a push model so it pushes the configuration to the devices that you are configuring. Ansible communicates over SSH by default. Other options are available and Ansible is probably the simplest of the configuration management tools.

It’s got a very shallow, easy learning curve and Ansible was originally released in 2012. Ansible modules are pre built Python scripts and many pre built network modules exist. So if you are going to use Ansible, there’s many different modules which are the different tasks that you can complete on your network devices so you can pull information from them. You can also push configuration to them as well. And there’s already loads of modules that are already configured that you can use so you’re not going to be starting from scratch. Ansible inventory files define all hosts that will be managed by the control workstation. So when you set up Ansible for use, you get Ansible installed and then you specify the devices that you’re going to be managing. You do that by adding them to the inventory and answerable playbooks are YAML files that outline the instructions it needs to run.

So you’ve got the modules which are basically like the low level tasks that you’re going to be carrying out, but you need to customize those tasks as well for your particular environment. So you’re going to need to specify things like the hosts, the IP addresses, if you’re going to be configuring IP addresses, et cetera. So you’ve got all these things combined, you’ve got the module, the inventory and the playbooks and that’s how you control your devices. Next one we have is Poppet Puppet. It typically uses an agent on the target devices. It is possible for Puppet to be run agent list now, but typically it does use an agent, meaning you do have to have a software plug in on the devices that you are managing. If you get asked a question about it on the CCNA exam, then Puppet is an agent based option. The server that is used to control everything is called the Puppet Master that runs on a Linux server. And unlike Ansible, which uses a push model, puppet uses a pool model. So you still do all the configuration on the Puppetmaster. But rather than it pushing the config out to the devices, the devices check in with the Puppet Master and they pull their configuration from there. By default, the agent will check in every 30 minutes. By default. Puppet is written in ruby. It does not use YAML like Ansible does. It uses its own proprietary DSL. And for the terminology, it’s a manifest that defines the device’s properties.

With Poppet, an advantage that it does have over Ansible. Because it uses a pool model rather than a push model, and because the devices are periodically checking in, you can use that to check for configuration consistency. So with Ansible, really it’s a one time thing when you push a configuration to the devices. But with Puppet, every 30 minutes they’re checking that their configuration is correct. So that is an advantage of using Puppet. And puppet is more mature than ansible It was created in 2005. The last thing we’ll look at is Chef. With Chef, like Poppet, an agent must be installed on the target devices. So you do need to install a software plug in on all the devices you’re going to be managing. Chef, again, like Poppet, is also a cool model written in Ruby. And the terminology in chef is cookbooks and recipes. And Chef Also Mature was released in 2009. So Ancient, Puppet and Chef, they were not originally designed for managing network devices, but actually designed primarily for server system administration, like your Linux and your Windows servers.

Ansible is typically more suitable for network environments than Puppet and Chef because it does not require an agent for your server systems. It’s very easy and common to be installing software plugins on there. So it’s not a big deal that with Puppet and Chef you’re going to install an agent on there on your servers for the servers that you’re going to be managing. However, it’s not common to be installing software plugins installing agents on network devices. So because of this, Ancient is generally more suitable for network devices than Pop, it and Chef are. Ansible is also simpler to learn and use than Puppet and Chef too. So, because out of these three configuration management tools for managing network environments.

Ansible is the most popular and typically it’s going to be the most suitable. Cisco devices usually can’t even run an Agent. But Puppet does work on some Nexus switches and more support may be added in future. Right now, there’s limited support for poppet on Cisco devices. There’s basically no support for Chef right now. That might change as the industry move forward. Cisco might add additional support for Puppet and Chef. But with Ansible because it does not require an Agent on the devices, ansible works just fine. The box with all network devices. Okay, that’s everything I needed to tell you here. In the next lecture, I’ll actually show you a live demo of Ansible.

• Category: Uncategorized