Good morning for those joining. Good afternoon. Good evening wherever you are in the world. Thanks for joining here. We're gonna get started in just another minute.

Just waiting for, rest of everyone else to get filtered in. Should be just about there. And I think we're good to go. So let's get started. My name is Tim Schryack.

I'll be your host today for the webinar. And today, we're gonna be talking about network automation with Nautobot and IP Fabric, creating a holistic network automation solution with a network source of truth and automation assurance engine, with our great panelists here with Kylie Kelly from Network to Code and Darren Folwell from Hyperfabric. A little agenda for, topics today. We're gonna go obviously, here we have the intro. We're gonna be going into the network automation framework concepts, some overview of NATABOT and IP Fabric, and then finally, chat ops and a really cool single source of truth demonstration.

And now our presenters. I will let them introduce themselves. So take it away. Go ahead, Paddy. Thanks, Tim.

Hello, everyone. My name is Paddy Kelly. I'm a managing consultant with Network Code. I'm happy to be here today. Started out life as a Java programmer, moved then into the networking arena, have about 15 years experience, mostly in the, service provider and data center space.

Now firmly in the network automation space, enjoying my time at network code and maintaining some of the open source projects. Looking forward to the, webinar. Darren, over to you. Thanks, Freddie. Yeah.

Darren Forwell. I'm, product evangelist with IP Fabric. I mean, it's the best title in the world, isn't it, really? Get to talk about network automation all the time. Why would you not wanna do that?

I'm a I love the veteran. You said the word veteran on the slide there. It's great. I've I've been doing this network stuff a long time, from everything, from, from the engineer on the ground to to the architect who does the design and and operations, side of things as well. So, yeah, I've got a couple of certifications, but really my my focus these days is the same in terms of PADI, really, that the idea of of network automation is the new way to operate networks.

It's a a fascinating topic, and I can't wait to dig more into it with, with Paddy today. Thanks, Paddy and Darren. Just a quick, shout out about some of our upcoming community webinars. We have, obviously, today's and then we do have coming up on October 6th, simplify network automation with Nautobot jobs. The link's there you can see in the chat as well for those of you that might want the link to, those upcoming events.

We're also super excited to announce and, start talking about Hacktoberfest and our hackathons coming in October of 2022. These are from network to code and designed for our community. We have 2 2 2 of these separate events going on in the same month. Yes. So Hacktoberfest, the full month of October, definitely willing looking for people to participate and the community to join in as well.

You can see the, links down there below for where you might be able to join. And then the hackathon. This we're, doing this year this year on October 14th 15th. You can join as an individual or as a team if you want to be able to really get in and compete for some of our awesome swag and prizes we'll be giving out. So please, definitely participate.

And then we also have some training coming up on, Nutabot in November. Our source of truth and Nutabot fundamentals, will be, November 7th through 8th and automating Nautobot with Python and Ansible on November 16th. Links there as well to sign up. And just a quick point out here, the code we have here is, especially advertised for the attendees of the webinar, and you get 20% off, a great discount off of our standard grades here for the public training classes. And now moving into the, presentation today, I'll hand off to Paddy for network automation architecture.

Great. Thanks, Tim. So we're gonna set the scene, really, for some of the integrations that we have coming up, and we wanna do that by sort of explaining where they fit in the overall, network architecture. So at NetworkCode, we've been building network automation solutions since 2014. And during that time, we've created and refined a network automation architecture that represents the core components of the holistic network automation solution.

So we'll go through this sort of end state architecture, and we'll review some of the components to give you an idea of where they fit in. We'll just start top down. So we'll go for user interactions. And the user interactions really is the sort of the entry and exit point of the network automation solution. That's sort of like how the how the clients or contributors would interact with the network automation platform.

So it contains some of the more common user interfaces or presentation layers that you might see for, like, chat ops or service portals, maybe some dashboards or even some documentation systems. So the orchestration component, this will basically, this will be more of a sign of a sort of a mature organization if there's a fully functional orchestration system in place. Essentially, now it defines the tasks that the automation system, will be used to to connect the various sort of tasks that you wanna automate, and it basically allows you to coordinate those tasks. So if you have the the workflow engine, we'll basically stitch together those tasks to be automated, and they could be executing jobs or getting data. But, ultimately, it sort of gives you the flexibility to add sort of decision or use conditional logic to control when the tasks will be executed.

And then you might have an event driven system. And here, you would need the observability stack really to to be in place, observability or analytics stack to be in place. And that's sort of the bridge between that workflow engine, and the telemetry system. And that makes sure that any of these sort of, events that are being triggered can can basically kick off the automation piece, within the workflow engine. So within the telemetry stack or the observability stack, this is where it exposes a continuous flow of enriched data.

So they're pulling back data from the network. And Darren will be going through a bit of this, later on where we see, like, the observed state and how the network is actually operating. So this is, one of the key things, in terms of the information feedback loop that we get back from the automation, systems to ensure that we have a feedback loop. It's very important because automation can only go so far if we don't have that feedback loop. And then the automation engine itself, this is but, obviously, this is sort of one of the key components as well.

So that the all the tasks, basically, that change the state of the network and any other sort of help helper functions. These are the components that are required to push the changes to the network and execute those ad hoc commands. You know? And that that could be the rendering where you're sort of pulling data from the source of truth, and mapping that against templates to produce the configuration or also the provisioning element where you're actually pushing the configuration out to the network. You know?

