Folks, welcome to our webinar, entitled uptime is money. Today, we'll be discussing the benefits of network assurance for financial organizations. Today's session is being recorded, and we'll be sending out a link to the registrants hopefully later this week once the recording's ready. So banking used to be a safe haven in the business world. Dependable, structured, meticulous, with archaic processes to check and double check everything.

It took place in big, sturdy, venerable, old buildings where transactions were carried out in a methodical, predictable way to ensure that not 1¢ ended up in the wrong place. But progress marches on, and business requirements change. And in the 21st century, there's a drive for agile access to flexible services and to increase velocity and the regularity of transactions. This sounds like the perfect candidate for IT in general and networking specifically. High volumes of transactions between multiple parties carried out speed from anywhere.

But, of course, the value of those transactions adds another factor. In and of themselves, those transactions represent somebody's money, often being handled by agencies on behalf of their end customers. And so, of course, there's an inherent currency value to those transactions, but the reliability and the predictability of those transactions also has value in terms of reputation and liability. And often this value has outweighed the need for speed and meant that while financial organizations have been prepared to pay for resilience in their IT, they've erred on the conservative side perhaps by being predictable and reliable at the cost of that agility and flexibility. Of course, they also need to consider the regulation that comes with handling those financial transactions for businesses and consumers.

So modern finance needs agility and predictability, flexibility for customers, the ability to consume service wherever and whenever they like, and their ever changing needs in these uncertain times mean that new financial service providers who can cater to those needs are making big wins. So how do we create that level of flexibility customers want at the velocity they need with all the certainty and predictability that they expect? Well, for one thing, we need to ensure that our IT operations can provide the right kind of support to the business to ensure the service availability in periods of high demand and change. And nowhere is this felt more than in the network that underpins the whole of your business IT infrastructure. My name is Darren Forwell.

I'm IP Fabric's product evangelist, and I'm joined today by Sebastian D'Aguve, one of our team of expert system engineers. We're both network engineers with many years of experience supporting and maintaining networks for financial services organizations. Our plan today is to highlight how improvements to network operations help an IT team manage the risks both hidden and exposed in financial services IT. We'll dig a little more into what's needed from the IT support, to support financial services organizations. And through examples and demonstrations, we're going to explain how IP fabric can be used to help minimize the risk in your IT ops to maximize agility while assuring service availability, specifically by baselining your network infrastructure, then proactively assuring that your network is providing the correct service at all times, and providing assistance to quickly react should an issue occur.

So reducing that mean time to to please feel free to offer up questions throughout in the q and a panel. The team will answer them if they can throughout or if we have time after the demos where we can answer the questions directly before we close with our takeaways. Now in our experience, we know that financial organizations have traditionally been very happy to spend to ensure that services are maintained for their customers, typically on higher end solutions with strong failover, clustering, or high availability options. But with so many environments which need to be connected together, how do we know that they're going to work together the way we want them to in normal operation and in failure situations? Can we verify that they're correctly configured and operational to provide the service the customers need?

We believe IP fabric can play a part in ensuring that your network provides the correct foundation to minimize the risks. And so Seb, I guess the first area that was worth considering here is, as we've mentioned, baselining the network, understanding what's there, how those different elements interact, and how they're working together day to day. Absolutely, Darren. So if you're happy with me, I'm going to share my screen. Please.

You need to stop sharing. Yeah. Thank you very much. And here it is. Alright.

So, yeah, obviously, as you mentioned, the first part is baselining. And for that, what we need to do is discover the network having the good view, the overview of the topology and even the pathway you may not be aware that you've got devices. So we need that full visibility. So let's find out how IP fabric works in term of you being able to get that full topology. So the the first step, what we what is going to do is is a plug and play solution.

