Nautobot Next: Mastering Network Data Population

hello everybody Welcome in always takes a minute or so for everyone to join in from the waiting room so we’re just going to hang out for about one minute while we wait for everyone to get joined uh it’s great to see so many of you here um wherever you are in the world um welcome it’s good to see everyone filling in we have a really large group today which is super exciting glad you’re all here and ready to uh get involved with our uh Nautobot Next series that we’ll be going through here today uh wow you all are really ticking in this morning well

morning for me uh so amazing love seeing the uh population here out uh joining and participating with us um as we move forward with our webinar series super exciting topic that we have going on today uh we’re going to be talking about mastering network data population uh so again we are just hanging out for about a minute while we wait for everyone to get joined in for those of you that are just joining in now uh we’ll get started here just shortly all right great seeing everyone uh Welcome to our webinar series uh this is Nautobot next mastering

network data population U how do you unlock the full potential of Nautobot and we’re going to go through learning some best practices to populate and manage your network data uh today for presenters we have uh myself Tim Schreyack and with me is Paddy Kelly uh who will also be assisting in going through some of the demos as we get into those details uh we’re going to talk about how the various methods of population that we can use to get data into Nautobot uh we’re then going to move on to the device on boarding 4.0 application a lot of great features

that we’ve had uh added in there into the device onboarding application so we’ll look at that uh we’re going to also talk about the single source of Truth application a great way that you can integrate Nautobot with other tools and get data from them um and then we’ll just overview some other methods that you might use uh of course Q&A and then we’ll conclude out the webinar for the day uh a couple of housekeeping items please do use the Q&A box if you have questions for us that’s the best way to get us questions so that we can make sure that we share

them with the group and and get your question answered and then as always please use the react feature it’s really helpful for us to know what you’re lighting up on what you’re interested in what you’re enjoying um as well as it’s fun for the community and lets us all kind of participate together so please do use the react feature as we go throughout the webinar for things that you might enjoy or like let us know okay so you’ve got Nautobot now what uh it’s a powerful Tool uh but it’s only useful if it’s you know put to a task that is we need to put

some data into it um and so that’s our step one is to deploy Nautobot um step two is to start populating data and then step three would of course be to deploy automations if you were looking at that whole picture of how you might use the Nautobot ecosystem So today we’re going to focus on that step two that data population piece that’s where we’re going to cover um and then later in the series as we go through the Nautobot next series we’ll go further into how you might deploy automations in your environment U making your P you know management practices

safer more efficient more cost- effective for example so what is data population um it’s uh it’s easy to assume that it just means uh device data right um but there’s a lot more to it than that uh while we’re tracking device data it it’s certainly an important task that Nautobot’s really good at Nautobot is is capable of tracking a a wide array of relevant network data such as you know locations and their Associated floor plans uh Personnel contacts manufacturer contacts contract information even Cloud resources such as controllers and storage and and

many many more things right so Nautobot really has a very large capability of what it’s able to track and fill uh so we want to make sure that’s clear right it isn’t just about devices uh it’s about all the things that you manage in your environment that you use for your day-to-day Network management activities um that can be tracked monitored and consumed within Nautobot so how do we get data into Nautobot there’s several ways right uh that we can do that U today we’re going to primarily focus on the two easiest me easiest methods to get data into

Nautobot that’s our device on boarding application and our single source of Truth application we’re going to give you an overview of each of those and then we’ll go into a demo um and then we’re also going to look at some of the other methods um at a higher level to ensure you understand you know how to determine the best approach for you uh you know as you can see here there are other examples such as you know CSV import maybe Ansible playbooks uh you know slurp it as a a great tool as well U or even you know just manually creating objects um and then

finally Nautobot jobs uh but again you know our recommended approach if you’re uh just getting started with Nautobot is to use the device on boarding 4.0 app uh or the single source of Truth app maybe both uh you might use them in combination so the device on boarding 4.0 app let’s dive into that first um and take it start taking a look at how that functions how you might use it uh it’s uh so the device on boarding app right it starts off with the uh IP address of the devices that we are interested in looking at or that we want to discover uh there are

two device on boarding jobs that will collect device attributes and then we use them to populate Nautobot cmdb this solution uh is best used intermittently when devices on your network are known that they haven’t been populated into Nautobot yet so as we look at this process here right first thing we’re going to do is to input those IPS into the app uh and we’re going to have those two separate jobs one job is going to get the device information uh that is just that the device exists and then the second job is going to actually go pull data from that

device so for example uh we need to go discover uh all of the vlans all of the interfaces all of the uh vrfs that are just configured on this device right that’s what happens in that second job so you can think of that first job as something that you do to discover existing devices or new devices usually that’s a less frequent task um but the go discover things may be on the device itself configuration things those might be more frequent um depending on use case in your environment so we’re going to go collect those uh uh device uh information from our

devices um and then we’re going to put that into Nautobot so uh that’s the basic concept right here uh the ability to provide some basic inputs so the IP addresses that I want to go discover uh the credentials that I need to use in order to get into those devices or attempt to get into those devices um the tools then going to find that they exist um it’s going to basically discover its management IP what type of device it is let’s say it’s a Cisco iOS device um and then from there that second job is going to go discover all of the details and we’ll be

able to bring that into Nautobot so again the idea of the two jobs um one result right how do we quickly populate device data and there as we look at these two concepts here right like we’re going to go a little further into what we’re looking at here um so first job right the initial device population out of the box support for Cisco iOS XE n xos um Arista EOS and Juniper right are standard out ofth box supported tools uh devices uh and these are the things that we can collect from the device during that process so its name its device type its serial

