--- title: "IP Fabric Partners With Illumio to Unify Cloud, Network, and Application Visibility" id: "27228" type: "post" slug: "illumio-partnership-network-application-visibility" published_at: "2026-09-02T12:41:11+00:00" modified_at: "2026-10-26T20:50:49+00:00" url: "https://ipfabric.io/blog/illumio-partnership-network-application-visibility/" markdown_url: "https://ipfabric.io/blog/illumio-partnership-network-application-visibility.md" excerpt: "This industry-first collaboration will help customers to correlate application and workload context with a digital twin of cloud and network behavior." taxonomy_category: - "Integrations" taxonomy_post_tag: - "Application infrastructure mapping" - "Illumio" --- # IP Fabric Partners With Illumio to Unify Cloud, Network, and Application Visibility This industry-first collaboration will help customers to correlate application and workload context with a digital twin of cloud and network behavior. [https://ipfabric.io/author/madeline/](https://ipfabric.io/author/madeline/) [Madeline Day](https://ipfabric.io/author/madeline/) Content Marketing Manager Published 2 Sep 2026 Updated 26 Oct 2026 We open on an all-too-familiar scene: a business-critical application is down, and multiple teams are working in tandem to troubleshoot the issue. Cloud engineers aren’t seeing any problems with their security groups. Network engineers aren’t finding any ACL rules that are blocking traffic. And yet, the application team is still reporting timeouts. Each of these teams has a different view of their shared infrastructure, spread across different tools. And each of these tools show only a fragment of the application’s path across their hybrid multi-cloud environment. For example: - **CMDBs** are often incomplete and inaccurate, missing as much as [40%](https://ipfabric.io/blog/cmdb-health-ip-fabric-servicenow-integration/) of the network. - **Observability tools** can’t give you the [depth of insights](https://ipfabric.io/blog/observability-tool-with-infrastructure-assurance/) you need to understand cloud and network behavior. - **Application performance monitoring tools** can tell you that an application has degraded, but can only pinpoint the problem if it’s within the application itself. - **Service mapping tools** rely on inferred or logical relationships, rather than actual cloud and network behavior. As a result, no one team has unified visibility into how cloud and network controls affect application performance and reachability. Read on to learn more about the impact of this visibility gap—and how IP Fabric and [Illumio](https://www.illumio.com/illumio-platform) are embarking on an industry-first partnership to fix it. Transcript I can tell there are 127 Phantom devices. Those devices that are in the CMDB but not actually in production anymore. For an enterprise access switch, it’s about $5,000. So, the the maintenance fees could be anywhere from $500 to $1,000 per year. We might be paying maintenance fees on those. Um, you know, often the vendor expects us to kind of true up at the end of the year. This is how I can know I’m chewing up uh in the right way. Um, 30 missing devices. So the opposite problem where I have uh devices that are in production that aren’t in my CMDB. So they’re ghost devices or documentation wasn’t updated. And then this last part is um we have puty changed devices meaning they’re in both the CMDB and in the IP fabric discovery, but the configurations are different. Right? We’ve matched the serial numbers, but maybe one is matching my my security policy and one is not. Hopefully, you know, the the production is matching our security policy so that we’re not, you know, nervous about a data breach. Um, but we should know about these things, right? And so that’s just a a quick uh demo to show you how this this happens in real time and how real numbers get attached to this type of inventory ## What Could Fragmented Visibility Be Costing You? Imagine that you’re tweaking a [firewall rule](https://ipfabric.io/blog/ip-fabric-7-2-infrastructure-security-and-compliance/#analyze-transparent-firewalls) or adjusting a [segmentation policy](https://ipfabric.io/network-assurance-security-compliance-controls/) , but as soon as your changes hit production, you see a spike in connection resets. As with any incident, you need to ask yourself: - What infrastructure does this app depend on? - Which applications and services are affected? - Is this application properly segmented and compliant with security / regulatory standards? In an ideal world, you’d have known the answers to these questions before pushing the change in the first place. But if you don’t have a quick and easy way to correlate cloud, network, and application data, then you’re probably paying for it in the form of [risky changes](https://link.ipfabric.io/4y5ejqz) , [lengthy troubleshooting](https://ipfabric.io/blog/ip-fabric-mcp-server-for-enterprise-aiops/#accelerate-troubleshooting-slash-mttr) , [failed security audits](https://ipfabric.io/wp-content/uploads/2024/07/SB_Security_2024.pdf) , and [unreliable automation](https://ipfabric.io/blog/network-intent-isnt-enough-for-automation/) . ### Risky Change Management Every change carries risk. The only way to minimize that risk is by anticipating the blast radius of a change ahead of time. And to do that, organizations need a view of their environment that spans from critical applications to on-prem and cloud environments. Needless to say, traditional [Visio diagrams](https://ipfabric.io/blog/network-discovery-build-network-source-of-truth/) and cloud documentation don’t cover this scope, so engineers usually fill in the blanks using their own knowledge of cloud and network behavior. But this approach has a few limitations, namely that it: - Only covers known devices. - Isn’t vendor neutral. - Doesn’t update automatically. - Can’t be easily be used by other teams, tools, or AI/automation workflows. Given these visibility gaps, it’s difficult to determine the impact of a change on any part of the environment. Unfortunately this means that organizations usually don’t find out what context they were missing until something breaks. Transcript Every network change is a bet. You’re betting that the topology you think you have is the topology you actually have. You are betting that redundancy you configured two years ago still works the way you expect or that a root change here won’t cascade into something ugly elsewhere. In most organizations, that bet is underwritten by one person, your most experienced network engineer, mentally simulating whatif scenarios against a version of the network they’re carrying around in their head. It works until it doesn’t, and it definitely doesn’t scale when you’re staring down an integration or a cloud migration with a hard deadline. Here’s how we approach it with IP Fabric’s MCP server. We start with a prompt available in our prompt guide linked near this demo that defines a specific traffic path. The path is a source and destination address and the snapshot. That snapshot is verified model of the entire network as it exists right now, not as it was documented 6 months ago to provide more realistic whatif scenario. The model runs a full path lookup query in IP fabric and maps the response every hop, every site, every ECMP branch along the way. It identifies the first hop gateway then queries the first hop redundancy configuration to surface the peers priorities preeemption settings and whether both gateways share symmetric uplinks and routing tables. Then it builds the whatif. What happens if that primary gateway fails? The report lays it out in a two column comparison. Current path versus failover path with the changed hop highlighted so you can see exactly where the switchover occurs and confirm that everything else holds. You get a failover timeline, detection, transition, convergence, recovery with expected timing for each phase. and you get a risk and recommendation section that flags gaps. Maybe there’s an asymmetric uplink or maybe a single point of failure the team hasn’t accounted for. The whole thing is delivered as a structured portable document or any format you like. Executive summary with stat cards at the top, detailed gateway redundancy configuration tables, the full scenario analysis and a remediation table at the bottom. For architecture teams planning a major change, this turns weeks of manual analysis into a repeatable evidence-backed workflow. For IT leaders who need confidence before signing off, it’s the difference between we think it’ll be fine and here’s the proof. Network confidence shouldn’t be a gut feeling. With IP Fabric’s MCP server, it’s a verified fact built from your actual network at the moment you need it with the evidence to back every decision you make ### Lengthy Troubleshooting When an application goes down, the only reliable way to find the root cause is by correlating cloud, network, and application data. If organizations do this correlation manually, it not only lengthens MTTR unnecessarily, but also obscures any issues that occur at the workload level. Think back to the example at the beginning of this blog post; while it may have seemed like the cloud an network were behaving as usual, the fault could have been a workload-level policy that no siloed team or tool could see. Transcript When an outage first hits, of course, the first question we all ask is what changed? Device by device, hop by hop. That’s what drags out meanantime to repair, MTR, right? In manufacturing, Seammens puts unplanned downtime anywhere from 39,000 to 2 million per hour. Uh, one customer of ours actually saw their MTR drop from hours to just about 30 minutes once they had accurate uh, end-to-end visibility into paths, dependencies, and config and state, right? Saving millions in avoided downtime. In finance, of course, trading and payments, time is literally money. Um, McKenzie actually estimates settlement processing delays cost $1 billion per year. Um, one of our customers actually cut their MTR by 98% taking a six-hour interruption down to just minutes and therefore reducing both their operational and financial risk. And of course, in healthcare, downtime isn’t just about lost revenue. It impacts, you know, delivery of care. So, Ponan estimates that downtime cost at at a clinic is about $7,500 per minute. Outages can of course though disrupt EHR, imaging, labs, monitoring, right? Where where reliability and and delivery of care ma matter just as much as cost. So the pattern is always the same. If your data is wrong, your MTR is long. And when teams can see the real state and configuration and dependencies in the network, those outage outages actually shrink dramatically. All from IP Fabric. ### Security Exposure & Failed Audits Host-based enforcement is now a core requirement for any [Zero Trust](https://ipfabric.io/zero-blind-spots/) architecture. However, if you can’t see how your applications interact with underlying infrastructure, it impacts your organization in two key ways. Firstly, you won’t be able to prove that your segmentation policies and other security controls are behaving as you intended, which means you don’t have compelling evidence for security audits. And secondly, you’ll slow incident resolution, leaving security teams to manually pull logs, dependencies, and segmentation data from disparate sources. Transcript Welcome everybody for the webinar about a security audit uh with IP Fabric in under an hour. Uh welcome everyone. Uh my name is Milan. I’m from IP Fabric solution architect and with me uh here is Christian. Hello I’m Christian also solution architect here at IP Fabric and welcome to our webinar. Happy to show you around. Yeah. So uh let’s get started. So about the IP fabric very very shortly because uh for those new to IP fabric uh think of us as uh creating a digital model of your entire network infrastructure. We automatically discover and map the state of every device connection and create context. And we we also capture configuration and state data across your environment whether it’s on premises in the cloud or hybrid. Unlike uh traditional monitoring tools that only show you what’s happening right now, IP fabric gives you a complete understanding of how your network is designed, configured and behaves. Uh this comprehensive visibility becomes the foundation for everything we will discuss today about a security and compliance. And uh Mur says that maybe nine out of 10 CIOS like a unified view of their infrastructure which opens organizations up to breaches and compliance issues. And with IP fabric we are trying to solve this fundamental challenge. IP fabric transform uh network security by giving you unprecedented visibility into your security posture. At first we automatically collect and analyze all your management protocol configurations like uh AAA settings S snp community sys configuration giving you a complete protocol inventory for device hardening. Uh think about that way that management protocols are the ultimate gateway to your network infrastructure. Uh as second our platform can simulate network path end to end showing you exactly how the traffic flows through your network including your ACL and we also understand the security policies that will affect the traffic or policy based routing rules. This means that you can test the security before changes or changes before implementing them or validate your segmentation whether is working as intended and identify potential security gaps. All of this discovery data becomes intelligence that you can leverage for the network hardening and finding the weak points or ensuring consistent security policies and proving compliance with security frameworks becomes very very standard and easier to achieve in the version 7.2 uh which is the main focus uh throughout this webinar. We uh significantly enhanced our firewall capabilities. Uh we now can provide detailed simulation of uh next generation firewall behavior including URL filtering rules and thread feed configurations. And [snorts] this is crucial because modern firewalls do much more than just allow or deny traffic anymore. Those are not just expanded ACL. They are making complex decisions based on application awareness and URL categories or threat intelligence. IP fabric now collects data directly from your firewalls and can simulate this behavior in our digital twin. And we’ve also added support for transparent firewalls. Uh those security devices that organization often lose track of because they don’t change IP address on routing uh by by design. Uh in the version 7.2 two, we provide uh detailed mapping and documentation of uh IP signals as well which are crucial for understanding how data are encrypted uh in secure communication channels as is required by the frameworks like uh ISO or regulations like Dora or these two. And thank you for staying with us uh throughout this brief uh presentation. And now I I would like to pass the word to Christian who will show you some very concrete examples in the way how you can achieve your goals uh with the current version. Thank you. Yeah, many thanks Milan. [clears throat] Um and I would like to start to talk about the enhanced [clears throat] intent checks. So basically um in the in the past um an intent check was always based on a specific uh table. So you could select um columns of the table and um define specific entries um yeah as a success or as a warning or as an error. Um but sometimes this was not enough. Um because sometimes you had that information okay um I have SNM SNMP configured ACL is not empty that’s great but just as an example if you want to understand on which kind of device do I have it or um do I have it on specific types of devices where I’ve added some attributes to it. um it was not possible to do. This is now doable. So if I scroll down um as you can see I can now select a different uh or additional uh uh information from the device table or in this case also add a device attribute and now um it will match this only against devices which contain the attribute I specify here. Let’s say I put in ABC if that is the name of the attribute. And now I can say if it contains [sighs] uh the word uh checkpoint as an example um then uh it will show me uh or it will mark only the devices with that attribute and where the access control is is not empty as successfully configured devices. All the others will be placed into other or no category depending on how you continue to configure your intent check. But this gives you un uh unprecedented uh uh freedom to really build intent checks um in a higher accuracy um and get the data you want to have. by the way uh for for yeah for for those who uh are not really familiar with IP fabric what we are achieving right now is that first the attributes are labels that you can assign to devices based on your own logic or principles within your CMDB or your organization and uh to be able to filter by the device vendor platform or even operating system wasn’t possible in the previous releases and it’s basically we are cross referencing the network inventory data with any table or information about a technology that we collect in IP fabric and we are combining with the intent rules. So whether you are applying a specific rules just to certain categories of devices based on your labels, it’s right now doable or whether you are applying your rules based on a specific vendor or site, it’s also available right now. Thanks for this addition. Okay, let’s now take a look on how we can visualize uh the IPC tunnels. Um, of course, we do have a table where you can see all your IPs tunnels, the state of your tunnel, is it up, is it down, which encryption are you running and all of that, but um in the past it wasn’t possible to see them in the diagram. And um I’ve chosen this diagram where you can see quite a few firewalls. And now I would like to show you how quickly and easily you can show inside the diagram. Um where are my IPs tunnels so you can visualize them. Um and I’m just removing layer 1 and layer two information. uh ungrouping the layer three uh information as it’s usually condensed into uh uh one single line inside this diagram. And now I’m selecting the IP sec tunnel. So I just want to see where are my IP SEC tunnels. I don’t care about the routing protocols, the default gateway uh and all of that. I just care about the IP stack tunnels. And when I click the submit button, he shows me I have here my IPSec environment. So I can easily spot where are the interconnections uh which firewalls are using secure communication uh t uh uh and and tunnel the data um so I can really um understand where do I need to expand maybe my IPSec environment my VPN environment or maybe where are the where are tunnels which may be of no no use probably uh and which can be removed. [clears throat] Yeah. Uh by the way, for those who are not familiar with the previous versions of the IP fabric, just to clarify, we already collected in the past information about the IP6 tunnels and the gateways. It was already present in our technology table in a in a very great detail. Uh the the what’s changed right now is that uh before 7.2, two, we were not creating the logical connection in the map in the visual topologies which right now we enabled in 7.2 version. Yep. Okay. And now let’s take a look at um how we work with or take a look at our enhanced firewall capabilities. So um in the past we had this if you wanted to check can I reach the the internet um using https you enter source any destination in this case I just use the DNS of Google to simulate an IP address and you click the submit button and you see the path okay I’m hitting the internet um the firewall is letting me pass all is good but what if you have a URL filter um and you want to understand are specific URLs reachable or not. So um and in this case we added this functionality. So now you can work with site categories and or URL or domains and if I use just as an example this URL if I get to it. So I didn’t change anything at source or destination or the protocol. I just added this URL and now if I hit the submit button I get a different result. So the firewall is blocking that URL. It’s not let letting me pass through even though the protocol is the same. Nothing has changed. Um and if I need some details again I can use the path inspector which is uh uh automatically uh showing you um which data are we using as source destination and all of that uh including also the routting information but also which firewall rule has been hit and clicking on it shows me the firewall rule so I can understand what’s going on um and therefore uh why is my traffic blocked or not? And let’s do the test. If I change the URL [clears throat] to a good URL and hit the submit button again, I get a different result. Zooming out. So um it’s really focusing on the URL which has been entered and which is not allowed to be accessed. [clears throat and cough] I think this shows quite well um how we uh have incorporated this into our solution and of course if you want to work with categories you can also work with categories here. You want to add something Milan or are we good? uh notice not this point. Thank you Christian. But the only thing may be that uh in the previous versions we could understand very well uh this simulation from source to a URL as a destination. In that case we had to be able to match the URL to to a specific destination IP. But we were completely unaware of any rules that include the URL filtering and with the 72 version that changed. Yep. Okay. And now let’s uh create a or let’s give a small sneak peek. Um so what’s uh also um what also is already added to IP fabric is the creation of manual links which allows you to incorporate your layer 2 filtering um into our solution. And as it’s usually not that easy to discover it and uh place the devices, a transparent firewall is a transparent device obviously. Um so we uh have built in this uh feature that you can add these devices and the links to it um manually. So you select the device you want to have and as you can see I’ve already prepared something but just to show you quickly you select the device you want to have you select the appropriate interface you define is it a layer 1 or layer 2 connection which is present and after you have created this link you run your snapshot uh we will discover uh the device and then also incorporate this incorporate this link um into the um view and again I’ve prepared it already. So the link I’ve created manually um and I didn’t want to torture you uh watching a snapshot being taken. So everything is prepared here. You can see that’s the manual link I have entered. So it’s visualized. You can now understand okay where uh is my transparency hiding basically. Mhm. Yeah. U maybe a little clarification why this is a little sneak peek because uh we can already discover transparent firewalls uh starting version 7.2. Uh let me say this transparent firewalls are always a challenging environment and they have uh their own goals of course you know there are IPS gateways and they have other functions and they’re essential in some places. uh we have a great discovery engine but for us even for our great discovery engine they are hard to discover they’re they’re hard to understand especially uh the way how they connect to other environments if they are connect to ACI leaves or other environment they require some IPS filtering. We thought a long time uh about how to resolve that issue and how to understand what interfaces of the transparent firewalls are in in reality connect to our environment and we came out with a concept of uh creating the manual links. Uh there are two types of manual links. one is layer one which will only appear as a map on a map like a standard like CDP or LDP connection with no real traffic functionality and then we can also create a layer two links that will help us uh to really use the transparent firewalls as uh uh throughout the traffic path simulations. So that’s for the future. uh it will be available starting version 7.3 which is going to be released I would say quite soon and since then you will be able to to discover your transparent firewalls you’ll be able to create connections to your environment and use them uh for the path simulations as well which is the ultimate goal yeah and I would like to and uh I’ve just seen Meline already put it in the chat but um If there are any questions, feel free to submit them in the Q&A section. Um, and I see um a question, are compliance checks a point in time or are they continuously monitored? So um our compliance checks are based on the intent checks and the intent checks are applied on every snapshot. So whenever we discover a network, we gather all the data. We apply the desired state of the network and match it against the state that we just collected and show you where there are mismatches or where you need to improve um your network to be compliant and where are you already successfully uh uh um yeah matching the requirements of any given regulation being list 2 being a DORA uh PCI, you name it basically. And as you can create now even more powerful uh uh checks, intent checks, this gives you even better detail in regards to compliance. So let’s see. Okay, I see there’s another one in the Q&A section. [clears throat] Milan, yeah, I see I see the Yeah. Yeah, I see the question. Uh can IP fabric handle automated path simulations over tunnels when there are multiple sources and multiple destinations at scale? Well uh that’s a great question. Thank you for that. So the way the IP fabric operates uh is that you can use the UI and of course there’s a limit because if you’re a UI user you can only at a certain time you can only simulate one thing or you can open multiple tabs and uh simulate many things but that doesn’t scale really well. What our customers are sometimes using is that they are leveraging our API capabilities because anything you can do in UI in terms of task simulation, data extraction and so on, you can also operate over API and the API skills very very well. So we have use cases where uh a customer wanted to test if the firewall was implemented correctly which means the test included uh 50 or it can be 200 different sources. there was one certain destinations and they they wanted to verify that all the 200 simulations were always traversing the firewall with the exact source uh interface and destination interface and uh to to be using the correct policy. So they leverage our API capabilities. They use it over the API and they simulated 200 different simulations over API and got the result within couple of minutes uh by using our engine. So it can be it can be pretty quick. So yes, uh the API simulation can scale very well, but you need to leverage our API. Mhm. And there’s another one. Um will there be selectable example intent checks such as the ones you had in mind when developing this or are supposed to dream up how to utilize these new features in the best way ourselves? Um, as we are usually supporting you with our customer success team, of course, we will support you in developing the right intent checks for your purposes. Um as these enhanced capabilities especially when it comes comes to the attributes we can’t create some preconfigured attributebased intent checks as these are really unique to your environment. Um so it will be very hard to create something up front but we will always support you our customers in enhancing what they have um using uh of course the knowledge we have as we are really um working together with you and of course um also showing you how to use it, where to use it, where does it make sense, what’s the experience we see and stuff like that. So um you don’t have to dream them up yourselves. We will support you in building them. Yeah. [clears throat] Uh thank you George. I I would only maybe uh add uh other other part for it. Uh the the in rules we saw in the in the presentations was the was specifically related to to the attributes or to the capability that we can now use attributes uh as an additional filter in the intent checks. Uh however there are already like more than 100 plus best practice intern rules inside e fabric by default but the attributes are are a little bit special because uh attributes are as Christian pointed out they are a very specific thing for every environment because every customer defines their attribute uh differently. So it’s a custom thing. [snorts] However, what I would recommend is not really uh try to uh think about the attributes or providing multiple intern rules based on the attributes in the UI. what what we are always recommending is to create a set of rules outside of IP fabric uh on a on a places like Git where you can really think about how to uh think about uh of programmatic compliance and from there you can easily pick up the rules and you can leverage that and populate all the attributes and all the intent rules into IP fabric over API from the source of your uh compliance programmatic uh database. So that’s the the way that we are trying to uh promote is that every customer first create their own concepts of the compliance and their own rules uh let’s say you know on paper or on git and then programmatically pushes that through to IP fabric uh which allows for more u manageability I would say uh for the second question which I’m seeing from from Desmond Chan thank you for that uh the question is can we define a generic router or gateway that is not being supported by app fabric. Uh unfortunately uh I I know where it’s coming from. We can right now create a manual link which in fact is not generated by discovery. So uh you may think that we can also add a devices or we can add a concept of adding virtual devices or gateway that are uh in fact not available uh in the snapshot. Unfortunately, uh this is not possible as of now, but uh possibly we will think about it in the future. Thank you for that. And there’s another one. Are there published examples, white papers of utilizing the API for mass testing the firewall rules? As you referenced earlier in the Q&A answer, I’m curious to know more about that. Yeah. Uh great uh great question. Thanks for that. Uh we we have examples uh internally uh based on our interaction with our customer. Uh unfortunately there’s no white papers yet. Uh but uh we can always uh we are happy to share that information once we form formalize uh that uh or those scripts that we used with the customer. So it doesn’t contain any code that we we cannot share. But uh uh long story short, we are only really leveraging our SDK to do that and uh all the documentations and our SDK is uh available online. But in any case, uh feel free to get in touch and uh we can we we’re more than happy then uh follow up on that. It’s it’s not that that complicated. Okay, I would say let’s wait another minute or two um if some questions come up. [clears throat] Okay. Um let me start the wrap up or or the way you say it. Uh again, thanks everybody for participating. Uh thanks everyone joining the webinar and uh listening. Thanks for for the question. Uh thanks to Meline uh who uh made the webinar possible. Um thanks to Christian. Yeah, many thanks from me as well. ### Untrustworthy AI & Automation As organizations deploy AI across change management, troubleshooting, and audit workflows, they’re discovering that AI agents are just as likely to make mistakes as human teams if their decisions are based off of fragmented data. AI can make those decisions faster than humans can, propagating errors at machine pace. Over time, this can degrade an organization’s trust in AI and slow progress towards digital transformation initiatives. Transcript we’ve introduced uh MCP as a as a way of of interacting with IP fabric as a as a as a platform. What what it wanted to do initially was really to to talk through a couple of things. So let’s give you the agenda for for what we’re going to talk through today. So the the first thing is really to understand well what is it that IP Fabric’s doing and why it’s interesting to what you do as a as a network practitioner. um and then really step into why um AI is important in that and what it what additional capability it brings as a result. So so once you have this this understanding of what the network is, why is is uh MCP important. So I wanted to cover those first and then what we’re going to do is just drop through a couple of um of use cases really. We’ve got um these three threads that I’ve chosen here really based on um things that are important for a network practitioner to do as part of the day-to-day job. So the ones I’ve picked specifically you can see here design validation this is really about saying is the network built the way I expect it to be and doing what I want it to be doing. Um you could equally say that’s around plan change as well and and being able to to understand right is the result of my change what I need it to be. Um the second thread really is root cause analysis and this is kind of almost the exact opposite of that. This is taking the symptoms of some change in the network and working out what has changed and why it changed. Um you know very very detailed um potentially uh analysis required there. The third one is is looking at something that’s that’s really not practically possible right now, but what we want to be able to do is is probe at that a little bit and see if there are ways that we can really help um predict the way the network will behave under certain conditions. And so so the whatif scenario becomes a thing. And then obviously at the end here we’ll just ch chat through what’s next for for two different sets of people. We know that there are going to be uh existing IP Fabric customers on the call who want to know more, but there are also going to be potentially people who haven’t yet used IP fabric and and so we want to give you some guidance as well as to to what comes next. But let’s just briefly uh explain about the really the point of the digital twin. I suppose when you’re going through any network operations uh process anything uh that where you’re looking after a network infrastructure there are certain things that that need to be delivered and it all hinges really on this first point here understanding how the network infrastructure supports your business. So it’s it’s being able to understand the impact um that issues when they arise can have on business process and it’s really I suppose mapping through those dependencies from um different parts of the network on each other but also on applications and how they sit on the network infrastructure. So um typically that’s in people’s heads or or you know really tribal knowledge that’s been arrived at through experience in an organization. Um and what we want to do is see where we can help with that. Um that spills down really into these other these other four areas I’ve listed here. There are lots of others, but things like reacting to unplanned change. So resolving incidents that have occurred um by being able to diagnose them and and so as a result minimizing the uh uh the outage time I guess for any of the services that run across the network and of course the number of outages as well because you’re proactively able to to to see what’s going on. [snorts] the idea of plan change where you’re where you’re having to prepare and and and consider what a change is going to to consist of to validate that it’s been completed correctly and of course to to you know look after the roll back or fix forward approach that you take as as a result of that not necessarily doing what you need it to do. So much understanding of the network is needed in that process and again so much of that is is embedded in people’s heads. um exposing that in a in a more uh programmatically available way a key to automation and potentially to to um agentic approaches as well. Um project control here this is about measuring and demonstrating progress. So this is about saying how do I how do I demonstrate that things have changed and these changes have been positive not to just the the network operations folks but people outside that um make sure that the the the CXOs see what progress is being made and how much better things are than they have been or um see where the the the critical pinch points are in the network and so on so that so that investment can be made to fix those things all about having a full understanding and appro of of being able to um demonstrate that the uh that you know and understand where the network needs to be improved. So it is really about that that measurement piece. And then obviously the the last one is a really simple sort of one. In reality it’s about life cycle management. It’s about having control that dayto-day control of the the the network infrastructure itself. Really understanding what it is um where it is what state it’s in and how it needs to change going forward. So these are all areas that that you need um that understanding for. And of course, this is where the digital twin really comes in because it can help you address all of those things. So what does that what does that mean? Well, from the UI of IP fabric, for example, you now have that ability to interactively observe the network. You have that ground truth, the the data model that sits under the, you know, in the platform gives you that data and gives you the the starting point for all of those things we talked about. you’ve got a single place to go to understand how all of the network hangs together and interacts with each other to deliver service. Great for the individual who who needs to use that as within the line of their work. But then we need to take that beyond that because obviously that that’s fine. Um when you’ve got sufficient individuals to do that work where you want to share that or out or make it um repeatable or or or automated you need to be able to appreciate there are data points in IP fabric and any other digital twin that you can pull those data out and then use them programmatically once you’ve built the the scripting or or or whatever workflow. it’s then available for others to use. So you’re not then relying on the one person’s head. And I guess the point with MCP is we’re taking that step further. We’re not just saying you need to know where all those data points are because the uh the LLM that uses MCP can reason about that. it can it can make those decisions for itself, decide what information it needs in order to do the correlation that it needs to do to build the narratives that it’s about to share with others. Um, and so, so as a result, you’re creating something that’s much deeper potentially from an analysis point of view or much more diverse in terms of where it’s gathering data from and then is able to present that in a way that’s consumable by a much broader audience. That’s really where where MCP comes in. Now, from an IP fabric perspective, this is kind of how it all hangs together. So at the bottom of our iceberg, we have in deep in the depths, we have that network infrastructure that’s, you know, unfathomable really to to many. It’s dark. It’s it’s complex and it’s and it’s hard to understand. And so IP fabric comes along and creates this data model based on the network infrastructure that then becomes a little more structured, a bit more normalized, a bit more manageable. uh IP fabric API on top of that data model makes that now accessible. So your the UI uh you can interact with it. The API you can make it programmatically available. But now by placing the MCP server this control layer on top of that what that now does is opens that up to whoever is interested in network information to be able to conversationally pull that data through IP fabric’s API and present it outwards. So as IP fabric is is the digital twin for this MCP becomes the interface into the LLM which is where that reasoning is going to happen where that correlation is going to happen and of course where that hallucination has the potential to happen. The key here is that IP Fabric’s data is deterministic and and bounded. And so as a result, you’re going to get definitive answers to to questions. And so there is no need for the LLM to to hallucinate about that data when it has the the um the definitive view. So hold on to that thought. So, let’s drop into to the first of the demo use cases and and um this is something that that certainly uh something I I’ve stumbled across many times in my role as a as a network consultant over the years. this idea of of checking and to make sure that the network as it’s implemented is as it was originally designed and that can be like I say full network design or it can be um down to the individual changes. IP Fabric will support that through each of the of the modes that we’ve talked about. From a UI perspective, you could just drop into the product, go look at the topology information that comes back, look at the technology tables and and ensure that those match what what looks what’s in the design document. You can check then by creating intent checks um on configuration to make sure that things are configured as they should be. But this is all down to the individual interacting with the product to do that. The next step up from that would then perhaps be to use the API to script those exceptions. So to look to see right okay this configuration isn’t as it should be. How do I go fix that and then build that into for example anible playbook or something to go remediate that based on inventory data that’s pulled from IP fabric. You might also choose to take that verified data and push it into other systems where it’s useful. This is where the API really would would be used in that case. It’s about about ensuring that everything is consistent with that design and with the the the network as implemented. So what does the MCP bring that’s different? Well, what it’s going to do is take that whole step further. It’s going to be able to produce uh a report and a remediation plan using those original source materials and best practices that are going to be consumable by the wider audience. So it could be another uh network engineer, it could be management, it could be whoever needs change management folk or whoever needs to understand that the network actually reflects what uh what has been documented. Give you a quick example. Um, if you’re a network engineer like I I was, you’ll recognize this instantly as as the kinds of documents that we use to build our our networks from. Uh there’s information in here about the uh this this document would have been put together by an architect to include inventory uh connectivity information, configuration information, control plane, management plane, all of those good things. Um, and if I scroll these through, there’s my diagram. Here are my here’s my inventory of devices and the versions of code that I want to run on them. Uh, here’s my connectivity matrix, which interfaces are connected to which. Here’s how span entry is going to be configured, what IP addressing I’m using, and so on and so forth. Right? So, there’s plenty of information here about how that network is wanting to be set up and built. This would be a very typical way of that that um being captured as a word document with a bunch of tables in here with all the information that you need. Um now that is great, but obviously if we’re then going to go and look at um at IP fabric, let’s say um to see how that that maps to the network as it’s been discovered. We can see obviously the diagram looks like the diagram that was in the uh uh in the product there. Um we can go into our technology tables and we can look at things like connectivity matrices and and in particular that was for the Paris site. So let’s let’s you know um focus that down onto onto Paris. We can see the information here that that matches the information in that uh in that design document. But it might be in a slightly different form and it might not you know necessarily be exactly the same. So we have to sit as an individual and do some translation between the two. We might also decide right actually I need to to to decide in the product where things match the standards I have and where they don’t. And in this case we’ve got NTP sources here. Um you’ll see this red and green color coding over here. This is basically my NTP sources are set the way I want them to be. This is my rule that I’ve created and essentially I’ I’ve filtering uh this list here. I might choose to only show the red devices and then I might decide right these ones I want to go and remediate in some shape or form. So I could do that manually by looking at these or if I should so choose I could go through here um prod that API endpoint with this uh payload and get that result to to then allow me to automate that process. So this is all about making sure I’ve got the right data in the right place in order to to automate this. But I have to know which data it is that I’m looking for. That’s that’s critical to this. So to go to my next stage um to to use my MCP and and what what I’ve done here is I’ve I’ve used Claude desktop. You could use any of the other um any of the other platforms, but Claude will help give us an indication of exactly what uh what’s possible. We use the Summit um uh for 4.6 model because it’s it’s a good model for this kind of thing. Um, your mileage may vary depending on on which models you use and which uh um which agents, but this gives us a good example. Now, and what I’ve done here is I’ I’ve basically said to Claude, take that that LLD document that you’ve that we were just looking at the word document and using IP fabrics snapshot validate that that low-level design has been implemented correctly. I’ve asked it to look specifically at a few things. You’ll see topology, VLAN, span entry, so on in there. But essentially, it’s going to just just do that comparison for us. Now, it’s we’re not we’re not scripting this. We’re not telling IP Fabric to Claude to look at, you know, specific IP Fabric API endpoints or specific pieces of data. It’s purely going to use that document to determine where to go look. And so what it’s going to do here is using the MCP server, it’s going to prod the API of IP fabric to essentially bring out a load of data. And and this was a really quick one. And what it’s done is it’s gone, it’s looked at VRP, OBF, span entry, BGP, NTP, SIS log, S&P, all of these things and assembled a group of findings. Um, and I’ve asked it to basically write that out to a validation report. So, if I just click through here, scroll it to the top, you’ll see what it’s done. It’s created a summary and said, “Look, these are there’s some deviations. There’s some, you know, there’s some areas where we conform to everything.” Um, and then we go into it in a bit more detail. You can start to see, right, yeah, actually, I’ve got things that are conforming here in terms of my physical connectivity, but some of my OPF tables are wrong. Now, this is just pointing out that actually there’s inconsistencies between the tables in the document, but it’s been able to to to do that for us as well. Um, there’s some some issues around some of the interfaces have been swapped around uh in the tables. But now we get start to get into the interesting things. Spanning tree, you can see we’ve got a root bridge placed badly here um and needs fixing. And as well as being able to spot that problem, what it’s also been able to do is give us the configuration that needs to be deployed and where to in order to fix the issue. Now, for for all the will in the world, you’re not going to automate this um simply uh through being able to pick these kinds of things up unless you’ve got essentially template configuration for every platform um and and every uh every condition, every technology that you’re deploying. What using the LLM has done here is opened up the door here to because IP fabric is a vendor agnostic model. we store things in that way. Well, you can use the LLM here to essentially um work out how to apply the data that comes from that vendor neutral model to a specific vendor environment. And um we’ll see that as we step through this further. So these in this case there’s some configuration for a couple of Arista boxes here that’s needed in order to bring um our span entry in line. Our IP addressing looks okay according to this, but VRP is broken. So again, we’ve got some remediation configuration to uh to deploy there. Um what else have we got in here? We’ve got some some issues around OPF on Cisco. So this is now Cisco IOS configuration in terms of the costs that some Juno uh Junos configuration as well here. So by by using the LLM, it’s able to to apply the the right remediation for the right platform. Um and you’ll see that yeah we’ve done our BGP checks as well. All good. Some more stuff down here around NTP. And this comes back to what we were just looking at NIP fabric. Um basically there’s a remediation activity here for certain devices where it’s not got an explicit um uh NTP server defined. There’s the Arista EOS uh command line. There’s the Cisco ISXE command line in order to deliver that and so on and so forth. We could go through step through each one of these, but in in reality, what you’re going to get is this report that tells you the things that are right and the things that are wrong. And of course, what that can now be done is shared with project managers, with network managers, with whoever needs to know in order to see progress. So, because you can run this now and then you can run it tomorrow on on the uh the next snapshot of IP Fabric and so on and so forth to see how progress is being made. Okay, let’s go to our second um our second example. And this one is is an interesting one. This is root cause analysis. And this kind of turns the whole thing on its head. Um because this is now not going to IP fabric and looking for for this specifically for the data, but looking really at where things have changed and um and and why. So it’s the symptom rather than the actual um the actual state configuration. So in this case in the UI it’s all about going to look at our path lookup capability and our snapshot comparisons to say look something’s changed. Where is it? What is it? And how do I find out what it is? As an individual I I’m doing the exploring but IP Fabric’s giving me the the tools to do that from an API point of view. we can take the end points that we find in the UI there and script it. So again, we can we can look at a specific path, show how it’s changed between snapshots by by scripting the uh the analysis of that JSON output that comes back from those API endpoints. But again, it’s very very specific, very narrow focused. soon as we introduce the MCP, it can it can [clears throat] broaden that that analysis and and and deepen it because it can now look at well actually it’s not just about the fact that the state has changed but we need to understand why it’s changed what from a network perspective would have caused that to have happened and really brings then a different level of analysis the the sorts of things you would get from that sort senior engineer. [gasps] So again, let’s have a quick look at what that actually means. Let’s start with looking at IP Fabric again. And in this case, what we’ve got here, um, we’ve got a traffic flow between an on-prem device in this Prague location at the top left, um, going down to this this, uh, AWS environment in the bottom right here, and it traverses a number of of stages in the network, goes through the MLS network here, through the Boston location, over a VPN, and going out into into the wider network. You’ll see firewalls shown here in green, which is all good. it means the policy uh is allowing that traffic to pass. And so as a result um we’re able to hit the load balances that we’re seeing down in the bottom right here in AWS in order to to reach the the the destinations we’re looking for. So that was then. But what happened overnight? [clears throat] Because this this is what this looks like after uh after a change. Um, Prague is still where we start obviously, but now we’re traversing into Paris and then fire a firewall in Paris out to AWS. Well, the AWS doesn’t seem to have changed, but our firewall is now showing red, which means that that traffic is blocked and isn’t going to work anymore. So, here’s here’s our issue. Something broke overnight. Something has has caused the traffic to change direction uh go through Paris. what’s happened now in in op fabric itself what we can do is we can do this comparison of snapshots I’m looking at day four I’ll compare it with day one and we’ll see what’s happened and you can see very clearly where that uh where that change has occurred going through Prague I reached this this router and where before I used to go this way now I go this way so I could start by uh digging into that routter exploring the behavior and if I just take one of these um you can see the routting decision that’s been taken and the and the routes that it’s used and now I can look at more detail at the rooting table, the ARP table, the MAT trade table and so on. So it’s giving me all the data as a as an individual practitioner that I need to go and work this out. It’s also of course again we’re able to extract that information through the API. So I can I can use the API to to extract the information about that path lookup and go and and make make more sense of it or I can ask Claude to help me. [snorts] So let’s switch back to Claude and let’s look at our second scenario here. And basically what I’ve said is look Claude do me a favor using the day one snapshot list out the the path between those two endpoints um using TCP 443. So that’s that’s working out is this traffic going to be able to get from here to here using that uh that port list. And you can see there that it’s that it’s built the path through and it’s showing all the elements the the onrem the MS and so on to through AWS. And then what I’ve done is I’ve asked it actually can you can you now look at day four and see what the difference is? And you’ll notice here it’s highlighted some things in the middle. It’s a different path out of of uh of Prague via Paris in order to get to to AWS. So now I need to understand well why is that happen? There’s some sort of migration event that it’s talked about in here. You’ll see the on-prem WAN path has changed. You’ll see the IPSCV VPN pointer has now shifted as well, but the AWS SP path itself is unchanged. So what what is that migration? What does it look like? And it’s saying here the pivot point here is the Prague router. In day one it forwards towards NS. In day two it forwards forwards towards H2X1. Well, what what’s H2X1? Well, as we look further down, it works it out, right? Same. That’s a that’s a Cisco SD1 environment. So, the migration appears to be from MS to uh SD1. Awesome. It’s really working this this through ne nicely. But it’s also talked about this cloud breakout anchor site changing. This is the VPN tunnel that was in Boston that’s now in Paris. So what’s happened there? And as you scroll down through here, it it basically points out that in day one you were receiving essentially uh a summary route via the the path in um through through Boston. Um this and now what we’re we’re seeing is this new uh path this new VPN tunnel which is giving me specific routes uh from AWS via the new endpoint and as a result you can see that the traffic is shifting there as well. So rather than go into it in any more gory detail here, I’ve with the the thing I’ve said, look, create me a report. Let’s let’s get to the bottom of this. And this is the report that it’s created. And essentially the overview is this. There’s a path lookup investigation. Um the results are these. This is the before. This is the after. This is the summary of the path differences. So how the path has changed. This is the AWS side. This is the SDWAM stuff that we’re now using the protocol shifts and so on. These are the prefixes and and as a result of that the interpretation is this and that can now be presented to someone who can just pick this up consume it and understand exactly what’s happened whether that’s an incident manager whether that’s the network management people whether it’s the people who are who are looking at the results of a change in a meaningful way. what we’ve what um IP uh sorry what the MCP has provided is all of the IP fabric data to back up this root cause analysis investigation the data is there if you were to do this as an individual but because the LLM is able to do this we can also uh then go ahead and and uh and use the data from open fabric for that as well so appreciate I’m uh I’m running out of time already here so let’s um let’s quickly dash On to the third use case that I’ve got listed here. And this is the the legend that is the whatif scenario. It’s probably the question that everybody wants to be able to ask. We know how difficult what if scenarios are, particularly in real networks because you’ve got such a variety of technologies, but it’s really hard to uh to emulate those. You have to divide and conquer your network into separate pieces in order to be sure that you’ve got an understanding of that centralized and distributed control plane and and the data planes and policy planes and the behaviors of those things. So really if you’re wanting to do this end to end the real solution here is not to try and emulate at all. It’s a really tough thing to try and do. It’s uh computationally intractable. So it’s just such a big a big challenge. So it’s much more sensible to reason probabilistically about this. It’s the way that you or I would as a network practitioner um if we were asked to try and determine what would happen. We would sit down and we would we would think it think about it and and weigh up the probabilities. What IP Fabric is bringing to this is that determinism. It’s saying this is what the network looks like and this is how it behaves right now. Um you can trust that the data represents the way that the network behaves. What the LLM will bring is this reasoning capability on top of that to say well actually I know and understand what these technologies uh do and the interactions between them assuming you’re using the right models. Um is what’s going to happen? Let’s let’s let’s think about it. Let’s correlate the data. Let’s let’s reason over it and give you an answer. So, let me very quickly show you um a final example. So here we have in our demo environment we have this this Frankfurt location which is as you can see there’s a a whole mesh of interconnection here using different protocols a whole bunch of different one different protocols um relationships between these devices both control plane and data plane um and it while it’s self-contained it’s also obviously connected through this firewall out into the to the wide area network. So the first thing I asked um Claude in this case was [snorts] well what actually is that location? you know, go look at the uh at Frankfurt site in that in that snapshot, see if you can work out more about what that location is. And so what it’s done is it’s created its own topology view, its own understanding. And it’s tried to using the protocols it can see characterize the behavior of that network. And it can see that there’s OPF running, which is essential for the uh for an underlay environment. It can see BGP running over the top of that. and it can see vxlan being used to carry data from layer 2 v uh vn v vlanss over vnis to the uh to the other vte across that and so it’s rightly saying look this is a a modern spine leaf data center fabric using vxlan using um ibgp for evpn um and essentially then routting via a checkpoint firewall out into the wide area network. So what I’ve then asked it to do is is map a path between two locations across that p that that uh fabric and out into the wider network which it’s gone ahead and done and understands how to what that means in terms of encapsulation and decapsulation and so on as it’s coming into and out of the the fabric. Again we can we can share all of these outputs actually. that might be useful to you to to look through in detail. But then what I’ve asked it to do is do a switch by switch failure analysis. Look at the the individual switches in that fabric and have look at the impact that they’ll have on that that traffic path. Now in that in this particular case it’s clear switch one and switch five are important to this. Switch five being the top of rack host where top rack where the host lives. the switch one being the the the um the spine switch that the this traffic is passing through by default and obviously initially if you lose that switch it will break the path but then what happens and and so I’ve asked it to then go to that next level if that switch were to go down or the interface go down what happens next and as a result it then looks right sees OPF will will do its thing and the underlay it will recon converge and as a result um we’ll be able to still maintain same connectivity and so on. So it’s it’s gradually iterating away on the uh the behavior of this this network to understand exactly what’s going to happen. You can see here it’s talking in detail about the different OPF adjacencies about the way that the VLANs are interconnected with the VNI and the using VXLAN and so on. Um and then it looks about then I’ve asked it specifically right we’ll look at the underlay routting and make sure that everything as it should be and again it goes into much more detail here about how OBF interior routting is working um what changes happen when interfaces drop and so on. Um so many so many different things it’s pointing out as it goes through and it’s really trying to work this out in detail. You can see um see here there’s there’s reference at the bottom here about there’s a genuine routting recon convergence not instantaneous ECMP rehash. This isn’t this isn’t [clears throat] um a simple superficial view of what’s going on there. And so now um we arrive at what what really is the um is the the the end point here. There’s there’s single points of failure that it’s identified. There’s issues here with with how this is deployed. And what I’ve asked it to do again is is basically write that out as a um as a markdown file as a report. And you can now step through that in the gorier detail that we’ve talked about. But it really here it’s it’s basically got a series of recommendations about how to fix this. So dual homing, firewall clustering, but also adding additional uplinks into the fabric where there are things missing. So it’s really about getting to the to the bottom of the problem. Something that probably wouldn’t have been easy or or particularly straightforward to have done by um without having all of this data available. And I guess this is this is kind of the point here. [sighs] So I think we’ll we’ll park the the the um the demo piece there. [clears throat] Um there is a essentially the the next steps if you’re if you’re an IP Fabric customer are to to go ahead upgrade to the latest version of IP Fabric accept terms and conditions enable the server and away you go. Really it’s then about setting up your your um your client to to refer to that. plenty of information in the documentation and plenty of support from our solution architects to help you get there. Um, you know, we’re really keen to help you break open these new capabilities that that you haven’t had available to you before. Um, for for those who are not yet IP Fabric customers, well, you know, you know where to go. I mean the website has has got plenty of of a information but b means by which you can come talk to us and start to talk about free trials and PC’s and the good and those good things. So um but yeah um hopefully that’s g you a bit of an idea about what the capability for in I think we may be on to our Q&A. I think that’s probably the best thing to do next. I think that’s Maddie, you’re back. Uh yeah, [laughter] and it seems like we’ve got a couple questions coming in, especially in the last few minutes. Um but just to start off with kind of a broad a broad question first. Um you were using Claude throughout these demos. Yeah. Um but can you use your own custom LLM uh with this MCP server? And is there anything you should do differently if you are using a custom LLM? Yeah, that’s a good that’s a great question. Um yeah, as you say, we we use Claude for the demos primarily because the data is all uh demo environments and and labs. Um and so and so from that perspective, we uh there was there was a lot of experimentation going on, right? Um we also found that the the models the anthropic models in particular are very effective and very well trained in uh network um in in network process. So they they they have you know they will reach a really good answer. Uh that said we have already got customers who have gone ahead and um and enabled this in their environments and are using it against private LLMs in their own pods um using the [clears throat] the open- source LLMs and are getting good results. Um, as I said before, your your results will vary, you know, based on on the uh the models you’re using and the the training that’s been done on them, but ultimately with the right prompts, you are going to get really strong results and and and address use cases you wouldn’t have been able to before. Great question. Yeah. Uh, and we have even more coming in. Uh I’m just gonna take in in the order in which they were received. Uh the next one is also pretty general. Um but how does IP fabric handle security for the MCP server? Okay. Yeah. So the security is is it’s really important actually that when you go back to that um the the iceberg slide um because the the uh MCP server is literally built on top of the API. We essentially use the same uh authentication that we use for the API in order to get access to data. So you provide an API token as part of your your M MCP client setup and it will always use that same API token to access the data which means that um when you define arbback the role based access control for that API token you’re able to limit or or or basically place the controls around the data that’s accessible through MCP. So yeah it’s really good question. Awesome. All right, the next one’s from Normand uh and he’s asking uh does the MCP server expose uh config management endpoints or just the devices and end to-end paths and technology tables? No, it’s a really good question, Norman. Thank you. Um yes, the the the config management endpoints are exposed. Um you can for example we’ve seen um cases where customers have used um done CVE analysis using the the publicly available CVE data but then IP fabric’s configuration data to make sure that uh that devices are are compliant or otherwise right so it’s a it’s a it’s a great use case all right uh the next one is since IP fabric now has MCP for LLM reasoning. Are there plans to add batfish like formal validation or is this outside the product scope? Great question. I I of course um while I work for the product organization um I probably can’t talk in terms of of formal roadmap but um I guess um yes to your to your point um that whole what if scenario formal validation piece is is important um as a capability I think um for now it will probably we’ll continue to experiment using the LLM in order to deliver that Um, but I would never say never. I’ll um I’ll that’s probably the the the most I can do in terms of a commitment for you. Never say never indeed. Um all right, the last question for now. Uh unless there’s any more. Uh this is maybe the last chance to ask any questions. Um what resources are necessary to implement an MCP server uh or a client server solution? Yeah, that’s a really good question as well. Um we’ve we’ve been very um gosh the team have been very very thorough looking at at the uh the resource requirements and everything in here. Um what we have managed to do from from an IP fabric appliance standpoint is to keep the resource requirements the same for where we’ve added the the MCP capability into the product essentially from a memory perspective from a CPU cycle perspective from a storage perspective there is no change um there is a an embedded small model um within the uh within the product now which is used to um essentially do the translation between the the natural language query and the API endpoints at the back end in order to pull um pull the correct data through. But that’s that’s already downloaded and and distributed as part of uh part of the product. So there’s no requirement for example to um to to um drop the air gap and and connect to the internet if you don’t need to. So, so basically the the short answer is there are no additional resources at this stage. All right, great question. Thank you, Renato. Yeah, so many really good ones. Um, thanks everyone for submitting your questions uh for participating in the chat. Um, again, if anyone wants to take a look at our prompt library, it’s free. It’s linked in the chat. It’s linked in the docs. Uh, if you have questions, feel free to reach out to the team. Um, we’ll be sending out um a follow-up with the on demand recording and stuff as well if anyone wants it. Um, and um, yeah, that’s all from me. Uh, thanks everybody. Yes, thanks very much. Thanks for your time. ## How Do We Close These Visibility Gaps? Each of these costs is firmly rooted in the visibility gaps between cloud, network, and application tooling. In order to close these gaps, you need to find a way to: 1. Discover your actual cloud and network behavior. 2. Understand which network, cloud, and workload-level controls impact performance and reachabilty. 3. Correlate cloud, network, and application layers into a unified view. And IP Fabric is collaborating with Illumio to help joint customers do just that. ## Why Is IP Fabric Partnering With Illumio? If you could add Illumio’s application context to IP Fabric’s model of cloud and network behavior, you’d get a unified view of how applications connect to cloud and network environments. Looking forward, you’ll be able to use that app-aware model to: - Determine the blast radius of a change or incident by understanding how devices, paths, and policies impact applications. - Accelerate troubleshooting by identifying whether an issue is caused by network policies, cloud controls, or host-based enforcement. - Instantly validate segmentation policies and security controls, and generate proof of continuous compliance. - De-risk AI and automation initiatives by contextualizing every change and automated workflow with app-level data. IP Fabric’s collaboration with Illumio is the first of its kind, going beyond the capabilities of any siloed tool so that when organizations are asked “Can you prove that you’re in control of your ‘crown jewel’ applications?” they can confidently say “yes.” Stay tuned for more updates on IP Fabric’s collaboration with Illumio, or [contact our team](https://link.ipfabric.io/45MGa2H) for more details. ## Related Resources Integrations ### [4 Steps To Map Application Dependencies To Critical Infrastructure](https://ipfabric.io/blog/map-application-dependencies-in-4-steps/) Use IP Fabric's application infrastructure mapping capabilities to trace application dependencies across network, cloud, and host-level infrastructure. Integrations ### [Application To Infrastructure Mapping 101](https://ipfabric.io/blog/application-to-infrastructure-mapping/) Protect critical applications across on-prem and cloud environments using IP Fabric's new application-to-infrastructure mapping capabilities. Integrations ### [4 Steps to Improve CMDB Health with IP Fabric’s ServiceNow Integration](https://ipfabric.io/blog/cmdb-health-ip-fabric-servicenow-integration/) Learn how to boost ServiceNow CMDB health to drive more resilient network operations.