The Hidden Bill of Bad Data: Is Your CMDB Driving Up Network Costs?

AI does not magically fix bad data. So often times in our modern environments, we’re dealing with multiple vendors, whether those are on prim in the cloud, different vendors for routing, switching, wireless, uh, firewall. So
what we end up with is with a hodgepodge of tools oftent times with different gooies for management, different operating systems, and even different APIs, logs only show a small portion of the picture. Whereas with IP Fabric or network snapshots, you’re getting a complete view of how that network is architectured, configured, and operating. Our mission at IP Fabric is to democratize your network data. We try to empower everyone in the organization, whether they’re admin, engineer, automation engineer, AI developer. We try to democratize that data so they all can have that power to do that automation and make those consistent decisions and understand their network infrastructure.

Brace yourself. Your CMDB is probably lying to you. Just kidding. It’s no secret that CMDBs are often inaccurate.
One of our energy customers thought they had 420 devices in their sample PC environment. A discovery with IP Fabric showed over 40 of those devices weren’t even live. And extrapolated across the entire network, that inaccuracy cost them more than $300,000 a year in renewals and maintenance fees for again unused devices. On top of that, dozens of host names and serial numbers were wrong, creating real security and compliance risks. That’s why we built our Service Now extension, the most accurate discovery on the market from IP Fabric, plus added value of dependency mapping for smarter change management and security. When you can trust your CMDB data, audits are easier, costs drop, and automation finally delivers. Ready to take control? Reach out to IB Fabric for a personalized demo.

Hello, my name is Sebastian. I’m a
solution architect at IP Fabric. And
today we’re going to discuss the use
case that we hear quite often about
merge and acquisition and the challenges
that we have with it and how IP Fabric
can help you with that specific use
case. To start, what are the main
challenges with the merge and
acquisition? So we all know that it’s
generally a very large project that
might spread over several months and
there’s a lot of risk involved a lot of
eyes looking at that project and you
want to make sure that everything is
going to go as smoothly as possible. So
what are the main risk that we see with
the mering acquisition? The first one is
the fact that you don’t know what you’re
about to acquire, what their network
looks like. And this is the main
unknown. So the big unknown
traditionally what happens in that
situation is network engineers are going
to spend a lot of time and resources
into understanding that network so that
once you’ve got that understanding you
can then on board that network be able
to merge it into the existing
infrastructure but to do that part like
I said is it’s a very intensive process
where you’re going to have to rely on
data that the other side may not have at
all do they have documentation Is that
the commission up to date? And all those
are questions that are going to be
worked by your team to extract that data
so that you have the better
understanding. Without this data, you’re
in a big blurry situation and you’re
just going to find out issues as you are
in the middle of the project and then
starting to realize, oh, there is some
specific things that have been
configured. We cannot just do a simple
acquisition. we can just simply migrate
that network into ours. There’s going to
be challenges with it. So, ideally, you
want to have all that before starting
the project, but you can’t because at
that time you don’t have access to those
devices or you don’t have the
documentation that you require to
perform this operation. So, today what
we’re going to to display is the how do
you do that with IP fabric? How can we
help to get instant value from the
discovery that IP fabric is going to
perform so that you can be a lot more
efficient when looking at that project
the the first one. So if we start
looking at the demo once IP fabric has
performed the the initial discovery. So
for that you still need as you would do
if you are going to do it manually you
need to have access to those devices and
be able to login even if it’s just read
only but just so that you can extract
the information once you’ve completed uh
the snapshot you would have first the
inventory of all your devices for
example may not sound like a lot but
it’s already data that you may struggle
to get in an efficient manner now you’ve
got device inventory You can get list of
what are the OS that running on them
some useful information already just
based on this but it’s also a lot more
data that we have where maybe one of the
use case that you want to to validate
during that mer acquisition is have I
got a certain number for all those
devices ensuring that everything is
correctly maintained and supported
actually you can also check at the end
of life milestone is there any hardware
with that network which are no longer
are supported in which case you want to
make sure that you’re going to account
like to take into account into the
renewal of the maintenance so that maybe
you just need to get new new hardware
for those. So in this table you really
have all the ser number that IP fabric
has discovered within the infrastructure
that was in this discover in that
snapshot. So all ser numbers are now
available uh in this table. So you can
easily do your due diligence and make
sure that you’ve got the maintenance uh
as expected in that situation.
So right now we’ve only looked at very
basic table that is showing us the the
inventory of like devices what you have
in that snapshot. But you may have a lot
more questions. Maybe from an inventory
perspective, you want to look at
something that’s going to be a lot more
network related where someone may ask a
simple question as what are the villain
that are configured on some devices in
that table I can see all the switching
or router devices where which villains
are configured if I want to see for
example which are the devices where I
can find that specific van I’ve got a
simple access to that information and
you’ve got to take into account that
This is not just for one device or one
type of vendors. It’s al it’s for the
wall infrastructure that you’re about to
acquire. So now I can quickly have that
good understanding of okay now I see
every villain 334 that are present in
that snapshot but obviously there are a
lot more technology tables that you may
want to use information from to have
that better understanding. So for
example, I’ve looked at the the villain,
but you can want to have the same use
case for the VRF. What are the VRF
configured on specific devices just to
have that better understanding
and up until now we’ve only looked at a
table perspective. So this is the data
and the information based on the data
representing the network we’re about to
acquire. Maybe you want to do something
that’s going to talk to a lot more
people just by having visual
representation of that information.
And this is where we can look at the
diagram that has been built based on the
data discovered. So if I open one of the
the the topology in here now what you
have in here is the topology that has
been built based on that data. So you no
longer have to manually connect to all
those devices and by by hand yourself
starting to draw and confirm that all
the vis diagram that the client would
have provided to say this is how that
site has been built. You can actually
have something that’s going to do that
for you automatically and it’s going to
after each new discovery make sure that
you can validate that this is how it was
meant to be built. So right now if
something change in this particular site
for example on those devices the next
discovery I will run will reflect those
changes. So now I’m no longer having to
rely on the manual input to update a vis
diagram but I can actually see directly
how things are represented. So you
you’ve got a lot more chances to have an
accurate data rather than looking at the
outdated visual diagram that the team
may have provided to to yours when at
the beginning of the project. Okay. So
we’ve looked at the inventory tables
that you have uh within the snapshot.
You’ve looked at how the topology is
going to help because it’s now
representing in a visual way how the the
network has been built. So all this is
going to be helping you in term of
controlling how the project is going to
to be planned. Some merge and
acquisition we had customer for example
where they planned for a number of years
for the merge to happen. They were able
to accelerate the wall project just
because they had the right data to have
the full understanding of what they were
about to acquire.
So if I summarize quickly what we’ve
seen is with IP fabric, you’ll be able
to have that visibility of that network
in minutes rather than having to wait
weeks or months to extract this
information from potentially
non-existent documentation
which this will help you to control cost
avoid having delays because you can’t
complete the project in time due to the
lack of information. Also having the
data means that you have the full
understanding for what are the public
IPv4 that are available in that network.
Maybe you want just to check everything.
So it can be whether it’s from a cost
perspective, from a security
perspective, just having that better
understanding again of the
infrastructure.
There is also the aspect from a
compliance.
Now you know how things have been built.
It’s a lot easier to plan what changes
need to be performed in the future to
make sure that that network you’re about
to ingest is compliant with the rules
that you have in place with yours. So,
as you can see, IP Fabric is going to be
the right tool to help with mer
acquisition project. And if you need any
further information, feel free to get in
touch with us.