number management IP uh the platform manufacturer Etc right uh this allows us to then get that list and now we’re moving on to actually going and collecting information from those devices right so here we’re saying hey can I get um all of the details so the device interfaces as I mentioned earlier the vlans the vrfs um those extra pieces of information now one thing to note here right um this particular aspect of the tool and similar across the platform in general is you’re saying hey you know what there’s this one thing I would really love to collect

that you don’t have already here no problem it’s very easy to extend the collection mechanism in order to be able to get additional information that isn’t Ed here let’s say you know straight out of the box right so very easy to do um and also key it’s item poken you can run this over and over again you’re going to get the same result no problem uh there’s no harm in running it multiple times right like it’s not something where like hey you can only do this once you know don’t do this uh again after you’ve done it the first time um this uh functionality

is available via the Nautobot jobs menu as well as the single source of Truth dashboard those are the two ways that you might get at these particular jobs and be able to run them off uh so now we’re going to Pivot over to actually some real hands-on experience with the device on boarding uh application here we’re going to go into this demo and uh Paddy is going to take over for this part and take you through that great thanks Tim okay so let’s take a look at device on boarding in action let me go over to my Nautobot here so here is the the main page for

for Nautobot for those that are not familiar with it so what we want to look at is how we how we’re going to populate Nautobot and the use case here really is that maybe you don’t have a source of Truth and you’re starting off and the first thing that you want to do really is uh populate your source of truth from your existing Network because at that moment in time the existing network is probably your source of truth already as in you you you trust the configs that are on the device okay so what we will do is we will go to use the uh device onboarding

app okay so device onboarding app as Tim explained has two separate jobs that we would use to basically figure out where the device is on the network uh and then add that into a specific location so that it can be um correctly stored within the source of Truth so when we go to our jobs page here we go into our device on boarding and we look for device on boarding here and we’re going to sync devices from the network so we’re going to select this uh option now our first option here which we’re going to uh turn off is dry run this is actually a best

practice that we would normally run a dry R before we do any sort of a sync but we’re going to explain that a little bit later uh as part of a different demo okay so for this we’re going to turn off dryer on so that means we’re actually going to make changes into the uh Nautobot database so once we turn off that then we’re going to select a location um we’re going to select a location uh for this particular device that we’re going to learn and we’re going to put it into Jersey City actually before we do that we can actually just check that there’s

nothing there just to make sure we I have a save view here for our Jersey City routers um okay so you see here that we have a Jersey City 02 um let’s try and import Jersey City 01 so let me go back to um my jobs and go back to my device on boarding so here we go and now we are going to go to Jersey that’s still location that I want to import this device into this uh location into this site okay we’re going to select the name space here this is essentially just a logical segmentation that you can use to have overlapping IP addresses if you want so we’re

just going to select the global here for this one um then we are going to give it an IP address so it expects to take an IP address so that it can basically connect out using SSH to ensure that you can log into the device so we’re going to use uh our IP address here our default port for SSH um and then for our roles we’re just going to select our role it’s just router we’re going to give uh the status we just need to give uh some status for any of the device or the interface or uh the IP address so we’re going to put these all to active and then our

secrets group we use our secrets group to Define what the credentials are to actually log into the device so this is predefined for us uh so we we have uh a username and password that are stored in this particular secret group um for the platform we are going to select this is a Cisco iOS device so we’re going to select Cisco iOS we don’t have to select the platform but in this case we know it so it actually makes it a little bit quicker if we didn’t it would actually just use the auto recognition U which is under the hood with using netmiko so we have

our Cisco iOS there to click run job so that is going to go out to the network um using that IP address we can see uh our status here will tell us how the job is going right now it’s completed uh when we look at the logs we can see here the commands that have been run we see show version show interfaces and then there’s a couple of sort of lower level details down here so let’s go back and see if we have uh our device now if we go back to our view on our Jersey City routers super okay so we have another device here okay so let’s check in here um this is

our Jersey City rudic what I get from this as you can see is I get the the type of the device I get my serial number I also get the platform which I had specified and it’ll also give me the manufacturer and some of these things will uh if they are not already there it’ll create them um and then it’s also going to give me uh the management IP address uh I see up here that I have one interface which is essentially my management IP address the loop back interface okay so that was the first job and that just gives us the basic device it also assigns it to a

site which is really important so now I know where it is okay so what I want to do now is see if I can get some extra data okay so I will go back to my jobs H go back to device on boarding and we’ll take a look at the second job that Tim outlined which is to sync network data from the network okay again we’ll disconnect or sort of uh deselect uh the dry on and now what I want to do is Select my Global again we give our interface and our prefix uh and now we already had our device name so we’ll search for that Jersey City uh 01 okay now I don’t need to

fill in the rest of the details because I know the device name is unique so I should be good now so all I got to do is Click run so it’ll go out connected that device and now as you can see here it’s running another set of commands so you can see it’s running show version show interfaces show interface the switch port and show ether Channel summary for some of the lag information okay so that’s going to give us a lot more data and hopefully when I go back I should see more data for my device okay so that’s back to my devices in my Jersey City click on

the device great okay so I have now more interfaces so here we will see that we have uh interfaces 1 to five it gives me the description mty u values and also the status of the uh the interface uh so this this basically means now that I have a device It’s associated with a site and I have all the information that are required now to start planning around how I can automate with this device okay that’s it back to you T thanks Paddy uh for that great demo there and uh we do have a lot of questions coming in don’t worry we will get them answered as we uh