Compliance is also a component to this where it identifies any deviation from the design rules that basically supports our standardization. And this is all underpinned by the, source of truth, which is basically a key component and it stores the data that defines the intended state of the network. So it's rare to have one authoritative source of truth for all types of systems. But, a source of truth should basically contain all of those systems and databases that act as the authority for their data domain. So to give you an idea of sort of some of the common, tools that sit across some of these architectural components.

Now this is not the only tools that do these jobs. It's just some of the ones that are so to give you a a visual representation of where they would fit in this architectural framework. But today, we're only gonna focus on 2 of these components. So we're gonna focus on the source of truth, and we're gonna look at a tool called Autobot that will allow you to to, integrate a source of truth into your network and IP fabric, for the observability and the analytics piece. Okay.

So Knowlobot. What is Knowlobot? Knowlobot is a source of truth and a network automation platform. So it's a it's an open source project that was created last year, beginning of last year, 2021. And Network2Code is the primary sponsor.

You can find it there on GitHub. You see the link down the bottom there, the the GitHub go GitHub, organization. And now we're just gonna go through some of the the the know about use cases. What does it do? What what what's the what's the goal of know about?

Well, primary use case here is that it's a flexible source of truth for networking. So the aim is to basically act as the authority for network data. Basically, essentially document the network with the source of truth. So here we have the different components that would sort of make up your source of truth. You'd have the IPAM, which are IP addresses and VLANs, or you'd have your sort of data center inventory management, which are devices, racks, and sites, and that's everything, and circuit information.

So the goal is basically to model this data to drive automation by defining the intended state. Okay? So building a source of truth, obviously, can be difficult, and that sort of depends on the environment. So if it's a greenfield environment, it's more that you'd use the design to generate the, source of truth. And more likely, it's a brownfield environment.

And what we're gonna do is we're gonna show you a use case where you can use IP Fabric to generate this, source of truth within a brownfield environment, by importing the inventory, cleaning up the data, adding a bit of metadata. Okay? Another use case for Autobot is to be an extensible extensible data platform for network automation. And, obviously, to do that, it needs to basically provide the, an extensive API and which it does. It has a REST API and a GraphQL API.

In addition to that, we have native Git integration where you can basically pull Git repositories into Autobot and have them available. They could be storing your templates or other types of, data for network properties, that type of thing. There's webhook support where it can basically trigger trigger a a web request based on an action. And in in addition, there's also the capability to run jobs. And jobs is a is a Nautobot feature that is basically running custom Python code within Nodobot within the Nodobot ecosystem.

And job hooks, these are basically like webhooks except they trigger, the execution of a job, within if there's an action that was performed on Notable. And last use case really is as a a platform for network automation apps. And this is a big part of Nodobot. It basically supports creating and deploying custom apps, to support your network automation use cases. Now these could be custom and they could be private.

You could build your own apps, or you could take advantage of the app ecosystem that is within, Notabot and that are available on that GitHub organization. And you can see some of them here. This is, obviously, it's a it's a fast growing list, and this is as a result of sort of many of the customer engagements that we've had. And we tried to give back to the community, by releasing some of these publicly available apps. We have 2 of them circled here, which are the 2 that we're gonna look at today, basically.

It's the IP Fabric, single source of truth, and the IP Fabric, chat ops. So to give you a quick look at Nodobot, we're gonna go through a a very, brief demo, and we're gonna if you want, you can follow along here at demo.nautobot.com. Let me shift this down so I can actually get to it. And that's it there. So this is the main note about screen here.

We can see a summary of all actually, if you're logging in, you just use the username and password here at demo.nautobot.com, and the username is demo, and the password is Nautobot. As I said, this is the main screen with all of the, summary of the data that we have stored in the system. And this is sample data that we have so people can take a look around, basically. We have the navigation bar up the very top, and there's lots of different options. We won't have a huge amount of time to go through all of this.

So what I'll do is take a look at a more device centric view of what we have and what we can store for a particular device. So if we go into devices here, once we click on that, we will see all of the devices that we have within our source of truth. So if I want, I'll actually go to have a look at, one of the the backbone routers. So I could go to role here, select backbone, and apply that. And I will go to this guy here.

So once I click on him, now I see the detailed view for this particular device. So in here, we can see the site location and the rack, and we have all of that sort of physical information that we need. We also know the tenant or the customer that is gonna be, associated with this device. We know the device type. This is Cisco CSR, which is great.

And we also know, obviously, where we just searched on is the role, device role. This is something that's quite important within a network automation, architecture because we need to know what the function of the device is. So we could have multiple devices that are the same type or platform. But depending on the function and what it actually does will depend on what features that are enabled or what configuration we need to apply. So role is really, important metadata that we could store in a source of truth.

We can also see the platform related information and any other management information would be here. Key thing that we also have that is within Autobot is providing the flexibility to basically create custom fields. We see custom fields here, and it has a field that is associated with a device. Now this is something you can add for any devices, and it's sort of specific to your environment. In this instance, we've created an end of support field that should be associated with every attribute, that is, on a device.

And then here, we have it as a particular data, and that could be useful for knowing when a device is out of support. So each device could have that stored, and you can create as many other flexible, options or attributes that you need. Let's take a look at the interfaces. Here, we just detail all of the interfaces for a particular device. It'll capture the, the name of the interface, the status, and you can see some of the other information there.