that all felt very fancy um welcome
everyone I am uh Lauren Maly I’m the
director of product marketing for IP
fabric um so today I want to talk about
a question we’ve probably all asked
ourselves probably several times
actually which is why is it that it
projects no no matter how carefully
planned always seem to run over budget
and behind schedule and I think the
answer lies in something that’s both
fundamental and deeply misunderstood
right it’s the unknown unknowns we’ve
all heard that before right but when we
think about it right we talk about
complexity in it and Technology services
and networking all the time but usually
we’re we’re thinking about the
complexity that we can see the
complexity that we know about but really
it’s the hidden interdependency those
forgotten risks and the technical debt
that truly does compound over time so
today we’re going to explore these
invisible forces right which create
absolute chaos and how you can actually
bring Clarity to the complexity so that
you can make more informed decisions
without slowing down your
Innovation so first I want to start with
a familiar story of IT project overrun
costs and delays and we all have these
stories right we need to talk about
these things I’ve I’ve had these things
as a network engineer and as a
consultant um we’ve first heard this
particular story though sitting on a
zoom meeting listening to a New Prospect
and one of the questions one of the
prompts we always ask when working with
new folks is to tell us about a time you
had an unplanned outage your teams had
to come in unexpectedly to fix some
issue quickly right and this team was
they just jumped right in with the their
answer right they called this project
they were working on building the sites
of the future basically they were
building new data centers modernizing
the connectivity and the land and the
WAN uh building an automation for
configuration and troubleshooting with
those kinds of things that that we’ve
all done right and when we joined them
though they were 18 months past their
target dates already and they’d actually
made it as far as turning on that first
site in London and the alarm Bells just
started going off and it turns out they
were actually using reusing maybe as a
better word the same networks as a
previously existing site in South Africa
now maybe it seems like they should have
caught this right but this is actually a
hypers scalar with thousands of networks
right multiple teams ma managing these
networks in silos uh hundreds of people
right and also isn’t it funny how we
always talk about networks using the
plural right but but it’s really just
one network right that’s the whole point
uh and and also why it’s it’s a problem
right we can’t have overlapping networks
and things like that at any rate it’s a
giant network with a lot of hidden
complexity so they just didn’t catch it
until it would into
production now this is just one example
right a real example but this is
applicable to everything is I like to
say every IT project is essentially a
migration with a lot of
interdependencies right do you have a
new AI or automation initiative a data
center networking refresh a cloud
migration or even a cloud repatriation
project coming right I’m willing to
about everyone in this audience has some
big project planned for this year right
or maybe a project that slipped from
last year and this slide represents a
familiar Horror Story that you’re either
in the middle of or you’re desperately
trying to
avoid now the reason I said I’m willing
to bet everyone in this audience has
upcoming projects is because we at IP
fabric have spent the last year actually
doing our own research calling people up
conducting interviews with uh so far 30
different um people in in technology
leadership positions at large
Enterprises and we’ve found quite a few
patterns but one of the the patterns
we’ve noticed is that when these leaders
are doing their planning they tend to
think in three Horizons right the first
is the near-term or the daily things
that just have to get done and by the
way these are the things bogging it down
the things that it really doesn’t want
to spend their time doing but also the
things that they just have to do then
there’s the medium term and these are
the things that are often more cross
functional you know they’re budgeted
they’re planned projects um these are
the projects that it actually wants to
spend their time doing but they often
fall behind on because of you know that
First Column the daily activities the
complexity of cross function
projects now this is that project that
we were talking about in that last story
right building the sites of the
future now lastly leaders are thinking
about the long term or how I like to
phrase it what the technology
organization needs to do in order to be
perceived by the business as a catalyst
rather than a cost
center now this is what’s driving that
current reorganization Trend uh to a
more distributed technology Services
organization which is more closely
aligned with different parts of the
business now if the Strategic
initiatives right th that medium-term
those medium-term projects are hard to
achieve you can imagine how difficult
the long-term business alignment becomes
especially in an even more decentralized
it org now it’s these three Horizons
that are The Balancing Act that
technology leaders face daily right
managing today’s fires tackling
tomorrow’s priorities and then building
for long-term
transformation and when one thing slips
from any of these columns everything
suffers and I know I’m a vendor right
and and you’ve heard these pitches
before but I’m also a data person so I
decided to do a little of my own
research for for this presentation and I
found several studies particular to IT
project overrun costs and delays so let
me show you what the research says about
the hurdles about the facing those
medium and long-term
Horizons so these figures up here come
from extensive research into it project
performance across Industries including
data from the Department of Defense from
McKenzie um from a study called the
empirical reality of IT project cost
overruns which actually followed 5,000
real IT projects and then based on that
data created a simulation
now their research shows that ignoring
low probability yet high impact events
leads to risky and often suboptimal
decision making it also says that we
don’t actually what we as Leaders don’t
actually mean to ignore these high
impact events but often we’re just not
made aware of them right we don’t know
that there’s a possibility that they may
occur so let’s take a look at some of
these statistics highlighting this issue
right so 45 % of large IT projects
exceed their budgets this is according
to
McKenzie um at the Department of Defense
only
35% uh of IT projects stay within
budget according to that study the the
5,000 real IT projects
right
26.5% of all IT projects report budget
overruns of more than double their
planned costs and by the way that range
is actually two to four four times the
plan cost right for 26.5% of IT projects
perhaps one of the most alarming
statistics up here right one project
recorded a 700% overrun showing just how
drastically things can go
wrong now these figures aren’t just
about cost right they expose a deeper
issue a lack of visibility into the
risks and Technical debt that compound
over time just like real debt now
without the means to see and address
these hidden
vulnerabilities organizations remain
trapped in cycles of inefficiency right
and actually I think that’s too soft of
of a phrase right it’s really cycles of
escalating
risk so the question is as I said in the
beginning why does this keep
happening now the short answer is that
it’s the unpredictable nature of it
we’re essentially just gambling every
time we roll a dice on a new IT project
now the last study I mentioned basically
found that it project overruns take the
shape of a power law distribution I’ll
be honest I had to look up what that
meant right um basically though it
describes a fat tail situation so it’s
like comparing everyday traffic jams to
a Citywide gridlock right you’re going
to have lots of small slowdowns people
are used to that it’s normal they know
what to do but occasionally one
breakdown causes such a catastrophic
chain reaction that the entire city
comes to a halt and that’s what happens
in IT projects interdependencies and
systems mean one issue can Cascade into
a much larger problem leading to those
massive overruns that 700% overrun and
it’s these interdependencies according
to the study and probably according to
the collective experience here which
create such an unpredictable
situation it’s what makes these
decisions so difficult for decision
makers like all of you because it’s
nearly impossible to predict and
understand what those chain link
reactions are going to be how and when
they’re going to occur and when is the
right time to to roll the dice on a new
IT
project what you see here is a snapshot
of what I fondly refer to as the
ecosystem of constraints face in
Enterprise it
today these challenges aren’t just you
know a list of of individual items right
these are all interconnected things
because interdependencies aren’t limited
to it equipment and networking devices
right this all comes together to create
a domino effect that only amplifies
complexity with every single decision
and like I said right why does this all
keep happening well because Enterprises
are eager to innovate
right to implement cuttingedge projects
like automation like AI like Cloud
migrations right but progress often
feels like it’s speeding ahead with with
a handbrake on now why is that because
the state of your foundation it’s your
daily operational demands that are
dictating your pace I want to say that
again right it’s the state of your
foundation that’s actually dictating
your pace the network for decades has
been a bottleneck right I’m not the
first say it I won’t be the last it’s
not because the technology is stagnant
and it’s not because Network
professionals don’t know what they’re
doing or how to how to go about it right
it’s because the environment in which it
operates is inherently
fragmented now if you think about it
right you’re your teams are managing
multi- vendor environments even if
they’re not let’s say it’s single vendor
right but you have you know data center
Cloud uh campus Branch right all the
Technologies are wildly different and
for all intents and purposes it might as
well be multivendor right because it’s
different os’s it doesn’t work together
so this creates distributed operations
and this is all happening on Mission
critical networks where downtime just
isn’t an option your teams are also
bridging gaps between Legacy and modern
architectures while also juggling
generational divides I’m talking about
the people here right those skilled in
CLI um versus those kind of desperate to
avoid the CLI right they’re focused on
the apis and the goys this this
generational divide exists and then all
of this is layered on to a foundation
that’s already strained by technical
debt with Gartner reporting uh 40% of
global it budgets are going towards
addressing addressing technical debt now
now the reality is that every attempt to
simplify whether through new systems
Solutions or skills ends up introducing
e more variables into an already complex
system each new tool promises efficiency
and velocity but without visibility
without a coordinated strategy they
often just add friction instead of
removing it so the takeaway here is that
these challenges again are not just a
list of isolated issues there’re
symptoms of deeper systemic constraints
that require a more holistic approach to
address so now the question question
becomes how do you bring Clarity to this
complexity without introducing even more
layers of in efficiency right basically
how do you take off that
handbreak so going back to our original
story of the hyperscaler struggling with
their sights of the
future they’re now one of our customers
by the way um so in the beginning we
deployed a proof of concept and one of
their senior leaders was was quoted as
saying during that time I knew we had a
a technical debt problem but I had no
idea it was this size and I didn’t
expect IP fabric to flip over all the
stones at one time now maybe it sounds
like we’re adding to the backlog here
but again it’s about knowing where those
chain link reactions are going to H
occur right knowing where those gaps are
so that we can make more informed
decisions so that leaders understand
what this decision means and ultimately
reduce risk reduce cost and even improve
Revenue so just quickly I don’t want to
make this a pitch right but just to give
a summary of this technology that I’m
even talking
about so IP fabric is an appliance that
you Deploy on your network um and it
maps and models your entire multivendor
network cloud and security environments
right your layer one through four
devices because again it is just one
network right when we say end to end we
mean end to endend some people refer to
it as a digital twin we think that’s one
of the use cases that we cover right so
we collect information not just on
configuration but State policies
interdependencies giving your whole team
regardless of skill set function or even
generation a full picture view of what
you have right not just individual
devices but actual behavior of the
entire network this tells you what’s
going on in your network at a point in
time not just what should be going on
now as we build out this data model we
apply Advanced analytics and insights to
the data set and then present those back
to the user or to the system right your
technology stack so that everyone can
see you know current issues potential
issues non-compliance single points of
failure Etc so your operations teams can
come in view the dashboard every morning
while drinking their coffee right see
what’s happening today see what’s
changed from yesterday between the the
two snapshots right and then taking that
a step further with these time time
based snapshots of your entire
multivendor network you can do things
like deep root cause analysis of things
that have happened in the past but also
then prepare and design for the
future now everything in IP Fabrics UI
is also available in the API and this is
what helps our users expose the
appropriate capabilities to the
appropriate teams because we don’t
charged by the seat right we want this
to be the Rosetta Stone for your entire
it
organization now you know does a
compliance auditor need a report well
the governance team can push a button to
get it on demand does the apps team need
to understand the interdependencies of a
certain application so they can migrate
to the cloud meet their own deadlines
they could use a self-service portal
does the security team need to know if
anything’s bypassing required firewalls
because your Monitoring Solutions aren’t
going to tell you that right they’re
just telling you what’s happening on the
individual device and what’s passing
through your firewalls they can consult
the chatbot right and IP fabric will let
them know if packets are bypassing
compliance firewalls right it empowers
other it teams it teams to selfs serve
while freeing operations teams from
answering unnecessary tickets and of
course along these lines right we plug
IP fabric into all these other systems
you’re already using service now right
itsm cmdbs your automation Solutions Etc
right your entire technology stack most
of these systems depend on having a
clean house right accurate data to avoid
that familiar garbage in garbage out
problem and this is why we’re actually
perfect for building your network AI
models as well right providing
structured multi- vendor data normalized
right we also work at both ends of your
automation Loops if I can say end about
a loop right we provide the information
that needs to be remediated or changed
and then after it is we’ll check to make
sure validate that everything’s
copesthetic after that remediation so
all of this comes together to mean
better collaboration between your entire
it Organization no matter how
decentralized it becomes and this is
what will actually accelerate those
strategic projects that you’ve budgeted
for or maybe most importantly the ones
that have already stalled
so I’m going to wrap with this slide it
projects face massive overruns in costs
and timelines and much of this stems
from the hidden interdependencies within
complex systems these
interdependencies right the behavior of
your network cloud and security
environments can create Ripple effects
what IP fabric does is bring these
interdependencies bring these gaps into
the light making the manageable rather
than overwhelming giving a road map
steps 1 2 and three where to get started
and actually how to execute so consider
these outcomes if you would in eight out
of 10 of our proof of concept
deployments we’ve uncovered unknown
devices right gaps that could compromise
both security and operational stability
I’ll tell you about a recent one I just
heard about this is going to sound crazy
right but we actually found a 20%
discrepancy between what IP fabric
discovered and what their prospects uh
cmdb was telling them they had in
production now it wasn’t just unknown
devices right it was unknown devices or
devices that were actually no longer in
production which of course is going to
change what you’re paying you know and
Licensing renewal costs it was devices
with incorrect host names and model
names which of course you know could
affect how security compliance
automation policies actually get applied
it could lead to actual compliance
penalties and fines and prison time
right things like that are what we’re
able to discover with our very accurate
Discovery customers have reduced root
cause investigations from two days to 1
hour and MTS from uh 24 hours to 30
minutes right tasks that once took weeks
or months ticket creation audit prep are
now completed in the fraction of the
time and more
accurately so these metrics demonstrate
that the complexity and the
interdependencies within your network
don’t actually have to control the pace
of your progress by addressing these
challenges head on IP fabric actually
empowers organizations to make
datadriven decisions reduce risks and
accelerate key initiatives now as Julian
Mano from Airbus aptly put it uh IP
fabric is a Cornerstone of our
automation strategy and a must have for
Network management so really you know
the question isn’t whether you can
afford the visibility and control IP
fabric provides right it’s whether in
this day and age right ransomware and
cyber insurance and all of that can you
afford to continue without it that’s all
I have I’m happy to take questions or
come visit the booth we also have a free
trial uh thanks everyone for joining