come towards the end of the sessions but so please do feel free to keep putting them in as you think of them it’s great uh for us to be able to know where you’re at and what you’re thinking um as we go through the uh the demo here and webinar today and uh thanks for all the reactions those are really fun love seeing them uh so let’s move on to the single source of Truth application uh importing data from sources that you already Trust uh so the Nautobot single source of Truth hat right it features 14 out of the box uh Integrations that allows you to

bring in data from other sources of record into Nautobot’s uh gives you a centralized repository of all that information uh so basically users and automation tools no longer need to access those multiple systems right they can just go to a single place and get all the data they need uh Nautobot can then leverage that single source of Truth app to populate its data models uh which goes beyond devices to include many types of data like you know the contact and circuit information like we talked about earlier right uh so we do cover a lot of devices out of

the box such as you know infobox uh device 42 ACI itential moroi you know you can see a a seg a summarized list here not everything is included here um that we do actually out of the box able to integrate from um and uh due to its extensible nature this app is really very adaptable so it’s very easy to add on custom Integrations you know maybe you have some unique in-house Tool uh or some other tool that we’re not currently supporting out of the box it’s quite simple to add that in that basically you’re adding in that additional API that you want to

extract data from and bring into Nautobot as we uh streamline this creation and maintenance of automation uh one of the key things that we really want to focus on that allows that makes the Nautobot platform unique is not only the ability to bring this data in with the single source of Truth application so maybe I’m bringing in some ipan data I’m bringing in some cmdb data I’m bringing in some software versions from these different applications or different tools that I’m running in by environment um what usually happens in the real world is that we

enter data in one tool with one standard and then inevitably in another tool it’s a slightly different standard and so we have let’s say our convention isn’t standardized across the organization or just over time people enter things in different formats we can leverage the data validation and data Integrity capabilities of the Nautobot platform when we ingest that data into Nautobot so we aren’t just blindly taking that data from those external sources and plunking it into the Nautobot database we can run it through the data validation and integrity

engines that Nautobot has to standardize and make sure that data is clean before we bring it in and this is such an important step uh particularly when we’re synchronizing data from multiple sources we do not want to be making different names for things for example it might be the same device but because it’s entered slightly different um if we weren’t running it through data validation and data Integrity we would end up with two devices created in Nautobot as an example rather than a single one uh so we want to make sure that we leverage that

capability so that we actually are able to make sure we have good data that we’re working from for both our users uh as well as the tools that are potentially accessing data within Nautobot to then drive automation for example uh this is a great way to actually get a handle on the data problem in your environment which probably you have uh so com combining that with the device on boarding I can go discover things that are exist out there in the real world then I can also pull things in from my existing sources of Truth and in both cases I can run that

data through data validation and data integrity and make sure everything is as it should be before I bring it into into the database so this is really helping us have a good clean data ecosystem within our environment uh absolutely very very critical uh when we think about how we’re going to drive automation particularly if you think to the Future um it’s one thing if as a human I look at a screen and I see you know something that is inconsistent it’s a whole another thing when we have an automation that’s about to go do a task and it finds

inconsistencies right either that automation is going to fail um or it might do something incorrect and so we want to make sure that we have good clean data when we get started so very important step as we think about how we use the single source of Truth app to bring data into Nautobot and leverage the platform uh to make sure that we’re able to drive both our user community and our automations in an expected behavior and Method okay that brings us to now the next demo that we have here in our webinar today that’s going to be the single source of Truth

demo and again Paddy’s going to take us through that great thanks thanks them again um so let me just jump out of that um okay and let me get back to my main screen so for the single source of Truth app that uh Tim is talking about and has gone through uh the the thing that we would use this generally for is if you have another system that is a system of record or an authoritative source for a certain data type and one of one of the examples that we we’ll use here for this particular demo will be info blocks for IP for ipam data okay so generally uh

before you have a source of Truth most organizations would probably have an ipam system or some way of managing uh their IP addresses so if that process is in place the the it’s easier to manage your IP data within the ipam and then you want to sync that back into your source of Truth it doesn’t necessarily mean that you have to have everything within the source of Truth you may already have already uh underlying processes that have already been well established so you want to sync that data in to make sure that the source of Truth has a consistent View

and that you trust your data that if you’re using your source of Truth to automate onto the network that is having the most uh recent data so to do that within the Nautobot ecosystem as Tim mentioned we have ssot app uh and what we’ll do is we’ll go and sync in this demo from the uh info blocks uh that we have in our environment so we go down to apps down here we look at the uh install apps that we have here um we look at our single source of Truth in our instance if we look at the um config we have an info blocks config list now this means that we can

actually have multiple in instances of info blocks which you’ve seen in a lot of different customers you might have a Dev instance you might want to think against a production instance and they could have different URLs and you could have different settings based on what you want to import or what you want to uh uh synchronize okay so we can do that pretty easily within the uh guy uh within the config section on the actual application so we see down here on the left hand side as I use the uh Navigator our single source of Truth is the section down here

so we’ll go to this dashboard View and what we’ll look for is our data sources this is what we’re going to look at is in this demo is the info blocks into Nautobot synchronization okay uh as you’ll notice actually the device on boarding app is actually also you using the underlying technology that we use for s soot uh and that is um using a diff sync library that we have an open source diff sync library so let’s take a look within the info blocks ssot we see on the right hand side here the data mapping so it basically gives us the data that we’re going

