Nautobot Next: Pre Built Apps – Supercharge Your Automation

Hello. How are you this morning, this afternoon, this evening, wherever you are in the world? Welcome to our webinar here. Uh we’re just going to wait about one minute while we wait for everyone to join in from the waiting room. There are a lot of you today, so that’s amazing. Love to see all of you out there. Uh we do have a poll for you here that we’d love to get your responses on as we’re waiting. Um so take a second to fill that out here. It’s totally optional, of course.

Um, but we’re just kind of curious to know where you are in your Nautobot journey and are you using Nautobot apps. Um, you know, maybe you’re just exploring all the way up to you’re building your own custom apps. So, kind of just curious to understand, you know, where the audience is and uh as we wait for everyone to get joined in here. Um, we will wait just a few more seconds here. Uh, there are still people piling in. Uh, so we’ll give it another 30 seconds or so for everyone to get joined in before we start the webinar.

Um, those of you that are just joining, um, please do give us an answer on that webinar poll. If you can, uh, we’re kind of just curious to know where you’re at in your, um, Nautobot app journey, where whether or not you’re using them. So, okay, it’s been about 1 minute and we’ve got a lot of you in the room here. So, let’s go ahead and get started. Uh, we’re going to jump into today’s webinar, which is in our Nautobot Next Series, and we’re going to be talking about the pre-built applications.

How to supercharge your automation with Nautobot’s most popular apps. So today uh we’ll be hosted by Chris Murray. He’s going to be doing the majority of the presentation and of course myself here Tim Schreyack as your host. Uh looking forward to taking you through the webinar here as we move on today. So our agenda for the day, we’re going to go through our Nautobot applications overview. Uh we’ll take a look at automation challenges and solutions. We’re going to do a demo. Of course, all webinars here at Network to Code include demos.

And then we’ll talk about our Nautobot Cloud accelerators, a new great uh feature that we have coming out in Nautobot Cloud and of course Q&A. Uh, a few housekeeping items. Please do use the webinar question section, the Q&A. Um, if you have any questions for us, that way we can track your questions, make sure we get them answered, and we can share those questions and answers with everybody else. As well, please do use the react button.

We’d love to know the things that are lighting up for you, the things that you’re interested in, the things that you enjoy. Um so please feel free to use that react button. That’s really helpful for us to understand kind of where you’re at and uh what’s what’s interesting for you. So let’s dive into our first uh section here that is Nautobot applications, the uh pre-built modular add-ons which enhance functionality and deliver solutions.

So, as we look at Nautobot applications, these are pre-built frameworks that extend Nautobot’s functionality. They’re modular, meaning that you can add or remove functionality without ever touching Nautobot’s core codebase. That gets you the functionality upgrades you need while minimizing core upgrade friction. Um, each app can bring new UI elements, jobs, and even integrations. So, instead of starting from scratch, you’re leveraging proven frameworks that accelerate your automation journey.

Additionally, it’s possible to build your own custom applications to suit specific use cases that are unique to your environment. So, you have a lot of power available to you, whether it’s out of the box or things that you might be custom building out of your own. Uh, and then uh when you’re ready to add functionality to Nautobot, the first place to look is the application marketplace. Uh, you can get to it right from the lefthand navigation under apps.

And here’s where you’re going to see all the apps that are currently available for your instance along with details like the licensing model, uh the publisher, and links to official documentation. It’s basically your one-stop shop for discovering and managing Nautobot add-ons. And once you’ve determined what applications you need, it’s time to begin the process of installing them, of course, right?

Uh because we want to go from that initial step into what it is that we’re going to do, you know, and actually starting to take advantage of those applications. So as we look at kind of installing right the upgrade procedure varies a bit based on the type of Nautobot deployment that you have for our on-prem installs it’s going to be a little bit complex right or maybe even a lot complex uh in the manual installation method you’ve got to first of all review the documentation to understand the upgrade procedure uh pull the application from GitHub manage your dependencies update configuration files restart services and validate effect.

Depending on your environment, this can stretch into some amount of time. It could be days or even weeks of work as far as getting something like this installed. And this is where looking at not cloud, the automated installation method, can really have a lot of advantages. It’s literally as easy as selecting your application that you want to have, click install, and that’s it. It is really the easy button when it comes to installing apps.

So that’s definitely the best method that you could possibly have for getting started with Nautobot applications if you’re using Nautobot Cloud. Let’s take a look at some of our most popular apps while we’re here and kind of just highlight some of those. So most of our Nautobot users start their automation journey with three applications primarily. The first two device onboarding and single source of truth. They’re all about getting your data into Nautobot quickly and ensuring its accuracy.

Once you have reliable data in place, the Golden Config app takes the next step by helping you enforce intent-based network management. These three apps form the foundation of pretty much all of our clients’ journeys with Nautobot. And today we’re going to walk through each of them and kind of take a look at what they look like in detail. So before we continue though, let’s just take a quick peek at that poll that hopefully you all filled out for us. I’m kind of curious to see where we’re at.

So, uh, somewhat to perhaps what I was kind of expecting, especially on a webinar like this where we’re talking about things. Looks like a good amount of you have just started to explore Nautobot. Haven’t really started using the apps. And then there’s a few of a few of you that have been experimenting in your uh labs, right? Perhaps playing around with the apps. Uh, seems to be the majority there. And then we’ve got a couple of outliers here that are building their own custom apps. So, welcome.