So the idea is you're going to be able to very quickly after installation collect the information from your network and have that information available. So the discovery is working just like a network engineer would work if you were trying to discover a network. So IP fabric is installed in a VM inside your on on premises network, and what we're going to do by default is connect to the default gateway using SSH, enter, different show commands to understand how that device is configured and also trying to see what devices are connected to it and understanding the relationship. And when I would say that, I mean, it's important to understand physically what's connected to it, but also understanding on the different layer what are my relationship with my neighbors. So understanding the layer 2 and layer 3 topology.

And then with that information, I'm now able to connect to the neighbors' devices and repeat the same process to crawl through the network and get the wall topology. So once we do that, we collect a lot of information, which again is not just the configuration of the devices, but it's it's the network state of each of those devices. All that data is then stored into our database, which we're going to call a snapshot. That's how we we say that. So the snapshot is going to be a representation of your network at a specific moment in time.

So after each snapshot, you're going to get a refreshed view of your wall topology. So with that data, what you can do is use the web page, and you'll have access to the documentation, graphs, check a lot of compliance that is coming out of the box, and that is what I'm going to show in a in a few minutes. But before that, I also wanted to explain as well that all the data that we have, we've done the work of doing all the passing, making sure the data is unified. And, you know, as vendor diagnostics, all the vendor we support, you're going to have the data displayed in the same way for all those vendors. So which means with, you know, with we can you can target all the the that data using the API, which means you can use the information that we've collected of of your network and integrate that within your tooling environment.

And one of the example there, you can see on the right hand side where we've got the monitoring. And what you don't want with your monitoring is having any gaps, having part of your network that is not under monitoring, and that's what you definitely want to avoid. So you can think of having some script that's going to use the data that we've collected, for example, your whole list of devices, and comparing it to your monitoring system and ensuring that you've got the same devices monitored, and if they are not there, to automatically add them. So that would be one of the use cases of how you can use our data inside your environment. There are other cases where it could be ticketing system, or it could be your CMDB that you want to update and many other use cases.

So this is for the brief overview. So now I'm just going to to move on talking about the baselining and to the to the, demo. So what we said is the first part I want to show is going to be the inventory and why is the inventory that important. Because I think the first point is it can be a very painful process, something that you have to do, making sure your inventory is up to date. And why it's important is because at the end of the year or I don't know how often you're going to do it, but you've got to ensure that all of your devices are under maintenance.

So you'd have to send that to your vendors and ensuring that, you know, you're supporting all of your hardware. But how painful is that process? It's I remember my days when I had to do work like this. It takes a lot of time. And then after days weeks some time of working on that list, trying to find out the deltas between what the vendor has and what we have, we were still not a 100% comfortable that we had covered everything.

So it's a long process, and you're never really sure that you've got you've covered everything. So the idea in here is we want very quick access to an accurate inventory. So what you can see here so I'm in inventory and devices. I've got the list of all the devices that IP fabric has discovered. So this is your old topology.

So straightaway, you'll be able to look for any specific information that you want for, for example, the cell number. And what you've got to remember is that data is going to be refreshed at every snapshot. So most of our customer like to do a snapshot every day. It can be different depending on on their needs, but it means every day, you'll have the that information that's going to be refreshed. So if you replace a device, a device icon 40 somewhere, you've replaced it, you don't have to worry about manually updating your inventory.

It's going to be done automatically there. So you know this inventory is up to date, and that's, you know, you can already start saving a lot of time by having that available here. What you'll also have, if I look at the part number here, you'd be able to see everything including from, say, power supply or the fan, all those, you know, modules and for SFP as well would be included there. That would take a long time to actually gather and put together. So all the information, you've got it there as well.

And, again, you've got the SAN number, so you're able to get the data. If we see this one, they're MT based because we they're actually virtual appliances, so that's why we don't have a cell number for that. And now how can you use that data? So, obviously, you can search for every day all the data you've got there, you can search it on the platform there. But what you can also do is share a link that's going to you know, that you can send to your colleagues so that they can get that exact same table.