to be pulling in syncing in from infol blocks what it is termed on the infol Block side so a network view will be pulled will be mapped in and synced into a namespace and network on info blocks will will be synced in into a prefix on Nautobot and an IP address into an IP address VLAN into VLAN and a VLAN view will be synced into a VLAN group on the Nautobot side so uh let’s take a look at synchronizing now so if we set our um job as we mentioned before when when you’re syncing in any data from any system the best practice that we would use is to run

through a a dry run first so the dry run basically would ensure that you can pull the data in this instance from uh infol blocks but not make any changes to Nautobot and saving any changes into the database but it will give you uh a diff view of what would change so you can basically validate if the changes that were going to happen as a result of the sync is what you want to see okay so in this instance we’re going to demonstrate the dry run feature so we’ll select dry run keep that on again we’ll select our config we only have one info blocks config

here represents our uh demo device and then we click um The Run job now and that’s going to run in dry run mode and we should see the status up here um which tells us that it’s complete right now it’s just giving us some of the the logging information in terms of what we pulled in from uh info blocks what we would pull in uh so it’s loaded in the namespace some prefixes and some IP addresses and then it gives us some of the the details down here on the actual diff okay so would would have created 55 objects objects so we can actually go up to the sync

detail section here uh and in here it’ll give us if you’re familiar with looking at a diff view it’ll give us uh a nice visual representation of what would have been added so here is where you would basically run this and S like a pre-check before you actually make the synchronization is to say okay well what am I expecting to see uh in this instance we see that there would be two prefixes added and there would be uh a number of IP addresses but we see uh quite easily the IP address and then what it would be and what the actual uh um domain is and any

of the additional attributes and what they would be set to okay uh so that will show us it’ll also show us the type here which is a dry run so it shows us that it wasn’t a full sync as a result when you see the statistics over here nothing has changed okay so that would if that was actually a non dryon you would have seen 55 creates here okay when I go into the sync log nothing is actually synchronized because I’ve run it in dry run mode so I don’t see any database changes but uh as an example if we looked at some um if you looked even at a history of

one that had happened before um let’s take a bigger one we have some okay down here if I was to check some of the logs of the sync logs of ones that are actually completed we would see for each record that was updated we would see exactly what what the record was and what the diff is what’s been added in okay so you can see obviously a lot of information but very good in terms of being able to uh validate that the changes that were made at a certain time and the expectation of what what the system state is okay so as we run a triy run we we don’t have

time to run the full sync but this is the data that you would have seen uh that you will see once you make the uh changes I’ll just go back to this so as a result of the sync you see all of the IP addresses that will be added in uh with their uh name space and the record type and then obviously with the status uh and then the additional prefixes as well that will show you okay back over to you Tim thanks Petty all right so we’re going to move in now to the last section of the webinar here where we’re going to go through other methods of population that

ways that you might bring data into Nautobot Beyond those primary two methods that we just discussed so first is our uh CSV import method um so yeah I think many of you probably very familiar with uh you know comma separated value files um and usually we would get these as an export from another platform such as maybe service now or device 42 and um while it is absolutely uh a very quick way to bring data into Nautobot um it’s not without risk um you know oftentimes the data from these exports maybe needs to be massaged a little bit before we can

incorporate it into Nautobot um but if done carefully and properly um it can be really helpful at facilitating that initial population of data into Nautobot uh some of the pros of this you know hey it’s part of the Native core uh functionality um all data models support it and it’s generally very easy to do to export from some other Tool uh some of the cons as we mentioned right like hey you could bring faulty data in you know accidentally um and it may require some Manual sanitization of that data before you bring it into Nautobot so something to keep

in mind if you’re using this method um we generally see folks using this as a one-time step as an initial step if for some reason you don’t want to use the device on boarding app or the other single source of Truth app maybe you might go this route as that one-time initial data population step uh another method right anle Playbook uh kind of an interesting thing to think about as far as like how might I bring data into Nautobot um Nautobot’s ansible uh collection does provide Ansible plugins uh that is a way to bring in like modules inventory lookup

filters Etc to interact with Nautobot uh these plugins are designed to help you manage devices IP addresses and even more um this approach does require uh an external Ansible environment and custom development is uh is required to leverage those plugins so uh you know some of the pros of this method right uh you can leverage those those pre-existing or public artifacts from Ansible uh to facilitate population um and it is item potent uh the uh the cons here you know hey it’s not directly integrated into Nautobot you do have to have an external

environment to run Ansible um and it will definitely require some custom development and maintenance next method uh Python scripts as as Nautobot job uh you know some of the pros we see here uh you know it’s a very broad plat vent and platform support it’s extremely flexible and extensible um of course you know with all things there’s going to be some downsides uh it will require a custom development and maintaining it over time is probably going to be a challenge um for those of you that aren’t familiar Nautobot jobs are scripts that are written in

Python uh to give you the ability to execute custom logic from within the Nautobot platform itself uh jobs can be written to facilitate nearly every single Nautobot task that there is whether it’s populating new devices to fetching data from external sources uh this uh custom script or code uh can be executed from the UI uh from the rest API or via Nautobot CLI uh you can even add like a UI button that can be added anywhere you want within the application uh to be able to quickly execute a Nautobot job so you don’t necessarily have to navigate to the

Nautobot jobs uh page in order to run a Nautobot job uh and additionally uh job hooks can execute a job whenever object is changed um so Nautobot jobs are a really powerful way to leverage the platform and one of them is you could actually use it to onboard data into Nautobot this would give you a lot of flexibility as as basically anything you can do in Python you could do in a Nautobot job another way uh would be using the slurp integration uh our friends over at slurp have written a very great app a very good application uh that allows you to uh

