The New Device Onboarding 4.0

hello everybody good to see people streaming in we’ll give it a few more minutes for people to come in and it’s great to see everybody here wow the room is filling up it’s awesome e okay cool well it’s good to see everybody here I think we’ll we’ll just get started um for today we’re going to talk about device onboarding I’m very excited to see this presentation because there’s something that we worked on for for a while and um you know everybody spent a lot of time in it we today we have Jeff that to do the presentation to go deep dive

so um I’m very excited to present this so next slide please Jeff So today we’re going to do some introduction we’re going to mention a little bit about the challenge of the device onboarding including manual entering the information which everybody hates importing C CSV files and you know and why we’re we feel there’s a need to do uh to refresh the device onboarding application how we’re leveraging the uh you know source of Truth jobs so we you know we don’t reinvent the wheels and we’re actually G to do a live demo for how it it works uh the

Q&A so one thing I do want to mention is the chat option is disabled so uh we’re going to have uh a Q&A SE uh Q&A time at the end so please type in your questions in the Q&A section and we’ll go over them toward the end um and of course after that we will you know do our conclusion and uh some of the next steps that people could take if they’re interested in learning more about either Network to code the social truth or uh various application we have including the device on boarding jobs

next slide again my name is Eric Chow Network automation Advocate at Network to code and I’m gonna pass the mic on to Jeff for him to introduce himself and take it from here thanks Eric my name is Jeff Kala I’m a principal architect at Network to Code a little bit of background about myself was a network engineer for years and years uh worked at large ISP worked at a few Enterprises and kind of got into automation over over time and fell in love with it and came over to network to code to uh just continue my adoption and my own Journey

so uh we’re going to start with some of the challenges um of device onboarding and what other options there kind of the solutions that have been up till this point and we’ll we’ll kind of continue down the road and get to a demo so we’re going to start here with some of the common methods and challenges that exist today um to populate data into Nautobot so very first one uh Eric had already mentioned it manual entry that one is the least desirable method to populate Nautobot uh it’s very prone to human error requires immense effort at scale

so yes it works relatively well for a local Dev environment as you go higher in your uh environment Lanes becomes nearly impossible to get right and to scale next up uh CSV Imports so CSV Imports are a valid way to populate Nautobot um but it comes with its own challenge one of those challenges being you have to have the data already uh whether that’s existing in a standalone spreadsheet that already exist in the Enterprise or maybe you have some other tools that are capable of outputting some csvs of of their own and then you’re translating

those csvs from its output format to what Nautobot requires and there’s some work there that needs to be done in order for that to really be able to scale and to get you uh to your end point uh third one there is device onboarding so today we’re talking about device onboarding for .0 uh device onboarding 123 has been around since the Inception of Nautobot it’s served a very important uh focused Point um and it provided enough functionality to dynamically get information into Nautobot it was just limited to basic details

so what we’re going to talk about today is how we transformed the app when it we went to Ford auto and talk about how much further we taken the application so previously uh we usually recommended you use device onboarding first and then if you needed more metadata on your devices you went to another Standalone python Library called Network importer uh Network importer was uh a very useful tool um but it had some external dependencies which kind of made the implementation difficult it was time consuming it required additional infrastructure

so all those those were kind of some common methods and some challenges with with the existing methods that exist today let’s go into a little bit more detail on some of those challenges and limitations of the methods that I just talked about so previous Solutions were very difficult to extend new platforms and attributes um that was due to a multitude of things um the original device onboarding was very strict and rigid to what it was capable of doing it provided a very flexible extension framework but you had to be pretty Advanced uh I would

say intermediate to Advanced in your python skills to be able to really utilize it and harness its full potential uh some of the other ones like Network importer um which relied on batfish that had some of its own challenges on adding new platforms but on top of platforms uh just general functionality right batfish is a super powerful tool I’m a big uh lover of it myself but the fact that it wasn’t capable of doing IPv6 has you know caused issues in the past with you wanted to import IPv6 data and then kind of generally touched on it external

dependencies can cause additional delays that we just need to avoid when we’re trying to get up and going in our automation Journey so this one’s specifically more towards batfish batfish has a requirement of Docker and what we’ve really noticed with large Enterprises not every Enterprise is okay with Docker maybe containers are allowed but they may delay um essentially the operationalizing that solution so I’m going to move on to ENT device onboarding 4.0 super excited to talk through uh what we did with the app and how we’ve made it

