Can you really trust your network data? If you’re reading this, odds are you’re thinking “no.” And if that’s the case, you’re not alone.
At the enterprise scale, you’re juggling dozens of vendors on top of siloed, unstructured, and hard-to-query data. You’ve amassed a hodgepodge of tools with different GUIs, operating systems, and APIs. There’s simply no way for traditional monitoring tools to catch it all, leaving you with an incomplete and outdated picture of your network.
These visibility gaps make it difficult for human engineers to operate efficiently—and it’s no different for automation tools. As the saying goes, “You can’t automate what you can’t see.” But there’s a little more to it than that.
Transcript
Silos are a big issue, right? When when
you have siloed data and you don’t have
the the overall picture, you you cannot
achieve anything because you will have
blind spots, you will have gap in in the
in the logic in correlations that AIOS
needs to do. So literally you have to
have uh some level of standardization,
some level of uh visibility and and the
better you standardize the better
visibility that you have uh from on-prem
infrastructure up to the cloud, the
better you can do with with implementing
AIOPS.
Learn how Red Hat got started with AIOps using IP Fabric.
What Data Do You Need to Get Started with AIOps?
AI doesn’t magically fix bad data. Before you embark on an AI or automation project, you need to take a moment to ask yourself:
- Is my data clean and free of errors?
- Is my data structured and normalized?
- Is my data contextualized with a complete view of network behavior?
- Is my data accessible to the people and AI agents that need it?
However, if you don’t have a complete or updated view of your network, you may not be able to answer these questions at all.
This is where network digital twin technology comes into play.
Transcript
Hello everyone. My name is Zach Brown
and I’m a solutions architect here at IP
Fabric and I’m here to talk to you today
about IP Fabric’s digital twin
capabilities.
In today’s hybrid multi- vendor network
environments, even the smallest change
can trigger massive outages, compliance
violations, or worse, downtime.
That’s why leading enterprises trust IP
fabric, the automated network assurance
platform
to build a digital twin of their entire
network, providing deep visibility, safe
planning, continuous validation, all at
scale.
In this video, we’ll show you how our
digital twin simulation capabilities
solve five critical challenges faced by
modern enterprises and operations teams
and how you can move from a reactive to
a proactive approach with confidence.
So, first we’re going to talk about our
first area which is multi- vendor
integration. So here IP fabric IP fabric
discovers and builds topologies for
heterogeneous network environments all
map to our interface making switching
between tools and different uh user
interfaces unnecessary
and it all starts with IP fabric’s
discovery process. So here on the screen
I have pulled up a snippet of our
discovery process and here is a quick
glimpse of that discovery process. So we
have a list of devices that IP fabric
discovered and if you take a peek here
all different kinds Juniper, Arista,
AWS, Cisco. So very diverse
heterogeneous environments. Also, we
have the device count as well as how
long IP fabric took to discover in my
case these 93 devices.
So, very robust snapshotting and
discovery process. Now, one of the
residuals of this discovery process is
IP Fabric’s full device inventory.
So with IP Fabric’s digital twin
capabilities, IP Fabric automatically
discovers and normalizes inventory data
so that it’s easily digestible in our
tables. So you can simulate your entire
network regardless of vendor and have
the intelligence of exactly what is in
your infrastructure.
So as I scroll over here, you can see I
have my full device inventory as well as
which platform operating systems and
versions I’m using. So very robust and
IP fabric is once again meant to
integrate into multi- vendor
environments.
Next we’re going to talk about network
state modeling, network migration
planning, and change impact analysis.
So, IP Fabric takes snapshots of your
live network, allowing you to model,
visualize, and analyze the state of your
infrastructure at any point in time.
Need to validate your routing behavior
from last month or simulate a new
routing protocol? Done. This is your
live network frozen in time available on
demand. So once that discovery snapshot
has has completed which we talked about
earlier, we have the network devices
discovered and full device inventory
compiled. IP fabric then visualizes this
with our dynamic diagrams. With these
diagrams you can run end toend path
simulation to get a device by device
analysis of the packet logic and exactly
how it’s moving from source to
destination. So here as I’m pulling up
my path simulation feature, you may
notice I have a host in one of my sites
and I am simulating the traffic flow to
remote site here in Prague. So as I
click through my platform and I click my
first device, I have my full packet of
logic as well as my decision making
table showing how I’m moving from source
to destination. Now, if you take a look
at this path, I have my first layers
three switch here. And now you can see
IP fabric is now taking a look at the
routing and ARP tables since we’re
moving on up that network stack. Also,
as I click on my firewall, you notice
it’s illuminated in red, showing me that
something is blocking my traffic. So I
have my access control policy here and
if I click I can see the exact access
control entry that’s blocking that
traffic as well as further down the path
I have a firewall here in green. If I
right click and click explore I’m able
to see that that access control policy
is allowing my traffic. Also to further
analyze our network model, IP fabric
allows you to compare changes in the
network, spotting when anything changes
instantly. So as I go and switch to my
next snapshot here, I’m able to see
exactly how my infrastructure has
changed between two snapshots. So what’s
red is what was previously in the
infrastructure and green is how my
infrastructure has changed over time. So
IP fabric really helps you visualizes
those changes really cutting down on
that meantime to remediation if you have
any problems with your network. So with
IP fabric engineers can compare those
snapshots before and after events or
changes to the network to be able to
spot changes instantly.
So, planning a migration, moving to
SDWAN or the cloud? IP Fabric’s digital
twin simulation simulates those traffic
paths, validate segments, and ensures
nothing breaks before ever touching one
single cable. So, you’re able to test
your migration logic safely, accurately,
and have a consistent approach to
managing your network. With IP fabric,
you can do comprehensive dependency
analysis to accelerate that migration
process and reduce project timeline and
risk even in hybrid networks.
So in our path simulation feature, we
even have the opportunity to get more
granular with what we test, even
controlling what ports as well as what
IP addresses we can test. really giving
us the peace of mind that when we make
changes to a access control list that
nothing breaks when we go to production.
A healthc care provider that IP fabrics
work with firewalls team needed to
expand the subnet and open ports for a
new application. using IP fabric. They
simulated the change and were and
discovered that it exposed internal
services to the internet which would
have been a huge hippo violation and
opened them up to additional fines.
Now as I move into our next point uh
configuration compliance and validation
here is our overview dashboard with a
mix of IP fabric custom wizage and
outofbox intent checks built for
inventory security posture compliance as
well as configuration management. So at
IP Fabric, a telecommunications provider
used IP Fabric to enforce PCI DSS
compliance across hundreds of routers
within minutes. With IP Fabric, they
were able to discover 30 plus devices
with TNET and legacy SNMP and were able
to close the gap all before their eyes.
Here with IP Fabric’s intent checks, we
have the ability to see, do I in my
environment have any devices with TA
enabled? So, we’re able to close those
gaps and further fortify our network
with IP Fabric’s digital twin
capabilities. So IP fabric doesn’t just
simulate behavior. It also continually
audits every device config against best
practices, regulatory compliance
policies, and your own intent.
You’ll know when compliance is broken
automatically with IP Fabric. Also from
the IP Fabric interface at your
fingertips, you have all your network
devices running configurations. So you
can compare these over time. As soon as
changes happen, outages occur or traffic
is flowing from a different path, you
can see what changed from a
configuration standpoint in addition to
those architectural changes as we
discussed earlier. So as a demonstration
of that, I am just clicking two host
names in my environment and comparing
the configurations from two different
points in times. So in green you can see
what has changed. In red you can see
what’s removed between those two
configurations. So easily you’re able to
validate your configurations and get
ahead of any potential configuration
drift.
So with IP Fabric’s digital twin
simulation, your team can stop
firefighting and start proactively
managing network health risk and
performance. Whether you’re planning
migrations, validating changes, or
ensuring compliance, you’ll always know
before it breaks. And for enterprise
leaders, it means faster project
delivery, fewer hour, fewer outages,
stronger compliance, and complete
network transparently without the
guesswork.
You’re ready to see it in your
environment? Book a demo or start a free
trial at ipfabric.io.
Thank you for your time.
Learn how to build a network digital twin with IP Fabric.
IP Fabric is the leading network digital twin platform that ensures you always have a complete and up-to-date view of your network behavior. Here’s how it works:
- Discovery: IP Fabric maps every device, connection, and dependency in your network from end to end.
- Validation: During the discovery process, the platform also runs a series of automated checks to ensure your network behavior is aligned with your business intent.
- Reporting: IP Fabric delivers an interactive, timestamped map of your network, as well as the results of your intent checks. Both the map and results are normalized so they can be easily pushed to tools like Ansible and ServiceNow via the API.
But we’re not here just to talk about IP Fabric—we’re here to show you how you can use the data IP Fabric gives you to get started with AIOps. Let’s dive into it with a sample workflow.
5 Steps to Successful AIOps with IP Fabric, ServiceNow CMDB, and Ansible
Step 1: Discover Your Network
IP Fabric discovers your network the way an engineer would: through the CLI and API. The platform automatically communicates with all vendors (e.g. Cisco, AWS, Azure) to locate 100% of devices from core to cloud to edge, all the while documenting the configurations and dependencies for each one.
This data is what IP Fabric uses to build a network digital twin: a normalized, end-to-end model of your network state at a given point in time. (I say a “point in time” because IP Fabric can run discovery several times per day, so that you always have the most up-to-date view.)
IP Fabric then pushes this data via the API to tools like ServiceNow and Ansible, which we’ll cover in step two.
Transcript
So welcome everyone to today’s ONUG webinar. Our topic today is unlocking AI
ops with Red Hat and IP fabric, the power of dependency mapping. Um I’m your
host um Stephen Collins. I am the ONG CTO and I’ll be your moderator today.
And we have two speakers. We have Martin Machka who’s um manager of IT networks
at Red Hat. and we have VTEC Savo who’s the senior channel development manager
at IP Fabric. Um, we’re going to have an interesting u discussion today about how
um Red Hat’s been working with the IP fabric to uh to do a a much better job
of getting handled what’s going on inside of the network infrastructure and um um responding better to um issues and
anomalies and incidents within the network and um and leveraging this dependency mapping capability to do a
much better job of being proactive and automating ating workflows, etc. It’s a really interesting topic and I think
very timely given the state of where networks are today. Um, before we dive
in though, I want to let everybody know feel free to ask any questions um that may arise during the course of the uh
next half hour or so. You can do that by entering your question via the uh Q&A
tab at any time. We’ll probably cue the questions up uh to towards the end, but
um but feel free to ask them at any time, especially if they’re really relevant. maybe we’ll just stop and answer it right at that at that point.
So, um that’s a little bit of housekeeping here. Um I just wanted to help set the stage here a little bit and
since the you know topic is AI ops um and and how this is you know related to
AI ops and the interesting thing here is AI ops that term was coined by Gartner way back in 2016. So you know in the
industry we’ve got almost a decade decades worth of experience with AI ops solutions. Um, you know, and back when
this kind of first came on the scene, a lot of the AI ops actually boiled down
to kind of machine learning using statistical analysis of time series
data. Usually, um, processes that were focused on a
given domain or a given layer within the network. um some fairly powerful tools
were developed but again kind of really zeroing in on on a given domain or a given layer. Um then the you know neural
networks u became kind of commercially viable. So we started doing more um actual machine learning on data and that
actually allowed not just um to look backward and do kind of historical views
of what was going on but you could actually use those types of capabilities to do predictions about what was going
on. So there’s been a lot of really interesting technology that’s been developed and of course the amount of
data that can now be consumed and analyzed and processed is now kind of mind-blowing. So you know tools have
gotten nothing but more powerful kind of at that kind of atomic level. Um but but
what’s interesting is as AI ops has progressed in its capabilities the environments that were operating in have
progressed in terms of complexity um and and scale. So, you know, back 10
years ago, a lot of folks were probably just running applications within their own data center. Maybe they were
starting to dabble with the cloud. You know, if you look at where we are today, you’ve still got a lot going on, of
course, inside of, you know, on premise data centers, but there’s also a whole lot that’s going on in the cloud and
actually in multiple clouds and multiple SAS applications. So the whole environment has become much more
distributed uh much more dynamic much more complex and and so it’s been a
challenge I think for AI ops techniques to kind of evolve out of that kind of private data center environment into
this now highly um complex and distributed environment with layers of
virtualization etc. So the interesting thing is, you know, what needs to be
done to kind of harness the power of AI ops in these environments and and really what it boils down to is being able to
understand and track the relationships between different elements, network elements, devices,
elements of the application infrastructure, what the relationships are between all those components and and
also the relationships between them as they change over time. And some of that
can be highly dynamic in these, you know, very virtualized application environments that are now becoming, you
know, commonplace with things like Kubernetes, containerbased applications. So, we’re in a world now where
um AI ops is is going to be not just a nice to have, it’s going to be a got to
have. And I think what we’re going to talk about today with Martin and VTEC here is a a really important concept
called dependency mapping and how that can be used um to keep track of what the
relationships are between um different components or different elements and different layers or different domains
and and then just do a much better job of keeping track of what’s going on, predicting what might be going on and
doing a leveraging the power of automation tools that are now at our disposal.
And that’s before we even start to apply things like, you know, generative AI and large language models to to the problems
that need to be solved. So, um, we’re kind of really, I think, at another inflection point here in the way
networks and application environments are envir are evolving. And so, I think today’s topic is, uh, particularly
relevant to all of that. So, with that little bit of a long- winded introduction, I’m going to hand this
over to Martin and VTEC and and let them run with it.
Thank you Steve. Uh let me move us on on on the topic. So uh thank you for the
introduction there and I think what we are dealing at this moment um with is is
really the paradox. So the promise is huge having proactive self-healing um it
that saves money and and time uh but eventually um
we have vast amount of data that is overwhelming and it it as you mentioned
Steve it’s very hard to navigate through the complex infrastructure of uh
virtualization containers uh all the systems being very distributed in
multiple data centers on premise or even in the cloud. Well, so uh basically the
core problem at this moment is that teams lack the real visibility into the infrastructure. They they they uh fail
to understand how things are being connected, what is dependent on what and
what happens when something breaks or what happens when I do a change somewhere? Uh what what am I what am I
breaking potentially? So um that that’s the biggest question that we have currently. Um and what AIO ops actually
is um well AI ops is not a a magic AI that you just go and plug it into your
infrastructure and it will suddenly understand everything be able to uh make all the decisions be able to provide you
with the full visibility uh end to end but you uh eventually need to provide
that context and provide that so so you can augment your expertise with with the
tooling with with uh with data for data driven decisions um and really moving
from proactive to uh sorry from reactive to proactive uh and eventually automated
remediation for that as I said you need the context so you need a single source of truth that is showing um in a machine
readable format of how things are actually connected how things are dependent on each other and you have to
go with from very bottom layer of of infrastructure up to the application
stack and and individual application uh resources because one application is not
just one VM running somewhere but it’s multiple resources that are connecting to each other and uh discussing or
talking data. So you need to have that context somewhere
and that is where the dependency map is uh is
coming in. Right? So you can eventually you cannot eventually automate what you
don’t understand and dependency mapping is there to help you understand that uh dependency mapping is there to be able
to connect everything uh instantly understand and see the blast radius if
there is an outage. So you can have a um fast or automated root cause analysis
nowadays with uh a AI agents and everything with this context that you
provide to AI agent. It can pretty much automate uh the root cause analyszis
with all that context. You can have smarter automation where uh you are
really hitting the right playbook for the right target and and and you get the automated remediation in no time and um
well as I mentioned you understand what what you are eventually breaking when when you do a change. So whenever you do
a change planning you know uh your upstream downstream relationships. So you you know who to notify who to talk
to. you have some stakeholders that that are dependent on your piece of infrastructure. So when when you do that
change, you can clearly articulate what the impact is uh and and have that uh
scheduled. So so nobody nobody um is affected or you limit that impact of of
the change. How we actually started with building the the dependency map. Now that I talk
about so much of the dependency map, we have a lot of tooling but we decided to start with uh couple of tools uh we have
some data in service now where we have the cmdb where we store all the data about um
business applications and and what actually forms these applications like VMs uh open shift kubernetes resources
and um storage and all that stuff. So we have that information there but that
it’s not showing how it’s connected uh down to the to the networking layer. We have network automation. We basically
automate the the whole network infrastructure and we know how network infrastructure is connected.
Uh we have open shift where we run basically nowadays all the virtualization and containers uh and and
that can provide by API quite a lot of context but again it’s not showing the
full context. So we chose netbox uh as an open source tool to actually be the
uh aggregator of the information. uh we put there all we wanted to put
there all the data from network from uh those sources like service now open shift network automation and kind of
connect it all together but for that uh to to be achieved that we needed the glue and um that’s why we are um
partnering on this on this webinar with IP fabric because we we used IP fabric as the glue for for the data to connect
the dots between uh the application resources uh the
virtualization workers uh and the infrastructure u the network
infrastructure basically uh IP fabric as automated network assurance uh
uh platform allowed us to pull data via API for all the mechads tables to be
able to use that data as the glue between what we had uh on one side and the other side. So application CMDB and
the network uh infrastructure and open shift um they resulted in pretty much simple
script that you can use go to the API of IP fabric and can get all the data
basically get the exact edge of where it’s connected what and connect it all
the all into one picture. Martin, listening to you, it’s very
interesting to me because I’ve been speaking with large Fortune 500 companies for for the past few years and
it seems, you know, that this issue with operating in silos and having data in
multiple different places. They’ve always had it. They always knew it’s a problem and they always were figuring
out workarounds or it wasn’t being tackled proactively. So I hope that now
as this AI op starts picking up, people will finally have a reason to uh move away from this and really figure out a
way to standardize everything. Yeah, definitely. And I agree with you. I mean silos are a big issue, right?
When when you have siloed data and you don’t have the the overall picture, you you cannot achieve anything because you
will have blind spots. You will have gap in in the in the logic in correlations that AIO ops needs to do. So literally
you have to have uh some level of standardization some level of uh visibility and and the better you
standardize the better visibility that you have u from on-prem infrastructure
up to the cloud the better you can do with with implementing AI ops.
Um on the next slide basically uh what what is next right when you have the dependency map what is actually the next
step so I’m I mentioned multiple times uh uh something um like automated
remediation uh for that you have to go you you can
go with uh well from the mapping into the action for us uh the chosen platform
was anible uh where basically you have an event, you have correlation of events
to incident and then then you can have uh or make datadriven smart decisions
and just go and and trigger event- driven automation to remediate um which with that you are basically uh
reducing the toil as as as uh much as you can and and you can keep adding to
that. uh and also you have basically contact context level automation that
that that can resolve things for you. So you are basically moving or this is the
first step where you are moving from reactive to to automated or to proactive eventually. So that’s the next step
there. Um I would just maybe uh summarize it from my side with key t
takeaways here. Uh what you need to do you have to reframe your goal. uh you
have to aim for um intelligent automation rather than some
mythical all knowing AI that is a black box that you plug in and and all your uh
things are being sold instantly going to the AIOS is he have a lift
that’s for sure but it is achievable you have to start with the foundation you have to uh you have to uh rather than
building complex auto complex a platform uh you have to start with the dependency
map. You have to understand what you are actually going to connect what what what context you need to provide. Uh then for
the data that you already have, find your glue. Uh as I mentioned for us it was IP fabric but find find a glue that
that can do it for you. Then when you have that glue, you have the dependency map, start stop start building on top of
that. So when you have the foundation, start building on top of that. Start with automating with context and then go
uh to the proactive. Having the automation with context, having some automated remediation will remove the
toil for you. And with that um with that you actually can uh invest
more time in in going proactive, going smart and going with with new tools. Nowadays with with the boom of uh LLMs
and AI agents, it’s even uh easier than before.
And Martin with implementing this uh in your infrastructure and your teams
starting use to use it would you say that of course you save time you make
things more efficient but is this unlocking some new interesting processes
or things that you weren’t doing before in general? Uh certainly it it uh identifies some uh
uh data quality gaps where we need to address those with standardization as as
we mentioned. Uh what it what it opens on on the processes side. Um
being proactive breaking down the silos as well. uh but being proactive really identify maybe uh uh circle the
dependencies where where where you have uh basically chicken egg problem and and
you are creating infrastructure that is impossible to to recover from a failure
uh that that all can be done with uh with well code and and some some further
analysis. So those are the new things that that it unlocks for you or for us. Uh and u well I think that that’s the
major thing. Um there is many more but you know it’s small things here and there that that it unlocks and and it’s
actually uh eye opening when you when you see something like this in action that you see uh context that you you
didn’t you couldn’t see before. Thank you.
Thank you. Thank you for that question. Um, and let me open up this slide. So, we take it’s
it’s your time. I guess it’s my time. So, uh, I think, uh, what you said as the last
thought is a nice intro to what we’re doing because it’s really about being proactive and Martin, we’ve been working
together with you and with Redhead for the last three years where IP Fabric was always used as a baseline for
automation. The reason I’m saying this is that uh most of the people that
listen right now are probably just thinking about AI ops or maybe just doing the initial research. But IP
Fabric is very relevant. If you’re not there yet, maybe if you’re just thinking to automate or if you’re thinking about
observability because all of these new trends, what they have in common is that
you really need a solid standardized data set to make them work. And you have
multiple options how to approach this. You have options to uh start writing your scripts on your own or just
collecting very specific data or to get a tool that will do it for you and
really accelerate your development because you don’t need to think about uh this part and you can immediately get to
a point where you are you have the data and you can start working with them.
So what this look like if I
let me this is screen two. Perfect. So what this means is that you get one
tool which gets information from all of
your islands from of your all of your silos. I have my AWS here. I have my Azure, my F5 load balancers, my VMware
NSXT, my firewalls, and all of this is ready for you out of the box to uh start
working with it. what we what Martin was talking about with you know the information about the hosts about the
ARP tables uh this is not just a list of devices but there is hundreds and
hundreds of pre-colcted tables uh that are very relevant to give context to any
of the advanced initiatives that uh you may have uh Martin was talking about ARP
table which I have here uh but for the ones that are not so advanced Usually
the first step in automation or probably the first step in leveraging AI would be
tell me what problems I have. So for to understand this first you need the data
and then you need to put the logic in. And sometimes you can even just use IP
fabric where if I just put one example uh we’re just working with a customer
where after they run the first discovery and we went to this table they noticed
why do I have V1 here? We just failed an audit. Everything should be V3. So if you get a use case like this, you can
just use IP fabric directly to make your intent check. Tell IP fabric my intent
is if version is
V1, make it red or in this case make it green if it’s V3 because this is what I want. And make everything else red. So I
can just easily use a tool like this to
quickly proactively validate my network. And this saves me a lot of time because now
I can action all of these insights. I can uh feed them to my AI or automation
logic and I can get the results based on this. So really accelerates all of these
projects. Uh while we’re at this, we can also do topology maps which I don’t want
to spend too much time on today, but if this is relevant, please do reach out to us or we have an online demo available.
But another thing that is very important for the context and for let’s say understanding uh the dependencies in
your infrastructure is that if you have a project where you know you will be adding a new application or you need to
troubleshoot you need to understand how the infrastructure actually communicates and uh how the path looks and based on
all of that data that we collect we can show you I can say okay this is my IPA
this is my second IP I can be much more specific specific
and now from the perspective of getting a context I immediately see this is where the device is connected it’s being
blocked by this firewall and
because IP fabric really is a in-depth data platform we also have the historical views so I can then go back
in time you see that now I’m looking at the network after the change and I can say how did this look before the change
and now I can dig deeper. I can evaluate. I can overlay immediately. See that I
don’t need to open that firewall because someone actually changed the route here. And all of these things are very
relevant for you to complement the standard reactive tooling that throws alerts at you. But it’s very hard to get
to the analytical part. And this analytical part is what will be required by all the upcoming AI initiatives to
actually give you the value. And we take now that you you showed that
you you can have the intent based checks and uh comparing the snapshots
uh I spoke about event- driven automation. So can you fire an event from IP fabric. So it says hey this
failed and you can do an action based on it. No, absolutely you can. Uh we do
support web hooks and uh there’s multiple ways how to approach this. Uh
the way we think about IP fabric is that we want everyone to have this one tool to go to and look at information. But at
the same time, we respect the fact that specialized teams have their own dashboards. It can be graphana, can be
zabix, can be solar wind that they already fine-tuned, have some workflows in there. So everything that I’m showing
can be gathered through API even this end to end I can just get the API documentation right here every check so
for instance we do have customers if I just stay on this screen that use IP fabric to validate segmentation I can
just say if I go to post change here I see it’s being blocked I can say this is correct this should always fail and now
after I save the path the next time IP fabric does a discovery and sees
uh careful someone made a bypass around your firewall just like we’ve seen in this use case you will know about it
thank you this is good thank you
I’m conscious of the time because I could keep talking about IP fabric
for a long long time we barely scratched the surface but I think really The key
takeaway is don’t think think about how you can
collect data. There’s a lot of tools that can already do this for you. They can integrate to your service now to
your netbox or you can just use them uh on their own and this will save you many
months of development.
Okay. Um, we’ve got plenty of time here for questions and um, I would encourage
people that have any questions to uh, enter them now in the Q&A tab. I I have a couple um, that I’d like to ask and we
had one that did come in through the chat, but uh, preferred vehicles to put them in through the Q&A. Um, but uh,
just to start off here, Martin, um, okay, so you talked about what you’ve done to date. You know, what’s next for
Red Hat in terms of uh, IP fabric data? what do you have planned?
So for us um well as VC was showing for us the next is is intentbased checking
and and uh plugging it that plugging that into those uh signals and events. I
mentioned that AIO ops is also about making or grouping um the individual
signals from the infrastructure and applications and everything. So getting those signals in as well is is one of
the next steps for us. Um, for us it’s also uh getting more out of the out of
the API and and filling in more data into into uh the dependency map. So when
the AI uh is is enriching events that are already there, it has more context
of what what is running where not only how things are connected but what device
it is, what version, everything like that. Um yeah, another question is kind of an
obvious one actually. So if you didn’t have IP fabric at your disposal, um you know, where would you where would
that leave you? What would you have to do otherwise um in terms of achieving the levels of automation you’re you’re
trying to get to here? Uh good question. we would have to go uh
look for any other tool like that or develop something our own because uh you
still need this level of insight and uh the well I I will keep it calling the
glue for for the data uh that you have from other sources and uh well it it was
just wiser for us to go with IP fabric than spending huge amount of time on
developing something custom. Yeah. Do you have any idea how long that would take you? You know, how big a
project that would be? Well, depending on the size of the team, but it would it would certainly take
ages. I it’s I mean with the variety of of uh uh platforms that we have and and
you know maintaining everything for each platform when code changes you have to change something um yeah that I don’t
want to Martin I’m still sometimes using what you told me a long time ago when we were
initially talking together and you told me how you’re planning to you know
increase what you’re automating and you were saying that many of your tools have native API but you don’t have this for
your legacy infrastructure and you told that you see IP fabric as an API endpoint for your legacy network and I
really like that. So this is something that stuck with me. Yeah. Um that that’s uh a good quote to
be honest because we don’t have that legacy network anymore. Uh as as you said we we use IP fabric for quite a
long time but we still use the API endpoint. uh it’s it’s just
with with S sur way of working and AI ops nowadays uh it’s it’s just nice when
you can hit an API and get the data that you are looking for.
Okay, we had a question that came in earlier which is um how can IP fabric discover telco provided provider edges
for MLS? Uh I’m going to just talk about how IP
fabric discovers in general. uh we we we had just a little bit of time so this was more of a sneak peek but uh this is
what makes us unique because we don’t use any SNMP we don’t use any IP scanning anything like this but this is
really based on a best practice of what a CCIE engineer would do if you ask him please uh map my network so we are using
SSH for the legacy devices and then we’re using API for the devices that do
support API and we usually only need few starting points where we connect to
device number one. We see there’s CDP here. We see there is a routing relation. We look into the ARP table. We
think this MAC looks like a a Cisco router. Let’s connect there as well. So,
we don’t try to blindly go everywhere. But it’s very efficient and very accurate. I’ll be happy to talk about
this later with you. Yeah. I guess the takeaway is you’re going to do what an expert CCIE person
would do in terms of probing the network. I got you. Yeah. Um, another question came in here. I’m
going to just read it verbatim. Um, is there a common sweet spot you see for enterprise customers taking snapshots of
their network to best help assure intended state? In other words, snapshots every two hours, every four
hours. I have an answer, but Martin, I’m curious. What is your approach?
How many time do you do
snapshots? Let me try to remember from top of my head. I think currently we have
full snapshot every four hours and do on demand snapshots when we need
in between. In general, we can discover let’s say 2,000 switches, routers, firewalls
within 20 minutes. So it it it’s very fast. Uh I would say the best practice
is uh two times maximum three times a day uh to to do a very large snapshot
and this is usually enough you know just to compare the state and so on. Then of course you can do smaller snapshots uh
before a change after change and so on. All of this can be triggered through API
as well. Hi, we just had a question pop in here
via the uh via the chat. Um, so this is
directed at you, Martin. Um, and I’m going to read it verbatim. How many do you have? How many interfaces? How many
vendors? How old is your network infrastructure? How many hosts?
There’s a lot of questions there. Quite specific. I will try to answer uh
without going into into the uh knowledge base that we have
uh or the DCM that we have. Um number of network devices
um I think it goes with couple of thousands. Um
did in well in addition of that access points and other other network devices
as well or appliances you just uh multiply that by default
number of interfaces I I don’t know from top of my head to be honest how many interfaces uh when it comes to the
number of vendors we we intend to be multi vendors so we have multiple vendors two to five depending on what
you count into that um how fault is the infrastructure um as
as old as as we can stay with uh being compliant. So so everything is uh under
support. So um basically the usual life cycle
um and I think that that’s probably what I
can tell um at this moment. Yeah, which by by the way this life cycle piece uh was one of the aspects when
Martin was testing IP fabric uh back be back before you were the manager right
Martin? It was some time ago. Uh so we do have the end of life information out
of the box as well. So I know that this was another thing that you back then was
impressed by saying how much time it saved. Um VTEC I had I had a question for you.
Oh, I’m sorry. Somebody No, go ahead, Steve. Yeah, VTEC, I I just was wondering, could you just elaborate a little bit
more on the specific types of dependency mappings that you maintain, not, you
know, more more based on okay, these types of mappings versus these rather than, you know, enumerating
all of them in those different categories just to give people a better feeling for, you know, what those mappings are. Yeah, I would say that
dependency map is the let’s say one step above uh what IP fabric gives you. It
gives you hundreds and hundreds of uh standardized parsed information. So if
you have a question about how is my AAA configured, if you have a questionnaire, how does my 1x look? Uh uh how is my BGP
configured? What is my global route table? all of that you have one place to go and it doesn’t matter if you have uh
one vendor in infrastructure or if you have five it is all standardized ready to be used and then with the dependency
maps you know we we do know about all the hosts we do know how they’re connected we can show you if the path is
redundant uh so this is right there in IP fabric uh sometimes it makes sense to
use the integrations we have with tools like netbox or service now and really use this as a baseline and still enrich
it with some other sources as well that we can’t get directly through the command line of the devices.
Okay, we got another question in the chat here. Um, interesting question. Martin, what functionality do you see as
a gap in IP fabric? I guess asked another way, you know, what would you like to see IP fabric add to the uh the
product capability? Yeah, thank you Steve. Um, it’s pretty good question and and as you said, I I
wouldn’t call it a gap. maybe um um something that we would like to see going forward and we actually are
planning to submit some of the requests for features with IP fabric. So as I
mentioned we are using MAC address our tables to collect a lot of data but we
are also planning to go even step further with LLDP and and well XDP
protocols. uh and we we like some flexibility there of uh the the custom fields that you can
use within the LLDP to to to have IP fabric to parse those. So definitely one
of the RFPs that we are going to uh submit but you get the the the basic information is there. Um I think it’s
sufficient for most of most of the companies but for us we we just require that cherry on top with being a little
bit more flexible. Um and nowadays what I would like to see
definitely uh support for MCP server uh with with agent ops uh becoming a thing.
We are talking about AIOS but now it’s it’s also a term agent ops. Uh it it’s
definitely going to be helpful with if we can get um MCP server that will be
natively supported by IP fabric that can connect and and provide context for your LMS. Mhm. uh we m Martin maybe from this
perspective this is something we’re thinking about we’re still evaluating the best way to add you know support for
AI into IP fabric because we don’t want to be another v vendor with just uh
improved chatbot calling it AI with the the GUI and IP fabric is very
straightforward it’s easy to get data but uh something like what Martin described is definitely what we’re
considering for the future of the tool All right. I think um I think this is
going to be a wrap. I think we’re heading up about 40 minutes after the hour here. So um um I’d say I’ I’d like
to conclude, but um before we do that, um I believe we’re going to put some information in the in the uh chat for
folks who want to follow up and learn more about Red Hat and about IP Fabric. So I think there’s a a set of links
there that have just popped into the chat. by all means access those. Also, um the folks at um IP Fabric will be
following up with all the attendees. So, if you have any other, you know, specific questions, technical questions,
business related questions, by all means, um feel free to to ask those. Um
so, in conclusion here, I’d like again to thank Red Hat, thank I fabric, uh
specifically thank Martin and VTEC for taking the time with us today, and thank you all for for tuning in. um those of
you who just tuned in live and those who are you’re going to catch this via the replay. And um I think that’s it and I
will call that a wrap. Um look forward to having everyone back here for our
next ONG webinar somewhere down the road. Thank you. Thank you.
Learn how Red Hat got started with AIOps using IP Fabric.
Step 2: Push Network Data to Your ServiceNow CMDB
Many enterprises think of a CMDB as a static inventory—but that’s just not true. Your CMDB is always changing, and those changes can have a profound impact on everything from cost to compliance.
In most of our proof-of-concept sessions, we find that as much as 20-40% of what’s in the CMDB isn’t accurate nor up to date. If you begin to automate with this outdated or incorrect data, your only options are to spend hours validating your Ansible automation playbooks, or to cross your fingers and hope that your network isn’t deviating too far from your intent.
But by aligning your ServiceNow with IP Fabric, you can be sure that your CMDB is always validated.
Step 3: Push Network Data to Your Ansible Dynamic Inventory Plugin
Next we’ll rinse and repeat the above process in Ansible. Once connected, IP Fabric automatically populates your Ansible dynamic inventory plugin via the API, so you always have stateful data fueling your automation playbooks. No more manually maintaining static inventory files; IP Fabric’s dynamic inventory plugin pulls structured, normalized data directly from the API every time your network is discovered.