I love to have all the wide range of experience here from the uh beginners all the way up to really experienced folks. So hopefully we’re going to have a little bit of something for everybody here as we take a look and continue through the process here of the webinar today and kind of really look at what we can do with our Nautobot instances and Nautobot applications.

So with that uh we’re going to move into our first section which is populating Nautobot with data and I’m going to hand over to Chris now for the the rest of this section as we go through so that he can give you a lot of details as well as do that demo. Thanks Tim. I appreciate it. And today we’re going to go over a couple of the challenges that we commonly encounter here at NTC. And one of those challenges is populating Nautobot data. We’ll go over the couple of ways that we go about populating and um kind of provide an overview.

Now, your environment likely has hundreds or thousands of network devices and each one of those devices has dozens of attributes which are going to describe its purpose and operation. A Nautobot relies on that data to deliver intent-based networking. Now, you could enter all this data by hand, but it’s likely going to take hundreds of hours and pretty much guarantee human error. You could also try importing this data with spreadsheets, but we found that in practice that these spreadsheets are almost always outdated and full of mistakes.

So to address these challenges, NTC developed an alternative which is our device onboarding application. Now this app connects directly to your devices and pulls in complete accurate device data automatically. It also ensures that the data is populated quickly and accurately without the risk of human error. That means your team is going to spend less time laying the foundation of automation and more time delivering value by developing. Now when the device onboarding application uh goes through this process, it does it with two jobs.

The first automation collects basic information about the device and populates that device in Nautobot. And the second automation collects the complete device data and enriches what was created in step one. When this process is complete, you can expect everything you see along the bottom of the slide to be populated from device names to platform interface data, VLANs, and more. With that said, let’s go ahead and contrast the two outcomes here.

Without device population, I’m sorry, device onboarding, you can expect at least some of these devices will be missing. Those that are populated will frequently have incorrect or missing attributes and the process is going to require a lot of your time. Furthermore, for CSV imports or um spreadsheet imports, you’ll have to pull that data from an existing database which may have imperfections of its own.

Whereas with device onboarding, you’ll be able to populate all of your devices quickly without mistakes or omissions and without the need for a pre-existing external database. The next major hurdle I want to talk about here is platform sprawl. So let’s take a closer look at how that impacts automation. Automated workflows depend on data from platforms by vendors such as Paula Alto, Cisco and Service Now. But every platform adds another unique API and another coding challenge and another translation layer just to standardize the data.

Additionally, when vendors update their APIs, as they often do, your automation code often needs to be updated as well. And over time, this creates a cycle of rework. It results in a lot of wasted hours, mounting technical debt, and automation development speed that simply can’t keep pace with business. Luckily, there’s a better approach, and that’s with NTC’s single source to treat that. Now, this application aggregates data from your IT management systems, giving you one place to access the information your automations rely on.

This streamlines development by letting you build against a single consistent API. And luckily, Nautobot’s API is easy to understand because it’s thoroughly documented on our doc site and it includes an interactive API explorer right in the Nautobot UI. And for developers who want to move even faster, we built tools like our Python SDK, PI Nautobot, which simplifies API interactions even further. Now, the single source of truth application works by mapping attributes stored in external systems.

Here you can see data from multiple sources, CMDBs, DSIMs, ITSMs, etc. and it’s compiled into a single unified view of this particular object which happens to be a circuit. Now this translation layer also normalizes the data. For example, different naming conventions across systems are aligned which avoids confusions and makes development simpler.

Now beyond aggregating and normalizing the data, SSOT also supports bidirectional synchronization and this is going to ensure that all of your IT management platforms are in sync with each other with up-to-date accurate data. Let’s contrast the characteristics of a network with and without SSOT. Now without SSOT, automation is going to be harder and more expensive. Teams are going to waste time dealing with fragmented visibility and inconsistent data which is going to slow progress every step of the way. With SSOT, the opposite is true.

Automation becomes streamlined. Implementation costs are reduced because you’re spending less time developing against multiple APIs and visibility improves as the data is consolidated into a single place. Synchronization across platforms also ensures that your data is going to remain uniform which is going to provide a solid foundation for you to build automation on. The last challenge I want to talk about today is configuration drift. Let’s consider why it occurs and what we can do about it.

Now, in a green field environment or deployment rather, your configurations are going to start out clean because everything is standardized thanks to the templates that are used during the planning process. However, after about a year, the cracks are going to begin to appear. Break fixes, urgent business demands, RMAs, and quick patches start to introduce these small inconsistencies.

And what often begins as a temporary fix to the problem of the day becomes permanent as the remedial configuration that was used is rarely realigned with the standard. By year two and beyond, those cracks turn into full fragmentation. The devices no longer resemble their original configurations or even each other. And at this point, the network becomes harder to predict, troubleshoot, and change with confidence. And I would venture to say that this is a conservative estimate.

