Network to Code Partner Case Study: AHEAD
Video Description
In this video, Brian Nelson, Principal Technical Consultant at Ahead, explores how to scale network automation for consistent infrastructure management. He introduces Nautobot, a tool that combines CMDB and DCIM capabilities to centralize and visualize data across networking devices, enabling standardization and automation.
Transcript Highlights
Contents
How Nautobot Centralizes and Standardizes Infrastructure Data
Brian introduces Nautobot, a tool combining CMDB and DCIM capabilities, allowing teams to manage and visualize infrastructure assets like VMs, containers, and network devices in one place. He highlights its flexibility, custom configuration fields, and ability to pull data using LLDP.
From Data to Automation: Leveraging GraphQL and REST APIs
He explains how structured device data stored in Nautobot can be accessed using GraphQL and REST APIs. This enables real-time updates, software version tracking, and integration with platforms like ServiceNow.
Building a Network Automation Delivery Pipeline
Brian walks through AHEAD’s CI/CD pipeline for network automation, emphasizing testing automation on digital twins, risk assessments through ITSM, and automated CMDB updates—removing manual processes for greater consistency.
Demo: Deploying Desired State with Ansible and Nautobot
In a live demo, Brian uses Ansible to restore BGP configuration on a Nexus device by pulling the desired state from Nautobot. He shows how structured data allows for consistent deployment across mixed environments.
Tool-Agnostic Automation with Structured Data
He demonstrates how the same structured data can be used with different automation tools like BackBox, and outlines the broader benefits of digital twins, software validation, and centralized data for scaling and flexibility in infrastructure management.
00:05
Hey this is Brian Nelson with AHEAD. I am a principal technical consultant here and I’ve been here for about two years, and my focus has been on network automation. One of the big issues we’re seeing with our customers is how they can scale and take their existing automation tools and solutions that they already have and how they can utilize those best to continue growing in the organization. How do they standardize their infrastructure how do they maintain consistency across
00:39
the board. So what I’m going to show you today is how we at AHEAD have gone about going and solving that. What you’re looking at here is Nautobot. It’s a solution that we have found to work very well for this Nautobot if you are unfamiliar with it is a CMDB and DSIM combined so it’s a change management database mixed with a data center management database. What that basically means is that we can now I can put every one of your networking devices or any device for that matter whether it’s storage,
01:12
compute, VMS, containers Etc in here and we can manage that through this service and we can be able to visualize that have it stored in a database. One of the reasons that we’re a big fan of Nautobot is its robust capabilities. So if there’s something in here that you need you can easily add it, you can come over to the features and you can add in custom configuration. This allows us to basically say hey you know what, there’s these additional fields that we need to be able to define this
01:47
product whether it’s like an F5, or it’s a you know Nexus or a Juniper right, there’s specific things for that vendor that we need that nobody has, so this allows us to be able to do that. So what we do here is we have all of the data for each one of our devices located in here. Here you can see the site that it’s located in you can see what kind of device type the chassis that I’m running the serial number for that chassis you can see the platform that it has the management IP you can see what login
02:17
information that I currently have set for it. Over here you can see all my BGP peering information, the ASN number assigned to it if we go over to the interfaces you can see all the interfaces, you can see the status to the interfaces, you can see what they’re physically connected to now all of this right here is manually assigned there are tools that we can use to help scrape that and put that in so you don’t have to do this for all your brown field stuff. And we can use things like LLDDP to pull that
02:45
information, and here is an example of what that would look like right so here we have LLDP pulled for this device directly it was just pulled just now. You can see that this is what we have configured and this is what LLDDP is showing in response. As you can see everything is matching up right here’s the device that’s the device that we have configured connected on that Port. Also some other awesome features that we have here is I can sign IP addresses directly to the interfaces I can show that we could add in like
03:15
VLAN, you know 100 and put an SVI on it and I could configure that as well. This gives you very robust capabilities, if I need to add more interfaces whether they’re virtual or I can you know if you have the ability to put cards or slots into your device this allows us to to manage that and and see all of that visually, but what’s even greater, is that the fact that it’s all stored inside of a database it gives me the option to be able to pull that data out. So what we what we’re using here is we’re using a
03:47
tool called graphql, it’s pretty native here and what I can do is I can define what I want out of this device, so I can actually search this by device location device name Etc, and what I’m going to get is I get all this data out. Now the way I get this data out is I make a rest API call so I call Nautobot through a rest API which works with pretty much any programming language, you can even use Curl if you have just a Linux host. I can get all this data out about my device, I can get the IP address of the device, I can get
04:19
the name, all that data, I can see now that hey look here’s this device this is not right and and you can basically pull out all this data that’s the one I wanted to Showcase here so this one shows like all of the interface statistics right so here’s this device here’s its interface is it enabled what’s the IP address assigned is it management only there any VRFS etc. and this does this for each interface. What this does is this allows me to take that data and then be able to use automation on it right, and all that data
04:57
is defined over in here on the device so now I have a way of defining the data that’s very well structured and I have a way of pulling that data out not only do we have a way of defining the data is well structured we also have a way of pushing the data in there so we can use things like service now as a front end and be able to push data into the CMBD we can use automation to do that right let’s say that we upgrade our software version right and you want to be able to track your software version.
05:23
Well you can manage that here as well right we can say that hey this is a supported version so for example, if I look at the this device here, I can actually run all my automation, I can pull the version that’s on it I can say is this one of the ones that we’ve already validated is it preferred right and we can change software versions. We can track all that we can track all CVEs in this. We can create reports creates one central location for all this data and at the end of the day you can also come in come
05:52
in over here and we can actually look at the configuration. Right here you can see the device configuration being pulled in and you can actually see everything that’s configured on the device. It gives you this real time ability to get to the device and actually see all the data, everything that’s configured on it. So what we’re going to Showcase to you today is I’m going to show you is actually going in and pulling this data out with Ansible and with another tool that we’re using called Backbox and
06:22
showing that it’s the same process between the two of them but we can go ahead and make changes to our networking devices. So what I’m going to show you here let me pull up a slide real quick and here in the slide you can see this is how we see the delivery pipeline of this data. So this is the CICD The Continuous integration continuous delivery the big thing that a lot of people don’t understand about Network Automation is you need to have a way to continuously deliver those automation changes that you’ve made. And so that’s
06:52
what you’re looking at here is how we see continuous delivery happen. Essentially you’d have an engineer go into an ITSM to track the changes it would pull in all your device configurations that are currently there aot with all that device configuration we can then generate a configuration template and we can deploy that to a digital twin we have continuous testing right because as we deploy this to your continuous twin, what we’re doing is we’re actually testing that code against the digital twin to
07:21
ensure that the code still works for the versions that you have. It continuously allows us to test that version of code the software that automation. Once we’ve stood up that infrastructure we can then run our prevalidation checks making sure that hey we’re going to do a software upgrade on this so we can we push the software, we test that software before, we test the current software we deploy the new software and then we’ll do a post test on it and we create these artifacts of data or things that have changed
07:49
between the two updates. Then we’ll have it the then the automation test and ensures that it can connect to all the infrastructure, and then all these artifacts that are generated from from these go into a risk assessment in your ITSM which then allows your change management board to actually see what the real risk is not just what the engineer assumed the risk was but what the automation picked up the risk was. And we can assign scores we can assign all sorts of stuff and we have all the artifacts of that data to justify or to
08:18
validate the scoring mechanism that was given to it. At that point, we use our automation to deploy the changes pushes that out to your infrastructure that validates that deployment and we can update your ITSM and we push those new changes that we pushed out into the infrastructure into your CMBD. This allows us that consistency to making sure that your CMDB is always up to date and always accurate. And the idea is is to not actually have engineers in there making changes to your CMDBbut rather have your automation making those
08:50
changes so then it just becomes a state for you to know what does your infrastructure look like. So this is the in resold but for the sake of what we’re we’re going to do in this demo essentially I’m going to generate the configurations we we’ll create the CMDB host variables here I’m going to generate those configurations and we’re going to deploy to the digital twin. And then if we have time I will show some validation steps. So with that being said let me cut on over and I’ll show you how this works.
09:21
so what I’ve got here is I’ve got Ansible Automation Platform it’s a really great product and we’ve got quite a lot of things going on here so let me go ahead and let me pull up the one that we’re going to do here and before I get too far let me show you what I’ve got going on. So this is actually our layout of our infrastructure today. This is what it looks like here, so you have a Juniper, we have an Arista, I have a Nexus, and I have a Cisco iOS device. So with these they each have a point-to-point connection between each
09:59
one with a /31 subnet assigned to each one of those interfaces. Then I have a management Network in the middle that allows me to use my Ansible and backbox to talk to all of these devices. So what we’re going to do is currently I have BGP established here and here and they’re all advertising that locally connected routes to each other so that I can ensure that I have consistency. So what I’m going to do is I’m going to go into the Nexus here and we’re going to wipe out the BGP configuration and I’ll show
10:31
that that essentially goes down, and then what we’re going to do is we’re going to have our automation tool be able to pull that desired state out of Nautobot and then deploy that configuration out to the Nexus. So I’ll show IP BGP sum there you go. You can see the neighbors, they’ve been up some of them over a week right now, so now I’m just going to copy this right here and paste and show IP BGP so. And here you can see now it’s not even running right so what we’re going to do is we’re going to come over here and I’m going to kick
11:12
off this job to go ahead and pull out the desired state from Nautobot and deploy to the infrastructure. So as we go to my jobs up here what you’re going to see is you’re going to see quite a few jobs running the first thing it’s going to do is it’s going to pull down the Nautobot inventory, it’s going to make sure that our our code that we’re using to pull the inventory hasn’t changed and so that’s doing that right now and in this case it hasn’t. Then what it’s going to do is it’s going to pull down the latest inventory, and
11:43
then it will check to see if our BGP code has changed and then it’s going to go ahead and deploy that. So let me go ahead and go through some of this code with you and kind of show you a little bit of what it is that we’re actually doing and how this works. So for any of the Geeks out there who really like the code, so what we essentially are doing here is I’ve got everything broken out into rolls. So I’ve got this template roll, and what I’m going to do is I pull in all my variables you know pulling in my
12:14
Sign in information all of that right here, and then we’re going to run through our roles and in this case the only role that we’re really wanting to run through is our BGP configuration. So inside the BGP configuration this is where things it kind of cool so we go over here to BGP config and we go into the main file and this is where a lot of how ahead approaches automation a little different because what you learn as you go into this is that as I write automation each platform requires a different set of instructions right.
12:49
Arista way you configure BGP is different. The way that you deploy BGP for a Cisco Nexus the way you deploy CIS, BGP to a Cisco iOS is different than Nexus right, every one of these needs different things. So what we actually do is the first thing that we really believe in is keeping things as modular and as simple as we can. We don’t want to make a large lot of large calls down to Nautobo pulling all this data and then have to parse through it. So what we’re doing here is very specific we’re pulling in that graph 2L
13:20
query that I showed you earlier parsing through that data creating a structured data set of that and once we have the structured data set I can then take that structured data set and run it through here and through my configuration here and be able to push that out to those devices because the data is structured now it’s really easy to manage. So inside of here what I’m basically doing is hey look up for the first found and the first found is the supported platforms and so in this case we’re looking for if it’s an iOS, a
13:52
Juniper, a Nexus, or an Arista right and we’re going to use the platforms that’s specified actually in Nautobot, I can show you that now if I come over to my devices here you can actually see the device types are listed here and if we actually go to platforms I have all the different platforms, what devices are assigned to them, and the network driver for each one of those right and this this allows us more customization more more control, more structure right because I have all this data defined now I can run through
14:25
it with my Ansible. and so essentially you know the Juniper is going to have different commands than the Cisco iOS, right Cisco iOS is pretty straightforward. Where the Nexus on the other hand there’s quite a bit more configuration that had to be added here. So you kind of get the idea, so what we’re doing is we’re pulling that out, we structure the data and then that allows me to basically say hey use the remote neighbor. but this same command here for data is the exact same command over here for my remote neighbor. You can
14:54
see they’re identical. And it goes across from my Junipers right as well remote remote neighbor right and you kind of get the idea here, no matter if I wanted to add a Meraki in here, or if I wanted to add you know extreme networks or any any other networking device the data is structured all I have to do is just figure out the command specific for that platform. So really the hardest part for you is just to figure out what the data is and then from there we structure that data we can push this
15:20
out to any device really quickly. The other advantage for it is let’s say that you’re no longer a Cisco fan you want to switch over to Arista, and you want to know what this network would look like what your network would look like with Arista, well I could come in here and I could actually Swap this device out and say you know what you’re no longer a Cisco now you’re in Arista and we’re going to push it out to here and I hit save and now when my automation runs it’s going to push out the Arista configuration of the device. Tt’s going
15:47
to use the same management IP and now this is really great if you’re using a digital twin because we can also specify how that infrastructure is going to look and the reason why we can specify that so easily is because because I have a wiring diagram, I have the IP addresses of all that, and I have all the automation to deploy all this so because I have all this data I can make digital Twins and we could shift out your digital twin with any other networking type on the fly. Let’s go ahead and we’ll come
16:16
back over here let’s take a look and see how we’re how we’re running let’s go to jobs we should be successful so take a look here basically ran through configured all the IPs all the interfaces everything that’s needed for BGP to function properly and there you go the only one that was changed is this one right your Nexus 01, so now if we go back take a look at the Nexus device let’s do show IP BGP-sum and there it is we’re up as of a minute ago fully functional fully working. Now I can take this and I can
16:48
take this to the next level, we can also since we can manage interfaces I can come in here and we could enable this interface and then that interface would now be enabled on this device as well. Because of the scaleless here and the way that we’re doing this is we’re so focused on process and not focused on tool sets, I can take this and I can run this through any other tool through the same process. So while I used Ansible in this demonstration, I could use another tool like Backbox backbox is another
17:24
automation Suite of tools that are out there that we can use and what I can do is I can basically run this right here and this will go out and follow the same structure that I just did with Ansible, but instead here I’ll show you one that’s already ran, if we view this and basically it goes out it does the graphql query, finds that data from graphql, does an API call into it and then from there it pulls that out processes the data puts it into a structure, structure data format, right and here’s our structure data format and
17:59
then from there I go ahead and I deploy that out with a bunch of remote commands. And we use Jinja2 templates and we can push this out quickly and easily right so the idea here is it doesn’t matter what the tool set is for automation now we could do this with DNA Center we could do this with Abstra, we could do this with any other tool out there the thing is is now that the data is in a generic format, all I have to do is take that data, process it into a structured data set for whatever tool I’m working
18:27
with and I can push the configuration out to the device. It’s just really powerful option for us. What we’re finding really here is in the market you kind of have two customers. You have those who don’t have Network Automation, and this is really what a lot of those customers are looking for. And the other side, we have a lot of customers that have Network Automation and one of the struggles that they have and that we’re hoping that we’re able to address actually with this is the testing of the code right and
18:58
That’s where this prevalidation comes from and you can see prevalidation changes here. This is the testing of the code once again another reason why we’re big fans of Nautobot because over here let’s say that I deploy new software to a device I can actually log all of that data over here on this Arista for example Arista here right I’ve got valid images and when if I came in here and I validated this image and I’ll show you this process of saying hey this is actually right I can say on this device this this
19:32
version of software is actually running successfully on this Arista device we know it works for these versions of these models right it can run on this one it can run on this one right and if I had more Arista devices I could add it we can even put in device roles for example if you had a leaf in the spine you could say here I’ve tested this on a leaf I’ve tested this on the spine so then when my devices are being assigned to these I can actually say hey it was validated and I can say it was validated
20:00
on this day, right I can say today was the day validated. And this is the preferred version. The other thing is you can also put in structured notes, right? We can use markdown language for this to be able to push that information out there. So now not only do we have a way to say hey we can test your code, right because our process defines a way to test the code, but we have ways to store that test in the same place that we’re storing all of the device configurations. One place to store all of the data for
20:28
your network infrastructure, for your data center in general. It doesn’t matter if it’s a VM it doesn’t matter if it’s a container it doesn’t matter if it’s a a database we can store all of that infrastructure configuration in one location and then we can just basically build ways of getting that data out and using GraphQL which is a very powerful tool and we can push that out to you I hope that this has been a really great lesson of kind of how to structure your data or at least be able to use that
20:57
data and the the abilities that you have if you have good data structures you can see this is very small but this scales very very quickly there are plugins to be able to pull in information from info blocks there’s structured ways to pull data in from service now there’s ways to pull data in from Arista, CVP, Cisco ACI if you already have configurations there there’s no reason to go in there and try to add all that data manually we can just consume all that data in here here and then we can write automation to go
21:30
AHEAD and push that back out whenever you make a change this becomes a good place for us to be able to test and validate code before it goes out because because I have the data I can make a digital twin for you at any time I want and so that’s that’s the real Secret Sauce here is is just getting that data and getting it into a place that I can use it and then I can I can manipulate it however I need I can replicate your entire infrastructure in a digital twin or you could use things like Spirant and actually create a
22:03
physical twin of the same infrastructure because we know all the wiring configurations, we know all the device configurations and we have the automated tool to push it out to these devices. It’s just a matter of just writing the code to that new structured data of the tasks and the processes that you want it to follow. Once again my name is Brian Nelson, and this is a great work that we have and that we’re doing here at AHEAD and if you have any questions please reach out to your account your sales account
22:34
team. Thanks again.
Contact Us to Learn More
Share details about yourself & someone from our team will reach out to you ASAP!
Thanks for submitting the form.
