4 Steps to Maximize Your Investment in AI

It all hinges really on understanding
how the network infrastructure supports
your business. So it’s it’s being able
to understand the impact and that’s
really mapping through those
dependencies from um different parts of
the network on each other but also on
applications and how they sit on the
network infrastructure. So um typically
that’s in people’s heads or or you know
really tribal knowledge that’s been
arrived at through experience in an
organization. Things like reacting to
unplanned change. So resolving incidents
that have occurred um by being able to
diagnose them and and so as a result
minimizing the outage time for any of
the services that run across the network
and of course the number of outages as
well because you’re proactively able to
to to see what’s going on. the idea of
plan change where you’re where you’re
having to prepare and and and consider
what a change is going to to consist of
to validate that it’s been completed
correctly and of course to to you know
look after the roll back or fix forward
approach that you take. So much
understanding of the network is needed
in that process and again so much of
that is is embedded in people’s heads.
um exposing that in a in a more uh
programmatically available way. a key to
automation and potentially to to um a
aentic approaches as well

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

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.

Thank you Matt. Hello everyone. Welcome
to this session. My name is Timcraft. I
am regional sales lead for IP fabric. I
just celebrated my seventh years at this
lovely company and this is actually my
sixth attendance at the Cisco live. Uh
not to brag but we are quite a
celebrity, a local celebrity with my
solution architect uh after our standout
performance last year at the live
karaoke but it’s another story. Uh I
remember my very first attendance at the
Cisco live. was back in 2019 in
Barcelona and we had a very small hidden
booth and we were desperately trying to
catch people attention and try to
educate them on our uh emerging
technology and now I see today it’s the
fourth time in a row that we are diamond
sponsor of the event we have a very
large and central booth in the world of
solution so it’s really with a great
pleasure and a bit of pride that I’m
presenting today with Andre and Kelvin
from entity data the result of our
partners ship in the AI ops space. So
guys, it’s no surprise we’re going to
cover AI today. Like almost all session
you’re going to see this week,
AI is in the mouth of every single CIO,
partner, vendor, your leadership is
requesting you to leverage AI
capabilities in your process to increase
the efficiency. But we see two main
challenges to that. First of all, how
can you trust the model? How can you
trust the data? How can you base your
important IT decision on a model, on an
output that you don’t fully trust? And
second of all, how sticky will become
the AI in your process if it’s artifici
artificially plugged into your process
in your tool without a real problem to
solve. And this give us a lot to think
about and raise a fundamental question
which is guidel guidelining this
presentation today. So if you are
intending on leveraging AI as part of
your process, I want you to consider
this.
Is AI the means or the end?
Am I adopting AI for the sake of the AI
adoption or is AI the perfect tool to
fix a problem worth solving?
And this is exactly the second approach
that took entity data. They had concrete
issues in the managed service space and
AI became the logical answer to answer
that. So today I’m going to let Calvin
and Andre present you um first of all
the challenge that raised this whole
initiative then the journey they took
and finally the result of their
development effort into the beline
platform that they are launching. Over
to you Andre
thank you very much Tilman. I think like
many of you I started my career in
frontline operations. I finally remember
doing L1 network support and Windows
3.11 support back in Port Elizabeth Port
Elizabeth South Africa and I think many
of you just thought Windows 3.1 what yes
it was a very long time ago since then
I’ve always been in frontline operations
and this is where our journey starts
frontline operations I was joining a
late night major incident call where
plan change had an unintended outcome we
cause a site isolation and I was
thinking surely this is where I AI could
assist us to a do a far more
comprehensive and thorough change and
impact risk assessment and B if
something does go wrong accelerate root
cause analysis. 60 to 80% of service
impacting incidents are caused by failed
changes. What if we can make that less
than 10%.
Beline was born out of real operational
needs, real nights on real bridges, not
a top down AI strategy set by
executives. Although to increase
efficiency and reduce cost, although
those are side effects, it wasn’t the
main driver.
our dev journey. Um, in my mind, this
was going to be easy. We got data
sources, slap the LL on top of it, Bob’s
your uncle. Then we started planning and
we quickly ran into some interesting
roadblocks. Now, I’m not going to say
much more about our dev journey today,
but you can join us in the IP Fabric
booth later this week. We will do some
more behindthescenes stories and demos.
What I will say is this. IP Fabric’s
digital twin and snapshot technology did
make this entire journey far more or
less complicated for us especially since
one of our core design principles from
the beginning was to be vendor agnostic.
Introducing Beite. All I want to say
here is we made this for engineers to
make their lives simpler, better,
faster. Less grunt work, less fewer
mistakes, more time solving problems,
less time digging for them just doing
engineering work.
And now, are you here? We’re going to do
some use case demonstrations today.
Unfortunately, they can’t be live today,
but like I said, we’ll do some live
demos later this week in the booth. For
the first one, I will be an L1 engineer
doing an incident ticket. For the second
one, Calvin will do a more complex
change planning for ISP move.
Think again.
And again. So, here we have our ticket.
All I did here was ask Beline to do a
root cause analysis. And I copy and
pasted the service now information into
the ticket. A user can’t access an
internal application. Yesterday it
worked. Today it didn’t work. And all
the necessary other information within
the ticket. The user move desks. They
change switchboards. They move back to
Wi-Fi. No, they don’t know which network
they’re on. And obviously the browser’s
connection timed out.
Here we got Beline coming back. We
should get a nice pass analysis. And now
we can see that the prog firewall is
blocking the traffic. And if we look up
at the details, we’ll see the policy
firewall policy that’s also causing this
problem. Now we know what caused it. We
need to know what changed this behavior
in the network in the first place. So
what we’re doing now, we’re asking
beline to check for configs, config
changes that could have caused this. So
in the background, Beline is pulling
some some rag information, doing some
conflict diffs, and we should get a
summary back in a second where we see
which firewall change it was and what
has been removed and what’s been added.
We should see HTTP removed and we should
see HTTPS now being the only protocol
being allowed.
And there we have it, a nice description
what is there, a nice summary at the
bottom. Now we can go back to the user.
Tell them to log a new request with the
security team. Case closed. over to you.
Thank you, Andre. Okay. Um, so as Andre
mentioned, I’ll be running uh a change
formal change planning. Um, my use case
is a little bit more open-ended and, uh,
hopefully I can show how Beline can be
useful to an engineer planning a formal
change. Andre, if you want to go ahead.
So, to start with, um, what we’ll do is
I’ll ask Beline if it can pull a site
diagram for me, um, and explain the
connection to the MLS cloud. So yeah,
what we’re looking for is just a nice
clear diagram of the site, something
that we can get a quick handle on what
we’re working with. Um, and an
explanation of the MLS connection uh to
the MLS cloud. So would be nice to have
some interface information, maybe some
IP addressing, um, just some basic info
about this connection.
We should get a response in a few
seconds.
Here we go.
Okay, so obviously the diagram uh here
we go. Nice clear diagram shows us D5X1
is the breakout to the MLS cloud. Um and
in the summary there we can see there is
some interface information. GI01
uh is the interface and there’s a subnet
being used for this link. Um at this
stage I’m going to give Elon a little
bit more context. Tell it we’re cutting
over to a new telco for the Helsinki
site. I’ve told it which device and
which interface the new telco will uh
terminate on and I’ve asked it to go and
suggest some IP addresses we could use
for this new link based on the current
configuration. So obvious output here is
we would like a /30 uh subnet to use. Um
but something that’s important is uh
you’ll see there’s a show tool use
toggle at the bottom. Um, I need to make
sure that Beline is checking the actual
configuration of the device so we know
that the answer is grounded in reality,
not just a hallucination. So, I’ll wait
for it to finish and then we’ll see
enable that toggle.
Okay, so we’re looking for a
configuration rag call up there. I can
see it has queried the correct device.
So now I know that its answer is
grounded in reality and we did get a 10
1 0212/30
as the suggested network. So very nice.
Um now I’ve asked Beline if it can
explain the routing configuration to me
uh specifically in relation to the MLS
cloud and to break it down by routing
protocol. Um as this is a demo
environment I obviously know that the
primary routing protocol in UCI is OPF.
So what we’re looking for is a nice
clear description of that OPF
configuration, some details about that,
and then just a summary of the other
routing protocols at play. So we should
get our response in a second.
Here we go. In the summary at the top,
we’ll see that MLS is primarily
connected via OPF. Um there’s a nice
summary of the OPF configuration. Um
some details about it, and then the rest
of the protocols are listed thereafter.
Um,
now based on all of this uh context that
we’ve gathered, all of this
investigation that we’ve done, I’m
asking beline if it can provide me with
some CLI commands, something we can just
copy and paste and we could put it in a
runbook and we could use this uh as part
of the change to just apply this new
switch over to this new telco. So, what
I’m looking for here, obviously um it
needs to be correct, but I’m also just
looking for something easily copy and
pasteable. So we’ll see in the response
I get a nice config block that we can
copy and paste. Um it’s using the
correct interface. There’s a
description. IP address looks good.
Subnet mask
and some additional details. So
as a final test what we’re going to do
is I have got a a config block that um
I’m asking beline to validate for me. So
in this situation I’ve given it some
commands and I’ve asked what would be
the impact of applying these commands to
the device and specifically I have
corrupted the subnet mask on this this
configuration. So instead of a slash30
I’ve given it a /24. I know that’ll
cause problems. I’m expecting beline
will highlight that for us. So let’s
see. Uh at the top it does give a nice
little description to say you know the
primary problem is the /24 mask. it
overlaps with many existing SL30s and
will cause serious routing and
forwarding conflicts. It then goes into
details on each of the other additional
areas of conflict. And there’s a
recommendation at the bottom to don’t
use a /24, use a SL30. Um hopefully with
that very quick and very simple use
case, you can see how Beline could
assist an engineer with planning a
change, validating commands, and
hopefully just make their lives a lot
easier.
Tman, back to you. Thank you Calvin. Um
so we clearly can see that this is for
engineer and I guess it’s more in a
managed service context but who is the
audience for this? Is it for your own
entity engineers operating large and
complex customer environment or it is
also for the end customer to have better
better visibility?
So like I mentioned first and foremost
this is to enable our engineers to work
simpler better faster. However, we are
planning a client front end which will
probably release in quarter three this
year. So if we are do have a managed
service with with entity, you’ll
probably end up with a client front end
as well later quarter 3 quarter four
this year. Super
but like I said it’s for the engineers
first enabling our teams
of course and maybe another question for
you Calvin because you have developed
this this platform and I’m sure you have
been through up and down. if you have
few lessons learned to share with the
audience
regarding leveraging AI and trying to
build something out of AI.
Yeah, absolutely. So, um I’m not going
to get into a deep dive of the
challenges or the architecture here, but
if you’re interested in that, come to
the booth. Um, but I will say that this
MCP agentic AI solution is definitely
the bleeding edge of technology and if
you are going to get involved with this
be prepared for multiple updates to
dependencies every day. It is a
extremely rapidly evolving space and
just uh trying to keep up has been a
challenge.
Super. Thank you guys. We are slowly
heading towards the end. I wanted to
wrap up. Another question for you uh
Andre, how do you envision the future of
this beline platform?
If you look at our future platform is we
definitely want to add more data sources
like data is everything. We’ve built the
engine the model. Um and we’re going to
add an agentic AI agent on top of this
to to validate service now tickets
before it comes to the engineer. So get
into the pipe sooner. So by the time
engineer receives a ticket, Beline would
have analyzed it already. So instead of
copying and pasting, we’re just going to
plum it straight in from Service Now. So
we’ll have a agent check those tickets.
Okay, cool.
Guys, if you want to see a bit more of
this beline platform if you want to see
it live and see the extent of the
platform and ask any question as Andre
Cavin was saying, we’re going to have
two uh invoo platform um sessions. So
one in on Wednesday at uh 1:30, the
second one on Thursday at 11:00. So feel
free to come and ask uh Andre and Calvin
every question that you have. If you
want to reach out directly to us, feel
free to to come after this session or uh
you can invite us on LinkedIn and we’ll
be more than happy to discuss your
concrete uh case and situation. So now
we wanted to thank you for your
attendance. We wanted to wish you a very
nice and interesting Cisco live. And for
those who would like to be interested in
other type of performance, I say I see
you on Thursday for the live karaoke.
So, thank you very much.