It’s more likely you’ll encounter these problems in year one, not after year two. So this is where golden configuration comes in. It lets you chew up your environment, restore standardization, and ensure that every device behaves exactly as expected. By regaining that operational simplicity, your network becomes easier to predict, troubleshoot, and update with confidence. Now, let’s have a brief overview of how this app works. Now, Nautobot is going to use device data and Ginger templates to generate an intended configuration file.

It’s going to go out to the live device and capture the actual configuration file. We then have our compliance engine compare the two and highlight any discrepancies. And when a mismatch occurs, the remediation engine generates and can optionally push the commands necessary to restore compliance. This ensures that the network conforms to established standards. And this is accomplished by scheduling this process to run automatically so that drift is prevented from creeping back into your network.

So when a device’s configuration starts to steer off course, the golden configuration comes in and puts it back on course. Let’s consider the characteristics of a network with and without the golden configuration application. Configuration drift doesn’t just create clutter. It impacts the reliability of the network. It impacts troubleshooting, security, and compliance. Now, reliability suffers as these small mistakes add up. It makes the network less predictable and more prone to failing.

Troubleshooting slows down because every problem looks different in a poorly standardized network. Whereas, in a consistent environment, the issues that you’re encountering are going to look familiar because you’ve encountered them previously. And thus these problems are going to be easier to resolve and be done more quickly. Now the attack surface of the network also expands when these misconfigurations slip through.

As you can imagine, maybe a couple of devices somewhere in your network may have expired SNMP credentials or some other security oversight and that’s something that can be exploited by attackers. Now during audits the lack of standardization turns into chaos and the network no longer matches the documented design and that’s exactly what an audit is designed to detect right when your network isn’t standardized. So that’s always a headache when when you don’t have something like the golden configuration app.

So in summary, you know, the Golden Configuration app solves these challenges by ensuring that your network always aligns with the standards that your architects intended. Now, with that said, I’d like to go into a couple of demos here. We’re going to go over the Golden Configuration application and the single source of truth application. So, we’ll come down to the golden config section and we’ll come to configuration compliance and I’ve filtered out some of the attributes that we’re tracking.

And for this demo, we’re only interested in the HTTP feature. As you can see here, we have three devices that happen to be in Jersey City that are non-compliant. Let’s go ahead and expand one of those and take a closer look. We’ll come down to the HTTP attribute. Here we can see the intended configuration. So this is what the device should have. Here’s the actual configuration which is on the device itself. Here’s the missing configuration that should be there and is not. Here’s the extra configuration that is there and should not be.

And here’s the configuration. These are the lines that we’d have to push to bring this device back into compliance. So, let’s go ahead and do that. Now, we’ll come down to the Golden Config app. We’ll go to configuration plans. We’ll add a configuration plan. The plan type would be remediation. If we had a change control, we could enter that here. And we’ll select the feature HTTP. Now, I’ve already assigned a tag to these three devices. So, we’ll go ahead and select that.

And that just isolates the scope of this process down to just those three devices. So, let’s go ahead and generate that. And that’ll finish momentarily. Right. Great. Looks like that was generated. So, let’s take a look at these configuration plans. Looks like they’re in a not-approved state. And that’s a change compliance function. We want to prevent users from accidentally pushing configuration that they didn’t intend to or maybe hadn’t gone through a cab.

There’s also a section here to add change control ID information if you get that after the fact. So, let’s go ahead and apply that. That’ll transition the status to an approved state. So, with it being approved, we now have the opportunity to deploy this configuration. So, let’s go ahead and do that. And what this is actually doing is going out to the device itself and pushing those remediation commands that we looked at earlier. In a moment here, we’ll have a result. So, it looks like those devices now have those uh configuration lines.

We’re going to go ahead and regenerate the report. Now, we’ll come down to execute all golden configuration jobs. We’ll select that same tag again. Let’s go ahead and run that. And what this is actually doing is going out to the device, capturing its live configuration and looking at the attributes in Nautobot and the Ginger templates and regenerating the intended configuration and going through that whole process that we looked at earlier again. Let’s take a look at how that report looks now. All right, great.

It looks like we’ve resolved the problem. And if we go into one of these devices and go down to that feature, we can see it is compliant and it has the expected configuration. So the next thing I want to take a look at here is our single source of truth app. So let’s go ahead and head down there. And here’s our dashboard. We can see our data sources and data targets. In this particular case, we’re interested in pushing Nautobot data to Service Now.

Now, the first time we run this, it’s going to be a dry run, so we can see exactly what will change before we commit to the change. And we want to sync our Jersey City site. So, real quick, I just want to pull that up so you can see what we’re looking at in Jersey City. In Jersey City, we have five devices. Click on those so we can see their names. And just note those names for now. And we’ll go back to this and we’ll execute that.

And while this is in dry run mode, I’m also going to kick off the actual change because it does take a minute or two and this will save us some time. I would not recommend it in a production environment, but since this is a demo environment, I think we’ll get away with it. Awesome. So, it looks like the dry run is completed. Let’s go ahead and take a look at the sync details. As you can see, no objects have been created, updated, or deleted in this process. However, it does tell us exactly what would have been created.

Here on the top, we can see the JCY BBB101 device along with its serial number and a couple other attributes and some interface details being populated in service now. And the same goes for the four other devices at that location. So, let’s go ahead and take a look at the actual push. It should only take another second or two here. And what this is doing is it’s actually pushing that data to Service Now. So, momentarily, we’ll hop into Service Now and take a look at that. And we’ll see the devices populated there as well. All right. Great.