Hi, I’m Sean, solution architect at
Pabic. Today we’re going to discuss the
use case about change management. For a
good change management, the process is
you need to make sure you’ve got the
correct information before your change.
all the pre-change checks that you’re
going to perform, making sure you’ve got
the correct understanding of what you
have so that you know what to change.
Once you’ve done your change, you want
to perform the correct post change
checks which are going to make sure that
what you’ve done is only affected the
intention and that you haven’t had any
side effect or something else that has
broke because of the change you’ve
performed. So today we’re going to
discuss how IP fabric can help with the
pre-checks and also the post checks to
simplify the process and also make it
more reliable to avoid any side effect
and unwanted surprises that you’ll get
the next morning because of things that
was obvious but you didn’t see because
of uh the time constraint of the change
window.
So if we look at the screen over here,
what we see is a network diagram. So
this is going to be based on the
discovery IP fabric is going to perform.
So now you have accurate information
that you can see of what is the current
state of my network and this is the
information that you need before doing a
change when you’re starting to prepare a
change. In this situation, what we’re
actually going to see is instead of just
seeing the diagram, I also want to see
some useful information where in my
situation, I’ve got single points of
failure in my network. And the one we’re
going to look at is those devices. I can
see that they are single attached the
two switches at the end. And this is one
of the issue that we want to fix with
the change. This is looking at it from a
technical perspective. But if we look at
the value side of it, what this is is
those are now two switches that don’t
have any resiliency. So what happens if
one of those link fail instead of losing
potentially just some throughput into
your network now what you’re affecting
is the server that may be connected to
it. So the application that’s running on
that server and now you’ve got a
business impact just because of
something that was unknown to the
network team that maybe was not
correctly monitored. So you have that
issue in your network that you may not
be aware. So having a visual
representation of your network allows
you to see those single point of failure
or to see other issues that you have.
But now when you’re about to talk about
the change is making sure what are the
interfaces that I need to use, what is
currently in use, what is not. You can’t
always rely on the vis diagram that was
last updated 6 months or two years ago.
So you will have to go manually to that
device to find out tell me which one are
the interfaces enabled, which one are in
use, which one have been reserved by
someone. So all that’s those steps which
are normally done manually at text time.
Now you’ve got the data that you need to
prepare your change available with a few
clicks in the right table to see the
information that you want to see.
So this is one side that we’re going to
look at. The other thing that we’re
doing in that change as well is we’re
going to change the routing for example
in here. And again now from that
perspective we’re not just looking at
relationship between devices but I also
want to see how is the network behaving
so that if I’ve got a user connected to
that site that wants to talk to
somewhere else in the network how does
it look like? So for that if I use the
path lookup and I’m going to use for
this one that I’ve got already
prepopulated as a source destination.
What I’m saying is I’ve got a source in
here that to go to a specific
destination on my SSH port, I can see
I’m being dropped by the firewall. Now,
if I want to go further, I can say,
okay, I want to continue. And now this
is the path. If the firewall was not
blocking that flow, how to reach my
destination.
So now again, let’s think from a change
perspective. What I’m trying to achieve
is I also want to make sure that now
this user can speak to this but at the
same time I’m seeing that there is only
a single
uh path between this site and the MLS
which I want to fix because I want more
resiliency and I’m going to enable that
as part of my change. So I’ve got the
information that I need. I can
understand that I’ve got a firewall
blocking the flow. And if I go back to
my topology, I know how things are
interconnected. So what I need to do
from a change perspective. So I’ve
prepared the change. I’ve now executed
my change. And now what I want to do is
look at the statuses that I’ve got
afterwards. I can already see something
has changed in here visually. I can also
see the those switches are now dual
attached. So maybe what I want to do is
compare visually those two topology.
So what this allows me to see is very
quickly I can again without having to
log to any single device I can check
that yes I can see things have changed
in here things in red have been removed
since in green added same in here I can
see that those switches are dual touch
it looks like I’ve achieved what I
wanted to do which is restore that
connectivity in here and change
something from a routting perspective
there.
So now I’ve looked at it from the
relationship perspective in the topology
but I can use the past lookup as well
and show the exact same end to end where
now what we see is the firewall has been
updated as well where before it was in
red for the same path now it’s in green
but now I can also see the difference in
the path as well there. So again if I
reproduce the compare those two snapshot
that’s what we had before and this is
the path that we see after where we’ve
enabled that path to go between this
site to the MS to reach the destination.
So the the pre and post check all those
checks and verification can be done
visually using IP fabric. You can now
see the impact that your change had on
the network ensuring that only what you
wanted to change has been updated. This
is the representation using the path
lookup visually. But you also have maybe
more related to from a compliance or
standardization perspective. You could
use the dashboard or other mechanism or
places in IP fabric where you can have
that assurance that the change you’ve
performed has been accomplished as
expected.
Okay. Um, so now what we’ve shown here
is how IP Fabric’s data can help from a
pre and post check perspective by
providing you with the right data, the
data that you need to understand the
network at scale because your network is
not just one or two devices is how all
those devices talking to each other. So
the goal of IP fabric in that situation
is after each snapshot is to represent
the network the way it behaves. So what
we’ve seen right now is how IP Fabric
can help from a pre and post change
perspective by providing you the right
data, the data that you need to ensure
that everything has been performed the
way you wanted it to. If I summarize
what we’ve done is IP fabric is going to
give you that confidence first by
ensuring how things are before the
change so that you’ve got you can
prepare the change accordingly but also
checking that once the change has been
performed things are still as you would
expect that there’s not been any side
effect so that nothing has changed in a
unwanted way by checking different
compliance dashboard or standardization.
So you ensure that everything is as
expected. IP fabric in the case of
change management is going to provide a
lot more efficiency for your engineers
so that they can perform their post
check as scale by not having to manually
connect to a few devices and run show
commands but having the full view of
your network in one table or one diagram
so that you can quickly see that
everything has been changed the way you
would expect it to. And now if you want
to have any further details with change
management and see how P fabric can help
you with this feel free to get in touch
with us.