We can also capture the cable, what the endpoint is, the device, and what the, the, remote interface is and any of the other, IP information as well. We could trace as well, and there's lots of other options that we do here. But this just gives you an overview of the type of information that we can see within, for a particular device. Another thing I'd like to just show you is It looks like we may have lost Paddy's Internet? Patty is back.

It looks like Patty is back. Did I drop? You did. We did lose you for a minute. We were just getting ready to, move on to Darren there if we needed to.

So, yeah, you could reach Erin. We can get we can pick back up. Funny enough, I actually heard myself in my headset, and I was like, that doesn't sound right. Apologies for that. So, we'll kick straight back into it here if you can see my screen.

Within conflict context, we can see that we have ACL and BGP data and route maps. So we can pull that in and associate that with a particular device. We can also do it based on, a site, and we could do it locally, so define it within Autobot, or we can define it within a, git repository and pull it in associated with a particular type of device or a or a site. The flexibility is there to do whatever we want really. So quite quite powerful in that respect.

One last thing that I would like to show you on the, device page here is that on this part of the page is that we have, additional plug ins that can be enabled. And plug ins are like a a first class citizen, I guess, within Notabot and that we can enable different apps, and that gives us additional functionality. So if we see here, the device onboarding, firewall policies, These are enabled, and we can basically get additional information by just installing these apps. So as an example, we have a a configuration compliance application, and this shows us that we can, we can track the compliance for particular features within a device config. And it does that by going and getting, going out to the network and getting the intended or the actual state from the network and comparing that to the intended state that we store in the source of truth.

It does the diff basically to compare it to see if it is, as it should be, and it will basically just tell us if it's compliant or non compliant. So it's a nice easy way to see if your device, is standardized across the design and how the network is performing. So I won't I won't go into any more there because we we will look at some of the plug ins and stuff a little bit later. And there is, obviously, a lot more that we could cover, but what we wanna do now is shift over to Darren. And we're gonna talk one quick question here on this topic.

It's not about collecting this information here via NetComm or RestComp and or telemetry hooks. The information, no. Well, so this information that was, put in was put in initially from an import and I could that's that's an easy way to get it in. You can use, like we said, the device onboarding would be able to go out to the network and pull it back in. For the compliance information, if that was specifically around compliance, it can go out and pull it back in the, the, actual state of the network by pulling back in the configuration.

And then it just compares it to what it has stored in the database for the intended state. Great. Thank you. Over to you, Dan. Nice one.

Thanks, buddy. I guess I guess some of the, some of the things you've touched on already are quite interesting, but but, IP fabric talks about, network assurance as being the next level. So from the compliance checks that we've already seen, these are based on on config. What the the role of IP fabric is is what we call network assurance, and this is basically making sure that the network does, what you intend it to. Not just one part of the network, the whole thing, by fair means or fail, I guess.

What do you do at the moment to to do that? Well, at the moment, you use documentation or tribal knowledge or guesswork often in order to make make that happen. And and the pieces of the puzzle, I suppose, are the ones that are shown on the slide here. Right? You you have an inventory.

You know what it is that makes up your network. But at the moment, you might use a CMDB for that or you might use an Excel spreadsheet or you may have a text file somewhere with with a list of all the devices in the network. Every time a new device is installed or decommed, then you have to go and make sure that that's kept up to date. Then, of course, you need the intended state for that device, and that's what we call configuration. Right?

That's the the config file, the templates, the backups of of what it is that that's stored on those boxes in order to to try and make the box do the thing that you want it to. And if you're lucky, someone's gone ahead and and installed some tooling to enable you to track that, or you may be using, some of the features of an Autobot to do that. The problem with config though is it's only what you intend to happen on that device. It's not actually what that device is doing at a point in time. That state information that's gathered on a on a device is is impacted by the things around it.

It's the network's a distributed system. Right? There's there's routing protocols running and so on that make changes to devices without you even knowing. So what you, what you configure isn't necessarily gonna give you the full detail of what you what you would expect to actually be seeing on a device. So you need to verify that.

Now most people use monitoring tools for this capability. Right? The the ability to determine and say, well, is a device up? Is is an interface running? How much data is passing through that?

How many errors are there on that? But it doesn't really give you the full sophistication you might need in order to work out is the device actually doing the thing you want it to. Then you're gonna need topology information. So you need to understand how those things are interconnected, what the what those interfaces are doing if they're layer 3 links or layer 2 links. Usually, you're gonna have diagrams to do that, and I know this is a huge part of, every network engineer's job and probably their favourite pastime is sitting in Visio drawing those diagrams out every time there's a change.

You'll see what I'm getting at here. There's lots of different tooling and lots of fragmentation in the process that that gives you that end to end view of the network. So so the point is that you can go through all these processes. You can have all of this information for perhaps for one part of the network, but then something else might be in somebody else's head or another part of the network you might have really good data for. And then, that key part in the data center, you might only have, 1 or 2 people who have a good understanding and everyone else is is a bit of a blackout.

The point with all of that is you've got different levels of data available. You've got lots of gaps, and what ends up happening, you fill the gaps through logging into devices and pulling commands out, and it's really difficult to get that consistent view across the entire estate. So if you can just go to the next slide, please, Patty. And sorry, Patty. Can you just go to the next slide?

