---
title: "Network Discovery 101: How to Build a Reliable Network Source of Truth"
id: "25871"
type: "post"
slug: "network-discovery-build-network-source-of-truth"
published_at: "2026-03-20T18:28:53+00:00"
modified_at: "2026-10-26T21:59:53+00:00"
url: "https://ipfabric.io/blog/network-discovery-build-network-source-of-truth/"
markdown_url: "https://ipfabric.io/blog/network-discovery-build-network-source-of-truth.md"
excerpt: "Embarking on an M&A? Building for AIOps? You need a reliable network source of truth—and that starts with network discovery."
taxonomy_category:
  - "Discovery"
taxonomy_post_tag:
  - "CMDB accuracy"
  - "Netbox"
  - "Source of Truth accuracy"
---

# Network Discovery 101: How to Build a Reliable Network Source of Truth

Embarking on an M&A? Building for AIOps? You need a reliable network source of truth—and that starts with network discovery.

[https://ipfabric.io/author/sebastien-argoeuves/](https://ipfabric.io/author/sebastien-argoeuves/)
[Sebastien d'Argoeuves](https://ipfabric.io/author/sebastien-argoeuves/)
Solution Architect

Published

20 Mar 2026

Updated

26 Oct 2026

Today we’re going to answer a question I’ve been asked a lot over the years: How do you know if you can trust your source of truth? Or perhaps more grimly: have you *ever* seen a source of truth you can trust?

Most organizations don’t have a single source of truth; they have several. Some data lives in your monitoring tool, while other data lives in your [CMDB](https://ipfabric.io/blog/unlock-cmdb-accuracy-webinar-ip-fabric-ntt-data/)
, your [IPAM](https://www.youtube.com/watch?v=VUBTIQoC3vQ&t=1415s)
, and maybe even an Excel sheet or two. Each “source of truth” only shows you a fragment of your network, and it’s up to you to piece it all together.

If this sounds like you, it might be time to ask yourself:

- How consistent is your data between these sources?
- How are you keeping this data up to date?

Not sure how to answer these questions? You’re not alone. At the enterprise scale, it can be near impossible to maintain an accurate source of truth—especially if you’re manually updating a Visio diagram.

If you fall behind on day-to-day updates, you’ll end up with data that you can’t trust. And if your company embarks on a major digital transformation—perhaps a [merger or acquisition](https://www.youtube.com/watch?v=qJ_dX1Q8PXU)
—you’ll need to discover this new environment from scratch. Either way, the result is the same: you’re only guessing what you have running in your network.

Transcript All right, good uh good afternoon  
 everyone. Uh I can see we still have some people are joining in so I’m going to start slowly. Um my name is  
 Sebastian. So thank you everyone for joining today. Um while people are still settling in uh  
 I’m going to start with something that I’ve heard a lot today also previously but it’s the question that someone we  
 will ask someone. It’s like how h how accurate is your CMDB? Can you trust it?  
 And today I actually had an interesting answer from from someone saying have you ever seen a CMDB that you can trust?  
 which I thought is quite funny but unfortunately where we entering  
 everywhere are talking about AI obviously automation as well both put them in the same bucket  
 that CMDB accuracy is going to become something that’s going to be critical for your project  
 um so most organization don’t really have uh a single source of truth for the  
 network because what’s going to happen is you’re going to have different versions of Right? You’re going to have  
 some of your information that’s going to be in your monitoring tool or in your CMDB, in your IPAM, some Excel  
 spreadsheet as well. So all that data give you part of the truth of what you have on your network. So each of those  
 are going to be important and they give you part of the information like I said  
 but the the problem is the are they cons consistent with each other and how often  
 do you keep them up to date so the reason why it’s hard to keep them up to date it’s because the network is  
 the only source of truth where your network is a decentralized or has information which is decentralized where  
 each of your switches, routters, firewall and all those pieces in your network contains information that you  
 want to gather in one place and this is what is difficult to capture this  
 information consistently. But for that what you need is the right tooling something that can actually help  
 by continuously validating the state of your network. uh but so validating but also  
 discovering those nodes that you have in your network without relying on those  
 manual updates uh because otherwise if you rely on those manual updates and you have to  
 const consistently updating those information and you don’t this is where you’re going to have that wrong  
 information wrong data and now with automation and AI if you trust your  
 automation to do some actions If they don’t have if that source of information  
 is incorrect, this is where the decision that’s going to be made based on that is also going to be incorrect. Now the  
 problem is the faster we are trying to go by automating doing things at scale.  
 Now what it means is that bad data and will generate bad decision and at scale  
 throughout your network. So this is where you need the right information to  
 be able to make the right decision. So what [clears throat] we’re going to  
 do is put ourselves in a very normal situation which I’m pretty sure most of  
 you are in a similar situation where at some point we can take the image of  
 you’ve joined a new network or you are a new company so you’ve got to look after a network that you don’t know yet or  
 you’ve been working in the same company for a number of years and now you’ve got a merger so you’re going to on board a  
 new network that you don’t know about or maybe someone is leaving the company and now you’ve got to look after a part of  
 the infrastructure that you’ve haven’t seen before or that last time you’ve checked it was a number of years ago and  
 it’s that thing where you don’t really know what you have and this is the image there is like it’s it’s guess work is  
 you think you know something people might give you some information this is saying this is our vis diagram this is  
 what our network looks like now you can manage it because you’ve got the data that you need but the reality is we’ve  
 all seen those um incident or changes that you would perform where the moment you start  
 your change window you’re about to do something and oh it’s weird it’s not how I’ve planned it  
 because maybe you were looking at that vis diagram and now you realize that ah that’s not the same what I’m seeing on  
 the device doesn’t match the vis diagram so now you’ve got to go back to oh what  
 what am I about to do am I about to break something if I apply my confusion  
 just the way it is. Do I need to review the actual config I’m going to apply?  
 And now you go back to the drawing board of saying, well, I need to go few step back looking at the current state of my  
 network. Can I still apply my change? And then you may or may not be in a in a  
 situation where if you’re still within your maintenance windows, you can still perform your change. If you’re not, it  
 could be a situation where you’ve got to say, “Well, I don’t have time to do it now, so I’ll roll back and I’ll try  
 again next week involving tester and all that things.” So, it’s a lot of wasted time just because you didn’t have the  
 right information to start with. So, how can we help? So now what we’re  
 going to do is try to imagine if you could get that understanding of that unknown or unsure that I fully know that  
 network in a minute in a few minutes rather than getting it throughout painful discovery and manual updates.  
 So what we’re going to do is trying to look at what does it look like to get that understanding in a few minutes. So  
 now what you’re seeing in here will look like a network diagram. But I’m going to say something is it’s  
 not just a network diagram. And the reason I’ve kind of mentioned it before is your visual diagram the moment you’re  
 going to click save you’ve got now you’re unsure that is it still going to  
 be up to date. Within the first few minutes hopefully it would still be but now after a few months a few years this  
 is where you’ve got the uncertainty. you don’t really know what you have.  
 So now the picture that you have there, this is what IP fabric will after  
 discovering your network will be able to discover what are the devices in your  
 infrastructure. But it’s not just about saying great I know that you’ve got a switch there and a router there. What we  
 are doing as well during the discovery is piecing that information together. So now the key part in here is really  
 having the relationship between your devices. It’s great to know that you’ve got 10,000 network devices, but what’s  
 really useful is to know how are they connected to each other. Where are the relationships? What could be the impact  
 if that device disappear or how how the application relying on the network.  
 [clears throat] So yeah, so the the key part in here is really the relationship.  
 So what we’re going to do they’re just looking at a specific site in here and  
 what we might be able to see here I don’t know how clear the image is for my angle it’s not but uh um [clears throat]  
 those relationship between devices where you see some in yellow you’re going to have your SPF your layer two further  
 down now if you are trying to do that manually this is the part where you connect to one device you do your show  
 ip whatever the command is you see some output and now you’re going to keep that  
 output in mind go to the next device do the same command and I’m trying to find is this this neighbor is it another one  
 and this is the part that takes time so now when we’ve done the discovery you don’t have to worry about it we’ve  
 done that relationship mapping we know how those devices are interconnected  
 so now this is where I’m going to see that as it’s the difference of knowing  
 what you own. So the devices that you have and how your network behaves or  
 operates  
 because the understanding the dependencies between your network is what really going to help you understand  
 the risk and the impact of a change or having a better understanding of an incident when such things happens. So  
 now what you’re seeing on the right hand side is a similar topology as the one that we see there which has been pushed  
 into service now with that dependency mapping of how are those devices connected. So now if you want to put  
 that in place into your CMDB, you can have the uh the affected CI that would  
 kind of say if I’ve got an incident affecting one of those devices, what are the dependents? What else could be  
 affected in my network? So now because as I can see we’re  
 showing in here, we understand [clears throat] sorry how things connect. But it also mean that if we can  
 show this, it also means that we’ve got a good understanding of what are those things. So going back a few step backs  
 is it starts with that inventory. I was talking about the relationship but if  
 [clears throat] we know the relationship it means we’ve got the understanding of the devices that we have in our network.  
 So in here what you have is a CMDB something that looks that maybe you have  
 the same in your Excel spreadsheet maybe you have that somewhere else in your source of truth. The main difference in  
 that situation is you haven’t done that manually that data is coming directly from the devices that we’ve discovered.  
 So no more I’ve mistyped a serial number and now I’ve got duplicate entries with  
 different ser number which is going to have an impact from a maintenance perspective. uh or the wrong um model number for for  
 a switch because I forgot that there was a a letter somewhere where the same model doesn’t have that letter. So  
 you’ve got information that’s available extremely quickly and that you can trust  
 because there is no more manual error when you’ve extracted that information.  
 Uh so that’s the example in what we had in IP fabric and now that’s the same information that has been pushed into a  
 CMDB. So that’s the example with service now and again with that you’ve got the  
 option now of having an accurate CMDB. So when you’ve got your security team, your cyber ops or depending on how we  
 want to call them and they’re going to say how many devices do we have that are running this OS and that version instead  
 of doing that guesswork before we say well we think we’ve upgraded the last  
 devices on that version and you’re not too sure. So what do you do? You’re probably going to spend some  
 time more or less quickly depending on your automation strategy if you’ve already got ways of gathering that  
 information but you still have to be involved as a as a network engineer to help that cyber security team to find  
 the right information where now if you’ve got that process where you’re pushing that and now your CMDB become a  
 place that they can trust because they know they’ve got up to date information in a good way. You’re out of the loop.  
 They want a question. They they’re asking a question. They know where to fetch the information. They don’t have  
 to come to you for can you check this now. Maybe they’ll come back to you only because it’s like well we’ve seen that  
 you’ve got three devices using that version that we should not have. Can you please correct this?  
 Um and I’ve mentioned service now but this is not the only place where having that upto-ate information matters.  
 and okay. Okay. Well, anyway, that in here what  
 I’m trying to show there is an example of other tools that we integrate with. So, you would have your not in the  
 background, Netbox slightly closer to the front where those  
 are the tools that we’re going to see when you want to build your source of truth of what is in your network. So  
 similar story as the CMDB but slightly different use case where you probably won’t be using your service now from an  
 automation strategy to know what are the villain configured on the devices what are the state of my interfaces the IPAM  
 now you probably want to focus on a more automation focused source of truth  
 [clears throat] or I mean I forgot to mention again in here but it’s or you could also put that  
 information somewhere in an Excel file but And there’s chances that uh that  
 file will become out of date the moment you send it to someone by email and now everyone’s going to create their own  
 final version v2 v3 which uh unfortunately I’ve seen way too many  
 times. Okay. So this is really what I’m trying to do there is the end goal is being  
 able to have simple information. If we think an inventory is a fairly basic information  
 automated where you now have a way of having that information populated in your different tooling of your ecosystem  
 so that you can make the right decision for the network team but that the right decision for the business to rely on.  
 Okay. [clears throat] So now we’ve seen that what the a good situation would  
 look like. How how do we get to that? So if it seems that we can get there, why  
 are we not there already? Why do we still hear people saying I do not trust my CMDB?  
 And [clears throat] there are several reason for this is  
 it’s not one of the reason that we know it’s not it’s not like people are bad at documenting is we can do network  
 documentation. It usually comes to other problem is first there is the always the  
 what I think we have on our network versus what we really have and this is that gap in between which the drift  
 between those two which create that delta which is going to cause some issues. So the drift is the main factor  
 for struggling to get that CMDB up to date because the network is going to  
 change. So despite having the best intention, there is always going to be a moment where a drift is going to appear  
 between what you have in your source of truth versus what you really have on your network.  
 So the the second um I guess issues with this or the the gap with that is the is  
 the impact for this is a cost. So there is a cost impact of not having that  
 correct information. I’ve mentioned earlier potentially having a change windows having to be rescheduled just  
 because of the wrong information. So those are not necessarily the the first and obvious one but there is that  
 time risk because without the right information you may create a change having side effect that you didn’t  
 foresee and financial as well because obviously if you create an an outage  
 there could be as well a financial repercussion of such issue and what we’re going to see as well is the why  
 now why do we need to start fixing that problem now and I’ve mentioned it briefly but obviously automation and AI  
 uh tooling that are coming more and more of uh at the moment and without the right  
 foundation it becomes very useful to to use them utilize them fully.  
 [snorts] Okay. So now [clears throat] let’s look a little bit more in detail in term of uh why do we diverge from the  
 reality. So the network is going to change continuously. We know that a  
 network never stays the same. There’s always going to be changes because users want to do something else. We need to  
 add villain, we need to configure whatever we the network is there to serve a purpose the business and then if  
 the business doesn’t change then there’s probably something that’s not going well. So generally speaking, we are  
 going to have to do changes to the network and that’s why I was mentioning that that drift is going to happen and  
 now is how do we control that drift and make sure we can document it back.  
 The another issue in term of the gap is manual updates. So when I’ve mentioned this is you do a change, you finish  
 late, you’ve done some quick test and now you’re like, “Oh, I haven’t got time to do the documentation.” It’s all  
 right. I saw that next week, tomorrow morning. But then we all know the reality is there’s probably going to be  
 another fire next time. And documentation can wait. And unfortunately, it’s often something that  
 keep being postponed until there is an incident and then we’ve got to go back  
 to the drawing board or some regularity audit. Someone wants to actually we need  
 to prove that we have documented our network and now this is where people are going to spend a huge amount of time to  
 update that information. So the relationship drift is really what  
 is the problem there where even if you think about that simple example of updating your vis diagram  
 because you’ve changed added a device somewhere it becomes difficult to also update  
 everything that’s kind of depending on those devices where it’s easy to add one device into a diagram but in term of is  
 the application going to be monitored somewhere do we know what else is changing by just adding that one device  
 and this is where there is that drift that becomes bigger where your monitoring tool for example may have an  
 understanding of the devices but without understanding the relationship in between.  
 So that was for the kind of the drift between the what you have on your network and documentation. Now we’re  
 going to look slightly more into the the cost like what’s the cost of the having that wrong information.  
 I’ve mentioned it is slower uh troubleshooting or more time to prepare  
 or plan or or or do a change perform a change windows including your post  
 checks as well. So everything is is going to tend to be a lot slower.  
 the risk I’ve mentioned as well where now having a change that’s not properly  
 managed is going to create those risk uh by you change something somewhere but  
 now you didn’t know that another application was also using this that you’ve affected and now you’ve got that  
 outage in your hand which could also cause that problem with the money  
 whether it’s going to be a fine or the example I’ve got in here as well is something and I’ll mention as well from  
 um a customer example people where what we did with them when they started P  
 with us they they they knew they had a big problem with their CMDB accuracy and  
 with a small gap and I’m just looking at the number I can remember but they’ve started with discovering around 400  
 devices and what they’ve realized once they’ve discovered those 400 devices and  
 compared that information with what they had in RCMDB they’ve realized that there was a 10% gap and by that I  
 10 extra uh 10% so around 40 devices inside service now which were not on the  
 network. So now it may not seem like a lot for some people they would say 40 is not too  
 bad but now that wasn’t the full scope for them. That was only a partial part of the network. Then they discovered the  
 full scope and obviously that gap did not go smaller. It tend to be even more.  
 But what does it mean in term of impact for them? It was just like what we have in our CMDB is what we’re going to use  
 for maintenance renewal. So it means that those number the information that  
 we have in service now it’s very possible that we are paying maintenance for it but those devices are not in  
 production. So now if you multiply I don’t know the cost but the average cost  
 of maintenance for a device but once you start multiplying by the number of phantom devices now you start thinking  
 oh that’s a huge amount of money that we’ve spent for absolutely no reason  
 but that’s only one side [clears throat] of the story. There is also the the other side of the story where it could  
 be the other way around where we would see a device in your network but it’s not in your CMDB and now slightly  
 different but now you don’t have any maintenance for it because maybe you don’t have it in your CMDB so the day  
 there is a problem you can’t easily contact the support so then there’s always that extra process because it’s  
 like well it’s not supported can we add the support the maintenance so not having that information is also  
 going to slow you or add extra processes or things that you have to perform.  
 Yeah. And um so so yeah, so it’s really finding that gap both ways of things that we have discovered and that maybe  
 are not in your documentation. The other example as well where outside of the  
 CMDB, it’s also what do you use to update and populate your monitoring tools. Now, if we’ve discovered a  
 network device that is not in your CMDB, are we sure that it’s fully monitored?  
 Is it on our monitoring system? Has it got the standard configuration that we were meant to be using? So, all those  
 questions can cause some impact as well.  
 Okay. And now the why now? Why do we need to do that change now? So, this is  
 the part where there is the the pace at which things changes. So we always  
 change the network and we need to do more changes and we don’t have time to go back. So yeah we keeping things  
 updated manually is not going to work. Now there’s also the regular regulatory  
 requirement where we have to be compliant with some specific framework  
 and for that we need to provide documentation because if we don’t we we know that  
 there’s going to be the the impact which could be fine uh depending on where you  
 are. Yeah, could be different framework but where the network has to show the documentation we have to show that we  
 are in control of our network. we we have control over it.  
 And the last one is going to be the automation and AI where we know that  
 human used to be what would do the cor the correction layer but now we are  
 doing more and faster using the help of automation and AI but like I’ve  
 mentioned if the inputs that you’re sending to your AI or automation is based on that wrong information you’re  
 just going to get not just the wrong output but also the wrong action that is going to  
 perform which can be uh causing more issues to your environment.  
 Okay. So now that we’ve defined the the problem and the potential solution, what  
 I want to know to to show now is going to be how how can we help with  
 validating this reality. So IP fabric  
 its role is going to like I’ve mentioned is going to be first to discover your network and this is where we go from a  
 very uh similar approach to the network engineer to find out what the devices  
 are in your network extract that information normalize that information because it  
 could be multi- vendor where you could have your fabric in your data center which is not going to use the same  
 technology as your campus or your plan or your firewall and all of that  
 information, it’s going to be brought into the same place with a similar  
 output. Because from our perspective, a routing table or a firewall policy  
 regardless of what device is behind it, it’s always going to look the same.  
 And now we’re able to do that verification as well because we’ve got that normalized data.  
 And finally once you’ve got and collected that data you can reconcile it with your ecosystem like we’ve mentioned  
 before whether it’s to push into one network source of truth your netbox or  
 equivalent and then from there that tool would now start populating different  
 system which could be now your CMDB your inventory your monitoring tools. So where everything now that you have your  
 correct representation of what you have in your network can be fully updated.  
 Okay. So before I start I’m going to move to a live the presentation of IP  
 fabric but also show some example of MCP. But before I do that, I just wanted to if if there are any question I want,  
 you know, please feel free to to ask because the goal of that live demo is something that I want to make sure like  
 you see something that you find useful. So feel free to ask any questions. Thanks.  
 And yeah, perfect. [clears throat]  
 Okay. So, so for this, so what I’m going to do, uh, sorry, I’ve just realized  
 this. Okay. Should be slightly more visible.  
 Okay. Can we see? Okay. At the back, I just want to make sure. Is that is that visible enough or would you prefer  
 bigger? No. Okay. Thank you. [snorts] Um, okay. So, now I’m in the UI of IP  
 Fabric and what we’re going to see here is different snapshot. The snapshot being what is produced after that  
 discovery. So discovery is IP fabric find what are the devices extract the  
 information and bring it into the UI or into the tool which we can then query.  
 So we’ve shown earlier this inventory table. Right now I’ve got my inventory.  
 I know what are my devices that I have. uh and if I filter for something like  
 this now I can see that I’ve got a mix of different platform from that same vendor and all that information is now  
 available I can query it as well via API so from a if I want to use that  
 information to push into different tool or different ecosystem I’ve got that  
 programmatic access to it so just to show the example I’m just going to take  
 the the net box but the information that we see for example in here in Netbox has  
 been pushed via plug-in that we’ve done with them to say take the information  
 from IP fabric put it in a new branch in Netbox show me the div and now what do  
 you want to do with that new branch do we merge it or not but now you’ve got that way of having that feedback loop of  
 I’ve got my source of truth networks is the data on the network still the  
 same or is there already some sort of drift that has happened where maybe if I look at one  
 device somewhere in here for example I don’t know it’s uh yeah is the IP  
 address that’s configured on that specific interface still this is what netbox is saying so what has been put  
 but what if someone has manually changed that information on my device now this is where you’ve got a drift you’ve got a  
 conflict of information where my source of truth netbox tells one thing but my  
 network tells something else now who’s right I don’t know. It depends. Was it  
 that IP change for a reason, a project, or was it an accident? Someone changed  
 something in net box that maybe should not have been updated that I don’t know. And this is where you might still need a  
 human to check the drift or if depending on what are the use cases and how you  
 plan on using it, maybe it’s actually the automation should take care of that  
 uh correction in that situation.  
 Okay. So that’s from the simple um CMDB I guess uh um updates. The the other  
 thing I wanted to to show now just to uh to have a better understanding. It was based on the the diagram. So we’ve we’ve  
 seen this topology which is a representation  
 of connection that we have between the devices. So now if I zoom to that same site that we had before now understand  
 my relationship I want to see what was connected to those devices at a specific moment in time I can go back to my  
 previous snapshot or the one from last week to see relationship that maybe were not present before. So if I zoom in into  
 those devices in this specific snapshot, I know if I go back to a previous  
 snapshot, I’m having links that were not present back then. So now if I wanted, I  
 could compare those two snapshot to say show me the difference again from a relationship perspective. And now that  
 would show me that between those two moments in time, new links have been added between those devices.  
 That’s from a relationship perspective. Now maybe I want to go further than that. It’s it’s great that I can see the  
 relationship between devices. But now I want to understand further how my  
 network behaves. So if I’ve got a user somewhere connected into one of my sites and maybe  
 the issue that I’m going to get is I’m going to receive a ticket from someone saying I cannot access a specific  
 application. So I’m going to use this one where I’ve got a source IP destination and someone is going to tell  
 me I’ve got an issue. I cannot access my destination. So now what IP Fabric will do in that  
 situation what we’ve collected from the devices is not just the configuration  
 but the state of those devices. So by that I mean it’s like we showed earlier the OPF relationship. You don’t get that  
 relationship just from the configuration. you need to look at the state of my SPF in that situation. But  
 we’re also collecting rooting table, art table, MAC address table which help us understand the forwarding that those  
 devices were doing at the time of that discovery. So in this example, we see that there is  
 a firewall that’s dropping this flow. But then what I can also see it’s what’s  
 happening further down the line and why that could be useful. So this one is a lot more from an operational  
 perspective. It would avoid potentially having the I receive a ticket, I open one firewall, I close the ticket, and  
 the next day you’ve got the user complaining that it’s still not working. Oh, we didn’t know that there was  
 another firewall further down the path. So now that we have this information, what we can do is perform the change. If  
 we want to change this, create the new snapshot and now we can have that  
 confirmation of how does it look like afterwards.  
 And that’s because I’m using the wrong one. So, so I was using the wrong port. I was on 3389 for different use cases.  
 So, okay. So, just to show again. So, now I’m on port 443.  
 That was the use case. So, before we actually had both firewall blocking the port 443 and after the change now we can  
 see that both firewall are green. So in that case the security has applied the  
 the policy correctly on both firewall. So now I’ve got confirmation that the pass is working.  
 Okay. And now the the last thing I wanted to show is going to compare  
 further that path lookup and show how an AI so an MCP server in our situation  
 with the help of LLM can use that data to provide I would say human readable  
 and not just as a diagram information that that would help with the understanding of what has changed on the  
 network. So this is the use cases where I need to go back to my  
 firewall in here. So now it’s a slightly different it looks the same. It’s a slightly different use case where now my  
 firewall in red is there for a compliance perspective where I do not want those users to be able to access  
 that destination on that specific port on RDP in that situation. So now what I’m seeing is my firewall is currently  
 blocking that flow and I’m happy because that’s what I wanted. But now what what happens on the next  
 snapshot? It looks pretty much similar but the firewall is no longer there. So in this  
 situation what happened is rooting has been done differently. So now the firewall is  
 being bypassed and we go directly to the next device. In reality, it could be something a lot more complex than this  
 where you perform a change and then there is something somewhere where now you’re going through you’re going to  
 route that network through a slightly different path and maybe instead of going through one firewall over there  
 the traffic is now going to use a different one which may not have the same rules in your firewall or like in  
 this case maybe you don’t even go through a firewall. So if you’re a compliance uh for looking at it from a compliance  
 perspective, you look at the firewall and it looks good because you’re blocking what you should be blocking,  
 but if your traffic doesn’t hit that firewall, that’s not going to achieve the the goal that you are trying to do  
 with this. So now in the in the example that we’ve done using the our MCP server  
 was we’ve asked to say show me the difference uh between those two snapshot  
 for this specific path. And what so in this one it was done by  
 close using the MCP server that we have with IP fabric where with that question  
 it generated an HTML report where I’m taking the source to destination pass  
 lookup from the previous snapshot and this is what we are seeing on the left  
 hand side and that looks like this is what we had on the on the graph earlier but we can  
 already see that it added that extra command to say now that device has been  
 removed when we look at the next snapshot. And now if we look at the the the next snapshot, we see that similar  
 format and now we’ve been highlighted in red that that firewall has been removed.  
 And now you’ve got clude who decided to make a a red warning about this to say  
 it looks like there’s been a firewall bypass with some explanation as well on from a rooting perspective that now we  
 are no longer going through the firewall but pointing directly to the device after. So now this is some sort of the  
 use case that you can start achieving because you’ve got information that you  
 can feed to an LLM via via the MCP server where without that correct  
 information it would be very difficult to use such uh such agent  
 because it won’t know how to get that information and that’s going to be I guess even more true when there when  
 you’re not using some sort controller for your network and that information is going to be spread throughout an  
 environment. Um, and probably the last thing before I  
 guess further question I want to show is something or maybe the second one was  
 similar past lookup but this one was an interesting topic that we had as well with few few people last yesterday about  
 the MTU as well. How can we put on top of that representation MTU information?  
 Because I want to ensure that my MTU is going to be consistent not just on the link to see that are both of my  
 interfaces configured the same way but now looking at it from a full path perspective.  
 And the last one is another classic use case that goes back to the CMDB  
 accuracy, your inventory. But this one was more from an end of life perspective where we already have that information  
 in IP fabric. It was just using the MCP and build uh a different visual for that  
 representation where now we’re looking for a specific snapshot where we would see which devices are now end of life or  
 end of maintenance. Uh I just wanted to bring it here to give the perspective  
 from that angle. And now this is the what the MCP took and the LLM decided to  
 create again a different reporting for that. But that information we would have so from the moment you do the discovery  
 to see that now we know what’s no longer up to date and as we mentioned with the  
 the customer I was mentioning earlier for them being able to see that information was a great help to say but  
 now we know that we can ask our management for further budget just because we’ve know we’ve got this  
 potential problem and we just need someone to say what do we do? Do we accept the risk that we’re running  
 devices that are no longer under support or if we don’t then we need to ensure  
 that we’re going to have the right budget so that we can work on the replacement for those.  
 Okay. Thank you very much. Are there any questions? Any comments?  
 Nope. Okay. Otherwise, if you’ve got any further question, you can always come and see us. If it’s to do more deep dive  
 from a an MCP server to see the what are the things that we can achieve with  
 those is obviously from our perspective the holidays. We haven’t released it publicly yet, but we’re doing some beta  
 testing or if it’s more from the use cases that where we can help as well,  
 feel free to come and see us in a in a world of solution. Thank you very much.

*Watch the full 40-minute Cisco Live session on how to “*[Fix the Source of Truth Problem](https://youtu.be/uyBXiku5YoU)
*.”*

## What Happens If You Can’t Trust Your Network Discovery?

Recently a customer came to me, knowing that they had a problem with their [CMDB accuracy](https://ipfabric.io/blog/ip-fabric-extension-improves-servicenow-automation-cmdb-accuracy/)
. However, they didn’t know the full extent of it.

After running their first network discovery with IP Fabric, they found that roughly 10% of their CMDB was outdated or incorrect. In an enterprise environment like theirs, that 10% could be hundreds or even thousands of devices. The impact of that inaccuracy was adding up, costing them:

- **Time**: slower troubleshooting and longer change windows.
- **Risk:** unknown dependencies linked to outages and rollbacks.
- **Money:**phantom inventory, incorrect contracts, and wasted renewals.

Each of these operational costs ladder up to larger business impacts like:

- **Longer service outages**, which can cause millions in revenue loss.
- **Compliance penalties** for violating security or regulatory frameworks.
- **Reputational damage**, if there’s a delay in delivering critical services.

Your network is the backbone of your business, and you don’t want that backbone to be built on guesswork.

*Learn more about the “*[Hidden Bill](https://ipfabric.io/blog/is-bad-cmdb-data-driving-up-network-costs/)
*” of bad network data.*

## What Does “Good” Network Discovery Look Like?

[Network visibility](https://ipfabric.io/blog/business-impact-of-network-visibility/)
 depends on discovery, and discovery depends on tooling. A good network discovery tool should be able to tell you:

- That all your devices are being monitored.
- That all your security and regulatory controls are documented and working as intended.
- How a change will affect your network behavior (before you actually make it).
- Where to start troubleshooting when an outage occurs.

In order to give you this data, your tool needs to be able to discover your network continuously. After all, networks are always changing. Maybe a new device gets added here, or a configuration is changed there. With each change, your documentation is drifting further from your actual network.

At the risk of sounding like every other IT expert out there, there’s only one way to keep up: automation.

## How Do You Automate Network Discovery?

What you see below may look like a network diagram, but it’s not.

This is a snapshot of an actual network that was discovered using IP Fabric.

When taking a snapshot, IP Fabric automatically:

- Discovers every device, connection, and configuration in your network.
- Maps the relationships and dependencies between devices.
- Normalizes that information, and uses it to build an interactive digital twin model of your network.
- Verifies all network data with a series of built-in and custom checks.
- Pushes the verified network data to any and all tools in your network ecosystem.

Unlike your traditional Visio diagram, which will go out of date the moment you click “save,” an IP Fabric snapshot is updated several times per day. Since it’s automated, you also don’t have to worry about human foibles like mistyped device numbers or duplicate entries.

## How Do We Solve the “Source of Truth” Problem?

At IP Fabric, we believe that the only way to get accurate network data is by looking at the network itself. Our platform makes it easy to gather that data, so you can feed it into your chosen source of truth. For example, our customers use IP Fabric data to fuel tools like:

- [NetBox](https://ipfabric.io/wp-content/uploads/2024/07/SB_NetboxCloud_2024.pdf)
- [Nautobot](http://v) (Network to Code)
- [Ansible](https://www.youtube.com/watch?v=QvIj7dMdyGE&t=1s)
- [ServiceNow](https://ipfabric.io/blog/ip-fabric-extension-improves-servicenow-automation-cmdb-accuracy/#how-does-ip-fabric-help-with-cmdb-accuracy)
- [Itential](https://ipfabric.io/wp-content/uploads/2024/07/SB_Itential_2024.pdf)
- [Splunk](https://ipfabric.io/blog/how-to-integrate-ip-fabric-with-splunk/)

Let’s see a step-by-step of how IP Fabric pushes network data to one of these tools in particular: NetBox.

### Step 1: Run a Snapshot

IP Fabric kicks off the discovery process by using [CLI commands](https://docs.ipfabric.io/main/overview/How_Discovery_Works/CLI_discovery/)
 and [API calls](https://docs.ipfabric.io/main/overview/How_Discovery_Works/API_discovery/)
 to communicate with vendors, pinpointing all their devices and known neighbors until 100% of them are found. From there, the platform also maps out each device’s connections and configurations, automatically checking them against your business intent. You can choose to create your own custom checks or deploy IP Fabric’s series of 160+ built-in checks, which are based on standards for leading [security and regulatory frameworks](https://ipfabric.io/network-assurance-security-compliance-controls/)
.

The results of your snapshot and intent checks are then presented in a normalized, user-friendly GUI, like so:

*Learn more about IP Fabric’s*[intent checks](https://youtu.be/ZN3izpnkpUk?si=TvzIY1GkjB1__DVU&t=330)
*.*

### Step 2: Push the Snapshot Data via API

IP Fabric and NetBox have collaborated on a plugin that automatically pushes IP Fabric’s network data to NetBox. That data can easily be queried either via API or NetBox’s GUI.

*Learn more about IP Fabric’s integration with*[NetBox Cloud](https://ipfabric.io/wp-content/uploads/2024/07/SB_NetboxCloud_2024.pdf)
*.*

### Step 3: Scan For Inconsistencies

The plugin automatically creates a new branch in NetBox, and highlights any differences between this newest IP Fabric snapshot and your NetBox source of truth.

Maybe you see an IP address that’s configured a certain way in NetBox, but it’s been manually changed on a device. This creates a conflict of information, where your source of truth tells you one thing, but your network is telling you another.

Maybe that IP address was changed for a reason, or maybe it was an accident. In this case, a human or AI agent can step in to correct the situation—and with the depth of insights from IP Fabric, they’ll know exactly where to start their investigation.

*Learn how to de-risk*[change management](https://youtu.be/vo5QXNBY564?si=noqHqdmrsdHatQIr)
*.*

### Step 4: Remediate Configuration Drift

Now you know exactly what’s drifted. But before you remediate the issue, you can run and end-to-end path lookup in IP Fabric to simulate the effect the change will have on your network. You can also run another snapshot after implementing the change, to ensure it had the intended effect. From there, IP Fabric will automatically sync with your NetBox source of truth.

*Learn more about*[end-to-end path lookups](https://youtu.be/ZN3izpnkpUk?si=Yxgufx1oiPxIPMdL&t=209)
*.*

## Finally, A Reliable Network Source of Truth

As enterprise networks continue to scale, it may be time to reconsider how we think of a “network source of truth.” It shouldn’t be a document or a spreadsheet you maintain, but rather a continuous feedback loop based on your network’s actual behavior.

So, back to our original question: have you ever seen a source of truth you can actually trust? Now with IP Fabric, the answer can finally be “Yes.”

*Try IP Fabric yourself with our [self-guided demo](https://link.ipfabric.io/4aYVcWh)
, or dive right in with a [free trial](https://link.ipfabric.io/3NBNXL1)
 today.*

## FAQS

### How Does Network Discovery Impact Operations?

Without an accurate source of truth, routine tasks become heavier lifts than they should be. Take change management, for example: if your documentation is outdated, you’re pushing changes based on incomplete information and opening yourself up to surprises down the line. The same problem shows up during compliance audits; if you can’t trust your documentation, you can’t trust what you’re handing to an auditor.

When your network data is trustworthy, both of those situations look very different. You can push a change and know that it won’t cause an outage or performance issue. You can give an auditor a timestamped report that shows all your security and regulatory policies are operating as intended. These may seem like small wins in the short term, but over time they ladder up to millions in savings.

### How Does Network Discovery Impact Incident Response?

If an incident occurs, your first two questions are normally:

1. What caused the incident?
2. What’s been affected?

On one hand, if you don’t have a reliable view of your network, it can take days to re-document it before you can even begin your investigation. That delay can be costly; depending on your industry, every hour of downtime can range from roughly [$39,000 to $2 million](https://ipfabric.io/blog/network-downtime-impact-on-manufacturing/#1-network-outages-why-every-minute-counts-for-mttr-1)
 in lost revenue.

On the other hand, if you have trustworthy network data, you can avoid this delay entirely. This not only means faster triage and remediation, but also a cleaner audit trail for any regulatory reporting that follows.

### How Does Network Discovery Impact AI & Automation?

There are so many tools out there for AI and automation. But no matter how good the tool is, it’s not reliable unless it’s equipped with accurate network data.

For AI to perform, it needs data that’s:

- Clean
- Structured
- Contextualized
- Accessible

With this foundation in place, AI agents can be trusted to make changes faster, with fewer errors and less need for human oversight. This reduces the risk of rollbacks, and gives the network team more time to spend on work that benefits more from [human input](https://ipfabric.io/blog/overcome-ai-slop-in-enterprise-network-operations/#improve-network-data-quality-with-technology-like-digital-twins-1-1)
.

Transcript What does AI need in order to be useful?  
 It needs its data to be clean,  
 structured, contextual, and accessible.  
 We need it to be free from duplication  
 or unnecessary noise. We need it to be  
 structured or uniform across our  
 different network devices as well as  
 operating systems. It needs to be  
 contextual and accessible. Without that  
 data, it’s impossible to have a  
 consistent approach to our automation  
 strategy.

### How Is IP Fabric Different Than a Monitoring Tool or CMDB?

As a network digital twin platform, IP Fabric sits upstream of your monitoring tools and CMDBs. It discovers and maps your actual network behavior at that current moment in time, and pushes that verified data into the tools your teams are already using. As a result, every team and tool in your ecosystem will be informed by the most accurate and up-to-date picture of your network, helping them to make more well-informed decisions for your business.

## Related Resources

Discovery

### [3 Ways to Improve Network Visibility in Hybrid Multi Cloud Environments](https://ipfabric.io/blog/ip-fabric-hybrid-multi-cloud-network-visibility/)

As your cloud footprint grows, it can be difficult to scale network visibility. Digital twin platforms like IP Fabric can unify insights across hybrid multi cloud environments, serving as a single source of truth.

Discovery

### [5 Ways to Improve Your Observability Tool with a Network Digital Twin](https://ipfabric.io/blog/observability-tool-with-infrastructure-assurance/)

Observability tools are great for troubleshooting at the app level. Pair them with IP Fabric's network digital twin solution for end-to-end network visibility and unparalleled control.

Discovery

### [What’s The Greenfield Fallacy And How Can IT Leaders Avoid It?](https://ipfabric.io/blog/whats-the-greenfield-fallacy-and-how-can-it-leaders-avoid-it/)

Greenfield environments quickly evolve into complex systems that are hard to control. Without proactive oversight, this leads to visibility gaps, operational inefficiencies, and security risks.