Thanks for joining. We regularly hear the story, that networks are becoming more and more complex as we build more capability into our IT systems. So networks that underpin them need to provide ever more sophisticated mechanisms to ensure that those systems and the services they provide stay online and available to the business users who depend on them. Now the truest definition of network complexity really revolves around the interaction of the elements that make up that network. And when you've got a wireless environment to connect your users to a campus LAN, which in turn talks over an SD WAN, which is overlaid over public and private WAN circuits to a data center infrastructure, which is then connected over private circuits to a public cloud provider where the infrastructure lives and where applications are hosted.

And then you have distributed security solutions throughout all of those domains offering a selection of mechanisms to enforce policy, well, there's a huge amount of scope there, right, for things to go awry. The potentially different configuration, different policy management mechanisms for every one of those domains, and significant control plane interactions required in order to stitch all those elements together to ensure that you've got that end to end connectivity for delivering your applications. Now with that variety of mechanisms at play, the range of vendors in these separate spaces and all of the different challenges that need to be addressed in each of those domains, I think it's fairly obvious that it's unlikely that we're gonna see any unifying standards at any time soon, which will allow us to have that single management point and consolidated control plane for all of these network and security elements. So should we just give up with trying to maintain that that complexity? Is there a light at the end of that tunnel?

Or I suppose in recent times, we've been looking at different supposed solutions to alleviate that complexity. Software defined networks and network automation, kind of the latest in a long line, I suppose. These can be seen as partial solutions to the problem. But the issue here is that typically, they only cover a part of the story, perhaps one of the many domains that make up that modern network. We can, of course, use automation techniques to create process workflows to deploy consistent policy and configuration across those network domains.

For example, you might want to deploy a new service, and that might mean creation of a new VLAN in the data center fabric, enabling the routing for that VLAN perhaps, and then propagating that route across the the WAN environment to the campus. There may need to be firewall rules that need to be opened up to allow wireless users in a particular location to have access to that service. And what a workflow might do is take all of the automation elements required to enable that and bring it together into a single process. But let's face it. It's unrealistic really to expect to be able to just flick a switch in in any real network and completely automate all its configuration.

The example I just gave takes time to put that together and understand all of those elements. You might only be able to do some of those elements manually, some others automatically. And so you end up in a in a hybrid approach with both manual and automated configuration in the one environment. Automated maybe in certain domains or vendors, but only in those areas. So how do you then ensure that you've got full end to end visibility to be able to maintain your service availability?

How do you manage? How do you monitor? How do you troubleshoot a network while you're going through a transition in order to move to that automated approach. Once your automation is pushing template to config as per its process, how do you verify that it is actually doing what it should, and what needs to be adjusted and changed if it isn't? My name is, Darren Forwell.

I'm IP Fabric's product evangelist. And over the next 20 minutes or so, I'll be explaining just how IP Fabric's network assurance capabilities can bring a little calm to the storm of complexity across your network. I'll explain how our product helps you by mining the data that's hidden through your network, and then it builds a model from it, which allows you to optimize your operational process to ensure that you can maximize your service availability. As we go, we'll take a look at some demo examples of usage of the platform just really to illustrate some of the more salient points, And then I'll take some questions before closing. As mentioned before, please put questions into the q and a throughout, and I'll cover those those before we, before we close.

Without further ado then, let's dig in a little into how IP Fabric's network assurance functionality helps create a more efficient, robust, and available network service. The first step is for us to appreciate just how IP Fabric interacts with your network. IP Fabric's discovery process uses CLI on individual devices or API access to a centralized controller where where you have one available to discover the state of the entire network at a point in time, after which it analyzes the control plane and forwarding behavior across the entire network and builds a multilayer vendor neutral model of the network and the forwarding through it. That model is stored in a series of databases and then becomes available to be queried in a number of different forms via our comprehensive API. The product's web user interface uses that API to provide you effectively with live interactive documentation for your network with searchable tables and visual representations of topology and path simulation through the network.