Sorry, mate. So what IP Fabric is doing to to to fix this is basically doing a a network discovery. Okay. We log into those devices for you. We take the drudge out of gathering all the data from all of those devices.

And in the blue boxes here, you can see the information we gather from those those devices. So we we complete your inventory. We capture the config and that state information and create what we call a snapshot of the network, a point in time model of the behavior of the network. From that snapshot, we can then start to build upon that with, the green boxes you see on the on the left, the topology, so the diagrams, the visualization that basically replaces the need for for operational Visio, and then allows you to ask some really, really interesting questions of that end, end to end network. And I'll give you some examples of those now.

Just gonna share my screen. So the first first question that that I've got here is is really simple one. Which devices have I got? Where are they? Which code versions are they running?

So we've gone in, we've discovered the network, we've crawled through all the devices, and we can very quickly identify all of the devices where they physically are because we're able to, associate them with each other and and, locations usually based on maybe based on host name, maybe based on an external data source that you've already got, or or maybe just manually placed into into those sites. We've got information then, about what code versions they're running and so on. So you've got all of the information you would often see in a in a monitoring tool here really simply. But you'll notice a whole bunch of this stuff is color coded. What that is is IP fabrics gives you an idea of the assurance capability straight away here because what we're doing is we're colour coding based on conditions.

So for example, the uptime here you see is red or green. If I hover over the, the intent rules at the top here, you can see ones that are red are basically devices with uptime of less than a day. So we're able to build rules to say how you want to to be able to to, colour code these, and you can filter those things based on, on those, those rules as well. Like so. So for example, if I'm given a code version of a of a device a bunch of devices that I know is is bad and I want to go and find all the devices running it, I can simply build a rule here.

15 5 t, I've been told, is a nightmare. If I click through on here, then I've you can see the version column. All of these are the 55 t t, devices, and those are the ones that I need to go and do something about. So very quick understanding of exactly what sits in that network. The next question you might wanna ask is, well, what does my network actually look like?

We can see all the devices. Well, what does it look like? Well, what IP fabric's now done here is taken all the information it's gathered, from the config, from the state to build the topology. So each line in this die in these diagrams here represents a relationship between devices. If I zoom these slightly and show you in a bit more detail, this head office location, for example, it's a bunch of layer 3 switches connected to some layer 2 switches, with what we layer 1 and layer 2 adjacencies.

So in this case, if I just flip to the visualization setup here, I can show you. The layer 1, these green lines represent CDP or LLDP. Okay. I may not have that everywhere. I may not be able to trust it, so I'm just gonna turn it off.

I may want to dig more into the layer 2. The layer 2, I've got 55 spanning tree instances potentially across this diagram. I'm able to just pick one of those out, and visualize that. And let's turn off this this mandatory neighbor relationship, And there you've got, a map of the the the behavior of that VLAN in terms of forwarding, blocking, ports, and the root switch. The point here is is IP Fabric's delivering this visualization for you without you having to go draw new diagrams or or fetch the information by hand because the information is there in the platform.

And in this case, you can see I've got a bunch of different technologies here. I've got this this Cisco stuff, standard Catalyst switching. I've got, Azure connecting up here. So I've got, cloud instance here, and I've got SD WAN as well. So we don't care about those, those vendors, the the specifics.

What we care about is that they're network, objects that we're able to query them, pull information through, and deliver that to, to whoever whoever wants to look at it. And I want to drill down into more detail. So in this case, I've got a bunch of technology tables here. I can understand a bit more about how, for example, OSPF's behaving. On the left hand side, I've got the OSPF configuration.

I can see the interfaces where it's configured. I can see how costs are configured and so on. On the right hand side, I've got the state information that's been gathered at that point in time that relates to that relationship. So you can see in this case well, I'm I'm in a good good state here by the look of it because all of my, OSPF neighbors are are in full state. And if I look at the top here, that confirms that.

But I do have something interesting here. I've got a cost consistency problem by the look of it. So if I click through on here, I can see very quickly well, I've got a firewall connecting to a switch and a switch connecting to a firewall that's got a mismatch of of my OSBF costs on the interfaces. Being able to to pin down those kinds of things quickly based on the state, is is something that that without having, a whole bunch of automation scripts to do is gonna be a struggle. IP fabric gathers that, and it will give you that that capability very quickly just through being able to understand the data in these tables.

What that leads to is this capability, which which which is really bringing all of this information together. Because what I can now do is trace from from an a, end IP address to a b end IP address through the entire network, through every step of the way. So I've got it, for example, I'm gonna start at this router, pass through these switches across an MPLS network, through, another site with a firewall. My firewall is showing green, so it's passing the traffic through over a VPN tunnel out into Azure in this case. And I can understand the the forwarding behaviour at every step of the way.

And if if I really want to, I can dig into the actual path and look at the packet headers and and so on. All of the information is here in IP Fabric to to do that. The other aspect of that is, of course, that I'm doing this not just at one point in time. I'm able to compare this between different points in time. So for example, in the snapshot I'm looking at the moment, if I compare that with a couple of days later, you'll see that path has changed.

In this case, my primary, path failed, and so this is my secondary path. And you can see if I hover over the green here, this is the new path. Hover over the red, that's the old path. So you can see the the actual impact of that failure and what what's actually happened in the network as a result of that. And every single table across the, the platform is enabled in the same way so that you're able to gather that data and and compare and contrast those points in time.