import and scan in uh your environment ingest that data into uh the Nautobot ecosystem uh some of the pros here right um it does perform this device Discovery um it does leverage the NTC text FSM uh repos and and templates in order to uh understand that unstructured or semi-structured data that we might be getting from various vendors over 117 plus supported uh and but a con to the application if there is one um it is a very good app we are friends with serpent so no worries there um but one of the cons if there is one is that it does require a license

to populate attributes of devices into uh The Tool uh final or one of the final methods here uh are manual object creation right just don’t do it by hand is absolutely a possible way uh some of Pros here right it’s very simple to do uh you go into the UI you open up a device you add it in um it’s pretty straightforward it’s quite intuitive um some of the cons of course anything we’re doing by hand prone to human error um and then of course this is not going to scare SC um this is an extremely time consuming process it’s good for one to a handful of

devices you’re definitely not going to want to do this at scale um you definitely be want to using the one of the other methods preferably the device on boarding app um would be the best way when you’re working at scale or working with larger numbers of uh devices so uh some other methods here of which you might want to get data into Nautobot as we think about how do we actually leverage the platform because the platform in and of itself is useless until we put data in it um and that’s one the keys here at Network to code right is that we want to have

functional tools that actually provide value um and this is Step number one in getting value out of Nautobot is getting some data in there to start working with so let’s go ahead and move on to our Q&A section uh there have been folks that have been hammering questions at us so thank you very much appreciate it uh we’re going to go through uh I believe we should be able to get through all of these if you have a question that you’ve been thinking about and maybe uh hasn’t popped up here yet please do uh fire it into the Q&A box we’d love to get your

question answered um we’ll start going through them here today um we’ve gotten a couple of questions about uh iOS XR support for the device on boarding app uh and whether or not that might be part of the uh outof the-box supported features I do have good news for you um it is on the road map and we expect it to be released within the next 3 to four months so it is coming soon uh so don’t worry there uh we are going to get you that um because we know that’s a very popular uh operating system that’s out there lots of folks are running XR devices so

absolutely want to add that in so uh that is coming uh so we’ve got that one there for you uh let’s see we’ve got a couple of other questions here um as well so uh let’s see this one paddy here do you um do you know or let’s talk about um how you might use the device on boarding app uh to be able to bring in the version of operating system or version of code that the device is running yeah you can actually extend that and it’s it’s something that we’ve done for uh other customers as well um which is there’s the capability to extend device on boarding um

for a particular platform uh you can do it within python code and you just uh there’s a mapper that you can configure within device on boarding to be able to map to your new module that will allow you to take advantage of some of the data that you’ve discovered uh say for instance from the show version and you can get the the iOS version within that show version command and then you can map that to either a field or a custom field or something like that or even one of the the existing Nautobot modules so that’s uh possible I will also add on the XO the

iOS or store stuff you can actually extend that yourself now as well there is there is platform mappers that allow you to create new platforms and extend the capability that’s there all you’ve got to do really is add in uh your own command and then you use James path to be able to uh extract some of the data um there’s a new yaml file that’ll allow you to extend uh so it’s it’s something that is well documented and there sh there is a process process to follow before it actually gets released in the next couple of months if you need it before then

excellent thank you P um okay next question uh the device Discovery job so the two that we talked about there the ability to go discover devices and then bring in the data from them uh are they part of the out of the box functionality or do I have to custom create those no you get them out of the box yeah so you get the initial one which is to discover just a device itself a map it to a location and then the second one about the the network data you get them once you install uh the application y okay uh now this one is specific to uh if I’m wanting to

pull in data uh from the device uh specifically about the location um will it support the idea that I might have locations that have sublocations uh so for example um a building might have five floors um each floor has four closets I’d love to be able to just run the data sync one time and specify this group belongs to you know potentially belongs in this location in the sublocation essentially rather than say having to run the de of the device on boarding app five separate times um is that something that we would be able to support in the near future

it depends where you’re getting the location from I guess uh if it’s something that you’re um defining at the start when you sort of you would need to define the location within Nautobot first to select it uh or you could if you had the location somewhere within the config say if it was in the banner or something like that you could actually extend it if you wanted to do it that way and sort of dynamically learn it there’s a bit more development required to do that but um any of those sort of use cases will be possible yeah and then followup question to

that uh with the concept now that we have those two separate uh onboarding jobs um will they ever be combined into one now I know there’s been a lot of internal debate about this uh so I’ll let Paddy explain some of the details around that thought process uh I guess that the the capability would be there um the jobs may end up staying staying um but we could potentially chain the jobs as in uh once you run one job it might kick off the second job and maybe that’s a um that’s hidden from the user um right now the the way that the um the Plugin or the app

has been developed is to uh take on the additional um um functionality that was previously in the networking order application um so the first stage was to move away from the network comporter and build that capability into device on boarding um and the first stage of that was to basically give uh device on boarding the job that was basically running the network and Porter um uh sync so whether it is going to um whether it will sort of um migrate into just one single job um we don’t have an answer just yet but I would suggest that it could be something

that we’d look at in the future fure yeah and if you think about this right there there’s really not a whole lot of difference between having it as two jobs or one job uh you could always chain the jobs uh if you wanted um but it does give you some benefit you know for example it’s pretty common in a lot of environments where you know new devices don’t get added to the network that regularly but the devices themselves may change more frequently um so that’s kind of those two separate steps right you might want to go out and discover if new devices have