We also build in compliance reporting across all the operated network technologies. The API is also exposed to external systems. So our integrations with other operational tools such as those you can see listed here. The system ships as a self contained virtual appliance. Within minutes, it's possible to have it up and running and creating its 1st snapshot of your network.

And then typically within hours, that first snapshot will be complete, and you'll be laying out your automated diagrams and looking to see what, what appears to be going well and going badly in the configuration and the state of your network. Most customers will run 1 or 2 snapshots a day in order to get the full benefit of having that regularly updated picture of the network. Now having seen how we gather the information about your network, let's take a look at the top nine ways that IP fabric shows real and specific value in your network operations. First up, using just a standard set of credentials, IP Fabric will automatically discover your complete network and its state in the blink of an eye. We create an inventory and a visual topology of the current network and its state by crawling the network and mapping out its forwarding behavior.

Just the way, in fact, that a network engineer would if he or she could run 30 terminal sessions at a time and correlate all the outputs and and, was a whiz with with Visio. That then translates into powerful documentation. We retrieve 100 of data points from every device that we query. But more importantly, we build relationship information from that discovery, and that allows us to build a complete accurate documentation of everything from the basic discovery protocols through layer 2 operations, spanning tree and VLANs, to layer 3, routing protocols like BGP and OSPF and beyond, will go into VXLAN overlays and ACI will go into, public cloud environments, SD WAN, those types of things. Then we make that that information available interactively through our WebUI in tables and topology diagrams replacing the need for printed or static documentation.

And because those snapshots are run regularly, that documentation is always up to date. I wanted to just show you at this point, an example of the, the diagramming in the in the platform to give you that that automated documentation view. What you see in front of you here, with, lots of colored lines and and icons that you'll hopefully recognize, this is a standard, site within IP Fabric. Each of the icons obviously represents either routers, switches, and firewalls. IP fabric also will discover your load balances, your WAN optimization, all of the elements of a network that are going to forward traffic.

And and, we we can build a topology and a and a view with those devices. And we operate, the majority of enterprise class vendor equipment. We're adding new things all the time. Now what you see here, a device is interconnected with with different colored lines. Those colored lines represent the layers, at which we've discovered adjacencies between devices.

So down the right hand side here, you can see green lines represent layer 1. Discovery, in that case, that's CDP or LLDP, those types of discovery protocols. Blue lines represent layer 2 discovery, so this is using spanning tree and MAC address entries and and forwarding at layer 2. The purple color represents layer 3 discovery. So this is where we have routing table entries that point across interfaces to other devices.

The beauty of that is that if we don't have a discovery protocol like CDP or LLDP, it doesn't matter. We can still understand how the network's put together because of the approach that we take to to the discovery and because we're using the actual behavior of the devices, to build that that topological view. And you can see down the left hand side here, we've got a whole range of different technologies that we're extracting information from, in the, in our discovery process. And that allows us to to visualize a lot of that information on directly onto the, onto the diagrams here and customize these views. So for example, if I wanted to see across our switched environment here, where VLANs were forwarding over spanning tree, I can simply click on one of the trunk links, select a VLAN, and open that up.

And, you can see here wherever I show a green dot, that's where I'm, forwarding on that particular VLAN. And and if I'm blocking on any of these, you can see here, for example, it just grays the line out. So in VLAN 110, I'm not forwarding across this link, for example. And the reason being that my root switch is is shown down here, as as this switch ac7 here. And so that that's what why spanning tree is built out the way it is.

Now that is impressive enough. But if I now, wanted to overlay a second VLAN, it's a simple case of going through the same process, and there I've overlaid the second VLAN. Now in this case, my my second VLAN actually has a route somewhere else, and so the topology is completely different. And the amount of time and effort that that whole process saves just because the data is in the platform and we're able to visualize it, well, I know I would have spent, hours getting to the bottom of that with a pen and paper, which I have done many times before. Similarly, in the layer 3, what I can do here is all I'm doing at the moment is showing a group view of all of my layer 3, topology.