The other beauty of the platform is this, that that this data is is great to view interactively, but this is also available over API. Every single thing we look at here, there's an API endpoint documented within the platform to show that if you supply the appropriate, payload and probe the appropriate API endpoint, then you're gonna get the data that matches what you're seeing in the UI. And that's the same, as data in the tables as it is with diagrams. We can pull the diagrams out in exactly the same way. We have the different, m API endpoints there for for if you wanna export it to SVGs and PNGs or whatever, or if you just want the JSON data.

It's all here and available just to to prod and pull out of the platform, which, of course, the API is the is the key to all of this and and certainly from a network automation standpoint. Because by by having access to that data over the API, what you can do is incorporate all of the operations that you see in here into automation process. You can you can update your documentation as part of your automation. You can query that that, information to help you, build the workflow to to say, well, I'm looking for all of the devices that are configured wrongly for SNMP. We'll just come to IP Fabric.

We'll tell you those, and then you can go ahead and use that as the as the basis of your process. You can create new snapshots and and update the documentation as part of the workflow so you're not having to go manually do that afterwards. So you're you're smoothing the whole process along. And, with the interim path, if for example, you're able to to basically validate that not just the individual tasks within a workflow are working, but the workflow itself has the desired outcome. The beauty of all of this, of course, is that that that API is there and available, and this is exactly what we've been working with with Paddy and and the guys at at Network to Code in really using to to develop a capability further, to to do some interesting cool stuff.

Right, Paddy? We've we've been having fun with this. Feel free to take the screen Great. Thanks. One second.

Okay. So SS DoT overview. So we we touched on source of truth earlier, and now we wanna basically take a deeper look at it. And what is SSOT? SSOT basically is single source of truth.

And we know that sources of truth are abundant, and organizations have different systems managing their network and who owns the data, that's that's obviously a a a complex topic. You know? And it's it often causes barriers to automation, But it is important that the data flows between the systems, to support automation. So if we have a look at some examples of the types of data, that can make up the intended state, and these would be selected. Inventory as we see at the bottom here and the the DCIM for your sort of location based stuff.

And then, obviously, the the IPAM and circuit information that you would have. But it can be difficult to maintain this authoritative data within a specific domain. And it is crucial to have, obviously, one source of record for a given domain. But duplication can happen across systems. And then if it does, you don't know which one to trust.

And if there's a lack of trust, then people are just ultimately not going to go to update that system. So we find that an aggregation layer can really help in managing that data. And it provide ideally, it could provide a unified API. And in that instance, it could be a GraphQL API or it could be a REST API, which is probably more standard. But this helps in streamlining, and this obviously supports automation.

So it streamlines, the endpoints that you need to talk to. And if you can provide that, you can aggregate everything to one endpoint. That can be really useful for the automation engine. In addition to that, it can overlay additional metadata across these different domains, which can be really useful and, that can really support, a really streamlined development for your automation systems. So Nodobot offers, an SSOT framework, and it has a plug in for it.

And this is sort of a plug in that provides a baseline to allow you to build other integrations on top of that. So we have some existing integrations, which we went which we showed earlier for the applications. And now what we can see is that there's, there's a lot of, like, apps that we can build to basically sync in and integrate, other data from other systems back into Autobots. So this is the ETL bit, which is the extract, transform, and load. So take the data from the system, do something with it, and then load it into your, into Nodobot.

Today, obviously, we're gonna focus mainly on IP fabric, And this is the the application that we're we're gonna show to you now. Basically, the the notable plug in SSOT for IP Fabric. And the the use case here is that we're we're moving data from IP Fabric into Nullabot, and that's where that's the sync direction. So we're taking the, observed data that IP Fabric has. We're using that to to basically build our source of truth.

So, this is the demo that we're gonna look at is to try and populate our source of truth. And that can be one of the biggest problems, really, is is, like, getting started. How do we get set how do you build your source of truth? So we're gonna leverage IP Fabric to do that. And then in addition, we're gonna show you how you can sort of run a diff between the snapshots that that IP Fabric takes.

Okay? So we'll jump over here to, Locobox. This is sort of a a a not a bot server that I have running, on my laptop here. So we don't have any device. It's basically blank.

We don't have any devices in it, at least we shouldn't. And we have no IP addresses. So what we'll do is we'll go over to the plug in section here. We didn't touch on this earlier. This is basically where we have our additional applications that we can load to provide, like you said, additional functionality for our network automation use cases.

So we're gonna jump into single source of truth. We go to the dashboard here. And here, we have the different data sources. So if we had multiple, SSOT applications, we'd see them. We only have one here at the moment, which is IP Fabric.

So this is like you say, we're gonna sync data from IP Fabric into Nodobot. It shows us here sort of, like, a history of syncs that we had. And on the right hand side, it shows that history as well. These are syncs that I had done previous. So we're just gonna jump in here and go with, the the form data that we see here for a job.

So once we start once we, click on sync, it gives us the form information that we can use before we can basically, kick off the job to sync. So we will select a snapshot, and we're gonna select this snapshot here, which is the day 2. It's smaller than the others, so it'll basically be quicker. These input parameters here are, more of safe safety mechanism. So the only one we wanna click here is the dry run.