been added to the network say once a month um but maybe you want to scan your devices to see if they’ve changed every day right so um there’s kind of that little Nuance there right like maybe that device uh the initial population uh job you just run it infrequently and the discovery of configuration within a device you run more frequently so that gives you some uh flexibility there by having it as two separate jobs okay uh let’s see here another question uh so after the device is discovered if we light up a new Port what is the best practice to get that

interface added to the database a weekly ReDiscover job or some other method so I’m going to give you a little bit of philosophy about how we approach uh Network Automation and and network source of Truth here at at NTC um and then we’ll uh kind of go from that sort of academic view of the world sort of a reference architecture view of the world to let’s talk about the Practical real world right um so in an ideal scenario we are changing Nautobot that is the source of Truth before anything changes on the network it is the place where we Define what the

network should look like it is our intended State um and that’s the purpose the primary purpose of Nautobot so in an Ideal World we shouldn’t have to go ReDiscover that that that interface was turned on because we already did that as part of turning the interface on that was the first thing we did we went and turned it on in Nautobot and then from there things started to happen now we understand that that process that paradigm shift as a network operations group or a network engineering team is going to take some time and so there are other methods by

which you could discover things in the real world and bring them back into our source of Truth into our intended state but always keeping in mind that is not the ideal scenario in which we drive change into a network the ideal scenario in which we drive change into a network is we change the source of Truth first um and then we start to make changes on our network uh but again we understand the real world that’s not always practical and sometimes we have to do things the other way around uh Paddy if you have any follow-up comments on that please do jump

in um but you absolutely could run that network discovery um that on a regular basis to go discover new interfaces that have been turned up yeah and that’s it I mean uh as you said sometimes those processes aren’t there to support the fact that now you’re using a source of Truth and if you were going to H you you you want to make sure that people that are going to the source of Truth they trust the data so you could run that sync daily because ultimately you want to have uh you want to get buy in for people to start using uh the source of truth that

they trust the data that they’re seeing accurate results from what they’re when they’re making change or when they’re looking for things so if you were doing that but as Tim said you you would need to make sure that ideally you move away from the discovery component and then you’re defining in your intended state from the source of Truth absolutely uh okay next question uh did that configuration that we pulled in uh from the device uh did did it go into golden config uh so great question about kind of how the Nautobot uh ecosystem and the apps interact

with each other and how does that all work so it didn’t go into golden config because ultimately you there’s no I guess at this point we there’s no guarantee that you have golden config so you want to be able to say yeah I turn on and device onboarding I want to learn my device um it is it is a good option in terms of saying okay how do I make sure that the data that I’ve discovered is now used in the rest of the ecosystem But to answer the question directly it it doesn’t go into um golden comp yeah not automatically but that data is absolutely

available to the golden gig app and you could as a second step then begin to incorporate into your golden config uh application for sure um but yeah it’s not going to automatically appear there uh because that might not be the behavior you want right we don’t want to assume things that you want in your environment we want to make sure you have the capability to use the platform as As You Wish okay let’s see uh is it possible to easily extend the onboarding app to new or not yet supported systems the short answer to that the TD art yes uh how complicated

it is for each and every system that may vary um but it is quite easy to extend yes not a problem uh we have sort of answered this in in a few ways here before so I won’t spend too much time on it but absolutely yes you can do that okay uh we have multiple customers with multiple locations can we onboard devices at a remote location with app overlapping IP addresses uh as and so that’s the first question there’s a couple follow-ups here so we’ll get that first one then we’ll go into the second one so first one there is how can I handle overlapping IPS

uh in in different locations yeah the overlapping IP was uh is handled really with the uh the name spaces so if you remember when we when we did the demo we had to select a particular name space where it was saying that if you um had two devices with the same IP if they’re in separate name spaces it was considered as a separate uh separate uh import because of the M mentation that’s happening within the name spaces so that’s the first part yep uh the next question was uh what about and I think it’s related to the the type of operations this uh

individual Works in uh where they are wanting perhaps a proxy that uh is able to get into that environment and like say send data back to Nautobot basically a phone home uh remote control type device you might put um on Prem uh at your customer location in this example another one would be maybe a distant location that doesn’t have direct access back to where n is uh we do get this question pretty regularly it is something that we have on the road map uh it is uh at the moment very unlikely it’s ever going to be part of the open source project it is

probably always going to be part of our Nautobot cloud or Nautobot services that you would get from NTC um so absolutely is the short answer um the longer answer there is it was probably not going to be part of our open source solution um this particular functionality this would be something that we absolutely would love to help you with um we do have this capability um but it’s to be as part of an engagement with NTC not um something that you might see in the open source project at this time uh okay uh then the next question is about um I think the

question is asking how can I easily get Nautobot with the device onboarding app installed can I just do that via Docker um I think is that is what the question is getting at essentially how can I get started uh with easily deploying Nautobot and the device on boarding app um in a single Docker or can I yeah you can yeah I mean it’s Docker is probably the easiest way to do it um that you can pull down the image uh and it’s basically going to be a configuration uh setting where you’re going to enable a particular Plug-In or an app um and from there um you

can ensure that you pull down the right image and uh get started it’s pretty easy yeah yep uh mad you asked a question that I don’t understand um I have to screen in single uh in schema single s source of Truth um I don’t know quite what you were getting out there um please follow up in the Q&A uh with a little bit more details there uh if you’d like an answer on that one because unfortunately I don’t quite understand what you were asking for I apologize uh next one is uh can we expect a Ruben Network support uh so our wireless uh infrastructure and do