Hello, I’m Christian Giebner, solution
architect here at IP Fabric and today we
are going to show you how we present and
talk about compliance.
One of the most common initiatives we
encounter with our prospects is
compliance. As it’s been mandated to
enterprises, they are required to solve
that task which creates a strong need
and as it also carries a lot of
penalties when it’s not done right. Um
it is a very challenging thing to get it
right in practice.
So what’s the deal when talking about uh
compliance? Usually an auditor comes
into an uh company to a prospect and
needs to verify do they match the
requirements for let’s say NIS 2 or DORA
HIPPA or CITS. So basically any
compliance requirements can be supported
with IP fabric. And the first thing they
want to see or get a report on is how is
your network infrastructure set up?
What’s the state? What is your inventory
and stuff like that? And if you bring
this data manually, this covers a lot of
risk by introducing the possibility of
human error into the process. So did you
collect the right information from the
right devices? If not, you have to
repeat that process again. And it’s very
time consuming to prepare such audits
which usually also hinders the network
team to focus on the ongoing projects.
So they really need to shift their focus
to provide the data to support the
audit. IP fabric gathers network
infrastructure device data automatically
on a daily basis as often as you like.
basically running at least once a day a
full audit of your network
infrastructure, providing you with a
full inventory of all your devices, but
not just the devices themselves, but
really going into the weeds. also
showing you which modules exist in which
device they are and also showing are
there any issues in regards to um end of
life information and IP fabric provides
this information out of the box. So
really supporting you to have a proper
inventory of all your assets
and also understanding
are there any devices which would
definitely
cause a penalty because you can’t secure
a device which is end of life at least
not in a conventional way. So you have
to prove then how did you mitigate the
risks of having a device which is end of
life and again IP fabric can support you
on that one also matters a lot is policy
enforcement. So how can you make sure
that uh the requirements of the policy
are met? An IP fabric offers with its
intent checks abilities to validate the
current state of your network, your
configurations
against the policy uh requirements and
shows you where are deviations. This is
now an overview of our out ofthe-box
intent checks which can be modified or
you can even create new ones. But the
real power of IP fabric when it comes to
compliance is
you can create your own dashboards. You
can really enter all the intent checks
you need to meet the requirements. So
you have one dashboard. You can see in a
single glance um where am I not
compliant and you can then quite quickly
and easily also drill down which devices
are affected where do we have some weak
authentication methods or none at all
which is even worse. Um so giving you
really a very quick and easy way to
understand where are misconfigurations,
which devices are affected and pro uh
offering you therefore also the
capability to mitigate these risks. As
we are a snapshot based solution, you
will always have historical data at your
disposure. So you can quickly and easily
uh switch a snapshot and then see what
has changed, did I improve over time,
where did I improve, where do I still
have gaps and all of these informations
which are crucial for you to prove I am
compliant and not just today or for this
audit, but really I approved my my
compliance posture. my requirements are
u met every day a bit better um and you
have all the data at hand and can create
quickly and easily reports uh out of
data going back to the dashboard this
tackles also various fields so it’s not
just oh do I have some some nice
security features but you can also
enabled or disabled but you can also
then validate
Do I have maybe some issues in my
network segmentation which should so are
there communications allowed or working
which should not be working or yeah am I
fine uh on that page and as we are
gathering that data constantly you have
a continuous monitoring of your posture
uh when it comes to compliance and can
quickly and easily prove proof that
you’re really uh um on the right track
and also um as you see with after a
snapshot after the calculations of our
intent checks are done where are
deviations. So did I maybe instead of
improve in a specific field did I maybe
well not perform as well as I should and
created new issues when it comes to
compliance requirements.
So at the end of the day, having an
automated way of gathering all the
information from your network
infrastructure devices,
matching them against the intended state
of the results, having the capability of
creating an alerting using our web hooks
and also feeding that data into other
solutions like your CMDB or your seam by
leveraging our
APIs. And as our approach is API first,
all the data I’ve shown you is available
and can be fed into thirdparty
solution.
So at the end of the day and to
conclude, IP fabric is not a nice to
have solution but it is a must-h have
solution when it comes to compliance and
in case you hear oh we already have some
compliance checks or tools which support
us on that one. IP fabric will augment
these solutions as the data collection
of ours is 100% accurate and the data is
not shown just as raw data but put into
context so even non-technical users can
use it to provide information to the
audit.
Thank you for your attention.