We don't wanna run a dry run. A dry run would basically mean that we don't wanna commit any of the changes into the database. In our instance, we do. We wanna take the data, and we wanna store it in Notabot. Execution, we could we could schedule it, but, right now, we only wanna run this one.

K. So we click on run job. So that'll kick off, and that's us running a job which will, basically, connect out to IP Fabric. You can see here we're starting the job with all of those input parameters that we we had set. Loading the data in from IP Fabric and then, loading the data in from node about which is nothing.

It's empty. Then it does a diff to basically calculate what's the difference between the number of objects that it's getting in from IP fabric and the number number of objects that it has in Autobot. Okay? The div summary here will basically tell us that, okay. Well, there's we're gonna have to create 6 over 600 objects because all of that, data that's in IP Fabric is not in Autobot.

So if we're gonna pull it in, that's gonna be the change. Okay? So that's gonna take a few minutes. So what we'll do is we will go ahead, Diane, if you wanna jump in. I was just gonna ask the question.

You you've got, 600 and however many objects there, and and you're probably gonna cover this anyway. But what what are those objects? What is it that your data is you're pulling across from from IP fabric? Exactly. Yeah.

So if we look in here, we see this is IP fab this is the IP Fabric that we're connecting to, and this is the it's Darren's demo 8 server. Gives us a high level overview of some of the the attributes in there. But the the important table that we care about here is the data mappings here. Right? And the data mappings will show us exactly the objects that we're gonna sync in from IP Fabric into Nullobot.

So we have device, site, interfaces, IP addresses, and VLANs. So there's there's quite a bit of, obviously, of data that will come in the in these particular objects. There is obviously more that we could do. And I'm sort of thinking that on the back of the some of the plugins that we've released in the last couple of weeks is the BGP models and the firewall models. They would be real good candidates to sort of take data from IP Fabric and basically, populate those models and and the database for the like, our our firewall rules and BGP config, that type of thing.

I think that would be really useful. Is that something that we could do in IP Fabric? Totally. Because that that data is all there. So, you know, we're we're scraping all of the the the that config, but the the state data as well.

So we're able to to put all that through for security policies, for routing protocol operation, things like VXLAN overlays and all of these kinds of things. You know, it's all all that data is there. So there's no reason why, you couldn't bring that across. There's some interesting, I'm just just looking at the q and a and and the chat here and similar similar themes about the idea of of the the the kind of the difference, I suppose, in the data. Right?

So because you're using Autobot as this intended source of truth, what IP fabric's doing is providing that operational state. And it's, there's some interest there's always some interesting questions and we've talked about this one before, right? About, how often you use that data to to synchronize from one to the other and how you then use it thereafter, you know, when when changes are made. So, I don't know if that's something we can, we can touch on as well. Yeah.

Yeah. And that's that's it's an interesting point because, really, this sort of this demo that we're looking at here is sort of touching on the initial sync. It's to say, okay. I wanna build a source of truth, but but how do I do it? And that can take a long time just to to to find out the information in the network because it's coming from lots of different sources.

And most most organizations probably would say that the the network is actually the source of truth at the moment. Right? So then you could use IP Fabric to discover the network and model it and have an API that you can use to query it. Once you do that, then now what we're saying is, okay, now I can pull that data into Knowlobot and then start to build my intent from there and then use that data then to start provisioning or automating some of the process around how you manage your network. And that that that's the key thing that we're trying to do here.

And I guess I guess Christian's touched on it in the chat as well here already that that once you once you're then going back to the network to see what's changed, you've got the ability in a dry run, for example, I guess, to be able to to do exactly that. Right? Yeah. Exactly. So, yeah.

We can show that. So what we'll do Cool. This one's completed, which is great. Took about 4 minutes. And let's just check on the SSOT sync details.

Okay. So it's created over 600 objects. And we can see here the the basic, diff. And, obviously, it's gonna be pretty much all green here because there was nothing in Nullobot before. So it goes through and shows us exactly what's being created from a device perspective and an interface.

And further down, we'll probably see VLANs. It's it's probably easier to see on this screen because it's, rather than a diff, you can actually just go in and check the devices. So now we have all of the, devices that we've learned in, and we've created roles for them. We have our status, and we have the different types, also the sites and the IP addresses. So now we've basically, provisioned or started to to import the data and to start building our our intent, in our in a sort network source of truth.

Again, we had lots of IP addresses here, and all of that data is in there. So, on that point though, what we could do is to say, yeah. Well, if you wanted to now that we have it in, the data is in there. If we wanted to sync against, another snapshot, we could just check to see what the difference is between those. So we we could run a dry run, as Darren has said, and we select a different snapshot this time which, has slightly different data.

And what we can do is if we run that, we can see what the difference is between us. So that could be if you basically made a change or you made a widespread change across the network and you wanted to check between those snapshots. It would be able to load all the data and tell you what the difference would be. So it's essentially doing a diff on your network to see, what the changes would be. And if we we could see at a high level what the summary is there to so that that it would create an additional 300, objects, and it would obviously make some updates and remove some things.

If we go into the sync details, it gives us, an like, a low level look and a detailed look at exactly what's changed. So in this instance, the device has changed its, its management IP. So it used to be 2, and now it's 0, 21. And we can see that some other interfaces have been added in, and then, obviously, quite a lot of data. Okay.

So you got some new devices? Things have been removed. Yeah. New devices. Yeah.