But I can break out the individual protocols that that are used to to determine that. So in this case, I've got BGP sessions running into my MPLS network. I've got OSPF adjacencies between all my routers. And I can visualize even where I've got multiple, adjacencies showing. In fact, in this case, it looks like someone's over overcooked it and, and misconfigured this and and not passed out a load of interfaces because we've got a whole load of extra adjacencies here we don't need.

But this just gives a very quick, very, very clean understanding of exactly what it is that we, we can gain from having all of this data available to us, in order to to visualize it. And basically give us that that online, documentation. Now we have it on good authority from from many of our customers that, IP Fabric can save time with their automation projects. 1 in particular, produces a statistic that says that 95% of the work behind normal network automation projects really comes in the toil of logging into different network platforms, fetching data, formatting it into usable data structures that are then able to be used in in other, logic and and other scripting. Well, IP Fabric discovers your live inventory, and then it captures all of the information that you've just seen, that technology data for you and offers it up through a simple to use API, which in itself cuts down hours of development time from your automation projects and really saves you from days days of maintain maintaining the automation ecosystem that's needed to do that.

There's a lot. If you were doing that using open source tooling, you'd be using lots of different tools working together in order to achieve that same output. With IP fabric, that's not necessary because we do that for you. We can introduce a level, of previously unseen of service efficiency Using a simple compliance checks, IP fabric discovers and centrally highlights things like single points of failure or policy and functional inconsistencies that can cause costly errors and outages. There are dozens of these checks in the platform based on years years of engineering experience included for your use when you when you first log in.

But, of course, you can also add your own, checks based on your own organizational standards and whatever hardening requirements you may have in your your management and control planes and so on. I wanted to just show you a couple of those, in the platform. This is a really good example, where we have, because we have an understanding of the topology of the network, because we have an understanding of which devices are connected to which on which interfaces and how those those are operating, we're able to do things like this. This particular table is a representation of all of the in interfaces in the network where Duplex is configured, at either end. And we're able to match up whether these the the the configuration state on one end matches that on the other.

So in this case, we have an intent verification rule built here across the, across that table, which essentially colors that left hand column based on the fact that, we look at the the that, duplex, and we can confirm, does it match what's at the other end, or is there information missing in this case? So if it shows as blue, there's information missing, and that would normally be on certain platforms. It may not report the the duplex properly, or it may be that it, is a is a fiber connection, so it's assumed to be full duplex. But in in cases where you've got, duplex that could cause a problem, I. E.

A copper interface between 22 switches, we'll take the the duplex one end. We'll take the duplex the other end, and we can give you that very quickly. Simply by clicking on the on the red state here, we can show you instantly, where devices are mismatched. Like so. And you can see here where we've got full at one end and half at the other or full and auto or half and auto and so on.

So we've got that mismatch, and we we have that information instantly available. It's just one example of of many, many of the intent verification checks in the platform. I'll give you a very quick view of of what some of the others look like. We can do things like validate, environmentals in the environment. We can look at management consistency.

We can look at stability of the of the routing protocols across the network and so on. Because we have all of this data available to us, we can report on pretty much any of it. Okay. Now as IP Fabric is snapshot based, tracking changes to inventory, topology, configuration, or state over time is simply a case of comparing the results of the snapshots. Using those snapshots gives absolute clarity when looking at the impact of changes in the network, for example.

Comparing the state from before and after a change and visualizing those states ensures that you can clearly understand the full effect of the changes on the network and validate indeed that they've completed the way that you planned them to. I've got another example for you here. We'll just step back to the GUI. So in this situation, what we have here is a snapshot containing, a location that's going to be expanded. There are there's there's a requirement to add some capacity into the network here, and well, you can see fairly clearly from from the diagram, there's a bit of a gap here.

The intention is that, that some switches will be be added in. They'll be connected into these distribution switches here, and there'll be some configuration changes on these, the interfaces here to fix that. Now as as well as that, while we're preparing this change, we've got all of the data available here about how those those, interfaces are currently set up, how they're connected, what the descriptions are. We can we can see, for example, which interfaces are currently down, so available to be used. All of that that is available to us immediately.

