Cisco

Today I was working to demonstrate how to get started with Nautobot Jobs within the Jobs root of Nautobot. This is not a pattern that I develop often, as I am typically developing Jobs within a plugin as my development standard. More to come on that later. During this case, the ask was to build a Job that would connect to a network device. I had a few troubles that I didn’t want to have to work through on a call that had limited time and that was a screen share. So I am taking to working on this via a blog post to share, and hopefully will be helpful for others as well.

This week Cisco announced the DevNet Expert certification exam. This exam and certification is something that I have been looking forward to for a long while. Dating back to the announcement of the certifications that were being provided. This was announced at Cisco Live 2019 in San Diego. I had started to lose some hope that this would become a reality with how long of a delay from the initial announcement to the announcement of availability. But it is now here. So here we go.

One of the best features of Nautobot as a Network Automation Platform is the ability to create your own custom code. This is executed via a job. What makes Nautobot unique is its ability to integrate with a Git repository to get those jobs and code for use into Nautobot. This provides perhaps the simplest, authenticated, and logged methodology for building your own API endpoints.

Nautobot supplies an API endpoint to start execution of jobs. The big deal about why you would want to do this inside of Nautobot (even if you do not have any other data inside of Nautobot, but you should add data, it is a perk) is that you get an authentication mechanism with the Nautobot token setup and a logging mechanism. With Nautobot user accounts you can create tokens that will handle the API authentication. This is helpful that you do not need to add that into your own Flask, FastAPI, or Django application yourself. This is the same for the logging mechanism. Every job execution provides a log of the execution and the result.

All of the work through the modules thus far in the series have brought us to what we all want to see. How to get or update device information inside of Nautobot. Adding of sites, device types, device roles are required to get us to this point. Now you can see how to add a device to Nautobot using the networktocode.nautobot.device module.

There are many optional parameters for the module specifically. I encourage you to take a look at the module documentation (linked below) in order to get a good sense of all of the options available. The required parameters for a device that is present are:

A device type is the next piece in the Nautobot Device onboarding requirements. The device type corresponds to the model number of the hardware (or virtual machine). This is where you are able to template out devices during their creation. So if you have a console port on a device type, that console port will be created when you create the device. However, there is NOT a relationship built between the device type and the device. If the device type gets updated after the device is created, the device itself is not updated.

A device role is aptly named, the role of the device. This is likely to be something that is meaningful to your organization and could change. For example you may have the 3 tier system of Core, Distribution, and Access layer environments. These are just fine. So you would want to have the roles there to reflect this reality. You may have leaf-spine environments, there are two more roles. And in my past I have also had roles that would indicate that there are dedicated DMZ, WAN edge, Internet edge devices. So this is the place to set this.

Platforms are an optional item when adding devices into Nautobot. The platform is the OS that you are going to be using. Most often this is used to help identify which driver your automation platform is going to be using. Specifically the slug of the platform is what needs to match. So in the terms of Ansible (since we are using Ansible to populate Nautobot), you will want to set Cisco IOS devices to ios. By having the slug match the automation platform name you have that information in your inventory. For these reasons I strongly recommend setting the Platform for devices.

Adding your manufacturers via code is the easy way to get started with your Nautobot devices. Immediately after adding Sites, the next thing to get going when using Nautobot as your Source of Truth is to add in Manufacturers. These are just that, who makes the gear that you use. For this demonstration you will see adding just a few manufacturers. I’m not necessarily picking on any vendors and who should or shouldn’t be here. It is just what my background brings.

All of the work through the modules thus far in the series have brought us to what we all want to see. How to get or update device information inside of NetBox. Adding of sites, device types, device roles are required to get us to this point. Now you can see how to add a device to NetBox using the netbox.netbox.netbox_device module.

There are many optional parameters for the module specifically. I encourage you to take a look at the module documentaation (linked below) in order to get a good sense of all of the options available. The required parameters for a device that is present are:

A device type is the next piece in the NetBox Device onboarding requirements. The device type corresponds to the model number of the hardware (or virtual machine). This is where you are able to template out devices during their creation. So if you have a console port on a device type, that console port will be created when you create the device. However, there is NOT a relationship built between the device type and the device. If the device type gets updated after the device is created, the device itself is not updated.