So lots of a new PE gone in there as well. Yeah. So it's it's yeah. We can run it in dry run and see what would change before actually committing the data. And that's that's the value of adding the dry run there to make sure that, if you you can check the data and see and that you're happy, and then you can import it.

Okay. I think that is on that. So let's jump over to the chat ops overview. So another application that we have within the nodabot ecosystem is the, chat ops framework. And this provides, basically, a multiplatform, chatbot that can be used to to integrate into other systems or external systems or it can be used to just run, different jobs within your source of truth.

So the it's it's quite extensible, and, really, it's very flexible in terms of what you need to do. The chat application itself, obviously, like, is is very common within enterprises. So providing with with a new interface into network data through an existing application is quite powerful. You don't have to vet the the the application, and you're just basically running the, additional functionality through the chat application that everybody has access to. So what we're gonna cover today really is the IP Fabric chat ops application that we've built.

Okay? Then it uses the there's a chat ops framework as well, and that allows us to to build on top, and that gives us that multiplatform capability. Here we see the existing commands that we have for our IP fabric chatbot. And, obviously, the the real value here is that we get to, create your own commands. You don't have to use only these commands here.

You can extend that. You can basically create your own commands that would have, something that would be useful for your environment. Like we said, it could interact with multiple systems. It could do, lots of different things and basically give you the capability to sort of aggregate and transform and display information and and and display it back to the user within a chat window. So it's it's really, really powerful.

Expose some self-service capabilities to other teams, something that you may normally get a ticket for. And now you can sort of create a chat command for that and rather than having to to dig into the network and and and, do some, troubleshooting or some, some investigation on certain, some certain issues that users can have. You can expose that functionality as a chat command, and that basically gives our capability for other teams to access the network and see data within the network. And that's a key thing. So in terms of the demo, what we'd like to look at really is sort of, the chat commands.

Some of the commands that we had shown there, we wanna basically get some connectivity information for a host. We'll have a look at sort of BGP peering details, which is a a big one for a lot of organizations, And then, a lookup path, obviously, the trace through a network, being able to having a source and destination IP and and and finding out what the path is. Okay? And here's a high level overview of how this would sorta look and what the the components. So you'd have your chat window on one side and making a webcast back into your your chat platform, whatever that might be.

Could be Slack, Teams, Webex. That then will talk to your chatbot server, which would be on the Nautobot side. And that then will, initiate requests out to IP Fabric to pull back in the data, do something with it, and then display it back into the chat window. So let me jump over to my chat application. And let me do this IP fabric.

Okay. So if we do a slash IP fabric, it gives us the main command, and this shows us all of the different options that we have. And first option that we would do is we would set our snapshot. So we set snapshot. IP fabric.

Set snapshot. Now we wanna go to snapshot 2. This was the one that we had selected. And, basically, that will set it. That set the context for any of the other commands then that we're gonna do because we're gonna query against that specific snapshot on IP Fabric.

Okay? So let's let's try and find the host. So for us, if we have quite a useful command, really, for for anything, not just for network engineers, could be security, security team or any other teams that are computer storage team that need to find out where a particular host is connecting on to the network. This is quite useful for for those teams and to expose that capability, to other teams. So if we do find host, we select IP here, and we should get a little window like that.

And let me get my IP. And if I enter in my IP, it should query IP fabric, and it'll get back the the details that we get for that particular host and what site it's in. It it'll also show us the gateway or the switch that it's connecting on to and the interface and give us some, host information with the MAC address. So this is a quite a common one, Darren, isn't it? This is something that's quite useful for yeah.

Obviously, you know, it's the whole thing of of how do you track down where where someone's connected. It's that trawl through the network looking for MAC address tables and spanning tree and, and and, ARP entries and and that good stuff. Right? So it it it's a a really useful, corner to cup, really, I suppose. It's, it it gives you gives you an instant response.

Yep. So let's check, if we also had, which is one for, some network changes. If we wanted to check on our routing updates, we'll check if there was right now, we have supported that we wanted to check, if there's BGP, peer relationships, and where what status they're in for a particular device. So if we just click IP Fabric Routing, we'll get to select a device. So if we selected a PE device, do we have a PE device?

We should have 1. Yeah. There's one there. Yeah. I'm gonna select PGP neighbors.

So here, we basically get back to say what type of state we wanna go in. Now we normally, when we're doing a change, pre change or a pre check or a post check, we don't really care about the established ones sometimes. You wanna know which ones are not which ones are not connecting. So if we select active, here we would see, we have 2 devices that are active. And this can be very useful just to to consolidate that sort of information, not get a huge output of all the all of the BGP peers that aren't actually, or that are actually connected with a lot of information.

Here, it just gives us a quick hit on the status of these particular, connections and their endpoints and the VRF that they're connected on. So it's very useful. The beauty of that one as well is is is that you're getting the configuration, but also that that that state. Right? So you're checking on the state within that snapshot of of what's going on.

And that total received prefix is column. Right? It's always a useful thing. If you've got an established peer, but you're not receiving prefixes, then that is not gonna be very helpful when you fail over to that link, and you're not gonna be able to do it anywhere. Right?

That's it. Okay. Last one that we wanted to check was really if we wanted to trace through, a network. And so we wanted to we have a a source and destination IP. Somebody is basically a ticket has come in or something, where you wanna basically quickly check what a path is.