But you can also see we've got some some shady descriptions here on some of the interfaces that we could probably do with tidying up as we go. So our change will be to add in these, additional connections to bring in those new switches and to update these descriptions and and get that, get that fixed as well. Now let's imagine that that that, that's been executed, that change has been executed, and that we've got, IP Fabric is busy, every night creating a snapshot of the network. And so we can show very quickly the changes that have happened when that snapshot has been run after that change was create was carried out. So in this case, just by by overlaying the changes onto the one the one view we have here, you can see that our 3 new switches have been added inside here, that we've got connections going back into those distribution switches.

Now it's not quite symmetrical, and we can see that there's there's a potential issue here. So what we wanna do is perhaps have a have another look at that, in a little more detail. Let's zoom that in. So we can see that we have, based on what we saw before, we have the same view in terms of the the the multilayered, view of the of the environment. You can see that we've got CDP or LLDP running between this switch and these two distribution switches, but we've not got a complete view of spanning tree.

There doesn't appear to be any layer 2 forwarding happening over these 2 interfaces, for example. If we click through on here, this shows us there are definitely 4 connected interfaces. In the same way, there are 4 connected interfaces over this side, but there's no spanning tree forwarding there. So there's configuration problem or there's some issue here. Without having that that multilayer visualization, we would probably never have noticed that was an issue.

Now we can click through onto our our distribution switch here, and we can go ahead and fix, find out where that's gone wrong and and what's going on. It looks like our port channel here is down, so that may well be the issue. But now we can also see that our descriptions have been updated as well from the change. So we've got that better quality information simply by pulling through configuration directly from the, from the network as and when it was changed. And so now we're in a position where we can go ahead.

We can tidy that up and fix the issue, and we can see then that the network will behave as we expect it to. Now complete visibility of your network and security estate together allows you to start thinking about highlighting situations that might occur in your network that you might not have seen previously. Traditionally, the security team have looked after the security appliances and and the environment and the network have looked after theirs and never the twang. Or they have met, but often through, clunky communication processes. Because we're able to bring all of that data together into one place, we can start to look at highlighting unwanted bypasses and policy violations to ensure that security posture is as you intend it to be, making your network less susceptible to intrusion.

Compliance checks also mean that we can take that further. We can validate that devices are running trusted software or that they're running, they have appropriately hardened management and control plan configuration. But what I'd like to do is just show you, very quickly how we use, the end to end path capability of IP fabric to actually validate some of the, some of the security in the environment. So in this situation here, what we have is, an end to end path simulation. This is, going from a client in a in a, an access network, in in one of our sites, site 47, cross our MPLS network into a data center and trying to talk to a web server here in, in the data center.

What this actually shows us, the path is, a rooted path. Now I've turned off layer 2 in this case, but I can turn that back on and show you that we can actually see what that path looks like, over the layer 2 switching to get it to to follow, follow that rooted path. But sometimes you don't need that visibility. So let's turn that off and, and focus in on the on the layer 3. You can see that as we're going from hop to hop, IP fabric is calculated in the the simulation of where packets packets will flow in order to to get from one end to the other.

And if we click through on one of the devices, we can show, the actual routing decision that's been taken at that hop in order to to traverse the network. In this case, we're coming in on source ethernet ethernet, 3, and we can leave by 1 of 2. So we've got an, an equal cost multipath routing decision taken here, and we can go one of 2 ways. And that's highlighted in the in the green there as you can see. At the next top, we've got, a little ACL flag here.

And what that's telling us is as well as a forwarding decision being taken from ingress interface to egress, we're also doing a policy check, and we're making sure that we have an a that the ACL that's applied on the interface here also matches in order to pass that traffic. This is good stuff. This means that if you've got security rules that are in your network but it also has to match policy. But it also has to match policy. We'll go across our MPLS network, and and if you're interested in in looking more deeply at the MPLS, you we can show you that the MPLS forwarding decision has been taken complete with the label, that are used to do the switching.