extendable and just generally how how useful it’s going to be so I’m going to start with um some personas so device on boarding 4.0 benefits extend to everyone uh that’s from seasoned Engineers all the way to your leadership so for engineers device onboarding uh the new app offers a streamline process to make it easier than ever to onboard new device into Nautobot um the update significant significantly reduces manual work simplified extensions and the application support custom attributes and gives you the ability to add additional platforms

relatively easily for leadership this version uh dramatically shortens project timelines by simplifying onboarding process so it enables you to start de deploying faster get your quicker return on investments and reduce complexities and operational overhead and now we go kind of towards the other side of the personas you have your users so new users they’ll find the new application uh Ford auto the ease of use and its intuitive out of the boox functionality to be really easy to use and what we really wanted it to to be is no need for complex

customizations a new user should be able to go right in even if they’re not familiar with the platform and be able to onboard devices and finally if we move into your experienced users they’re going to appreciate the item potent Discovery feature you can rerun this over and over again on your equipment and it’s only going to update what it needs to update it’s reliable it’s repeatable there’s no side effects and again the lack of external dependencies make it easier to maintain manage and control um across the fleet

so next I’m going to jump into the actual process itself so 4.0 offers two new ssot based jobs um so if you’re not familiar with ssot uh that’s single source of Truth we have a framework built in another Nautobot application that’s capable of diffing two different systems data uh so we’re utilizing that and all the all the great functionality that comes with uh natively so to talk through the two jobs uh the devices from network is now mimicking what the original onboarding job did in this application the purpose of it is to get the initial

basic data set and inventory item added into Nautobot it add its things like device name device type your management IP and interface your platforms and your manufacturers it does that automatically one cool thing to note on the sync device from Network we do still support an auto detect functionality so perhaps you have an IP address you know it’s in network element but you’re unsure what the platform even is maybe it’s been there a while uh you don’t have your context data to know uh it it is capable of going in using nmo autod detect to

figure out what platform it is but I do want to mention um if you know what your platforms are you can skip that by providing a platform when you run the job and that speeds up the actual functionality uh quite a bit uh the second job is sync network data from Network um little play you know a little bit hard to say that one but uh this is your job that’s starting to mimic what your network importer used to do so it gives you all that metadata that you were craving it’s in the same application

now right right next to your onboarding task and this one is giving you much more detail uh this one’s capable of syncing in all interfaces metadata for all your interfaces MTU Mo description status Etc um but also has the ability to toggle more data on or off in your job so maybe you want to sync in your vlines uh you care about vrfs and the mappings those have and potentially even the fact that you want your cabling so it’s very robust um and again it mimics what network importer used to do it just gets rid of the dependency and puts it right

in the same application so I’m going to touch on that a little bit further kind of in the two steps to complete onboarding so again the two jobs that exist today are sync devices from Network and sync network data from Network and you’re the anticipation is you will always run both of these um the first job you run again kind of provides you that base requirement to be able to manage the device from Nautobot um it’s a very a very great initial first step gives you foundational data um and most importantly uh you have

now you have device presence in the system so one thing I kind of want to mention here is there may be valid use cases where this is where you stop perhaps it’s a device that you want to know your inventory and you only care about the basic information maybe you need to be able to log in take a backup but you don’t have or you don’t actually maintain ownership of that device and maybe that’s where you want to stop you don’t need all that additional metadata but if you do um that’s where step two comes in

so sync network data from Network kind of Builds on top of that now we have devices in the system and now we’re actually saying now I want to go out and get the rest of the data that you’re capable of getting again interfaces IP addresses VFS cabling Etc down the line so one thing I’ll bring up with the second job is it does allow you to do some data population in a strategic and iterative way meaning maybe you want to start with just interfaces and and their characteristics but you don’t need VLAN data you don’t need cabling quite yet you

haven’t figured out a workflow for those yet and you prefer to wait on those the second job gives you that ability to toggle on those features so if if you don’t want to syn in vlans you just un toogle that feature you won’t syn in vlans but maybe down the line in a year you decide you want to do some automation with vlans you could come back rerun the job sync in the vlans and you’re you got an immediate quick win to be able to start doing some automated workflows

so my favorite slide uh how it works this will a little bit more technical um in nature but I want I find it important um I think we all know how it’s made Net TV show and and I’m a nerd so that I like that type of thing so how it works in general uh both ssot jobs that I just talked about follow the same pattern the only difference is how Nornir handles the inventory creation so besides that that’s the only different so upon executing one of these jobs the Nautobot job creates a Nornir inventory and loads in all the requ yaml definition files