Looks like it’s completed. Let’s go ahead and pull up those sync details again. And here we can see 149 objects and attributes were added to Service Now. And again, it’s exactly as we saw in the dry run, the five devices in Jersey City. So, let’s go ahead and hop over to Service Now and see how that looks. We’ll go to our device inventory and we’re going to filter out the name and we want to start with JCY. And now we can see that those five devices have been in service now. So that’ll conclude this demo.

I’ll go ahead and pass it back to Tim here. Thanks Chris. So hopefully you all were able to grab some really good information there out of the demos and the details that Chris shared with us as we look at how you can potentially use Nautobot applications in your environment and our most popular apps that we have uh within the environment. Before we move into our Q&A section I do want to take a moment just to talk about our Nautobot Cloud accelerator for configuration compliance. Uh we’re really excited to announce our cloud bundle.

This is uh for configuration comp compliance specifically and Chris you can go to the next slide please. This offer is designed to get you up and running quickly. We handle the deployment of Nautobot’s so you don’t need to worry about that. And we’ll also help you with the population of device data and establish that configuration management from day one. The result is a strong foundation you can build on enabling you to accelerate your automation journey and move towards world-class solutions with confidence.

So really what you’re looking at here is the ease of use that comes out of Nautobot cloud and those three uh applications that are the cloud deployment, the onboarding and the golden configuration app, all part of that cloud accelerator to get you up and running as quickly as possible and actually start delivering value from Nautobot uh rather than spending days or even weeks maybe even months in trying to get Nautobot up and running manually the old fashioned way.

If you will write a great option available for you there using Nautobot Cloud and our cloud accelerators okay with that let’s move into Q&A now I know we’ve been having a few uh questions coming in here during the webinar which we will work our way through. Of course, if you’ve had any questions triggering in your mind, which I’m pretty sure there are questions out there, feel free to start uh putting those into the Q&A box and we will work our way through them as we have plenty of time to uh to look at your questions here today.

So, uh let’s just start off with the first one that we got in from Ashish, which was can this replace network monitoring tools like Avoc or Solar Winds? Uh so, generally speaking, Nautobot is intended as a network source of truth and an automation platform. It is not intended to replace a tool like solar winds monitoring or any other monitoring tool for that matter. However, Nautobot integrates very well with those tools. So what you will see a lot of times is using Nautobot in conjunction with those tools.

So rather than having to say populate in devices into your monitoring tool, you can use the single source of truth app like Chris just demonstrated uh to populate those devices in for example. So really easing your uh use of those tools and your simplicity of the consumption of them. So a great option there for you. Not intended to replace but definitely can work with. Another question here from Nathan. Uh if you’re using Nautobot as an orchestrator, how would devices get out of sync? Uh so there’s a series of questions here.

I’ll just kind of work through them and then we’ll we’ll we’ll talk about it, right? Uh, are you talking about engineers making changes directly on the devices to fix issues? Or what if there was an incident and manual configuration was to put in to fix the outage? Could the golden configuration override the fix and break the network? Again, a lot of questions that we kind of hear generally speaking about golden config. Um, so I’ll uh answer the first one and then I’ll let Chris take uh some of those second ones there.

So on the first one there, which was how would devices get out of sync if you’re using Nautobot already, right? Uh, so great point. A couple of things. one uh when you’re using the golden configuration app, you do not have to deploy it completely, right? So, you don’t have to deploy it for all your devices and you don’t have to deploy it for all features right out of the gate. So, you can pick and choose as you deploy it.

What we’re showing here in the demonstration is assuming that you have not been using Nautobot golden config app before and you have a network that is very very out of sync and you’re trying to bring it into compliance. Now once you’ve reached that compliance state and you start to use Nautobot as the method by which you manage your network then you’re absolutely correct Nathan the network should not get out of sync uh assuming everyone is following proper process right.

What we’re demonstrating here is that idea that hey you were coming into a brownfield environment and we’re trying to fix it on the fly. If you will Chris, I’ll let you handle some of those other uh the follow- on questions there as well uh perhaps about like how uh what if there’s an incident and I want to have a manual override for example Yeah. So, ideally, if you were to implement a fix to resolve a problem today, you should figure out why your standard allowed for that problem to occur, right?

And maybe update your standard so that it uh complies with the or aligns with the fix it implemented. uh that way we’re kind of not shooting from the hip and the activities of the changes that are taking place in the network including the incident management changes are planned out and thought through. Yeah.

So great great point Chris as well as if you think about the process by which Chris showed during the demonstration uh we still had to go through approvals to get all of our proper change uh you know our cab approvals and all of those things before not went and did a deployment. So in the case of let’s say you had a break fix scenario where someone went in and manually updated a device in order to solve a problem uh we definitely should be uh going and updating that uh we should be uh going and updating the template or you know that that gold standard that we’re maintaining in Nautobot after that incident.

Uh so that way in the future when someone goes back to you know make an update into not or manage the network um you know we’re not overwriting that change right this is just good process that we need to be following when we manage the network. So uh to answer your question there Nathan, hopefully we got you we got you covered um feel free to follow up if we didn’t uh make anything clear for you there as well. Okay next we’ve got one here asking is there a free version of Nautobot and if yes is there any limitations on using it?