And then we'll drop into our data center environment at the other end here. Again, we've got, routers with ACLs applied, and we'll pass through those routers and eventually get forwarded to our firewall here. Our firewall also shows our forwarding decisions that's been taken. It has routing tables after all. It's a routing device.

And in this case, we've actually got 2 routing decisions because we've got multiple VRFs. So we're we're understanding that traffic comes in on one VRF, actually goes out to another firewall, off to the left there, as you can see. And then it'll come back into the firewall on a different VRF in order to get towards the destination of the, of the workload that's running the service. But as well as that, as you'd expect, we also look at the the the firewall rules themselves that allow that traffic to flow or or not. In this case, you've got a permit for both, both VRFs and the both access, rules that are applied.

And so we're permitting traffic to flow all the way through. Now there may be a problem here because what if the, application owner decides to implement HTTPS instead of HTTP? Well, we can very quickly run that simulation to see if that would have any impact. And in this case let me turn up the layer 2 again. In this case, you can see our firewall has now gone red.

The reason it's gone red well, it's not the forwarding. The forwarding is still showing as green, but the zone matching rules are now showing as red. And the reason being this deny statement here is being hit at the top as we're leaving the WAN heading towards the host 126. That policy is is breaking. We can dig into that in a little bit more detail and just have a look at the the policies in total.

And you can see here the the way the policies work. We're denying SSH. We'll permit www, but that just means HTTP and not HTTPS. And then we deny any traffic, so we're hitting the end rule there. So there's a firewall rule that needs to be updated and fixed.

Now this is a bit strange because there's there was a a situation here where this was working previously, and we want to understand why. Well, what we can do, similar to before, we can take a snapshot from a from a another point in time and overlay that and look at the differences. And here you can see the difference. The difference is that in this case, the firewall where it was previously being, having traffic pointed to it in order to get to that endpoint, is being bypassed. Yeah.

The there's the routing has been configured on routers 56 here in order to point straight at the the, the subnet where that where that endpoint lives, and the firewalls are no longer, being accessed. And so here's an issue that that you wouldn't pick up if you were just monitoring your firewalls or just looking at your firewall state. And the reason why you need that combination of network visibility with security visibility to pick out issues like this where, that that combination of functionality and configuration is what's used to actually enforce the security. Really good example. Now with its powerful API and webhook capabilities, IP Fabric becomes the cornerstone of your network operations toolset.

Through integrating your network tools, your reference data becomes definitive, and you need never create copies of that data to use in other systems. You build a powerful flow of information, which enables teams across functions to make the right decisions and derive new value from their standalone tools. Our customers and our partners are using IP Fabric in conjunction with everything from automation platforms to ITSM tools, from monitoring platforms, to CMDB systems. And really that feeds straight into the next point, which by creating the accurate single point of reference for network information, you can securely share sensitive network information between teams, breaking down silos and ensuring that data is democratized. No longer will your security team have to request information about security config from the network team, as we've seen, or the project implementation folks won't have to wait for copies of documentation of the live network from operations before they can plan any new development work because they simply log into the system, as we've seen, and they have that information available to them.

And because data is constantly kept refreshed and accurate information is available daily, then all the weeks of preparatory work for compliance audits, for example, become a thing of the past. The data is always there and always available to whoever needs it, even to the procurement folks who are looking for an up to date inventory for renewing support contracts. IP Fabric fosters relationships between the product team, between users, integrators, curious network professionals, and technical peers to share ideas, integrations, code, or just discuss stuff. Community fabric is an open melting pot of experience, discussion, inspiration, and integration across GitHub repos, YouTube channels, Discord servers, emails, and Slack chat. Now having seen all the value that IP fabric can bring to your organization, consider now how deployment into your network operations matures over time to continue to increase that system's value to your operations.