You can export to CSV, which is always useful if you want to work on Excel and then send it to your vendors. And you've got that a question mark there. And if you click there, you'll get the information on how to access that data using the API. And that's how you can use that for your integration. So this is for me once you've got that, you've already got an extremely good view of your inventory, and that is something that can already take a lot of time and being, you know, it's it's, I would say, very critical because you don't want to be in a situation where you've got a hardware failure somewhere and one and that device is not under maintenance.

So you end up having to find a replacement somewhere else and not within the SLA that you would have normally agreed, and it can affect your business a lot more than if it was pricing under maintenance. So this is the first part I wanted to show. Now what I'm going to show there, if I go through the technology, this is the list of the technology that we're going to collect from your network. I'm not going to go through all of them because this will be there for a lot longer than, than we have, but I'm just going to show a few one. For example, starting with the CDP and LDP neighbors.

The idea there is having the list of all the physical neighbors. So I've got the list of all that there. And what I wanted to say here is that information is we are then going to use it to be able to build the diagrams, which I'm going to show in a minute. So this is the information showing for each devices, each interfaces, what neighbors do we have. I can briefly show as well if I go to spanning tree and spanning tree neighbors, I have the similar information regarding my layer 2 information here.

And just again, briefly showing sample OSPF. If I look in my neighbors, I've got the list of all my OSPF neighbors. So now let's quickly check what it looks like once you put it into a diagram because that's really what you want to be able to see. So I'm loading a diagram for a specific site, and I can see that information there. So it's a very dynamic diagram.

So what you can do as, you know, as, the idea is to be able to quickly check the information that's going to be relevant for you during a troubleshooting. So for example, I can decide to remove my layer 1 information, so the link's in green, just to have a little bit more detail there. I can display the detail about my routing protocol that I have on that network. And now what you need to know is you can click on any devices or link, and you'll see the information that we've collected. So let's look for at the trunk that we have between those two switches.

So if I click there, I'll be able to see the VLAN going through the trunk. So if I select pump on VLAN triple 1, now what I can see is that device there at the top has become green, and it shows root. And that's how within a few click, I can already see who is the root bridge for that specific VLAN. But what I also want to show is I can get to more detail by showing the detail of that specific villain for that, spanning tree loop. If I click on this link, you can see that red dot there.

And straight away, I've got the information showing me what are my blocking and forwarding both. And that is information that, you know, I'm sure a lot of us had to go through and manually working on connecting to different devices and finding out which ports are blocking, which one, for rounding, and you are able to get that information within just a few click, and that could save an, you know, a lot of time when you're actually trying to troubleshoot or just looking at the documentation. So that is for the layer 2 information. And then I just wanted to show as well what you have on layer 3 information for everybody followed there. So you can see an eBGP link.

If I click on the link, I'll get some information. In that instance, you can see b GPS been established. You can check the number of receive prefixes. So all that data is what you could see on the technology table over there is now available for you to see on the graph. And, again, with in that example, I've only got BGP and OSPF, but you could have the other routing protocol.

As long as we're supporting them, you you'd see them. So, you know, all your ERGRP, MPLS and all that is actually is supported, so you'd be able to see that. So now what I wanted to show as well is in here, it looks like there is something missing that part. So if I look into the options, I can actually display the single point of, failure or the vulnerability of things that looks that hasn't been configured correctly. So if I show the non redundant link, I can see this link is non not redundant.

And, yes, if this link if this link fails, you'd be in a situation where that site is going to be isolated. So what I'm going to show now is the snapshot we have for the day after. So if I go to the demo day 2, I can see that now this has been correctly implemented. So if I look at the non redundant link, this is no longer an issue. So the idea of those different snapshot, having a refreshed data that you get, you know, every day is you can now compare and be able to see what has changed.

So if I compare the snapshot, look at the day before before, I'll be able to see that those links were not there, and that's how you can quickly check what has changed from one day to another. So you could obviously think about how you can incorporate the sort of checks within your operation or day to day. So I think with what I've shown is this is for me what I would say now I've got the baseline. I've got a good understanding of my network and my topology. That's I mean, Seth, that's perfect.