Learn how to automate firewall rule management with IP Fabric and Network to Code.
Step 4: Validate Network Data in ServiceNow & Ansible
ServiceNow and Ansible don’t have the ability to handle configuration-driven management on their own—but IP Fabric has it covered.
Now that we’ve established IP Fabric as our source of network reality, it’ll automatically sync with ServiceNow and Ansible every time we discover the network. (As I mentioned above, this can be several times per day.)
During each network discovery, IP Fabric runs a series of built-in and custom compliance checks across millions of infrastructure data points, and report the results via our GUI, API, or MCP server. Most businesses choose to create their own custom checks; it’s easy to do so, as it doesn’t require any advanced knowledge of coding or query languages.
By having these checks completed by a third party like IP Fabric, you’re also able to maintain a Segregation of Duties (SoD) for proper governance. You can think of this SoD as an additional layer of validation, ensuring that no single tool can push a change or workflow through without it first being checked against your business intent.

Learn more about IP Fabric’s intent checks for security and regulatory compliance.
Step 5: Push Changes With an Ansible Playbook
Operations, architecture, security, and compliance teams all need to have access to network data. If they can’t understand or access the data, it creates a bottleneck, placing an undue burden on the network team. The same thing happens with AI agents if they’re not informed by the right data.
With IP Fabric, your teams and tools alike have access to actionable network insights. That means you can trust your AI agents to put your Ansible playbooks into action, without the risk of downstream errors.
What Happens When You Can Finally Trust Your Network Data?
By following the above steps, you’ve built a solid foundation for AI adoption. But you’ll also see benefits like:
- A reliable source of reality for your network.
- An always-updated CMDB.
- Faster troubleshooting and mean time to repair (MTTR) should any issues arise.
These benefits not only keep you AI-ready, but also help you to lower network costs, ensure continuous compliance, and prepare for digital transformation projects.
Ready to take control of your data? Contact us to get in touch with a network automation expert today, or try a self-guided demo of IP Fabric today.