so I’ll talk a little bit about the yaml definition files in my demo just around kind of the DSL we built around those um and what those Define is the commands that we are requiring that M to run or noret M if you if you want to be specific so we do a d duplication process make sure we’re not running the same exact command multiple times we run the commands and we uh pass back the raw data so the next thing that that yamel definition file does is tells you what type of parser you want to use

so in this example on the screen it’s using text FSM that’s going to translate that raw output and transform it into Json data that we can now uh parse out so here’s a really kind of interesting part of how this is working um there’s a transform function to extract the data from the Json based on JMESPath so if you’re not familiar with JMESPath JMESPath allows you to build an annotation uh and query to be able to say for this entire Json structure this is the data I care about and I need to extract this data we took that a little bit further

we’re using uh ntc’s Library called jdiff which has our own implementation in James uh James path and what that is going to allow us to do is get the exact piece of data we care about per command per kind of schema definition so one thing I want to make sure I mention here is that capability of Ginger to So within your yaml definition you have your own context data that you can actually render so you can see here in this example in that JMESPath we have IP address equal equal and then obj obj actually gets rendered into that original IP address

that you put in the job form uh we have a couple other uh deeper extensions to this um that I will talk about later uh in My Demo but I just gives you that powerful way to to Really extract exactly what you want from the uh from the Json data so finally I’ll mention you’ll see the postprocessor there we use uh JMESPath we got the data we need but maybe we there’s some more processing we need to do there uh the postprocessor allows you for that final data extraction and do one last transformation of that data before you pass it to the ssot

engine so once we have parsed all the commands each one of those iterations runs through we get an output uh similar to what you see in number seven there just a Json payload with everything extracted and that’s where we hand it to the Nautobot ssot framework to diff against the current objects in Nautobot and then that determines what needs to be created updated and deleted and in my demo I’ll show you kind of that diff view that the ssot framework uh provides which is really great to see

so now let’s talk about kind of the biggest challenge of 4.0 um was we wanted to make this as extensible as possible we understand not every customer customer only has Cisco not every customer only has Juniper um multivendor networks essentially at this point are are the norm so we wanted to to be able to provide an easy way to extend this to new platforms where the only thing you need is a yaml file so that DSL that we built all you need to do is if you can divine define a yaml file you know the commands you need to run and you can verse those

out and transform them into the uh data attribute that you need um the rest of the application will will run that in and it’ll continue to work so adding support for a new platform is as easy as creating a yam file with that Network driver um naming so it could be Aruba uh AOS yaml um and then it knows we basically just added that support for that new platform so the last thing I’ll mention here is we wanted the flexibility to be able to extend the application just via uh basically creating one yo file we also wanted the customization and

flexibility to be there where you don’t have to Fork it and put the code right into the code base and then redeploy your application so what we did is we’re allowing you to actually create those yo files using the Nautobot core git data source functionality so we added a new provides method there where you can actually say this git repository is providing these command mappers and when that exists uh the application itself goes and looks for those pulls those in and just assumes um these are these are the uh highest weight

so I’m going to use this file over what the native app supports so this is great for adding new platforms but it’s also great if you just have some business logic that you need to implement in one of ours so you could copy and paste the Cisco iOS yo file and maybe your business requirements are all host names must be uppercase so you can actually add some of that logic into your postprocessor and so that when you run onboarding it will automatically do some of your business logic which is very very valuable

so that’s how you extend for new platforms uh next I’m going to talk about kind of new attributes so what if it’s something brand new you want to sync in um I’m going to give the example of software information because we’re already kind of working on this in the back end um maybe you want you’re already logging into the devices you’re already running show version I want to get that software version from that device and Sy it directly into the Nautobot core models for for software

so that that involves a little bit more you still need to add your attributes to your yaml definition file but this one would require some updates to the actual application just simply because dsync and ssot are used you have to create those models you have to update some of the Json schema and yaml definitions that that the application is expecting just to validate that the data is accurate so there is 100% you know uh path forward for new attributes it is a little bit more complicated than just a simple yo file but the overall Frameworks in

use here are used across many of the Nautobot open source application so we find it very uh user friendly to be able to add this support so um let’s get into the demo and this part I’m very excited for so um to start off I have a very simple lab uh you have a uh Arista router you have an iOS switch you have an iOS XE router um that’s all I’m doing here obviously this can extend to hundreds of of devices at the same time but for my labs purposes that’s what I have

so I’m going to start I’m showing you my Nautobot this is for this webinar I’m just going to refresh to prove I have no device types I have no devices nothing is in here um except for two pieces of required data those are location the onboarding tool needs to know okay you want me to onboard this device what location does it go to and the second piece of information required is a Secrets group how do I log into the device I need the credentials other than that I have nothing else in this instance besides some change logs from some testing I did