Uh so the short answer is yes there is a free version of Nautobot. It is an open-source model and no, there are no limitations on using it. There’s a caveat though uh as hopefully we demonstrated here during the webinar today. If you go the free open source route that does mean you need to manage everything yourself. Uh that is understanding your dependencies and the infrastructure that you run it on and are you sure, do you really know how to run systems? Right. Uh Nautobot is a relatively complex application.

Uh so you will be responsible for all of that along with some of our applications that are not open source. So for example our OS upgrades applications along with NautobotGPT that are not open source and those are only available through an engagement with the Network to Code. So a couple of things there but the vast majority of particularly what we went through today are open source applications. Yes and they are available there’s no limitation on using them. Okay. Uh, let’s see another one here.

The source of truth models for different tools like service now and solar winds would uh having separate models can be utilized would would having a separate model be utilized uh in the SSOT application uh I think what you’re asking there is can you have different methods by which you sync between these different tools so maybe different fields between the different tools uh for example. The answer is yes absolutely.

Even the direction right you might choose to synchronize uh to or from Nautobot depending on what that tool is or even you might synchronize uh some data into Nautobot from a tool but also synchronize data back. Uh a good example of that is something like a uh Solar Winds where perhaps you use Solar Winds as your authoritative CMDB. So therefore we extract the data from Solar Winds into Nautobot which would be exactly the opposite of what Chris just demoed today. Right?

That’s where we’re saying, hey, we want to pull the data from Service Now into Nautobot. But perhaps you also want to be able to enrich that data. So your network engineers might add notes or some other metadata about a device in Nautobot. And you want to push that metadata back to Service Now. That’d be a great example of actually a bi-directional synchronization from Nautobot relative to Service Now in a way in which you might use Nautobot.

Very flexible, super powerful and can do a lot of things for you uh when it comes to synchronize data and move data around your environment. So hopefully that helps you there. Let’s see uh from Mia uh you mentioned changing SNP credentials for SNP v3 where credentials are hidden. How do you verify compliance? Specifically, how do you confirm the configured password matches the required one? Uh Chris, do you want to take that one? Yeah. Um, so I’m not exactly sure how SNMP version 3 credentials are stored inside of a Cisco IOS.

I’m assuming that’s what we’re referring to here. However, if it was a hash stream, you could compare the hash. We also have a secret secrets manager which could potentially be used in accomplishing that aim. Additionally, um, typically something like an SNMP version 3 uh password not existing would be detected by your monitoring software. Yeah, great answer, Chris. Uh to expand a little bit on the secrets capability within Nautobot, we do provide integrations with things like Hashi Corp Vault, for example.

Uh so you can integrate your vault store into Nautobot uh without worrying about the privacy or the secrecy of your secrets and then we’re able to do the comparison that way, right? So uh potentially that’s also an option. So you have a couple of options how you might deal with SNPv3. Uh but to your point um that SNPv3 is actually one of the more complicated uh configuration compliance things to enable. Um and that is one of the reasons for it.

So uh great uh great highlight there and the power and flexibility of not uh let’s see uh can golden config remediation also update the service now CMDB. Uh I am struggling to think of a use case in which we might want to do this. Uh Chris, if you have any thoughts on that, but I’m not quite following what you’re asking there, Avan. So, um maybe you could follow up with uh with us on that, unless Chris, do you have any ideas there? Um I I also struggled to find a use case for that, too. Yeah. Uh so, Avan, feel free to follow up there for us.

Um not quite sure what you’re asking. Is it important to implement IPAM before device onboarding? Oh, super interesting question. Uh I know Chris has done a lot of work on understanding IPAM and kind of being able to explain it is throughout our webinar series. So I’m going to go ahead and let him answer that one. Well so it’s not a device onboarding doesn’t require an I uh IPAMP. What you could do is um collect that information into Nautobot, right?

The IP address information and then export that to uh something like infoblocks that be a potential use case. I hope that answers your question, Todd. If it does not, please uh please ask again. Yep. Perfect. Thanks, Chris. Uh got one here from Justin. Can you share a rough road map or estimate when Arista CX devices might be supported for data sync from devices on the network? Uh so I think what you’re asking is for a device on boarding uh for supporting Arista CX.

Um I’m not familiar off the top of my head, but we can take a note on that and try to get an answer back to you. Um, and just to keep in mind, this is something that’s always uh part of an engagement with Network to Code. If you need a feature like Arista CX to be supported, please feel free to reach out to us. We’re happy to work with you on that to find a way to get you what you need uh and get you in the timeline you’re looking for. So, definitely feel free to reach out to us. We’re happy to answer that for you. Okay, next one.

Uh, is there a benefit of integrating Nautobot apps with Arista EOS? Uh so uh I think what you’re asking is there a benefit of using Nautobot to manage my Arista infrastructure and I’m guessing you’re asking that question because you’re using cloud vision uh which provides some of the functionality that Nautobot does. Uh where there will be some differences uh is that Nautobot provides you a vendor-neutral place to describe how your network should look. Um and that is different from what cloud vision provides. Right?