I’ve been speaking to a European bank
that first step was netbox integration
driven by their automation team. They
know they need to move fast with
automation. So they needed their source
of truth. Couldn’t trust the CMDB. So
they’ve done something in one of these
repositories. But the next step is the
network assurance into CMDB and making
sure there’s true up between these
systems and then they can start
leveraging the next level up of
reporting based on this clean data to
start tackling the operational level
trust issues the ideas of tribal
knowledge and then we start seeing the
leadership programs SD1 migration cloud
migration that in the past may have had
a six-month window for due diligence
data collection documentation
analyzing and like can we trust the
service provider? Is that consultant
really telling us the truth? All of that
stuff disappears because they’ve built
this foundational integration. What I’m
going to hand to Seb to show the demo of
is one piece of the picture. It’s how do
you take this accurate data? How do you
put it into service now within the CMDB?
But all of these topics that we’ve
discussed, they’re addressable steadily
over time by working with the right
partners to build the right road map and
peacemeal it so you can eat the elephant
one bite at a time. So Seb, I’ll hand
over to you and you can show how to bite
an elephant one bite at a time. No
pressure.
You better be hungry. Then
what I’m going to use is one demo
environment that we have. So it’s a
virtual lab. um what you can see in here
in in this screen. So it’s one of the
snapshots. So in this situation, we’ve
got two. You’ve got one that was the
same network before a change and the one
that you have performed after a change.
So one quick way where maybe you want to
see from the network what has changed
between those two snapshot. Uh we can
use the the the comparison of the
diagram. So what this would highlight is
things that so what we’re seeing in red
is things that were not present before.
So in that change and the key part I
want to focus on is the fact that two
devices were not present before and now
that we’ve done the new snapshot we can
see that they’ve been added to the
network. So that’s kind of the main part
where we’ve got the network network
change there is always changes happening
and now what happens is we’ve added new
devices and now there is the question
where someone has done that network
change has it been reflected to the CMDB
correctly and this is where we’re going
to look at it from this extension that
we have that kind of helps doing the
synchronization with service now and I
also have if I can find it yeah I’ve got
an instance of service 9 in here where
I’ve already got a number of devices and
this would be the state of my CMDB at a
given moment in time.
So now now that we’ve got the the app
running I just need to synchronize it
and for that I should remember
partially.
So now the only thing that I’m doing
with this extension is I’m synchronizing
it with my service now instance and on
the other side because I’ve run it from
IP fabric is already aware of the
snapshot that I have which each snapshot
again is a picture of the network.
So the the first run that we’re going to
do in term of doing the the
synchronization is I just want to say to
to compare what we have in the the new
snapshot. So the one that we’ve done
after the change and I’m going to do it
as a dry run because I don’t want to
write anything to service now at the
moment and it’s just going to be tell me
compare the inventory that we have in IP
fabric so things that we’ve discovered
from the network devices and show me the
comparison between what we have already
in service now
and now what you’re already able to see
in here is that we’ve got a number of
differences that we spotted uh and we
can go through the details But we’ve got
three devices that IP fabric has seen
which are not present in service now.
Five in service now but not in IP fabric
and four differences.
So I could drill down, find more detail,
and I’m going to focus especially on one
in here where it’s a common mistake that
unfortunately I’ve seen many times
before and we’ll look into it. But this
is the one where we’re saying we we
found this device and it’s not present
in service now plus the two that we know
we’ve added after the change. So now
we’ve got three new devices that we’re
going to push into into service now.
Similarly, you can get more detail of
the other way around where maybe you’ve
got devices that are present in your
CMDB. So in that case, service now, but
maybe they’re not reachable. So IP
fabric doesn’t see them. Uh today I’m
not going to focus too much on that. And
this one where what is different? So we
know that this device was present before
and after, but for example, you can see
what is different in this one is the
login IP where that was referenced in
service now. IP fabric has done the
discovery in the new snapshot and we see
that the information we have is
different from the information in
service now. So in that case this is
going to be overritten and we’re going
to update in service now.
So now that we’ve done that I’m just
going to push the change and then we’ll
move to service now to see
what information we we can see in that
cmd. That might take a few seconds.
Okay. So now I had 97 devices. I know
this one takes a few extra seconds to to
get the new devices. And now I’ve got a
few more devices.
The one I wanted to look at and
we we see it right there is that device
where we could see that it was present
already even though or it was one that
IP fabric had and was going to add
because we couldn’t see it in service
now and I’ve made it kind of like fairly
obvious maybe in here for the the eyes
that are used to work with the CMDB and
we all know that there is a typo
someone’s going to confuse the zero and
O which may not seem like much but when
you’re starting to work with a CMDB that
ser number becomes critical because it’s
the unique ID for your device. Now the
impact for that is if you’ve got the
wrong ser number your maintenance
contract may not correctly reflect what
you’re having what you’re paying the
maintenance for which mean potentially
you’re not covering the devices that you
have and then it’s probably going to
cause some sort of issues later when
you’ve got a problem with the device you
need to do an RMA so in that situation
someone has entered the one with the
four O’s where the quiet one was the one
with the zeros. So the only difference
we see in here is the date where now
this one is no longer the most recent
where the correct one is this one. So in
that situation as well what’s important
with the current extension IP fabric is
not going to remove entries from the
CMDB because that needs to follow a
correct process and the goal is not to
decommission or remove something from
that CMDB but to have now the accurate
information in your state.
The the other thing that we wanted to
show in the few minutes we’ve got left
is what we were showing earlier. If I go
back to the to the diagram,
it’s representing relationship between
devices where in service now and you’ll
find the same other CMTPs. You want to
know that if there is an impact or a
change affecting one device, you’d like
to understand what’s the chain, what
else is going to be affected by that
change.