we uh can we be able to bring that in um I don’t know the answer off the top of my head for that one right now Paddy I’m not sure if you know um if not we will find out and get you an answer on that yeah other other than the the platform mapper which you could actually uh specify um the new platform and map that to the schema around sort of uh the the additional the attributes that we have already um if that was possible and if you can run I guess CLI commands to be able to to pull that data and if it’s coming back in in a in a format that’s structured

and you’re going to be able to pull it out then I think we should be able to support that um but like if it’s like any other um Network operating system we should be able to extend and support that if it’s if if it’s over the API that’s going to be different and that would be a a more specific extension that we’d need to build yes yep okay uh next question uh is there a way to customize existing models and then um then how would I then I I think the question so basically is there a way to uh to customize existing models so uh short answer is yes uh you

can add a custom field and a custom relationship directly within the UI of Nautobot to any table in the database um so you can very easily extend those tables beyond what they have out of the box so absolutely no problem uh and then I think your question then was getting at like hey if I did that um is that going to cause me any problems when I do an an upgrade or an update um and no so long as you do it through the UI you add those custom fields or custom relationships you have a lot of flexibility there and you can think of those even though we use

the word you can think of them as extensions right like you’re just extending the model um as well as those relationships in the database uh so there’s not going to be any impact if you do an upgrade no problem at all uh the next one uh if we want to have a customized command in the on boarding app uh how could we do that uh so basically you know I want I want to be able to uh say um do some modification to the data as part of that onboarding uh you know or or add some additional component that maybe isn’t there you know can I extend the the apps to do

things beyond what they do out of the box yeah and as mentioned before that the platform Apper is going to do that and it has the capability to extend it as well um and what you do is you use a yammo file so if there is also a a platform that’s already supported if you take for example Cisco iOS if you uh it gives you the option to sync in a new um Cisco iros yo file and then you would extend that file uh and then the git data source would be the one that’s preferred so it giving you the option to basically uh create your own uh and so that’s how You’

probably go around that you all have been asking lots of questions greatly appreciate it uh here we go we got 11 more minutes let’s see what we can get through uh does Nautobot or can Nautobot have the capability to do a link layer discovery of generic devices such as IP cameras or whatever things that are connected to a switch or a router uh so Nautobot have the capability to use uh CDP or lldp information uh beyond that as far as discovery of those devices I’m not sure what our platform capabilities would be there so py I will I will PIV it over to

you for any yeah that’s going to be custom I mean if it’s something that we can do if if it can be reached VI um IP and we can SSH onto it and it has that capability then it’s it’s um extendable within the device on boarding to create your own platform for that um so uh it depends on the uh the platform I guess in in terms of getting access to it yep uh this one here is kind of an open-ended question it’s about you know how data governance um basically how can I use Nautobot to um make sure that I have good data Beyond just the things that we mentioned

today is say data validation then data Integrity engines within the platform uh and I I think I’m not sure exactly what you’re getting at here um Pedro but it could be what I can imagine the question around is like who can change data uh do we have a history or a record of those changes uh as well as perhaps um maybe who owns a piece of data you know and and how is that attached to perhaps some policy uh So within the framework um you do have a lot of flexibility in how you can leverage it um you can also potentially use the python aspects of Nautobot

to write your own custom business logic into the way that you do that data validation and data Integrity but around the concepts of like who owns the data absolutely you can uh specify those various fields and who they belong to you do have the capability to integrate Nautobot with your single Source uh single sign on um and therefore having those arback controls so you can have a lot of flexibility of far as who owns data and who can uh change data and even who can see it um you have that capability within the platform to uh make those specifications

so there was fair a fair amount of flexibility there um Paddy feel free if you have any additional comments no oh good cool okay so we use the uh single source of Truth app and integration with info import ipam data from infobox and Nautobot great then we follow up with uh we have some issues because of custom config on infobox that is their extensible attributes and Nautobot custom fields and trying to map those and create the mapping between those um and they’ve had to modify the single source of Truth plugin to do this um is is there any way around

that uh you know as far as like should we really be needing to modify the single source of Truth app or is there a better way well I mean it depends what you want to do with them really there is is the within the app you can actually exclude them if you wanted to do that because sometimes the data that’s there um you don’t want to have um but if you wanted to do something with it the the best way to do it is to extend the app um because of the fact that you have full control then when you’re talking about any of the the crud operations and you can

Implement your own logic um and if that’s something that’s a one-time thing though um maybe you want to look at sort of uh exporting it may like if you if you just do a one-time export from info blocks and sort of um build that straight into the source of Truth um that might be an easier way rather than uh constantly syncing it the idea with ssot is that you’re going to constantly sync from one source to another so sometimes we’ve seen with customers that they’re using the extensible attributes um more using info block specifically more as a source of

Truth by using these extens ible attributes um but then once you start to use Nautobot you should have the native data models to be able to support a lot of the things that you’re doing within infol blocks so what we’ve seen before would be that they wanted to get rid of all of the external attributes um which is why we have that exclusion uh filter which you can handle from within the application and then you best way to do that is just a onetime export basically uh import them into the the correct models on the Nautobot side and then from there on

then all you’re syncing across from info blocks is whatever the data that you need I the IP addresses vlans and prefixes got it uh do we have the capability to onboard devices from controllers so whether that’s dck or paal’s Panorama or arista’s uh Cloud Vision uh can we import from those controllers rather than directly from the device we would have to extend device on boarding to do that uh the driver right now now would be using U net Meo uh under the hood to basically do SSH onto the device it doesn’t mean that it can’t be into an API but it would