I think what what you've shown there, and it's clear that that once you've gone through this process, there are no gaps in your understanding on your coverage of what is operating in your network at a point in time. And and you can see that change over time as well, right, which is which is is great to have that visibility from an operational perspective, but also, I guess, as well to save time on those annual audits, when you're doing regulatory compliance audits. You're gathering all this data all the time. So you're not having to waste time on on activities on, on on gathering that data manually. So that's that's really, really useful.

I guess once you have that data, once you've got that view, you can then start to proactively assure that the network is behaving as it should do, providing the service that that a customer would expect both in normal operation and in a failure scenario. Right? Abs absolutely. And that's obviously the the next part where now we've got that information. We've got a good understanding of the infrastructure.

We've got that, you know, baselining that's been done. But now how how are we going to be proactive? You want to check things that maybe misconfigured the inaccuracies that you have in your network, but that sometime monitoring system are not able to see. And for that, I've got a few example, which I would say I'm pretty sure some of, so you have probably worked with. Let's say, for example, MTU.

So why I'm going to take that example is because you're in a situation where everything looks fine, works fine. And then you've got a primary link failing somewhere and then you end up having a backup that's not working correctly. You've got you had no alert in your monitoring system, You start troubleshooting and you realize you've got your MTU, which is inconsistent. Yeah. I've seen that one with running overlay networks like, Cisco's OTV solution for Nexa switching, where exactly that, that it worked just fine, on the primary.

But as soon as that primary failed over to the to the backup, the backup was misconfigured and so didn't work the way you expected it to. And that's yeah. We've we've had a a similar situation. And then the problem is then you're thinking, okay. I fixed that problem for that backup link now, but what about my other links?

How do you ensure that the rest of your network is going to be, you know, not facing the similar issue when another link is going to fail one day? So so now if you think about how you're going to proceed for that, you're going to say, okay. I need to collect for all my links, the MTU on both interfaces. And it's not something you'd be able to do easily. You know, you can find the interface, the MTU on one interface fairly easy on the screen, but how are you going to match it to get both sides?

So with IP fabric, from the moment you finish the discovery, we've got in here an intent verification rule that is going to do that for you. So if I look and if I click here, I'm going to see all the empty all the links where the MTU is inconsistent. And straight away, you can see if I take the first one there, on one side is configured at the 9,000 and the other side is 1500. So just looking through that link, so through that list of, in inaccuracies there, I would say, you're able to start proactively proactively fix issues that you have in your network before you actually start impacting and having issues, you know, and, you know, dealing with all that postmortem of the ones and actually having to say, yes, we were not aware that things were misconfigured. Now you can be proactive and actually fix that to ensure you've got your resiliency working as expected.

And I would say, yes, you we used to run Doctor twice a year or depending on the environment but those Doctor tests is there are often issues that happen and then you might not be able to test everything, but you want to be in a situation where you're confident before the g r test that you've got that resiliency that is working. And that's that's what you can do there by fixing all those potential resiliency issue. Go there, fix them, and then on the day of your Doctor test, you can actually ensure that now everything is working smoothly. So that was one of the example. The the other one, and it's an issue that we faced and caused us a bit of grief, We need to look at the BGP table, and I'm just going to look at this intent verification rule, the one that loops for the received prefixes.

So if I look at this one, I'm going to get the list of the BGP session that are established where we did not receive any prefixes. And why is that something that is a problem is main issue with that one is from a monitoring point of view and from a device point of view, BGP is fine. So you're not going to get any syslog, SNMP trap alerting you of of a problem, but you are not going to receive any routes, which means you're not going to be able to use that link to pass any traffic. So by actually being able to very quickly look at those, you're able to proactively check issues that we have. So now what I wanted to show there is fine, but I'm going to go back to, the the site I was showing earlier.

