hey good morning good afternoon good evening everyone just going to wait a minute here for everyone to filter into the webinar it always takes a minute for folks to come out of the waiting room so just give us uh about one minute here while we let uh everyone get joined in we’ll get started here just shortly and for those of you rolling into the room here we are just waiting about 1 minute for uh for folks to filter in we’ll get started here in just about a minute give everyone a chance to get joined in so you don’t miss out on the great topics we’re going to cover today looking forward to going through this uh presentation with you all
okay and it’s uh I think we’re have good attendance here great to see everyone pouring into the room so great to see so many of you out there uh let’s get started uh so we are covering today getting started with Nautobot uh why data is the key to unlocking successful Enterprise Network automation so our agenda for today uh we’ll go through through some introductions uh talk about current Network management challenges Uh current and possible state of network automation as we look at where we are today
uh introduction to source of Truth intent versus reality what do we mean by source of Truth specifically when we’re referring to network automation uh we’ll go into a Nautobot overview uh dive a little bit deeper there kind of go a little bit uh under the hood of Nautobot and take a look at some topics you might see there and First Steps uh in using Nautobot finally wrapping up with some Q&A um always love to ask uh if you could please use the Q&A uh feature here within the webinar that’s the best way for us to be able to capture your questions and share them with everyone uh versus using the chat
so please do try to use the Q&A section if you have questions and and please do feel free to ask them uh we may not answer them uh until the end but we will try to give you uh all answers to your questions as we go through so please do feel free to ask us as we’re going down okay so my name is Tim Schreyack uh I lead the sales engineering team here at Network to Code so I’ll be here presenting for you today uh but before we get started just want to uh drop this here for you we do have a complimentary
uh to our handson Nautobot Workshop it this is going to be uh complimentary for folks here joining this webinar only uh it’s going to be held on May 30th and it’s going to focus on Nautobot’s various use cases including its role as a flexible single source of Truth for network operations and an extensible data and app platform it will also include Hands-On Labs uh it has limited availability so if you’re interested please do sign up um with the link that’s going to be dropped in the chat um for as well and this is a preview of our full day course that there may be a little sneak peek of that coming here at the end as well so stay tuned for the end of the webinar for that
okay so let’s take a look at some current Network management challenges as we consider the landscape as it is today so we have vendor diversity uh each vendor has their support contracts right unique apis uh SNP oids Etc right like there’s just all these bits that are unique to each and every individual uh vendor right whether it’s uh CLI or the the UI manager interface even down to the configuration commands everything is unique and bespoke per vendor uh we have Network growth
uh new technologies requiring you know the netops team to constantly learn new skills and adapt and expand the network uh new device types are being brought to the market uh you know introducing new requirements whether it’s security or bandwidth or you know a new a form of fabric or whatever it is that we’re doing and managing the network with constantly new technology new Dev device types new things that we have to handle uh the network is facilitating new types of communication
uh you know whether it’s uh voice over IP or video uh where we need to have you know less Jitter less latency better you know no packet loss you know all of these kinds of adaptions that we’ve had to make on network space uh is as as we look across both the past and the future uh future uh Workforce shortages uh simply you know hiring more people is harder and harder that is you know finding the skills that we need in order to operate these now extremely complex networks uh is is is a challenge
we have you know senior Engineers who kind of grew up doing this work are are now beginning to enter retirement age um and we may or may not have enough Junior Engineers to backfill for example as we look across this space um and you know security threats uh you know as we see all of the different uh attack vectors that are now coming in across the Network space and and the adaptations that we have to make as we manage and operate these networks you know and just a quick quote here from you know Cisco’s uh in Internet report you know there’s going to be a approximately 30 billion network devices uh as up from you know 18 billion
so we have this very very large growth in our space of devices as they get added to our networks and things that we need to manage documentation this is something that we have always struggled with in the network space particularly uh this is a very difficult problem for us uh we have typically often you know things like expel sheets uh Word documents uh we’re trying to uh you know get access to different pieces of equipment or platforms that we treat as sources of Truth
sometimes we just treat the the network itself like we go look on a device and we just declare that the source of truth it’s often in people’s heads um this is something always one of the you know when you start a new a new job uh a new role maybe a new network uh you you have to try to consume that Network and understand how it’s been architected and designed over time uh and that could be very difficult to do um as well as you know it’s just really hard to maintain uh Network documentation as we look across time uh it’s difficult a to enforce standards
uh it’s hard to get everyone to do thing cons do things consistently and the same uh and most of the time what we often see is we will go and build a new environment and we promise ourselves we’re going to do an amazing job of keeping the documentation up to date and we typically last about a month that we do that we build it it’s all perfectly documented and then a month later we’re off the rails again right because it’s just hard for us to maintain things at a manual level in our space
because what we do as Network operators is really unique we have a tremendous amount of data that we need to maintain in order to operate our environment very different from all other Tech spaces so what we end up with uh increased downtime reduced efficiency higher error rate generally based by human human causes right um and it’s difficult to collaborate it’s hard to work together especially you bring someone new in how do they learn the environment it’s usually really hard uh so here’s you know some of the the challenges that we face
so let’s transition into kind of the current and possible states of network management where we could go so as we start to leverage a source of Truth so here’s what we see typically across our clients uh as we work with various in uh companies and individuals what we’ve seen is this sort of gradual growth starting over to the left hand side we’re looking at very early days everything’s done by manual CLI uh at some point usually some engineer decides that they’re tired of going out and banging out the same thing every time on a CLI and they will start to write scripts
now those are things like Ansible scripts maybe some python or even maybe a shell script you know some kind of poers shell or bash shell you might see being used there and then eventually someone else hears about this really cool tool that so and so is using and they’re like hey can I get access to that and suddenly that thing that started off as just a little personal script on somebody’s laptop becomes a departmental power tool
and now we’re using it across the organization and it’s usually at this point that we begin to recognize the need for a sour of truth that is if I’m going to take this idea of power tools and really run with it um I need to have a consistent way to feed data into these scripts or code uh because what happens is I I have this amazing code but it doesn’t really work if I don’t have data to feed into it
um and this is the problem that we commonly see and where we begin now to recognize the need for a source of truth that if we’re going to continue on this trajectory of moving down into more higher level of maturity in the way that we operate our Network and use automation to drive it uh we need to have a consistent good clean source of data that we’re going to feed into the automation that we’re building so this is a typical spectrum that we see across our clients as people move from more traditional to more code driven methodologies
so here’s you know some practical examples uh you know with a uh a shared Enterprise source of Truth uh we can eliminate uh discrepancies between the various bits of data uh we can harmonize our sources of record so let’s think about that for a second which is in most organizations you are probably going to have multiple sources of record that is you may have a cmdb you may have an ipan you may have a DM tool you probably have a monitoring tool um and those are going to remain
and what we can do with our shared source of Truth is being synchronize those various sources of record and get them to all have consistent clean data synchronized between them we can uh create uh extensible Enterprise uh automation architecture so we can configure uh and deploy new assets that are received into the organization as well as disseminate the information about them into all of our sources of record we now no longer having to do this by hand we’re not having to do multiple steps over and over again we can drive uh self-service portals via iatm our ticketing system uh by having Integrations between our source of Truth our Automation and that self uh the itsm tool
so now we can do things like say maybe we want to automate or at least manage our deployment of security policy our firewall rules uh perhaps we want to be able to automate uh zero touch provisioning for a new branch office so we can now drive all of that from a portal in our ticketing system as an example I click in that hey we’re spinning up this new branch office here’s some basic information about it and then we let the automation do the rest
ultimately a highly automated and resilient infrastructure uh where change is driven from intent uh out into the network then we can automatically deal with potential issues closed loop automation right like the where an issue occurs we can have the automation take care of that and close that ticket out some great examples of things that we can do do uh as we start to have a source of Truth so let’s go over kind of an introduction to source of Truth and what do we mean by that intent versus reality
so source of Truth is all about uh what we’re planning to have happen in our environment what is our intended state it is about what we expect the environment to look like this is where we express that where we take what’s in the architect’s uh head and design and move that into a place where we document it so it’s a way to codify our design if you will source of Truth data drives Parts labor and configurability so we end up with a fully realized Lego model versus the pile of Legos on the floor and what do we mean by data specifically when we talk about the network
so let’s kind of dive into that a little bit uh understanding our Network configuration data so here’s the example of uh some typical Network device configuration right we’re looking at here is an interface uh you know we have the interface ethernet one its description it happens to be set to mode access and it’s uh in VLAN 5 so some of that is vendor syntax some of that is just the way this particular vendor which obviously in this case looks like nsos um has has specified how we configure this particular device in other components of this are data
so let’s think about what what here is data like for example VLAN 5 that’s some data the fact that we’re setting this port to mode access another piece of data the fact that this is interface one um is another piece of data those are all things that are are vendor neutral it wouldn’t matter which vendor device we’re using it’s still going to be V 5 it’s still going to be access port and it’s still going to be interface one so you could think of most of our data as this vendor neutral information
and then we have the vendor syntax right those are two different bits there and the reason we have this configuration though is because of our design the design drives the configuration our design specified that this particular Port should be VLAN 5 so it kind of want to think about two different bits here is we have what the design is intending and then what that means as a result now we have some data that is implementing that design
and finally we have the how do I actually configure this device from a vendor syntax perspective to drive that actual design so the final configuration on the device itself is a blend of the data along with the vendor specific syntax that implements the design required and this is what we Express in our source of Truth the actual design via the data and then the configuration components so here as we’re highlighting things I just covered on the previous slide going over those highlighting bits right ethernet one
uh the description which I didn’t allude to earlier right that’s another piece of data like what do we want our description to look like the fact that it’s mode access and that is fan 5 so here now again we can see these data points now entered into the database so now here in the database what I’m storing is hey interface set to ethernet one description set to whatever makes sense in your environment however you make your description standards and then the fact mode is AIS and Vine is five
so we can see here all of that data stored in the database okay and source of Truth this is really the foundation as we look at driving from a CLI or manual driven Network to one where we drive intended State into our environment and as we look kind of across this spectrum of possibilities here starting off with just we want to EXP express our intended State uh we begin to use some scripting eventually we start to move into net devops where we’re really operating the network
through uh very controlled managed efforts um to eventually having things like Network as a service and intent based networking where our environment is really being driven by code uh and the low-level tasks are all handled through automation so let’s start to dive into Nautobot and give you a little quick overview of what Nautobot is and how you might use it in your environment so here’s some specific use cases we might use uh the platform as a source of Truth uh in our environment
so we can model the environment for things like our devices um our IP addresses our vlans and if you think of the traditional tools here uh you might have a cmdb something like service now really common example that we see um ipen uh infobox is another common example we see there and and decent you know device 42 or you know what whatever decent tool you might be using in your world um you can think of these three different places and they’re all storing related data but often not enough data
and what a network source of Truth does is gives us a centralized place to store all of the data we need about our environment and potentially to synchronize it and harmonize it within our environment so for example what do I mean by that let’s take a look at the cmdb example uh so it’s really common that organizations will have some uh organization wide official cmdb
as I mentioned very common we see service now uh cmdb in use across our clients but and it’s a great list of information but it does not contain all the data we need need for example uh if you think of a typical Network device a typical standard network switch uh it’s got 48 ports on it at a minimum quite often there’s even more than that there is no way that anybody over that’s managing the service now CNB is interested in modeling All 48 of those ports or any of the other bits of information
we need in order to really understand that device all they’re interested in storing is you know that the the make the model the serial number what it was acquired know those kinds of information typically more relevant to finance and uh maintenance on those types of things not so much on the configuration and management of the device and that’s where Network source of truth comes in and is in sync with and works together with our cmdb the CNB has that basic information whereas the network source of Truth has all the information we need all of those details about the device stored in the network source of Truth
and now from the network operation perspective uh we can use that Network source of Truth to update those other sources for us so rather than uh as a as a human needing to go and enter this new device in in the service now cmdb we can just enter it one time in the network source of Truth Nautobot and allow Nautobot to then synchronize or update that data into our service now cmdb as an example of how you might take advantage of the power of the platform uh Nautobot also has a power as a network automation platform
so at its core we have that capability to be a source of Truth uh but then there’s a layer on top of that which gives us a place to actually build and drive automation to integrate with uh the business process to integrate with other tools you have in your environment and this is a key thing that differentiates Nautobot from pretty much all other sources of truth that exist out there in the world today this ability to take the data um and blend it and merge it into the way we actually operate and manage our Network and this is enabled by the automation platform component of Nautobot
uh finally we have all of the flexible ways in which we can use that data or the automation within Nautobot via the graphql endpoint um integration with Git web hooks rest API and of course the Plug-In or app ecosystem that is what powers the automation platform so some key features um the source of true right these These are absolutely fundamental to Nautobot’s platform and core uh this is how we are able to aggregate data uh across different platforms uh it’s and very very flexible right this is a key bit as well uh we want to be able to make sure that the tool adapts to you and your environment uh you shouldn’t have to adapt to it
uh so we have that ability to both extend and be flexible in how we use and store data within Nautobot uh between the combination of things like uh custom fields and custom relationships you are able to model virtually any type of device or configuration within Nautobot without having to make any changes to the platform itself you can simply extend it through those abilities uh and then the automation platform as I mentioned uh earlier this is a key component and what differentiates Nautobot
um and this ability here is primarily driven through the job ecosystem a job is a way is a full python environment within Nautobot and enables you to implement your custom business logic uh as well as to embed your python code your power scripts uh directly within the platform you get a lot of benefits from doing that one is you don’t need to make external API calls or graphql calls to and from that database uh because you’re native on the platform you have direct access to the data
so it’s a lot faster if you’re operating at scale this can make a huge difference uh where you’re able to render configuration to execute code much more quickly because you’re directly on the platform versus calling Nautobot externally so what we see as we look at you know datadriven Network automation some common examples things like using uh Nautobot to drive Green Field deployments or or firewall rule updates uh managing configuration compliance is my network actually in the state that I wanted it to be
uh and the the answer to that is most likely no um almost always when we see this at clients when we begin uh using our our config compliance tools within Nautobot we always see cases where there were things unexpected that were discovered as a result of beginning to use configuration compliance management uh something that you can do with Nautobot OS upgrades you know two of the most common problems we deal with in network space how do I get my devices upgraded how do I make sure they’re in the state that I want them to be in
okay a little bit deeper here as we go just a bit more under the hood of Nautobot and its functionality so a Network’s architecture and configuration can be defined by objects attributes and relationships so objects um those are things like routers and switches um or they could be virtual right they don’t they don’t have to be physical um attributes the the things we use to actually make sure those devices are doing the thing we wanted to do you know a essentially a router out of the box versus a router that’s been configured those are the attributes
and then the relationships that is how does this device interact with other devices in the real world uh again whether it’s physical or virtual doesn’t matter so if we just take a simple example we here we have uh two devices uh a router and a switch connected by an ethernet cable uh the ethernet cable there’s some attributes on that as well like it’s termination points this cable goes from this point a to this point B
and then there are configuration attributes on the devices themselves uh the speed the duplex the IP address you know is it a switch port or is it a routed Port uh how are we operating this network what’s the design that’s implementing and uh informing those configuration attributes so as we look across that this is how we’re using data to define the network you know here we’re saying hey the circuit provider AT&T um the role is it’s appearing router uh its status is provisioning because we’re just configuring it now uh you know the interface IP address and it’s an Uplink and all of these bits of data that are actually forming our configuration
so now moving on to how do we get data into our source of Truth this is one of the most difficult problems particularly when we’re starting from a Brownfield environment uh we may or may not have good accurate data to start with and if yours is anything like most of our clients you probably don’t have 100% accurate data today uh and as we move into this world of we need to maintain good clean data in order to then drive automation this becomes Paramount how do we make sure that what’s actually out there is fully represented into our database um and modeled in
so we want to make that as easy as possible this should never have to be done by hand except in the worst case scenar scario so here starting in the top left some examples of ways of tools that we could synchronize data to or from and I want to highlight these are simply examples these are by no means limitations or requirements so you can synchronize data between Nautobot and virtually any other tool so long as that other tool has a well represented rest API Nautobot single source of Truth application is capable of synchronizing data to and from Nautobot to any other tool that has a well documented rest API
so some examples infl box Arista Cloud vision service now CDV device 42 is your DM tool IP Fabric even could be treated as a source of Truth on which we might bring data into Nautobot or maybe we’re pushing data to those other tools uh then as we look at how we might go collect data from the environment we start off with uh two basic methods here one is the onboarding app which is a way in which we can go discover existing devices um and learn basic information about them things like their serial number they’re making their model
um we do that by providing an IP or a list of ips um there is a way to do bulk importing through the onboarding app and we’re able to bring in all those devices the basic information about those devices into Nautobot the network importer tool what it does is now goes out and discovers the extra information all the stuff that would not be out in your C tmdb tool so all the interfaces all the VLAN the IP addresses all of those extra bits of data that we need to use to configure the device can be discovered with the network importer Tool
uh so those two work together hand inand to both populate the data base with the basic information and then enrich that data with the rest of the details that we’re looking for here on the network side so some options there for you on how we can get data into U Nautobot now let’s go through a specific example of what you might do as you move into a world like this so here’s an example of onboarding a new device and perhaps it used to take days and now we can potentially do it in minutes
so here let’s look at how this might work we start off with a self-service portal uh where a new device is going to be instantiated and so we you know enter the basic information about it and uh trigger that flow from our itsm perhaps uh whatever you know portal you might have created in your environment that portal is then going to uh send a request to Nautobot that hey we’re going to create this new device and here’s the basic details about it that we need in order to begin the process so Nautobot creates a record for that
um and then we move on to okay now we have our next steps perhaps we need to go out and uh uh create a record within infobox and get some IPS uh to assign to this device we want want to go update our uh service now cmdb uh with all of the relevant information that the business cares about tracking about this device um and we’re going to go put it in our decent tool we’re going to update it into our device 42 uh tool as well
so now we’ve just gone and automated the deployment of this information about this device into our existing sources of record that we have in our environment let’s say and now we start looking at other uh more dependent systems things like our monitoring tools whether that’s logic monitor or solar winds or or maybe Splunk um we can go and configure them for hey this new uh device is being onboarded into the environment
so now rather than a human having to go and touch all of these individual tools do configuration uh get that device up and running we can allow Nautobot to extend that information and synchronize that data for us um and this is a really key element behind the notion of Nautobot and what facilitates the idea of using Nautobot as the way to drive your data which is because we’re making the process easier it becomes natural often when we try to implement a new source of Truth uh it basically means extra work for individuals and it’s really hard to get people on board with doing extra work
so let’s find a way where introducing a tool like Nautobot actually reduces your workload it doesn’t increase it um and this is a key way we can use Nautobot to facilitate really very Ted busy work and let machines do those kinds of things let humans focus on higher level tasks things that we’re better that we’re good at so let’s take a look at some first steps of actually using Nautobot here as we come into the second half of the webinar uh accessing Nautobot right
so we do have a demo instance uh available uh it is our public sandbox available out there at demo.nautobot.com uh you can see the credentials here they are also prominently advertised on the demo site as well and uh you can use there for trying it out for experimenting feel free to do whatever you like there it is a public sandbox the data gets refreshed every night um so you can do whatever you like in the public sandbox give it a try uh as we look at the landing page it’s fully customizable here
now of course in the sandbox you’re not going to be able to do all of the admin things that you could do once you deployed it um on your own or or signed up for Nautobot cloud uh but here you know we’re able to customize this and display the things that are valuable to you this can be fully customized and organized As You Wish uh just a quick overview into some of the various components uh one of the most interesting things that we introduced in uh Nautobot 2.0 uh was this idea of locations
uh locations give you a tremendously flexible way to describe how your uh physical world is laid out uh whether we’re talking about you know continents countries um subdivisions such as like States or counties um cities neighborhoods buildings you you name it you can use locations as a really flexible way to model your environment uh in in what physically exists in the world compared to what how we presentent that in the database uh allows us to create a true hierarchy of details that represent the physical world
so we can uh list all of our locations it’s easily filterable we can get down to the important things that we need like hey I just want to look at the sites that happen to be in the United States for example here in this case uh we can look at racks so we can model all of our racks as they exist uh out there in our data centers in our offices and Branch offices uh wherever they are we can see utilization we can see how much power is allocated out for that given Racket and how many uh how much space is left available for additional devices to be inserted into the rack
so full representation of what we have physically out there in the real world as well and we can drill down into detail um so we can see all the specifics of Iraq both uh what’s physically there in the representation of the text but also a graphical representation there all rendered automatically by the UI this isn’t something you have to maintain by hand um can be really helpful for our DC Ops teams where they can visualize where device is in the rack they can more quickly and easily locate things
out there on the data center Florida getting a view across our racks and being able to see all of our rack elevations in a in one seamless picture can also be really powerful for planning for architecture and for network operations in general being able to get that Consolidated view of what exists in our racks in one simultaneous view our platform page uh this is all of the ways in which we are accessing devices and modeling devices
so is it Arista uh EOS is it Cisco iOS is it Cisco iOS XE or XR n xos the Juniper any number of cases across our comment platforms well supported here for all of our network drivers and this is handled by the platform screen devices themselves uh new devices we need to associate with a location uh a device role device type and operational status so these are components that are required and all other options are uh optional for you depending on what makes sense in your environment here
we can just see some examples of device types again the way that we model uh existing devices and and more abstractly think about them uh we don’t want to go off and create a device type for every single device we have we want to do that as abstractly as possible so here you can see device types represent essentially models that you might get from a vendor so taking your network management to the next level uh in this webinar here today and in our companion video that uh we did release uh a few weeks ago as well
uh We’ve covered the first steps in using Nautobot to model and document your network populating devices how do how do I get devices into Nautobot how do I relate my devices to my organizations my locations uh and then how potentially I might use the Nautobot job ecosystem to go create some automation task these were topics uh that we covered in our Nautobot Navigators guided sandbox video one uh which is available out on YouTube and I believe we have the link here dropping for you as well
uh and then just a little teaser for our next upcoming webinar uh we are going to go deep under the hood of Nautobot and start talking about modeling ipam and vlans uh within the Nautobot ecosystem and how that functions um and you will see both there will be a guided sandbox video as well as the webinar here together covering these topics here as well okay let’s do some Q&A uh I think we’ve had a few questions coming in I know I believe Taylor has been handling some of those uh there was one that came in about tracking granularity of network source of Truth compared to uh cmdb uh Taylor you want to chime in on that yeah absolutely
so the the question was uh going back to the um beginning of your of your speech when Nautobot can integrate with other sources of record and other Technologies um and so to answer that question Nautobot and a cmbb can coexist together uh the example that would be given would be the scenario um for a device onboarding uh situation where a device could be onboarded into Nautobot per se and automation can then sync that not Nautobot data into the cmdb to make sure both locations have uh the same information in the same data
so that’s a good question there was also another question uh Tim that was regarding Network importer um and asking if it supported a distribute hierarchy uh for regional devices to be able to be discovered by Regional importers um the short answer to that question question is yes uh that is a uh function of the tool um and it allows really for us to um at scale be able to uh import and Achieve uh the uh scalability and the management of the network devices across those different regions and geographical locations excellent yeah
and I see we did just get an additional question coming in uh regarding Nautobot versus netbox um as alluded who there in the question yes uh Nautobot is a fork of netbox um which we did quite some time ago now at this point uh we had our you know it’s been a few minutes uh since we did create that fork uh but what you see and the reason why we did that um is as a lot of the topics we just discussed today uh we wanted to be able to facilitate datadriven Network automation um and that’s what Nautobot exists to do uh we wanted to take the idea of a network source of Truth which is what you have at its core within netbox
and then really expand on that how do I actually use that data to drive Automation in my environment uh and that’s where you see that Nautobot app ecosystem or the automation layer of Nautobot really coming into play which is this is how we are now able to take the data and begin to drive our Network and our Network changes configuration all of those bits about the network uh we can actually facilitate its use and this is a key concept behind Nautobot is that we want to make the data consumable and usable
uh as we move from a reactionary uh state where we consider the actual state of the network to be authoritative to where we consider the intended state of the network to be authoritative and that’s what we’re driving into our environment and this is the purpose Nautobot serves to exist uh or exists to serve sorry uh to drive our automation from the data uh and that is the key fundamental Phil philosophical difference if you will between Nautobot and netbox there are practical applications of that uh for example the job ecosystem
as we alluded to here uh and we will dive into that a little bit deeper especially if you watch that guided sandbox video I alluded to there we do cover some of those topics as well looking at how you use Nautobot jobs uh and how you can use that to drive your environment let’s see I think there’s a few other questions coming in at us we got some in the chat as well uh let’s see uh yeah so is the demo is just persistent do I have to worry about breaking something so no it does get refreshed every night
so please feel free to do whatever you like in demo.nautobot.com it is there for you to play with and test so please do absolutely feel free to hammer away at it uh as well uh another question just coming in here last minute how would you detect Rogue devices so I think what you’re asking is how do I detect that somebody plugged a device in on the network uh that I wasn’t expecting or wasn’t planning for uh and this is something you know Nautobot as intended to be our place where we express intended State there is functionality within Nautobot to discover existing devices and bring them into the network but its primary purpose is not a monitoring tool
um so that is really not what its main purpose is uh but what we can do is use Nautobot to understand here’s our intended State here’s some information we’re collecting from the network and do those align um and so this is something that we do see folks using the tool for uh you can use both a device on boarding tool to discover devices that may have been added to the network and compare that to what you understand as my current intended expected state but again highlighting Nautobot’s primary purpose in life is to express intended state it is not representative of actual uh or considered a monitoring tool
so always keep that in mind when you think about what Nautobot’s purpose is in your network tellor any other questions that you see coming um yeah there was a question asking if uh a user can incorporate a server infrastructure into Nautobot something that is not networking infrastructure absolutely uh and you know this is one of the use cases we love um in fact uh just before this call I was talking with a client uh who actually has more server infrastructure loaded into their Nautobot instance than they do network devices um he was giving me some use case is there
he has uh approximately 20,000 network devices loaded into Nautobot and he’s got 35,000 Linux servers loaded into Nautobot so just to give you an idea of what’s possible absolutely you can model uh your devices regardless of whether they’re network devices or otherwise let’s see I think oh we did just have another question coming in uh from Peter here in the context of a Global Network when intent is being deployed to the live Network are there worker notes deployed regionally that connect to Regional devices and update configuration accordingly basically how do we get from intended state to deploying that configuration out in the real world
and then can that be configured deterministically for example network devices in Asia pack might be updated by worker notes in Asia pack so understood the question absolutely So currently today uh the way Nautobot is designed to uh function is from a centralized core now you might decide that you’re going to break your Nautobot deployment up into multiple Nautobot instances where you have uh one case of Nautobot in let’s say the US and another in EMA and maybe another in Asia pack would be an example of a really large uh Network design uh we do have on the road map though the idea of remote workers
um so that’s the ability to say have a centralized Nautobot within a remote worker node that would be placed in your region and in your use case here um that is on the road map I don’t remember off the top of my head when that’s coming but it is on the road map uh for availab;e so that’s something we have uh coming uh but today we would recommend if you were doing it today you would do that by breaking up your Nautobot about instances specifically
one more question looks like but we’re getting a bunch in here which is great love to see all the interaction thank you everyone uh from Howard here what tools does not used to configure switches for example if it’s Ansible how do the two work together to configure the switch Yeah so great question uh I’m going to address the first bit of about Ansible first and then we’ll kind of look at uh the actual the underpinnings of of the root cause of your question there uh Ansible uh we utilize and support Anem very heavily within the Nautobot platform
and so for example if you take a look at our golden config application our our configuration compliance tool you will notice that it uses Ginger templating uh which is obviously an Ansible function uh and we in integrate ansible so tightly into our platform uh that in that case you don’t even need to know about Ansible or even use it it’s all handled by the platform itself so the platform itself Nautobot will handle merging data into your Ginger template and then creating your configuration
so there’s an example of how we use Ansible but the specific case was about how do I reach out and touch a device to actually configure it um and this the actual answer to this question is uh it depends uh which is uh a question I don’t love giving but it is the reality so we will often uh we will use the tool that makes sense depending on the the way that that device type is configured or the driver is configured for that particular device type so it could be uh something like Nornir it could be Napalm it could be nit M uh it could be uh Ansible right
so there’s a lot of flexibility in the specific uh technology used under the hood uh but again the idea behind Nautobot is that we want to abstract the complexities of those tools for for you so you’re not worried about you know what specific tool is being used you’re just getting to enjoy the benefits of those tools without having to worry about the management of those tools okay wow yall keep firing questions at me which I love uh how many Global deployments of Nautobot are you aware of and what are some of your Flagship customers
okay great question uh we have uh our largest current deployment of Nautobot uh is approaching about a half a million devices um I can’t give you the the company that that is in within but uh very large scale right so we have lots of deployments of Nautobot operating at very large scale uh unfortunately most of our clients do not allow us to publicly mention their names so that’s not something I can give you uh but to spice to say that we do work across almost all sectors
uh we have uh clients that scan whether it’s a financial sector or education or government or Tech sectors uh Healthcare we span a lot of different sectors and have very large deployments um we can help you um whether you’re in a highly secure environment something that’s like healthcare government um to you know maybe something that’s more flexible and looking for uh fast and quick like a tech sector right so lots of flexibility that we have there did I miss any questions to get them all uh there was just one other question by Peter
that uh that was asking if we develop or provide any python modules to interact with Nautobot uh the answer is yes we have a Nautobot and a network to code get Hub repository and in those repositories you will find um some python modules that we provide and maintain for the community to use to interact with Nautobot yeah absolutely um you have both your uh Nautobot uh python Library available to you as well as if you operate your python code directly within the Nautobot platform you can take advantages of all of those functionalities there as well
so either way whether you’re running your python code external to Nautobot or running your python code on Nautobot itself you have lot of advantages there for you and making it as easy as possible as Taylor alluded to there you folks thank you so much for so many questions here uh that was amazing love it when uh everyone’s interacting and asking us stuff uh as well so oh I just see one more coming in here uh comply for healthcare companies yes absolutely we have deployed Nautobot at multiple Healthcare facilities both insurance and uh Hospital related so absolutely we are very familiar with the healthcare sector yes
okay uh as I mentioned at the beginning just to reiterate uh we do have our complimentary 2hour Hands-On Workshop coming up on May 30th this is limited availability it’s only available to folks joining here on our webinars so please do make sure you go sign up uh once the seats are taken they’re gone and the course will be full so please take advantage of that it’s a really amazing course gives you a great uh teaser in tidbits into how Nautobot functions and how you can use it as well as gives you an overview of our full day Nautobot course
uh so getting to that our full proper Nautobot courses um here special for you folks here on the webinar today we do have our 15% off discount code that’s available for you covering the following courses coming up uh we have our source of truth and Nautobot fundamentals course uh that’s on April 9th and 10th our our public Workshop which is Nautobot extensibility on April 16th and automating Nautobot with python and Ansible on April 30th uh one of the things I’d love about all of our courses
particularly when we talking about like the python and Ansible ones uh is you are going to cover and learn topics that are relevant to you as a network engineer or network operator we’re not going to be teaching you how to do some weird math problem in Python uh you’re going to learn real practical things that you can come out of the class and use immediately at your current uh role or job so really practical useful information coming for you in these courses all instructor Le uh with Labs so you get that advantage of having the instructor there to help you learn
and then you actually get to practice it and try it out there in the lab as well so lots of going back and forth with your instructor and your process of learning so great classes there for you and an amazing 15% off so please take advantage of that thank you for attending some quick links for you here uh the Nautobot link our apps our documentation and of course Nautobot Cloud all things not Nautobot available to you and the easy button you can operate your network environment and your network source of truth from the cloud using Nautobot Cloud
uh if you’re interested in a demo please do reach out to us love to give you a private one-on-one demo we can really go through these topics in detail and answer your specific questions thank you so much for joining look forward to seeing you on the next webinar