So we have a command that would allow us to do a a path lookup. And let's get some we're using that, demo or day 2. So let's get source and destination IPs. And now what we wanna do as an engineer is just basically do a, like a like a traceroute, I guess, where we would what IP Fabric gives us is the capability to have a visual representation of how that would look across the network with the components and the nodes that are in in place. So we have a the command that we will enter is just a path lookup.

We give our source and destination IP, and we wanna look across a specific protocol, in this case, HTTPS. So once we issue the command, we get back the, the diagram, and we can see here it's it's it's very easy to see the path from source to destination. Right? So we say Yeah. It's coming in on the left hand side and the router coming across our colo, a couple of switches, hitting into the MPLS, on the PE, and then it hits, into the, head office.

Seems to be hitting a switch, and then it looks like it's hitting a firewall. Do we need do we need to know anything else with that firewall? The firewall's red. Right? So what that's actually telling you is that the firewall is not passing the traffic, on towards the destination.

Right? So what you've what you've got there is an application that you've run that you want to run on the network and won't work right now. Right? Because that firewall is, is causing you a problem. So, maybe if you have a look at, say, ICMP through the same same source and destination, and we can have a look at the path.

Okay. So if we do a path, we also have another command, which is the path lookup ICMP. Here we have our see, it's a actually, we can just do it like this. And then we can get a service destination IP. That's gonna be the same one.

So last time we checked, it was HTTPS. Now we're gonna check and see if ICMP is gonna pass through that firewall. Does it look any different? And is this that's something that we can check here. Echo reply echo reply.

That's probably okay. Let's Let's check that one. Ah, okay. Ah, Yeah. Okay.

Yeah. So now we see the firewall is green. So it's obviously it's passing ICMP traffic, and it's allowing us through out to the cloud. And the destination is in, Azure. Yeah.

Yeah. So there you go. So so the the the next sort of, the next action action on that, I guess, is then to go back to IP fabric, itself. Have a look at that firewall. You can dig into the security policy that's actually causing that to fail.

Right? So we can actually show you that, show you the exact point where that is. And so then it becomes a a query to the to the security team to go to go deploy the appropriate policy. But Yeah. Yeah.

You can you can give that to, I don't know, a server a server team or application team who want to be able to deploy an application, they can do a quick check to say, well, if I deploy it, will it work? And if it won't work, why won't it work? And if they can narrow down quickly that it's a firewall that's causing a problem, they don't need to engage anyone from the network team. They can just go straight to the security team and say, look. There's some security policy here that's stopping my application work.

Can you fix it, please? Yeah. Which is really useful, though, to be able to see that, right, and then have it available in a chat command is is really powerful that you can just run that. To to share the information across all the people who need it. I mean, that's that's the other thing.

You don't gonna have to sit and wait for a network, the network team to go and and find that information out for you. So Exactly. Great. Okay. I think, I think that's all we had.

So I apologies, Tim. I think we ran slightly over there. I had a lot of connectivity issues, so apologies for that. All good. We have a couple of quick questions.

Maybe we can just chat about live here, and, we'll go maybe just a few minutes over. One question, getting back to the, single source of truth idea and using IP fabric. Supposing, you know, you have an environment where I'm not gonna automate all the things all at once, which is, you know, everybody's environment. Right? You you can't do all the things all at once.

So what do I do where I have a scenario where I've got some portion of my network automated, and I'm driving that from my source of truth from not about And I have some portion of my network that is not automated, and I'm getting that actual state from IP Fabric. And let's say I wanna sync those two things. How do I deal with that problem of, you know, some of it's coming in from IP fabric with actual data from the network versus I'm driving intent from sort of from Autobot into some other portion of the network? That's a really good question. Shall I start?

Yeah. Sure. Okay. So, yeah, I mean, we always talk about IP fabric as being that observed truth, if you like, the the the operational state. And and from that perspective, you're always gonna want the the the brownfield, the the everything that's in the network.

You're gonna want that in IP fabric because the real value comes from having this this end to end view of the whole network. There's a couple of ways of of of dealing with with that situation, I guess. You could in in IP Fabric, you could create, smaller snapshots of just the areas, that are that you're running the automation for, for example. So you could you could simply gather a separate snapshot of the state that's that's, being built through the automation platform and then just synchronise that back. Because the other point here is that that we've and we've talked about this, the the diff sync.

One of the things that we've also talked about with the team is is looking at conditional, conditional synchronisation. So being able to filter the things that you want to synchronise back into. And I think that is, you know, that's certainly something that that we'll we'll hope to to develop further as we continue in conversation because it's this is relevant to not just, data coming from IP Fabric. This is coming from any external, source into the SSOT, database. I think that's fair, Paddy.

Yeah. Yeah. And, one thing I'll add to that is that we we do have the capability to add a site filter for, for data that's coming in from, IP fabric, and it will only sync for a specific site within Nodobot. But that's the capability that we have right now. And as Darren mentions, we are looking at ways to basically get a more granular control, on, a, the models, and then, b, the attributes syncing across as well.

Great. Thank you for that. And that actually, is the last, question that we have here outstanding that I'm aware of. So with that, thank you, Patty. Thank you, Darren, for this, great discussion and presentation today.

And, with that, thank you again to all of our attendees, of course. Thanks for joining and listening in. Great. Thank you. Thank you very much.