before so the second piece I want to just jump to quickly is just to make sure everyone realizes that you can actually access these jobs in two ways uh from the jobs menu you can go to jobs and you can see these two they’re under the device onboarding tab um and just to show the other view in case you’re used to seeing it in tiles and tiles you can see they are located right here the second place you can access these because they are using the SSL framework is literally via the single source of Truth dashboard

so you can see here here’s my dashboard I purposely ran some just to you know have the dashboard looking nice and green um it gives you the history of executions and that’s kind of where we’re going to start today so I’m going to go uh over to my job results just to speed this up a little bit and I’m going to just prep my sync devices from Network so as I mentioned earlier in the slide this is essentially step one um and this is what the job inputs look like

so what do I have to select I need to select the location name space so again this is syncing in uh for this job management IP address it needs to understand where does this IP address live what name space could provide a common separated list of ips so these are the management IPS of these devices that I showed um and just to quickly jump to it we do offer CSV file input as well so if you don’t want to do this like this you can prep a CSV file and do a bulk on boarding of everything you have um just as easily give it a few pieces of metadata

around the connection and then we’re basically all of these here are just selecting default statuses default roles for things you want to that you’re adding in so for this case I have a device roll called Network that I’m plugging everything into for now my default statuses are here so again because we’re creating all these objects in Nautobot they all require statuses we just want to understand what do you want to build them out as so again may maybe for you it’s always going to be planned or staged until you actually do a production migration

Etc last piece here Secrets group how what credentials do I use to connect and I mentioned it before a platform you can select it speeds up because it doesn’t have to do auto detect but because I have a mixed bag here I’m just going to use autod detect so it automatically detects all three of these platforms since all three of them are different and it will create everything I need so I’m going to run the job as this job runs you’ll see there’s some pretty good logging that’s going to start showing up it’s loading in those yaml definitions

files it’s autod detecting the platforms based on those it’s going to determine what commands I need to run it’s going to run the commands it’s going to parse out the data it’s going to pass that Json data to the ssot framework and once that is completed uh we’ll have a very nice ssot sync details view of what it did um and the devices will be in there so you can see here it is taking about a minute um to uh to do this but it should be finished in just one second and while this finishes up you’ll see here kind of tells you quickly what commands

it ran what host it was running on um and gives you some some good details here so I’m going to run over to the ssot sync details this is a great view this comes native in the single source of Truth application you’ll see here if I scroll down we now have a diff of everything that this job added to Nautobot it added devices it added everything that we expected it to add and you’ll see it even added platforms device types manufacturers all this is directly off the device based on how we’re parsing the data

so I’m going to go ahead and just for for the sake of it here I’m going to actually rerun that same job while I go and show the outputs so this is just to show that item potent nature I change nothing on the network I can rerun this as many times as I want and there’s going to be no issues so if I quickly just while that’s running again I go to devices you’ll see now I have my three devices these are the exact host names off the devices management IP was set set to the location it created the device types it assigned the right statuses and if

we go into one of these you will see it also does have seral number uh it assigns the secret group which is very nice so further automations you don’t have to redo that and then finally you’ll see it did determine the correct management interface assign the IP address to it and based on the actual status of the interface set the proper enabled state so if I hop back over to my job results you’ll see it ran again this time if I go to the sync details no creates no updates no deletes this is perfect that’s item potent that’s what we want

so that proves that functional functionality out so if I go back to my homepage just to show now you can see got my devices device types prefixes so that’s one thing I didn’t show is we also created the IP addresses but because Nautobot in the newer versions requires a prefix when you create IP addresses it’s also smart enough to understand I actually need to create the prefix as well so next let’s go into the second job so I go back quickly let’s run sync network data

now you’ll see the job inputs for this are are pretty similar here’s those toggleable options to give you that iterative approach say you don’t want to do cables um you’re not quite ready for um sync in vrfs or VLS you can uncheck these I’m going to leave them all checked for the sake of time we’re going to sync in everything again some default statuses some default name spaces that any IP address you want to uh create goes into and then these bottom selections are essentially a filter what devices or location or role do you want to run this on

so this is one piece that’s a little bit different than regular ssot based applications that we have where it does it on everything we allow you to filter a bit to be able to be a little bit more uh explicit so I’m going to run this you’re going to notice this job is quite a bit faster and that’s simply because there is no more auto detect needed it knows the platform it knows what drivers it needs to use to connect to and because of that it’s much faster um Gathering the data