Why is CMDB accuracy so important for network operations? Read more.
FAQs
What Kind of Data Do You Need for AIOps?
Before AI can do anything useful, it needs data that meets the following qualifications:
- It has to be accurate. Even a 20-40% error rate in your CMDB means your Ansible playbooks will be targeting the wrong devices, missing others entirely, or inheriting compliance gaps.
- It has to be normalized. From Cisco to AWS to Azure, every vendor structures data differently. Without normalization, your AI and automation tools won’t know how to interpret your data.
- It has to be contextualized. It’s not enough to know that a device exists. You also need to understand its dependencies, and how a change could affect the rest of the network.
- It has to be accessible. Data needs to be available by API so teams and tools can query it easily, without causing bottlenecks.
What Happens If I Build AIOps Without the Right Data?
The short answer: your automation becomes a liability. At the enterprise scale, visibility gaps can compound quickly. Maybe a configuration change wasn’t captured, or a new device never made it into your CMDB. Individually, these seem like minor errors. But when your AI agents are executing changes at scale, those gaps translate to outages, noncompliance, and other risks. On top of that, when something goes wrong, it’s harder to diagnose because you can’t trust the data you’re troubleshooting with.
How Does a Network Digital Twin Help with AIOps?
Most enterprises already have monitoring tools, CMDBs, and automation platforms—but they’re all working from different snapshots of the network. They’re updated at different times, with different levels of coverage. IP Fabric’s network digital twins solve this issue by building a single, normalized model of your entire network, which is refreshed several times per day. This means your AI agents and teammates alike are always working from the freshest and most accurate network data.
Why Does CMDB Accuracy Matter for AIOps?
At the enterprise scale, your CMDB is always in motion. Devices get decommissioned, new devices get added, configurations change. When those changes aren’t properly captured, the ripple effects can be costly. You could be stuck paying maintenance contracts on hardware that’s already been retired, or looking at compliance reports based on a network that no longer exists. In line with this, your automation will be running against a device inventory that doesn’t match what’s actually in your network. When something inevitably breaks, your engineers will be troubleshooting with data they can’t trust, which not only takes longer, but also drives up operational expenses due to downtime, noncompliance, and more.
How Do I Get Started with IP Fabric’s ServiceNow CMDB Integration?
Our ServiceNow CMDB extension runs via a Python command-line tool that syncs network inventory data between IP Fabric and ServiceNow. To get started, install the tool via pip, then configure a staging table in ServiceNow, where IP Fabric data lands before being mapped to your CMDB. From there, the extension automatically compares your live network data against what’s in ServiceNow and reconciles any discrepancies. Read our installation guide for more details.
How Do I Get Started with IP Fabric’s Ansible Integration?
Get started by installing the IP Fabric Ansible collection from Ansible Galaxy. Once installed, the dynamic inventory plugin connects to IP Fabric via the API and handles the rest automatically. Now every time IP Fabric discovers your network, your Ansible inventory updates with it. No more manually typing key-value pairs, since IP Fabric’s network discovery is already reported in YAML. Contact our team for more details.