Two recurring patterns that I see is the
first is ownership ambiguity. Nobody
explicitly owns the CMDB accuracy. The
network team thinks infrastructure is
doing it. Infrastructure things networks
doing it and it just falls into a gap.
Without clear accountability just decays
over time. I think the second is
dependency mapping. Organizations tend
to focus on catalogging devices. I’ve
got 500 firewalls. I’ve got 200
switches. But the miss actual service
dependency mapping. And an instance
response that that’s critical. You need
to know if this device fails, what
breaks? What’s connected to what and
most CMDBs don’t have that information
or the information is wrong. It requires
constant discovery and maintenance to
get a CMDB correct. CMDBs are hard. I
mean, make no joke. It’s hard thing to
get right. And if a crisis hits and you
don’t understand your dependencies,
response time just explodes. And this is
a real thing we see in operations daily.

So first I want to go over what it is and why it matters before we go directly into the demo. First of all it’s an integration right between IP fabric and Service Now’s CMDB. So this is not about the ticketing and enrichment but simply the CMDB and specifically their network gear table. So IP fabric validates that service now’s CMDB network gear table is accurate because we know that IP fabric’s discovery is the most accurate on the market. And then it goes even further to sync and then visualize device dependencies network device dependencies inside of service now. And we’ll show that in just a moment. Now why does this matter? Well, CMDB accuracy is foundational to the network, foundational to architecture, to planning to troubleshooting to governance. It matters for everything from SDWAN to cloud migration to any other IT project you have going on. But these these highle four pillars are really what I want to go over. So from a compliance perspective, it allows us to catch inaccuracies before they become audit finds. From a security perspective, IP fabric reveals hidden risks. So if there are missing devices and there are always missing devices in our PC’s that we’ve found in the current CMDB and we find those missing devices and make sure that they then are populated into the CMDB so that they are for sure getting proper security policies and automation policies etc etc. For the flip side of the coin, cost. When there are stale records in the CMDB, meaning that those records still exist, but those devices are no longer in production, then it’s still possible that companies could be paying maintenance fees, licensing fees on those devices, even though they’re not in use anymore. And from an IT efficiency perspective, this all helps across the board. But I do want to just kind of go over that dependency mapping which helps prevent unknown outages and prepare teams for change management and we’ll get into that a little bit more here now.