so again job results look pretty similar but this is the awesome part we had 60 create seven updates so you might be thinking what kind of updates would be needed you start pi ing when we initially onboarded we only cared about the IP address on our management interface now we’re adding more detail Mac address MTU Etc so you can start seeing these are the vrfs created we created cables we created vlans we’re smart enough in the backend logic to be able to assign uh lag interfaces based on what was in the configuration assign the vrf to the

interface and even do Tagg and untag vlans which was probably the most challenging part of this effort so if I go back now to the devices you’ll see these look the same if I go back to that device I was at before I now have four interfaces um all my gigabit Ethernet are here enabled as properly set whether shut or no shut was on the device and you’ll see if that had an IP address it configured it even better this one here realized that oh I can actually create a cable I know side a I know side B I’m going to go ahead and create the cable

between the two devices um I’ll quickly hop [Music] into the vlans so you can see here vlans were all created the names were created successfully VFS were created if you clue into those it gives you some details about where those exist what devices they’re on so that’s a just a awesome ability to be able to quickly get your devices onboarded and then onboard it plus get all that additional metadata that allows you to start generating configuration start doing some automated workflows

so that was my demo from the Nautobot perspective um I’m going to quickly jump into code so again we wanted to make this a little bit more technical of a webinar and we just wanted to demonstrate quickly that yaml definition file what does it look like so you can see here um at the root of each of the you’re going to see the name of the actual job that it’s for so sync devices that one’s for the sync device job sync network data that’s for the syn network data part and the way that we wrote this was essentially we are creating the Json schema

based on these root um variables so the finalized data for this will actually be a Json blob the key will be host name the value will be based off of what was pared out down the line uh so that’s very valuable just in the sense of we can start doing some Json schema validations to make sure the data that was extracted is actually following the right schema that ssot is expecting so again here I’m just showing you the capabilities of right now text FSM is the only parser we support where we’re going to add TTP probably Pats a few others um to be

able to take that raw data transform it to Json so that you can extract it we can start seeing some of the flexibility here um as far as the JMESPath goes and then even more so as far as the post-processor goes you can start doing things like using your Ginger filtering to start saying I’m going to get back a list of of X I just want these to be unique and give me the first entry um or you can do more C uh you know more customized things like flatten lists create your own Ginger filters very powerful that way um last thing I just wanted to show

you here is an example where you might have native support for structured data from the CLI of one of these devices so you can see here in our in our Juniper example we’re actually setting the parser To None um and this is because Juniper gives you a pipe display Json functionality that we can actually get back structured data directly from the box and now we don’t need to use text FSM or another parsing engine to uh translate that data and again you can see you have your JMESPath how do you get the data you care about out of that output um and

then post processors for doing anything much more difficult than that so um that’s about all I wanted to cover so uh I have one more thing I just want to show you but while I’m doing that if you have any questions that you want to start asking in the channel That would be great to get a head of the game and start throwing those in and we’ll cover those shortly so the last piece I wanted to quickly cover was just the fact that you can sync these in from a git repository

so I’m not going to do the whole uh thing but I do want to just show you how easy that can be so from git you can add a git repository and the one thing you’re going to notice is these are all the same as as the core application I just wanted to quickly show you the network sync job command map that’s where you would select your provides method so this is how the application itself knows okay I’m going to look through my get repositories if one of them is providing more command mappers I’m going to sync those into the application and I’m going

to uh trust those over what was natively provided in the application itself so that’s it for the demo uh hope you enjoyed it as much as I did and we’ll kind of hand it back to Eric and we’ll start going over any questions that uh came up in the Q&A section thanks Jeff that was awesome um I laughed a little bit because when you say Hey you know get ahead of the game because a ton of question has already popped up and I hope we can answer all of them if we don’t you know please feel free to join ntc’s sock Channel we all you know we’re all there

we’re monitoring we’re constantly uh looking for you know uh questions to answer so let’s let’s get to it um I did take a peek at the existing questions and I know there was a lot that was about extensibility hopefully you know you guys all saw Jeff’s uh you know explanation on how to extend different platforms for the standardized way that we borrow from ssot jobs uh there’s a lot of questions about supportability and you know thank you Tim for answering those quickly uh

so and you could you could get list of that off our uh GitHub repository and the Very expending and you could also add to your as Jeff had mentioned for extensibility so let me go ahead and uh take a look at these questions I’ll go ahead and uh you know run them down as sequential so as they typed in so the first question is from uh Andre say is NTC discontin the supportability for Network importer altogether and will it be deprecated in time continue to grow and be improved in GitHub