A device role is aptly named, the role of the device. This is likely to be something that is meaningful to your organization and could change. For example you may have the 3 tier system of Core, Distribution, and Access layer environments. These are just fine. So you would want to have the roles there to reflect this reality. You may have leaf-spine environments, there are two more roles. And in my past I have also had roles that would indicate that there are dedicated DMZ, WAN edge, Internet edge devices. So this is the place to set this.

Platforms are an optional item when adding devices into NetBox. The platform is the OS that you are going to be using. Most often this is used to help identify which driver your automation platform is going to be using. Specifically the slug of the platform is what needs to match. So in the terms of Ansible (since we are using Ansible to populate NetBox), you will want to set Cisco IOS devices to ios. By having the slug match the automation platform name you have that information in your inventory. For these reasons I strongly recommend setting the Platform for devices.

Adding your manufacturers via code is the easy way to get started with your NetBox devices. Immediately after adding Sites, the next thing to get going when using NetBox as your Source of Truth is to add in Manufacturers. These are just that, who makes the gear that you use. For this demonstration you will see adding just a few manufacturers. I’m not necessarily picking on any vendors and who should or shouldn’t be here. It is just what my background brings.

This originates from a conversation had on Twitter about how to get the IP Prefix information from an IPAM tool, specifically NetBox using Ansible. There are a couple of methodologies to go through, and I had originally started down the path of using the URI module. Which could be done. The more elegant solution is to use the NetBox Ansible Collections to handle the logic for you! Let’s take a look.

In an earlier post I took a look at how to setup EVE-NG to get access to virtualized network devices and topologies. This post is going to take a look at how to setup GNS3 systems to allow access.

In the overall topology that is a “home” network sits a device that supports a routing protocol, usually either OSPF or BGP. What is known to work at an inexpensive price point is the Ubiquiti EdgeRouter X.

In this post I will be taking a look at some of the usability setup of managing Cisco IOS devices with the Ansible Cisco IOS User Module. This can be very helpful for setting up managed user accounts on systems, or the backup user accounts when you have TACACS or RADIUS setup.

The module documentation overall looks complete from what I have done for user account management on devices in the past. There are a couple of interesting parameters available, that I may not get to completely on this post. There is support for aggregate, meaning that you can generate the configuration for multiple user accounts and pass it in as one. You can set a password in clear text that gets encrypted when on the device, or you can set a hashed_password with the type of hash and its corresponding value. And as expected with a module for setting user accounts you can also set the privilege level for which the user account uses.

This has become a post about the ios_interfaces module with documentation that can be found Ansible ios_interfaces doc. Originally I was going to write about the deprecations for just the Cisco IOS modules. Then as I investigated further, I had found that there are many more modules that are being deprecated. In this post I will take a closer look at the differences between the ios_interface and ios_vlan modules that I had written posts on last year and what their new counter parts look like. And in the end the post had quite a bit of good detail about the module. I think you will like what is here.

In an earlier post I covered the differences between ios_config and cli_config. However I did not cover what the difference was between ios_command and cli_command. Most of the items covered there remain the same. So this will be a post that mostly gets straight to it and sees what the difference is.

A reminder that I am also putting playbooks used here out on Github. You can find this at: https://github.com/jvanderaa/ansible-using_ios

Differences #

First, for the cli_commands module, you must be using a connection method of network_cli. You should not use connection: local for this module. Note that the cli_command can also be used with multiple device types, including multiple vendors. Take a look at the cli_command documentation page that there is a link at the bottom of the post.

In this post I’m going to be taking a deeper dive into the new in Ansible 2.8 IOS BGP module. This may be one of the more complex modules to date and I’ll try to make it as simple as possible.

For a reminder about the BGP protocol is that this is the predominate protocol that runs the Internet. It is used to peer up with other companies and is what helps to make the Internet great. This is a very powerful protocol, and has been expanded to support many things. This is also a protocol that is heavily used in modern data centers.

Today we are taking a look at the newest module out for Cisco ASA Ansible module - asa_og. This one is particularly exciting for the configurations that are being managed heavily with Object Groups on firewalls. I’m particularly excited to review the asa_og module, time to dig in.

New in this post is the finished playbooks being added to Github. I’m hoping that this may be helpful and I am uploading the contents to Github for more to be able to see and get access to if necessary. This will improve as I continue.