Okay. So here we are inside of IP fabric. I’m going to go to extensions and then click on my Service Now extension. And here I see what we’re about to find out, right? So the devices in IP fabric that aren’t currently in service now cmdb or the devices that are in service now not in IP fabric or possibly they’re in both places but the devices have changed the configurations look different. So then I can just simply choose the snapshot that I want to use. You know generally it’s going to be the latest snapshot but you could do it for other snapshots as well. And then we’ll connect to our service now instance.

And now we see we have some other options. So we’ve automatically populated the staging table. We can say do we want to show the diff right here? Do we want to write the diff to a file? We can select our diff source whether we want that to be IP fabric or service. Now in this case we’ll leave it as IP fabric. dry run means that I can actually run this whole thing and see what it’s going to do without writing anything to the Service Now CMDB. Now, if I leave that unchecked, it will in fact write new devices to the Service Now CMDB network gear table. We can specify time limit, record limit if we want a verbose output, maybe there are some errors, we want to see more information, the insert limit, and then optionally we can choose to include switch stacks, fabric extenders, and sync relationships. Now, I’m going to go ahead and sync relationships because this is how that dependency mapping is built. You’ll see that in just a second. So in service now that dependency mapping is is visualized in their UI but it’s populated with information from IP fabric.

Okay, now our sync is complete and if we scroll down we can actually choose which currency we’re showing. So whether we’re in Europe or North America or wherever we are we can show that the correct currency. Then we get an IP fabric trust score. This is weighted based on the heavier weights go to missing devices in service now and change devices. So if they’re simply maybe stale records, we didn’t give much of a weight. Now we see a lot’s changed which is why we have such a low IP fabric trust score. So you see we have four phantom devices, 44 missing devices and then one change device. And based on the total of devices in our lab, this is, you know, a really low score because it’s a lot of the lab that is incorrect. And then we’ve actually given an estimated potential business impact. So for every Phantom device that was in service now, a stale record that isn’t actually in production, we’ve said that’s probably about $1,000. For compliance risk, we’ve said it’s about $50,000 by default. And then for security risk, we’ve said it’s about $100,000 per incident. Now, these are all changeable, and you can, you know, raise that or lower that however you like, and it will then recalculate the information for you.