so did you want to take that real quick Jeff sure support network importer was never actually upgraded to support uh Nautobot 4 2.0 and that was simply because we knew this refactor that we talked about today was coming um as far as supportability uh we do still have maintainers on the project itself um but I wouldn’t consider it uh to be a lie for you know for the future I think the future is device onboarding 4.0 um it’s solving a lot of the problems that existed with network importer in general but if there’s a specific thing that you’re

trying to get out of network importer I would still suggest you put in issues on the repo we do like I said have maintainers on the repo the project is still alive from Network to Code’s perspective so would love to just understand uh maybe why device onboarding 4.0 doesn’t doesn’t do what you want it to do and why you’re looking at Network importer to solve some other problems cool the next question is uh presumably sync network data from network works across all platforms um I assume that means you know the supported platforms that we have

yeah so we have a support Matrix um on the repo itself that covers all this so as of today the the second job sync network uh data does work for everything uh that we support except for wlc um that’s a kind of a TBD on on when we get to it but uh Cisco wlc is currently the only one that doesn’t support um the entire functionality of sync network data the other piece of that is We are continuing to add different attributes so I showed in My Demo cabling cabling has been added only for Cisco

so far uh we’re working on Arista and EOS but like I said we have a supportability matrix on the actual GitHub repository where it has green check marks you know red x’s and then even a test tube on things like cabling where we’ve been able to implement it but Network to Code doesn’t have a huge Fleet of network gear to test every use case so uh we kind of Mark it as test tube in order to let people know like we we would love you to use it provide feedback um and you know uh put in bug issues that you might that you may find

yeah that’s a good point you know we’re taking contributions from the community that’s for sure and and you know it is a is a community project and you know with our as being a sponsor so we do want to rely on you know the community to help improve it um the next I’ll add to that Eric sorry to interrupt I mentioned how you can extend this and add new platform support via get reposting that is a no way to discourage contributors to say creating a new platform internally it works great you’re loading it in from git put in a poll request we we

love Community contributions and getting more and more platform support to the community will just Harden the project and make the application stronger absolutely so next question is for sdn environment do you support collection comparative information about VX land with mp bgp uh evpn so I think that’s goes into that supportability Matrix right and adding more uh features yeah so that one’s actually a little bit extending upon that in the fact that we don’t currently have data models in Nautobot core to support vxlan uh data modeling and kind

of modeling those uh we’re working on that already uh in the back end but as soon as that existed and the data models exist it would follow that exact slide of new attributes that I talked about where you might have to do a little bit of work with some ssot models but the framework is there and it’s powerful and adding that support should be pretty easy excuse me should be pretty easy nice um I think the next question would kind of answered it but we just go over quickly is the pluging extensible as in kind use my own Netmiko nap drivers to get

the information from the device yeah so there would be ways to um adopt that so as of today the 4.0 is using noret M um we’re doing a little bit of Magic on the first um job and that’s simply because like I mentioned the only difference between the two jobs is how Nornir inventory gets created for the first job because there actually is no source of information to create an inventory we’re doing an empty Nornir inventory and creating that inventory on demand

so there’s a little bit less flexibility today to use your own driver for that but for the second job we’re actually using um Nautobot plugin Nornir which is like what golden config uses in a few of our other applications that one has all that already built in to be able to say I want to use this framework instead and I need to uh pass in these extra variables to net M or Napalm so I would say uh it’s partially supported we know we’re going to get there with kind of that first job the sync devices being more flexible and how we’re creating that

kind of initialization of Nornir but that was a very large challenge was how we create an inventory when we don’t have anything to create the inventory off of except for what somebody put in the job inputs so that’s still a challenge we need to you know fully solve yeah I kind of take that as a as a cue to you know kind of provide more example on how to extend it you know like vendor X how do we go from you know nothing to over so I’ll take that as a kind of a to-do item for for future maybe we could do something about that in the uh you know

documentation so the next question is can I use divide onboarding 4.0 for devices that already are in Nautobot that may not have all the you know the second job right essentially the interface VLAN caos Etc cool Jeff yes you can and like I said um I didn’t demonstrate it today but those jobs I ran have a dry run feature so if you’re a little nervous about it click on dry run it gives you that same ssot detailed sync View and then it just doesn’t actually Implement them into the database

so should it work out of the box yes um and obviously there’s probably a couple it depends in there around making sure that it can actually relate that device you’re onboarding to the device that exists it should if you have the same device host name and like serial number those are kind of the uniqueness identifiers we’re using but yes it should work and then kind of stage two to that is if you want to make sure it works before touching your data run the jobs and dry run and just see what it would do um and then when you feel confident run it