We see 3 main stages to deployment of IP Fabric in our customers. During the first, the baseline phase, the primary challenges we tackle are those caused by having inaccurate data and unreliable process wrapped around the network. We help solve those initial issues by creating that automated documentation that we've seen through our discovery, through our topology analysis, and our compliance reporting, helping to indicate where there are hidden problems that aren't yet necessarily evident in normal operations. As we move forward into the operate phase, we're really starting to integrate IP Fabric into the day to day operational processes, tackling challenges like slow incident response, enabling people using our end to end path simulation capabilities, and by tracking changes in the network from snapshot to snapshot. We also help where there may be siloed operational teams, as we've seen using conflicting systems of reference to their network data by giving them access to our queryable network database.

And that third stage of maturity is that of innovation where IP Fabric has been fully embedded into the operational ecosystem and the data in the platform is now available to help build trust and increase time to value in automation projects through our open API. Using that community of partners and customers interacting and sharing ideas and code just helps that process along and makes integration with all kinds of operational systems, including chat ops and and new, interaction capabilities a reality. Ultimately, the goal is that of intent based networking. What this means is you take an expression of intent for the network, whatever that intent might be. It might be an abstraction of your configuration, or it may be more a more general, idea.

You define that in a source of truth database that's used by a fulfillment function, and that will be network automation or, service orchestration or or something similar, which delivers rendered configuration into your network devices with the intention of of, delivering that very intent. The key to it is having an assurance engine. That's where IP Fabric steps in to validate that that intent is being met, that the configuration of the network is as you expect it to be, and most importantly, that the network is behaving the way that you intended. And then you can either adjust the intent itself, so update the data that's being that's in that that source of truth, or you can feed back into the fulfillment function in order to ensure that automation is updated, that, further activities are, kicked off, and that you gain a balance and the network is now behaving as you intend it to. I'm gonna pause, there for some questions if you've got any.

It'd be a good time to to look at those. I've got one that's come up, earlier in in the chat, and it's an interesting one. Does using overlay technologies like SD WAN or or NSX not make networking simpler? It's it's a little bit of a religious debate, this one, almost, but, I think the the point of an overlay technology is to create an abstraction of the the complexity that sits underneath that so that people can consume it in a different way. The overlay technology itself may be simpler.

It may be easier to use. And so for the person who's who's actually, using it, and that may be, in the case of NSX, that may be a server admin or an infrastructure person who's who's wanting to to connect to a network and have access to to certain capabilities. And it may be dead easy for them to to to use that regardless of where they sit on the network. If they're running NSX, they can just drop into a virtual network and away they go. The problem, of course, comes with the fact that what sits underneath that overlay in order to make it function, You have to have an underlay network to carry that traffic.

You have to have interactions between the underlay and the overlay, And then the very definition of complexity in terms of those those interactions and relationships between different elements starts to come into play. So operating, overlay technologies becomes almost more complex because you're having new interactions and and adding new layers of, of connectivity that you didn't have before. So that, hope that answers that question. Do we have any more? Great.

I've got a couple here. That's great. So, Claudio, third party API integration is flexible. It comes with new releases of IP fabric system. Right?

So in terms of our API integrations, what, the the API itself is open and documented. And and as we, build the platform, so we modify and update the documentation all the time. Every single function you've seen in the platform and you see in the platform through the web UI is accessible. Every piece of data is available through that API. And so for for flexibility, what we, the way we build integrations is usually using scripting, to allow us to to get the right data, to process it in the right way, and to give us the ultimate flexibility as to where we then push that data on.

We've got all kinds of, integrations up and running with customers at the moment, into things like ServiceNow, into monitoring forms, and so on. And it is purely a case of being able to extract the data at the right time in the right form, and and then, use something like Python to manipulate it into the right form then to forward it on into into other systems. So completely open, and is regularly updated. Peter, so which stakeholder are you talking in prospecting phase? This is a really good question.