And so then, if we scroll down, we see the total potential business impact, $2.3 million here. And below that, we’ve actually chosen some spotlight examples. So, here’s an example of a device that’s in IP fabric and not in service. Now an example of devices in service now not in IP fabric and then an example of those changed devices with a little information below. Why is why does this matter? Well, attribute drift may hide patch or EOL gaps and increase incidental risk. Then you get into some more technical information, right? the total counts of course, but then I can expand these expanders, get some more information on why this matters, but then I see the actual JSON code that tells me, okay, this is one device right here. And this is the other device, right? And we can see all of the devices through JSON. And of course, we can send those to program, you know, to be included for automation workflows and things like that if we don’t automatically just push the config. So that’s an option of course too. And now also included in this is the executive summary report. So it’s simply an HTML file that we can open and then we could print this off for our executives. And we see, you know, all of that same information that I just went over but in, you know, a summarized report.

Now, if I go into the service now tables and let me just refresh this. So, I see all of the devices that are now in here because we did push that config. We didn’t just do a dry run. And the other thing I can do is actually go into these devices. Now, when I’ve gone into this device, I can see all of the fields that we can possibly populate, even if, you know, some of this information comes from IP fabric. And then down under related items, I see the level one, level two, level three connections to this device. Now, this isn’t should it be confused with layers from the OSI model. These really are levels, the the degrees of separation between devices. And even cooler, we can then see the dependency mapping visualized for us. And so here’s the the switch that I actually chose. And then here are all of the different devices that are connected to it. And of course, I can use this information. Then let’s say I’m updating the software for this switch or I’m changing it out for some reason. I need to create a change management ticket to do that. But the change management team is going to want to know every device that’s connected to it which could possibly be impacted by an outage especially if it’s unplanned or you know takes longer for it to come back and then of course we can you know derive more information from this say you know well I know the application our our POSOS application lives on you know these this network and so it might be impacted. So, we can we can do some of that sort of thing here as well. That’s all I have. Thanks everyone for watching.