again and unselect that checkbox yeah that’s a good point we didn’t we didn’t actually show I mean we kind of it’s on the screen but you know we never just for the sake of time you know but you could do a dry run to get a a more confidence in your job beforehand so I don’t you know I’m going to read off the next question I don’t really you know understand it but maybe you could give me maybe you know you understand a little bit better so how how to configure the yamamo file to get information directly from R API

yeah okay so um yeah it’s a good point everything we showed today was CLI based right log into the device via SSH run a command parse it um there’s no reason you can’t use another Nornir or Napalm driver that is already doing API based um calls but in general uh we do have plans to create kind of a called a generic uh API getter which would the entire framework here is built to support that uh we just haven’t quite had that use case yet to build for but essentially all you would really need to build out is that Nornir I’ll say nor net moo but

really it should be Nornir maybe a a rest API uh driver that’s capable of doing that but yes the rest of the framework would actually uh should need no changes as far as the rest of the framework work so yeah that would be a great one if you have some ideas uh Community contribution would be awesome but we do have some uh some plans on the backlog to introduce that got it cool thanks Jeff uh next question namespace is some kind of modeling multi-tenant

yeah Nam space is a Nautobot core functionality now um and that’s to be able to start dictating uh where you’re allowed to have unique IPS uh whether duplicates are allowed that type of thing so uh if you need more information on namespaces in general and maybe our entire ipam and how we have it implemented uh docs. Nautobot.com you can go to the ipam module and we explain name spaces very uh very well there so I would uh recommend you check out our docs page for that

yeah it’s more like a I pimp thing uh than than device onboarding but cool yeah exactly yeah so can the feel taking some like a range like a prefix of you know 10 or maybe not a prefix it’s specific question asking for uh say like 0 to 10 for the last octed 0 to eight that sort of stuff yeah we we don’t have that today um that that’s going to be probably a pretty quick turnaround for that um we’re not intending this to be a discovery tool I’ll say yet um there’s no you know end map syncing or end map scanning yet

so if you were to do that we would kind of anticipate one through 10 are all actually management IPS that are accessible obviously we have exception handling Etc built in where if it fails to connect it just doesn’t do anything but uh yeah today it’s comma separated uh actual IPS and again most likely if you have more than 5 10 devices you’re going to go with that CSV uh functionality where you can build out a CSV file and just give it to the job and it just reads off of that for everything it needs got it

so do CSV imported device support individual device types designated designations or is it one device type for each job no uh if you do CSV file import you have the ability to identify all of those job inputs on a per device uh I’ll say Row for your C D which again that’s what really makes it powerful and that’s really where you start getting into I know what this platform is I’m going to provide it so I can skip that autodetect speeds it up um very well like I said before but

yeah it is each row SL management IP you have the ability to fill out those job inputs um in the CSV file uh you don’t have to kind of assume they’re all the same yeah I’m just doing a quick time check I might not we may not get to all the questions but again you know if we don’t answer your questions or we didn’t get to it please feel free to hit us up on slack we’re happy to know kind of follow up from there and it would be you know multiple people who’s watching those lists and you know obviously Jeff would be there but uh you know just get

a more prompt answer that way um next question is is there a way to tag the devices for rediscovery at a specific interval so example update data every 24 hours essentially schedule your job to run like a crown job right yeah for that that I would say behind the scenes it’s a Nautobot job we are uh have native capabilities to schedule jobs uh you could put a tag on the devices you want to do that on and just say um you know I want to run it on these

so I will say the current job filter today uh doesn’t have tags as one of the filtering options but we we could add that I know we have some some uh work to do on kind of all the filters that we want to accept in that job but but yeah at a high level you can schedule jobs today these are just Nautobot jobs after all and you could run them as you needed nice um so the next question is how does device onboarding handle chassis based multimodule devices like an Nexus 7700 9500 does onboarding input all of the internal modules

so I guess that’s kind of you know besides the the normal you know like the check boox the vlans the the uh serial numbers and so on so do we do anything additional to accommodate you know multi chassis multi module devices yeah so a little bit of a broken record with Nautobot 2.3 where we added the data models for that we kind of anticipate that we’re going to have to add those into the framework today today it’s just sinking in essentially the chassis Hardware