We we try to engage a number of levels, when we're talking to to potential customers. As you can probably tell from the, from the the nature of the the platform, it's it very much appeals directly to the network engineer on the ground for a number of reasons, not not least because it saves them from having to, to do, documentation because we're able to to automate that process for them. And I know as a as a network engineer, I hated documentation. It was a real necessary evil. So, so that appeals to them very, very nicely.

But, obviously, there are additional elements. So we talk about the compliance piece. We talk about, being able to to help with audit and and reporting, and that information is very useful to the to the next layer up, to your network management folks, to your to your, service providers, and so on. And and by by looking then at how we help with the automation story and around intent based networking, that idea of helping to manage networks more in a more cloud like fashion. So that appeals then to the next layers of of, the higher level, management and into the to the, the CXOs really to Thank you very much.

For those. We can improve we can help you improve your level of, service management to your customers. To close what I wanted to do by helping you operate your network more in the cloud. Think about intent based networking, I suppose. So hope that, hope that answers your questions, folks.

Claudio, you've got another mess question there, and I will come back and answer this. How's the collected data stored and managed? Do we use an internal or external database model? And, what about So the the collected data is stored in an internal database. We have a number of structures to the database.

So it's a multimodel database. We can we use graph database. We use, JSON objects, and use straight relational database tables as well and bring all of those things together under the hood. So it's a complex multimodel database. We can, we can back that up off the platform if needs be.

But typically, what we do is we we maintain it within the appliance. It's very compact and very, efficient in terms of storage space. What that allows us to do really is is maintain the the device as a as a single appliance. And so from a a backup and restore perspective, your the best approach is typically to use, if using VMware, for example, or or, that sort of virtualization technology, taking snapshots of the actual VM and and and restoring those should there be a problem. But, typically, we don't really see that.

There are newer options coming. The the the virtual appliance supports up to up to 20,000 comfortably, network devices. But if you wanted to scale beyond that or if you had a complex environment with some parts of the network inaccessible from others, for example, but you wanted to bring all the data together, we are looking at a, like a multi instance of distributed deployment, whereby you can have a, a centralized, console that's able to access multiple instances of IP fabric and bring all that data together. So that's road map, and we're working on that at the moment. That also would allow you to have, be able to to kind of shard the data and store elements of the network data in different places.

So you you have an element of, of about that as well. Great questions. Thank you very much for those. So for for the takeaways. Yeah.

Intent based networking, it sounds like a pipe dream. But as a paradigm for network operation, what it allows us to do really is to achieve those goals that we have for automation, the the the control and the flexibility around being able to to have automation as part of our network, but then grow that automation across multiple network domains. In the real world, we have a number of customers and partners who are using IP Fabric's assurance capability in exactly that way today. The ability to provide that feedback loop to the automation system, perhaps if you're detecting a drift from intent or, suboptimal operational conditions like running vulnerable software code in the network devices. And And then to be able to take that corrective action really has the power to completely revolutionize the way that you operate your network service.

But you can't just dive into it. You can't just start operating an intent based network environment. There's a process journey that you need to go on. I know it's corny, but it's true. But the best place to start with that is to use an assurance capability and introduce that into your existing operations.

We've already shown today the value that bringing IP fabric into your operational network as it stands now with all its its manual process can bring. And once you have it in place, you can then develop that out into the idea of, full intent based networking. Now we've produced, a flyer with IP Fabric's main value points from today's session, which, I'll talk to to the guys about getting those sent out to everyone who's on the call today, and with the the link obviously from today's recording. Please read, digest, forward to to, interested colleagues. And, obviously, what we would really like to do is to give you a full demonstration of the capabilities of the product and ultimately, work with you on doing a proof of concept in your own environment so that you can see the real value that IP fabric could bring to your network.

If you're interested in doing that, please just get in touch with us. Our contact details are on here. The sales at ipfabric.io is the, the best email address, or just go to the website, and you can access us through the, through the online chat there. Thank you very much for your time. Thanks for listening.

Appreciate your company for the last well, it's turned into almost an hour, and hope to see you all again at one of our future webinars. Thank you very much.