And I'm going to move to day 2 here. And what I want to say there is I can overlay the information that we have in all those technology tables. So if I look there for BGP, this is what I'm going to see now. I can see this one is in red. This one is in green.

So if I click there, this one is going to tell me that now my BGP is established but I do not receive any prefixes. So why is that potentially major problem? And that's what we faced is you can have in here maybe, you know, a market data provider or some critical services that you're receiving. This is your primary link. If that links fail, you're expecting your backup link to start handling the traffic and, you know, it'd be almost invisible for your users that something has gone wrong.

But what happen if you're in that situation? The primary links fail and the backup is actually not ready to work. So you end up having a black hole. You you cannot route traffic. You cannot access or get the data you were going there.

So you're actually quite in a difficult situation where you are totally helpless because it's out of your control. You can only call your third party to say you need to fix the situation. We've lost one link, and our backup is not working. So this again is another check that you can do to really, I would say, go further and be able to fix issues before they become an issue. What if you could have fixed that problem, you know, when it happened maybe 3 weeks ago, 3 months ago and not waiting for the Doctor test to actually spot the issue or worst case scenario is actually waiting for the primary link to fail to then realize you had that problem.

I was I was just gonna say, I mean, that's that's the key, isn't it? It's being able to say there are hidden issues that you can't see on an operational basis because your network's working the way you might expect it to. But by going that step further, by looking that step deeper, we can verify that actually should a failure occur, then your network will give you the support that you want because it is doing what it should. And if it doesn't, you can act on that before it becomes a problem. So yeah.

I mean, that's it's brilliant to to have that view, to to have that that ability to look forward, in time, almost as well as looking back in time, how things have been previously. And I guess having all of this data is not just about about being able to be proactive, but also, I'm I'm thinking that that, you can use it to support the troubleshooting process should problems when problems do occur. And I guess to reduce the amount of time that it takes, in order to to solve those issues too. Right? Absolutely.

So that's I would say, the last part. So now we've got, you know, a good understanding of you've got your baseline, you're now starting to fix inaccuracies that you have, so you're being proactive, but you still need to be reactive. Issues are likely to happen again, and you need to be able to fix them quickly. So what we are doing here, if I go back to the diagram, and I've got the end to end path. So what I'm going to be able to do there is to look at the path from a source to a destination seeing all the devices that are going to be in that path, including firewalls.

So if I take a situation or an example there, someone is going to say from this IP to that 1 on port 4 4 3, for example, I cannot access it. I've got a perm, you know, the the classic issue where something is not working. So the ID there is just by entering the information, I've got the wall path. If I look into a little bit more detail there, I can see my source here. That's going to be the default gateway, the switches we're going through.

If I click on one of the switches, I can see the decision the the switching decision that's been made by the device. Same thing if I click on another router here, I can see what's been happening from a the routing point of view And, also, like I was mentioning, the access list. So if you could access list potentially blocking that, that, traffic you would see here as well. So this one is fine. And going through the MPS cloud and then back to the site where, obviously, we see this one in in red.

So if I click there on that firewall, which if I look at the detail, for example, this is a Juniper firewall. Again, as important to mention, it could have been any other firewall, and the data would have been displayed the same way. So the forwarding on the firewall is fine. It's working as it should. But then in term of policy, we are not annoying.

I can see that one is denying and that's my deny any at the end. So HTTPS is not allowed by the firewall. So this is how very quickly I can check the the traffic I've got from source to destination, speak to the user to say, yes. The firewall is not allowing the traffic. So the idea with a tool like that is you can actually give it to, for example, your note or something like that to be give them a little bit more information or insight to help them troubleshoot better and offload your level 2, level 3 team to make sure they can work on, I'd say, the more important tasks or interesting projects.