So cloud vision first of all it’s Arista only obviously uh but secondly it doesn’t really provide you an intended state location uh a place where you manage what your network should look like external to the network itself um and that’s really a key benefit of using Nautobot is that it allows you to have this place where I can uh describe how my network should look and then compare how it actually does look and in fact integrating with cloud vision is one of our very common use cases um where we see not being used uh to integrate with Arista cloud vision.

Uh we often are at a lot of conferences or even uh user groups where we do co-present with Arista. So very very friendly with Arista um as well as working with the Arista infrastructure is really common for us. So yeah, great question. Um absolutely uh definitely uh something that’s possible and something that’s very very useful actually. Uh let’s see. Is it the same to use the single source of truth to pull from different platforms to populate Nautobot than to use the device on an onboarding job?

A really great question uh and a great point to distinguish the difference between what is device onboarding versus single source of truth. And again, I guess I’ll let Chris answer this one here uh since he was doing the demos on the details of those two apps today. Yeah, sure. I think there’s different use cases here, right? It’s applicable in different scenarios. If you already have IT management systems that are robust and accurate, it makes sense to pull that data in to Nautobot and start synchronizing it right from the start.

However, if you don’t have the competence in your IT management systems uh recording or the records that are in there, it makes more sense to use device onboarding and then uh kind of go forward from there. Do you have anything to add to that, Tim? Yeah, I think the only other comment I would make is that um device on boarding helps make sure perhaps you have some devices that you know got missed. You know, they’re not in your records already. Um, device onboarding is a good way to double check that, make sure you get them added in, right?

Uh, yeah. Uh, but I think otherwise. Yep. Absolutely. Coming in here from Justin, do you offer break fix support to help accelerate on-rem deployments? Absolutely. Yes, we do. So that can be anything from just your break fix as you mentioned all the way up to uh helping you with that deployment through a professional services engagement or even an ongoing uh engagement where we might help you on occasion. Uh so definitely feel free to reach out to us Justin. Yes, we’re absolutely happy to help you with that. No problem. Let’s see.

How can a single source of truth interact with many different devices without their API? Ah, so I think we just addressed this, but just to highlight, a single source of truth app is intended to interact with other tools, not with devices. That’s where you use the device onboarding app. A single source of truth is intended to interact with a tool that has an API. So yeah, great call out there. Um, just a different use case that you might use those two different tools, applications for. Okay.

How does the topology view compare to traditional network diagrams? Oh, so I think you’re referring to that topology view that we might have seen during the demo here. Uh so what we’re viewing in Nautobot is a little different from what you might see in your traditional network diagram. That’s for sure. Uh and it is going to be more reflective of what the intended state is contained within Nautobot as well as gives you the capability to map out what your data center floor plans look like.

Uh so you can map out your intended states for your floor plans uh both physical and logical there. Right? So that is a little perhaps a little different from something you might do in your traditional network diagram using uh you know any of the drawing tools, right? So this is something that’s done more dynamically on the fly as opposed to uh you know traditional vis. Hopefully got you an answer there, Nathan. Feel free to follow up if uh that’s not a good answer for you. All right, let’s see. Uh great demo. Good job, Chris.

We got a shout out there for you. Thanks for that there. Uh and a question in uh does the solution support any branching or approval mechanism? For example, if someone updates the intended NTP configuration, can it go through approval process before be applied? Love the question. Uh so uh a couple of things. Uh there are several ways in which you might implement this concept. There is the first which could be that not all data that Nautobot works with needs to be stored in the database attached to Nautobot.

So for example, something really important like an NTP uh server setting, you might store in a YAML file that you synchronize into Nautobot via Git. That would be one way. And then of course that file is stored over in Git. And we would have all the version control options available to us that you would use normally in Git, right? That’s one way. Uh another way is using something that’s called version control within Nautobot. This is one of our newest features and it is uh we do have a pending update coming on that very very soon.

Uh I can’t give you more details on it other than that but yes absolutely it is coming and it is going to be able to do native version control within Nautobot directly. So u that is also a feature coming as well very soon. Um so uh hold tight uh we will definitely be doing a webinar on that coming up this fall. Let’s see; question from Michelle. Uh the configuration remediation setting seems very complex to set up. Are there any tools to help with creation of these? Uh so the short answer to your question is yes and yes.

Yes, it is complex to set up and yes there is help and that is network to code. That’s why we exist. We’re here to help you with that. Uh so that could be anything from uh using Nautobot Cloud to simplify the deployment of the application all the way up through leveraging our professional services that can help you get up and running as quickly as possible. These are complex problems. Uh and it’s not something that’s like hey I’m just going to have this automated tool go out there and you know and help you with that. It’s just not a thing.

Um and that’s where we come in both the professional services side of the business as well as our cloud side right. So absolutely we’re here to help you. Do you offer a trial license to use in an actual environment? Uh so uh the of course Nautobot itself is open source so you can go download it um and start running it today right there is a lab-based VM that it’s an all-in-one package you can give it a try um or you could even go to the our our public demo site that’s demo.com uh we’ll give you some links here at the end of the webinar as well uh you