yeah um so any module Spas sfps all the actual individual modules for a modular device those are not uh in scope yet but again 2.3 of Nautobot just came out that supports those models now we just need to kind of write the functionality and syn those in yeah I I just see like it just got spawning out of control but it’s all right it’s it’s reality right yeah so um what about overlapping IP addresses with multi-tenant where each tenant uses his own vni VF I think that goes into kind of the namespace thing but I’ll let you answer that Jeff

yeah those ones um I think would be solved by namespace uh I would have to really dig into dig into that question a little bit more to understand um best thing I could suggest is try it out uh if you’re running into issues again let us know on slack let us know on GitHub issue and we’ll we’ll try to address it we did our best to test across everything and all the different you know different uh platforms and versions that we have but uh you know inevitably we we miss something

so if there’s something that is not working properly for you feel free to reach out try it down your lab if you’re lucky enough to have a lab oh okay yeah there you go or or you know some kind of Brownfield or I don’t know yeah s do in the safe place um okay so this is a good question do we also need uh the SSL app or is it independent so if you install it you know without ssot does it also install like all the necessary backend stuff yeah ssot has a dependency uh

so Nautobot ssot is um but you can by default turn off all those other Integrations that app comes with we just need the framework that it comes with so it is packaged into device onboarding now as a dependency so if you install that it should automatically upgrade and install what it needs but yes it is a dependency cool so uh next question say same question but M lag VPC pair Discovery I think that also goes into like the the more features right

so essentially what do we support yeah again I’ll just uh yeah for for time being I’ll point you to the uh the repository on GitHub and and really the docs page for this application we have that compatibility Matrix we tell you every single thing we’re currently syncing in and I’ll say put in a feature request in the repo if you have some that you would like to see nice um hey I I like how you’re thinking Martin because he’s talking about new vendor contribution if he wants to add a new vendor yamoo file should where should he add it like under

command mappers on your you know like structure yeah so in in the repo itself it’ be under command mappers um again with with that extensibility via get reposting it’s a great way to be able to do it and test it without having to rebuild build your entire application and deploy it every time so that’s where I would suggest getting started once it’s working and you’re comfortable I’ll put in that pull request into the uh into the app add your unit test

so we do have quite a bit of unit test on this um and again we’re happy to help any way we can but getting community support and more contributions would be amazing yeah also the next question is kind of related and I think that would be a good point where you talk about like uh file merging and all that right so the question is with the command mapper if you add another command and bring it in does it merge or replace the app map yeah so we completely stuck with if you sunk it in from git that’s going to be the um most preferred we’re not

doing any merging um just because of the complexity that adds so if you do say need to add one thing or change one thing for an existing mapper you would need to copy all of the existing mapped data into your file make your one or two changes and then once you sink that in that is taking precedence over the native mappers we provide with the application so that may change in the future but uh command merging and file merging gets very complicated and we thought this would be the best path forward to get the application out as quick as possible

yeah we’re yeah that’s kind of important but we’re solving we’re solving the big issues first I think and you like you said it’s important and it’s on the road map perhaps future for merging but right now uh just keep in mind right like if you want to ask some stuff you got to copy in the existing ones as well so Lo limitation of data collection on Cisco W’s was that for iOS XC o air WC or both uh a Okay cool so I would say D um I know we’re running shorter on time Eric did you want to move to the recap

yeah let’s do that okay yeah happy like Eric said before I’m on slack he’s on slack come come join us ask questions there would love to have that correspondence with you yeah so you know we’re just doing some recap today we you know really learned about device onboarding 4.0 and it’s really a big Improvement I would say on elevating this onboarding process you know just to and make it super easy to fill in Nautobot with these device data and you know as Jeff had mentioned and demoed that these are um you know you really simplify the whole

process and uh you know we talked about the challenges of device onboarding we talk about why we need uh 4.0 and what are some of the behind the scene work that we’ve done for 4.0 and we show the demo for running the the onboarding jobs the two-part process the some of the technical specifics specifics that we have done and really glad to have Jeff here because uh you know I couldn’t do as good of a job as he did so you know really appreciate that we did the Q&A and um

next slide please really appreciate you attending we know your time is valuable and we have a few URLs and we have the uh uh you know like the QR code for more for demo if you want to learn more about Nautobot if you want to learn more about the extensibility with Nautobot apps and also you know mentioned a few times that we really do try to make the docs extensive and uh comprehensive to cover all these questions so please keep the question coming we’ll update the docs uh with you know if we seem necessary of course you know Nautobot Cloud if

you feel like you know you don’t want to deal with the on-prem setup you want to have a SAS version of Nautobot we’re always there for Nautobot cloud and with that want to thank you for attending and we look forward to seeing you on the next webinar thanks so much