So once you've realized what the problem was, yes, the firewall is blocking it. What you can do is speak to your firewall, make sure that they open the necessary tickets for flow, and so now I'm going to move to day 2 after this has been requested, and now I can see the firewall. If I click there, forwarding is fine. And then in here, the policy, I can see now that we've got a permit for HTTPS, which is brilliant. So now we know that the issue has been fixed.

We can assess that, that page correctly. But you probably want to go a bit further as well where you you want to say, okay. Now I want to ensure that port 80 is going to be blocked for hamper because it's no longer safe, you want to make sure everything is encrypted so HTTPS in here is blocking which is good that's what you now want But how can you ensure that it stays that way? And the idea what I'm trying to say about that is you almost want to check that there is no changes in the network or the firewall that's going to bypass, you know, something. For example, if you were to bypass the firewall, your firewall team is not going to notice something because the the rule is still going to be there, but it's just not going to have any hit on it.

So how do you do that? So what we can do here, we've got the defined path check. So I can ask for this particular flow on port a t to be failing. So which means now if I go to the path verification table I've got here, This is the one I've got at the end there on port 80. I want it to fail, and I can see the current state is failing, which is what I want.

But what happened is if that bypass I was mentioning has been put in place somehow, someone has managed to bypass the firewall. So now I've got an an error that appears there, and I can see that this is supposed to fail but it's not failing. So if I look here, I can see what's been happening, and the firewall is no longer appearing in that entrance path. So I'm in a situation where something has changed and potentially from a fire point of view, no one would have noticed anything, and maybe his network may not have been able to spot this. But I was able to go further and be alerted that there is a security flaw there and that now the application is actually reachable on the port 18.

So I think, as we mentioned, this is important to try to reduce the risk of outage by being proactive, but it's I think it's key as well to make sure we've got the right tools to be able to troubleshoot quickly things that have been happening in in your network. So in in here, what I could do is use the comparison as well and check what's been happening from what was the day before, and you can see previously the firewall was in the past, which is no longer the case. That's great stuff, Seb, and and thanks for for sort of talking us through those things. What would what I'm gonna do is, just, I've got a couple of questions that have come up in the q and a. So, let's cover those.

If anyone else has any questions, now's the time to to shout up because, just pop your questions in the in the chat, and we'll pick those up now. But, you you, talked about the end to end path there and and demonstrated that. I assume then that you need visibility of hosts in the network in order to make that work. What do we do about about that? Absolutely.

So we are not going to collect data on the host, though. We are going to see where the hosts are, And that's something, again, probably you have to do that a lot as well where you're being asked to find out where the IPs, which IP is connected on which port device. And is that, I would say, it's it's not the fun fun part of the job where you've got to actually just connect your many devices, get the MAC address table, the app table, and which we've got there. We've got that app table. You you can get all that information.

We've got that my table. But what we've done is inside the inventory, we've got the list of all the hosts that we've collected. So you've got the information there. You've got the IP address, so you can search for any IP address that is on your network, and you'll be able to see on which devices and which on which device and which interface that bot is connected. So you've got that view of all the hosts in your, I mean, in your network and with the information, again, available with just a click.

So, again, you can export the data and use it the way you want. Perfect. Perfect. Thank you. And, another question that's come in, intent rules.

Do you have to build them yourself? So is a really good question. It's a good question because I can probably when you quickly write so if I look, for example, in the devices there, you can see you've got the one the one that are there are the one you will get by default. So it comes with more than a 120, intent verification rule out there, which are going to be based on experience and things that we would want to check-in the network like we were showing earlier, the MTU. So those one come by default.

They're there. Like, if I look at this one, you've got memory usage where you want to see something if a memory, at the moment of the snapshot is above a certain percentage. But what you can also do is you can create your one very easily. So very quick example I'm going to show there is you've heard that there is a a version of a noise that's got a bug. So I'm just going to enter, for example, that one there, and we want to check that any version starting with 15.3 is going to be highlighted as one of the verification.