could try it out there also if you want to just you know kind of play around but if you really want to try it in an actual environment probably the simplest way is pull down that VM and get started with that uh once you’re interested would definitely be happy to get you set up in Nautobot cloud so you can give that a try as well. How featured are Nautobot’s monitoring features? Is that via the net ops app? We use logic monitor, a SAS tool. So just decided and then uh would Nautobot be a reasonable way to monitor our APs?

So Nautobot core is not intended as a monitoring tool. Uh there is the Nautobot observability platform and that is primarily intended to integrate with a other uh open stack based tools such as graphana and prometheus in order to implement a uh monitoring stack uh that is uh actually quite robust and fairly complex um in its capabilities uh but it isn’t something that’s part of core Nautobot if you will right um so that was definitely something that is available via engagement with NTC only um not something that’s part of the open source project will

there be more out-of-the-box integrations for example Arista Jira 40et short answer is yes um as we have client demand we implement those types of integrations and features and of course they can always be done um for you specifically if there’s anything you need that’s missing feel free to reach out to us we’re happy to help via uh you know an engagement with NTC I sound like a broken record I keep saying that over and over um but that is usually the answer right like if you need something from us just reach out let us know uh speaking of SR and operations.

Are there any plans to move away from Django Python to make the packaging and operation side things side of things simpler? Uh great question. Uh and the short answer is I don’t know exactly. Uh you know we’re always looking at how we can make Nautobot simpler to use. Um and you know we do have our road map published. Uh for the immediate future though we are on the Django and Python path for the immediate future. So um there wouldn’t I wouldn’t expect any immediate changes there but you never know as we look to the future.

I think it’s also worth mentioning that we have NautobotGPT available as well that can help generate some of that Django code and some of that Python code that you may need to accomplish uh your projective. Great call out Chris. Yeah, actually I wouldn’t even uh think of that as part of the answer, but absolutely yeah NautobotGPT can really simplify your life as far as using Django and Python um and allowing you to move forward and even level up your skill set. Um so yeah, that is a great great call out there.

Can Nautobot trigger ticketing systems to create a ticket like using web hooks that Nautobot used to have? Absolutely. Yes. And Nautobot still does have web hooks. That is not anything that has gone away. Uh so uh yes, absolutely. Oh, I think you’re referring to Netbox perhaps there. Um so yes, uh Nautobot does have the web hook capability and uh yes, absolutely you can do that. That’s a really common use case that we often see clients doing, which is to automate the creation of tickets based on some event that occurs within not.

Yes, absolutely. All right, we finally got down to Avanoshir with the follow-up. Uh, so we’re getting a lot of questions, Amber, and we’re still doing okay on time, so just double checking that here. Uh, when we sync Solar Winds, we create a separate Solar Winds location on Nautobot so that it would all be separate sources of truth, but we have the devices already available. Uh, so I think you’re asking basically, how do we make sure on locations lining up with what we might have in Solar Winds? Uh Chris, any thoughts on that question?

Um if not, Avanosh, I would suggest um reaching out to us. We’d definitely happy to get on a call with you. We could kind of discuss through it. Uh we could bring one of our architects if necessary u to kind of look through this use case. But uh Chris, any comments there? Yeah, I would just say this kind of goes into a deeper discussion about what constitutes a system of record and what constitutes a source of truth and how we align that in our ecosystem to achieve uh you know a robust authoritative source of truth. Yep. Yeah. Uh, perfect.

And you know, absolutely. Yeah. And if there’s any other questions there, please just reach out. We were happy to set up a call and chat through. From John next here. Uh, is there a plug-in available for ingesting devices into Nautobot via API calls? Yes, absolutely. That’s the single source of truth application. Um, that’s what it’s exactly designed to do. Bring data into Nautobot via API. And it doesn’t matter what that other thing is. So long as it supports your standard REST API, no problem.

So it could be, you know, uh, you know, Arista CCF. Sure, no problem. Uh, probably a little bit of an unusual use case. Typically, we’d be using devices on boarding in that case. Um, but you could absolutely use the single source of truth app so long as the device has a REST API. So yeah, no problem. Uh, Golden Config has the capability of remediation if there is any config drift. So while making the device uh, actual config fix, we should also update to service now C new. Uh, so the short answer is yes.

um you would absolutely want to build out your workflow, whatever your business case is. Um and not is intended to be really flexible like that. So yeah, absolutely if that’s how you run your business process, then yes, you would definitely want to do that as part of that flow. Um and something you absolutely can do using Nautobot jobs, right? So you can build those kinds of orchestration flows using a Nautobot job. So yeah, absolutely great great great point there.

Where should I update devices that I want to be onboarded or how do I tell Nautobot to get these devices? So, uh yeah, it’s kind of just like how do I get started with a device onboarding? I think this is the question here. Chris, do you want to take that one? Yeah. So, um the device onboarding application ingests a list of IP addresses that you would pro uh that you provide to it and that’s how it would kind of kick off the process. Yep. So, you just give it that list of IPs and it’s going to go off and query them.

you give it some credentials that it’s going to attempt to log in with um to understand what the device is. So yeah, pretty pretty straightforward. When we get information from manufacturer devices, we should use the same library for all the separate libraries for each device. Like with Juniper, we have uh oh yeah, so the different drivers, right? Whether it’s net new or newer, uh those will depend on the kind of the functionality and what it is that you’re attempting to do with the device.