Welcome everyone. Today I’m going to
demo some of the uh capabilities that
we’ve created using uh an internal
self-service portal kind of mimicking
what you probably are already running in
your environments or if you’re not using
a self-service portal, you know, the
Ansible playbooks or Python scripts or
or things like that um to automate some
commonly done activities. We’re also
going to show how you can better utilize
the the technical stack that you’re
already working with. Um, so you can see
at the top of this internally built
portal, uh, our IP fabric netbox
integration sync status. And what I have
here is just the ability to show what’s
happening um, in our IP fabric netbox
integration. So we have an official
Netbox integration. I can actually
trigger uh syncing right from my
self-service portal. But if I want to
pop into Netbox and see a little bit
about what that looks like, I can see
I’ve triggered this job. So I’m here in
the community of edition of Netbox. If I
scroll down, I can see that IP Fabric
integration. And of course, we have tons
of of things that you can look through.
We’re going to sync that information,
sync all of the the network information
that IP Fabric gathers, which is
incredibly uh it’s it’s a the most
accurate discovery on the market today
because of the way that we do our
discovery. And therefore we can update
um your your netbox, your other DSIMs,
your CMDBs, your IPAMS, uh any source of
truth really um because of our
incredibly accurate discovery so that
you’re not looking at stale records um
and trying to you know work with your
compliance teams, work with your finance
teams, work with renewals and all of
that um with stale information.
So that’s kind of the the idea behind
this IP fabric netbox integration.
Again, we’re just bringing incredibly
accurate information to this source of
truth that you might be using. If I go
back to my uh self-service portal, I can
see, you know, again, I have a job
syncing already. It’s reminding me
because of the version that I’m working
with, the latest version. I can actually
um trigger this automatically. So I have
uh web hook triggers available. Every
time uh a snapshot finishes, I can
trigger it to do a sync with NetBox. So
we’re always constantly up todate. And
then branch um branching is enabled as
well if you’re familiar with the coding
term branching. So basically we can
branch this information and then merge
it into main when we’re ready when we’re
sure that we are ready to do our merges.
And maybe you saw that here. Uh you can
see my demo 2 is ready to merge. I’ve
already run a sync and and we can merge
that information to make sure that you
know we’re not working with multiple uh
versions of of what’s actually on hand.
And then to kind of tell the story a
little bit further, I’ll run this VLAN
provisioning uh service from my
self-service catalog. And you know, this
is a pretty common activity where we
want to just make a new VLAN available
on our switches in let’s say Helsinki.
So, I’m going to put in a new VLAN uh
that I want provisioned. And we’ll say
um new service. That’s not a great name,
but for the sake of the demo, that’ll
work. Um we’ll select a subnet. Now, all
of this information, especially from the
pulld downs, is available because of IP
Fabric. It’s actually pulling this
information from the IP Fabric APIs into
my self-service portal with just some
really easy API calls. And of course, we
always need a justification because
eventually this is going to turn into a
change management ticket. So I need this
VLAN to provision my new revenue
generating service
and then of course who it’s requested by
and we’ll validate with IP fabric. Now
here we go. We we always want to
validate and make sure VLAN 100 is
available. And IP Fabric actually says
that it is available. And I can pop in
through my deep link back to IP Fabric
and see what this is all about. And I
see VLAN 100. So why is it telling me
it’s not available? Well, because it’s
actually not um taken in the Helsinki
site. If you’ll recall, we chose
Helsinki. Um so we still have VLAN 100
available there. So that’s all good.
That’s correct. But Netbox is showing
that VLAN 100 is already allocated. And
a couple things could be happening here.
So maybe we haven’t done a sync recently
with uh the Netbox integration and we
need to do that sync because maybe we’re
seeing some stale records or a really
legitimate reason why VLAN 100 might be
showing up in Netbox is that maybe
another team, another person has already
requested that VLAN but hasn’t had the
change management window yet uh to
provision it for real on the switches.
So IP Fabric wouldn’t know about it yet.
IP Fabric knows what’s actually
happening on your network today. Netbox
is showing you what your intent is for
tomorrow maybe or next weekend. So no
problem. We’ll go ahead and use one of
these suggested VLANs and we’ll go
through the validation again. And now we
see, okay, the subnet that we selected,
the VLAN that we selected is available.
We could go back into IP Fabric and and
you know validate that. But I’m going to
go ahead and confirm and provision. Now
here I’m not actually provisioning that
new VLAN on my my switch interfaces
right what I what I want to do is
actually create a change request ticket
because you know I work for a large
enterprise and all of this will need to
go through uh during a change management
window and of course the first thing is
to get approved during for that change
management window. So what I’ve done
here is I’ve automated the uh population
of a service now ticket then and again
all of this information comes from
either templates from the back end of my
self-service portal but the the actual
data comes from IP fabric itself and so
if I scroll down I can actually see okay
this comes from the self-service portal
I entered in my justification
um all of the subnet information the
gateway information again comes from IP
fabric and And through templates, I’ve
said, okay, every time I provision a new
VLAN, then we need to run through phase
one, which is a pre-change snapshot. And
I already have an Ansible playbook set
up to do a pre-change snapshot. So
that’s going to be the first thing that
gets run in an automated way, right,
through an ansible playbook. And I do
have that set up um with Ansible
Semaphore here. You know, again, we’re
we’re working with a lab situation, so
this is kind of a lighter version of of
tower basically. But whatever you’re
using um for automation, whether it’s
Ansible or Terraform, Python scripts, it
doesn’t matter. Um I’m just showing how
this all kind of works together um to
make sure that you’re using the best
data, especially as you bring automation
or even AI into your regular practices.
And so phase two, of course, is going to
be the actual VLAN provisioning. We have
another anal playbook that’s set up to
do that. We have all of the accurate
information. Um once that those or that
one VLAN in this case gets provisioned,
then we’ll do another post change
snapshot again via an Anible playbook.
So these these IP fabric snapshots run
on either side of it so that we can
compare, make sure everything is set up
as it should be um as we intended, make
sure that things are are routing and
frames are moving the way that they’re
supposed to be. Um and then we can go
through and you know be feel good about
our changes that that happen you know
Sunday night or whatever. It also
prepopulates the risk impact uh analysis
um again with a lot of that information
that we’ve already run. Um but you can
see you know even information about BGP
neighbor state device reload reasons all
of our intent checks. Let me just show
you what that looks like really quickly.
Um you can see we have over 160 intent
checks just built in out of the box. You
can create your own custom ones, but you
could specify any of these intent checks
to run that would be applicable to uh
whatever change you’re making. And just
make sure again everything is copacetic
as you go. And it’s just a really easy
traffic light system uh that uses logic
to understand whether you are within the
the best configuration or you’re you’re
starting to sprawl.
And then again, we have a backout plan.
Of course, the change management team is
going to want to see that. And the great
thing again about IP Fabric is that we
have config backups already. That’s
another capability within the IP Fabric
platform. So, not only do we do that pre
and post change snapshot, we can
actually give you the configs of all of
your devices um individually and what
they looked like before you made the
change. So now you have basically that
holistic view of the entire network
through the snapshots and then the
actual configs on the devices. So we can
basically do a roll back and the the
change management team is going to love
to see that. And then of course a test
plan. So that’s all I had planned for
this demo today. Thanks for watching.