So what I'm going to do there is click on the intent verification rule, give it a name. So I'm just going to collect OS this. I'm going to colorize the version here. So that's the color the the color I want where I I apply a a color for it. And what I'll do is I'll put in red, and I'll put the my rule there.

I want the version to be containing 15.3. That's so if I do this, and let's let's see what it does. So now what it's going to do is going to look at all the devices. So now if I remove my filter here, just by clicking on that intent verification rule I've created there, I can see the number of devices using the the those OS version matching this role. So that's how you can quickly create your internal verification rule and also ensuring that it evolves the way you want.

So, ideally, once you've seen that, you're going to ask your team or to upgrade those version, and what you would want to see in a future snapshot is this number to go to 0. And that's that's what you want. I'm guessing as well you can access this through the API. Right? The the filtered by that that intent one.

So at the moment, I've clicked there. So now if I click on the question mark, you're going to see that I've I've got my payload there, but I also have a filter that is going to match exactly what you're seeing here. So if you're using this payload inside your API call, you'll get exactly those two results as your JSON output. So you could you could monitor that or you could use an external script to kick off automation to go and do the upgrade or whatever whatever you wanted to do. Yeah.

If if you've got some Ansible playbook that are going to be activated by this, you can definitely do that. Yeah. No. That's great. I'm just looking to see if we've got any more questions.

I can't see any more coming. If if anyone does have further questions beyond this, please just contact us. The contact details will be, we'll show them at the end, and we'll follow-up with you, individually. Emails, you know, the the the usual channels. So, thanks very much for the demo, Seb.

That that was really, really useful. Thank you. No problem. My pleasure. Okay.

Well, well, if you can stop sharing your screen, I will share mine and we'll continue. So, really, we're we're coming towards the end of the, of the the webinar. We'll we'll talk about the the the takeaways, the things that we've seen, and the things that are important. And I suppose, ultimately, the story we're telling here is is like with most businesses. In financial services, service availability is, of course, king.

But coupled with that, there's a real and strong desire to minimize risk to the point where the where the organizations are typically very conservative in their approach. Now that's traditionally meant sacrificing new technologies and approaches that would increase the flexibility and agility for service users, but we want to help with that. What IP Fabric does is provides that level of visibility into all of the disparate technologies in an organization's network and the way that they work together to provide services, which means that an organization can be confident that they know and understand their whole environment through baselining and automated documentation. But they can assure predictable behavior of their network through the ability to pinpoint inaccuracy and verify compliance using intent. And they can minimize the amount of time taken to rectify issues when they do occur by having the correct and up to date network data to hand and the tools to make use of it for whoever needs it.

And this functionality provides the comfort of knowing that you're minimizing the risks that you both do and don't know about your network and how it's behaving. And so then you have more confidence and comfort in using more modern operational approaches to delivering your service. I just wanted to close with a a quick story of how one of our financial services customers has used our platform in their operating operations to help cement their position as a real success story in 21st century banking. AirBank in the Czech Republic have been trying to innovate and provide a next generation banking service to their customers, but we're still having to spend large amounts of time preparing annual audit reports demonstrating their understanding of the risks and impacts in their IT environment. By deploying IP fabric, they now have the data updated daily to satisfy that audit reporting requirement, but they can also track remediation activity and prevent the need for these big annual projects to bring environments back into compliance from an uncompliant state.

They regularly tell a story of saving 90% of the time and effort they would otherwise have spent on carrying out those audit activities manually. If you're interested in finding out more about how IP Fabric can help your organization, check out our website where you can find a useful 2 page summary flyer where we discuss our specific value to financial organizations, and we have our relevant case studies. You can also request a demo, a trial, or call our expert sales team who can help you to understand those benefits that IP fabric can bring to your network operations. All that remains is for me to thank you for attending, and I hope you found this informative. We'll be sending out links to the recording shortly, which, of course, please feel free to forward to colleagues if you feel that would be useful to them.

And for myself and Seb, let's say thank you for your time. Thank you. Thank you very much.