Um Chris, do you have any comments there about how you might choose a particular library to integrate or to uh interact with a particular device? I don’t really have a lot to add there. I would just say that a good place to start would be identifying the most common manufacturer or operating system that you’re running in your network and start with those drivers and then kind of build out from there. I hope that answers the question. Um but if it didn’t, feel free to add a followup there. Yeah. Yeah.

And this is something that we can help with as well. Um this is uh one of the things that we commonly do in engagements is our architects will work with you to understand what your infrastructure looks like and give you recommendations on what uh tools you should be deploying and what would be kind of the easiest path forward if you will. So again, one of the advantages of working with Network to Code, We’re going to save you from having to figure out all of those uh questions and problems, right? So yeah. Okay, we’ve got a couple left here.

Uh what are the main decision points whether to do this on prem or in the cloud? I’m sure there are lots of factors. I’m guessing Nautobot Cloud costs dollars. That’s also a factor. And yes, of course. Um, and you know, just pointing out that running on premium is not free. Um, that’s a common misconception that, uh, people think that, hey, I’m just going to run in my own environment and that doesn’t cost me anything. It absolutely costs you money and time.

Um, and almost always what we find is that running in Nautobot Cloud is going to be cheaper than running it yourself if you consider how much time and effort you’re going to have to put in to maintain it yourself. Um, this idea that running open source code costs me nothing is simply not true. Um, so keep that in mind, right? Um, yes, Nautobot Cloud costs money, but it is probably going to be cheaper at the end of the day and it is for sure faster than something that you might do on your own.

So that really I think is the main key there is are you an SR? Probably not. You’re a network engineer. So let SR’s handle that function here at Nautobot Cloud. Um, and you just do what you do is be a network engineer, right? So focus on your skill set. Don’t worry about those other kinds of details, right? That would be my opinion. Um from here you’re coming from the Network to Code side. Um but even as an engineer back when I was one, I had the same philosophy, right? Like why should I do things that are out of my skill set?

Doesn’t make sense for a super large on-prem enterprise connecting to Nautobot Cloud uh overVPN or directly connecting to AWS. What are the bandwidth and latency requirements? Uh so you know to be honest we have extremely large clients running in Nautobot Cloud and by extremely large I mean half a million devices and more and into millions of objects stored in Nautobot Cloud and we have no issues with that whatsoever as far as latency. Um the uh we do deploy across multiple uh regions.

So we have that making sure we’re close to your environment as well as the bandwidth requirements of Nautobot are generally actually pretty low. Um they’re not heavy usage in and out of the devices. So um pretty pretty straightforward not a big deal there as far as running in really large infrastructure and we are very familiar with running in extremely large networks. So no worries there. Within the single job device on boarding can we add all the site devices with different secret details? Uh interesting question Chris.

I don’t know if you know the answer to that. I’ll let you uh have an attempt at that one. Um if you don’t then we’ll have to get back to you on that. Avanosh, let’s go ahead and follow up later because I do want to make sure that we will give an accurate answer to that. We’ll get you, we’ll get you an answer on that. Just not sure off the top of my head either. Todd, is it practical to start on prem and migrate to cloud later keeping what you built? Absolutely. Yes, you can definitely do that. We have a lot of clients that do that.

You get started in your lab or some small environment. You experiment, show the value back to your business and then eventually migrate over to Nautobot. And in fact, that kind of migration, we don’t even charge you an onboarding fee into Nautobot cloud. We’ll do all of that as part of the process totally for free. We’ll take whatever you’ve built, migrate it over into Nautobot Cloud. So yeah, no worries there. Feel free to go that route. Absolutely. Then reach out to us when you’re ready.

Do we need to provide standard config for golden config? So I think what this is asking is basically how do I get my gold standard? Uh how do I create that gold standard? And yes, the short answer is yes, you do need to create that. Um that’s something that you define, right? Because your gold standard is unique to your environment. Uh so that is something that you’re going to define. You’re going to set up those templates that uh explain to the system as well as to yourselves, you know, what are our standards?

What does our gold standard look like? So, absolutely, that’s something that you’re going to do as part of the uh setup and process of the golden config application. And again, again, not to sound like a broken record, but that is something that we commonly help clients with is figuring out what are my standards and how should I define them. We will help you with that uh as part of an engagement with NTC. So, with that, wow, we were hammered with questions. Um that’s probably the most we’ve ever gotten. Uh so, that’s great.

Thanks all for your interaction there. Uh let’s move out of the Q&A section and just kind of do a quick wrap-up here. Uh so today we looked at Nautobot applications kind of went through an overview of what they look like and what some challenges are with automation. We did some demos and of course we talked about the Nautobot Cloud accelerators and then all of your questions which were amazing. So thank you for that.

As we look towards you know where we go next right so we want to hear more um please feel free to reach out to us as well as we have a lot of information available online previous webinars that you see here we’re going to drop some links for you in the chat so you can grab those as well as coming up here shortly we’ll give you links to all things Network to Code and not so as we wrap up the session today thanks for attending! Happy automating, look forward to seeing you on the next webinar.

And don’t forget if you have any further questions, definitely reach out. Thanks very much and we look forward to seeing you again.