need to be built so my guess is uh it would be best to sort of bring in U Professional Services to do that um because that would require some driver additions for the device on boarding um we have done it before um for different platforms um that had uh API support but it really depend on what controller that we’re talking about yep uh Paddy you mentioned uh Netmiko and this question was hey I thought SSH to use Napalm with Nornir not Netmiko yeah it used both actually it used to use Napalm at the start I think and it was just sort of backwards

compatibility things that we’re trying to maintain there um so some of the platforms then uh there’s a little bit more support on Netmiko um for some of the platforms whereas Napalm was um a little bit more restricted in terms of the platforms that are supported um so let’s say I have a list of devices in CSV format um it’s only got the IP addresses um can we use one of the or can we use some form of the device on boarding app to then uh fetch all the rest of the data uh so basically can I load from CSV and then take advantage of device on boarding to

get the rest of the data can you load from CSV into into Nautobot um all you need really to get device on boarding going is um a location to assign a device to a location and then an IP address so once you do that um that’s all you need to start loading in the rest of the data which would be anything from interfaces vlans vrfs um that the device on boarding will give you and then also the platforms manufacturer and stuff like that so uh I think the answer is yes as in as long as you have an IP address uh you’re good to go yeah uh I think also if you

think about this right the way that the uh onboarding is broken into two different jobs um you could in theory load uh those devices into Nautobot via CSV and then run the second Nautobot job to go collect uh configuration information about those devices sure that that would absolutely work Y and then of course with the onboarding you would have you can specify if you’re adding uh all the devices into one site you can specify the IP address as a comma separated list so if I you’ve had multiple IP addresses you can do it all in once if they’re all going

into the same site um so it makes it a little bit easier then if you have uh multiple devices to be discovered yep uh this is someone doing some of their own custom Nautobot uh app creation this is they’ve written their own uh ssot uh app and to to do data uh on boarding and they’re wondering can they leverage some of the underlying jobs that device boarding has um and the short answer is yes absolutely uh the the world is literally your oyster when it comes to Nautobot um you can absolutely interface with those other existing jobs um you would just

need to install the apps so those jobs get installed um and then you could leverage them from your own custom app sure no problem yeah absolutely um although of course we would ask why are you creating your own ssot app when we’ve got one for you but um hey maybe that’s works better for you so no problem there uh let’s see couple other questions here these are kind of like development uh questions so one was just like uh could you talk a little bit about kind of the development environment for creating applications or jobs like say with pycharm or some

other ID like you know do I need more than that is am I do I just install py charm and get going any any comments there yeah and I think there’s a developer guide on the Nautobot uh uh documentation which goes through a lot of it um we also have a lot of blogs on how to do it um and it’s it’s for the most part I don’t think it it tackles py charm specifically vs code is the sort of the uh I guess the de facto in terms of what we use within Network code um but it some of the guys also use py charm but in terms of getting set up yeah once you pull down

the REO once you basically um uh pull down the git repo and then you can uh open it up in your editor and you can start to work on a particular Branch then um yeah it’s it’s from your perspective then if you’re using Docker then you just map that back into your Docker container and uh you can spin up your own instance and test it locally yeah absolutely uh question here but about you know like future updates maybe to the single source of Truth app in this specific case hey you know about like more flexibility in data mapping those kinds of things but

this is true in general my answer that I’m about to give you which is um come participate with us in the community um in the uh GitHub in the repos you can join there you can uh open feature requests as well as uh interact with us we’re always looking for input back from the community so if you have specific example of a feature that you’d like to see um added or something updated or changed whether it’s a single source of trath or any other um please engage with us we want to hear your inputs we’re happy to get you uh and try to implement those as we

move forward in our roadmap so um short answer is come engage with us we’d love to uh see how we can help and what updates you know ideas you might have others may be looking for as well so please let us know uh okay we got time for a couple more questions here um perhaps let me see if I can find uh a couple that might be useful uh so what if I modify existing models directly in the source code please don’t do that that’s a really bad idea um you are going to go down a train where now you’ve essentially branched or forked from us um that that’s not the

appropriate way to make those sorts of changes um paddy just real quick I think you had mentioned it earlier I think it’s going to be the same answer um just how should I do that as opposed to say going and modifying in the source code you just if it’s specifically on uh well from an app perspective you just create your own app right if you want to do something right uh but if there’s something within device on boarding specifically it has the ability to extend the application by creating your own module and mapping that to a specific platform okay and

again that’s well documented on the uh the uh documentation site um but as Tim said you wouldn’t you wouldn’t um update the the specific code you would create your own extension and then uh build that extension back into um build that extension back into your environment Y and I apologize I know there are a few more questions that we did not have time to get to we will try to get you we will get you those answers to those um here in a follow-up after the webinar um but we are at times so we want to be respectful of folks time uh just a quick recap hey

we went through the methods of population here today looked at the device on boarding 4.0 app the single source of Truth app and then covered briefly other methods that you might put data into Nautobot please don’t forget about the 100 days of Nautobot if you have haven’t joined there is still time uh we have completed the first segment and we’re now into the second but you can join at any point you can start wherever you like you can start on the first segment the second segment whatever makes sense for you um please do participate with us this is

great um and if you are participating let us know on LinkedIn um it’s great for us to know who’s actually benefiting from this uh project um it’s a great chance to interact with uh erow here at NTC uh thanks again for attending here’s links to all things Nautobot and always if you’re interested in a one-on-one demo please do reach out to us the sales team and the sales Engineers would be happy to engage with you and take you through how Nautobot can change the way you operate your network thanks and we’ll see you on the next webinar