The Network Data Problem Slowing Down Enterprise AIOps

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.

we’ve introduced uh MCP as a as a way of of interacting with IP fabric as a as a
as a platform. What what it wanted to do initially was really to to talk through a couple of things. So let’s give you
the agenda for for what we’re going to talk through today. So the the first thing is really to understand well what
is it that IP Fabric’s doing and why it’s interesting to what you do as a as
a network practitioner. um and then really step into why um AI
is important in that and what it what additional capability it brings as a result. So so once you have this this
understanding of what the network is, why is is uh MCP important. So I wanted
to cover those first and then what we’re going to do is just drop through a couple of um of use cases really. We’ve
got um these three threads that I’ve chosen here really based on um things
that are important for a network practitioner to do as part of the day-to-day job. So the ones I’ve picked
specifically you can see here design validation this is really about saying is the network built the way I expect it
to be and doing what I want it to be doing. Um you could equally say that’s
around plan change as well and and being able to to understand right is the result of my change what I need it to
be. Um the second thread really is root cause analysis and this is kind of almost the exact opposite of that. This
is taking the symptoms of some change in the network and working out what has
changed and why it changed. Um you know very very detailed um potentially uh
analysis required there. The third one is is looking at something that’s that’s really not practically possible right
now, but what we want to be able to do is is probe at that a little bit and see if there are ways that we can really
help um predict the way the network will behave under certain conditions. And so
so the whatif scenario becomes a thing. And then obviously at the end here we’ll just ch chat through what’s next for for
two different sets of people. We know that there are going to be uh existing IP Fabric customers on the call who want
to know more, but there are also going to be potentially people who haven’t yet used IP fabric and and so we want to
give you some guidance as well as to to what comes next. But let’s just briefly uh explain about
the really the point of the digital twin. I suppose
when you’re going through any network operations uh process anything uh that
where you’re looking after a network infrastructure there are certain things that that need to be delivered and it
all hinges really on this first point here understanding how the network infrastructure supports
your business. So it’s it’s being able to understand the impact um that issues
when they arise can have on business process and it’s really I suppose mapping through those dependencies from
um different parts of the network on each other but also on applications and
how they sit on the network infrastructure. So um typically that’s in people’s heads or or you know really
tribal knowledge that’s been arrived at through experience in an organization. Um and what we want to do is see where
we can help with that. Um that spills down really into these other these other four areas I’ve listed here. There are
lots of others, but things like reacting to unplanned change. So resolving
incidents that have occurred um by being able to diagnose them and and so as a
result minimizing the uh uh
the outage time I guess for any of the services that run across the network and of course the number of outages as well
because you’re proactively able to to to see what’s going on. [snorts] the idea of plan change where you’re where you’re
having to prepare and and and consider what a change is going to to consist of
to validate that it’s been completed correctly and of course to to you know look after the roll back or fix forward
approach that you take as as a result of that not necessarily doing what you need it to do. So much understanding of the
network is needed in that process and again so much of that is is embedded in
people’s heads. um exposing that in a in a more uh programmatically available way
a key to automation and potentially to to um agentic approaches as well.
Um project control here this is about measuring and demonstrating progress. So this is about saying how do I how do I
demonstrate that things have changed and these changes have been positive not to just the the network operations folks
but people outside that um make sure that the the the CXOs see what progress
is being made and how much better things are than they have been or um see where
the the the critical pinch points are in the network and so on so that so that investment can be made to fix those
things all about having a full understanding and appro of of being able to um demonstrate that the uh that you
know and understand where the network needs to be improved. So it is really about that that measurement piece. And
then obviously the the last one is a really simple sort of one. In reality it’s about life cycle management. It’s
about having control that dayto-day control of the the the network infrastructure itself.
Really understanding what it is um where it is what state it’s in and how it
needs to change going forward. So these are all areas that that you need um that
understanding for. And of course, this is where the digital twin really comes in because it can help you address all
of those things. So what does that what does that mean? Well, from the UI of IP fabric, for
example, you now have that ability to interactively observe the network. You have that ground truth, the the data
model that sits under the, you know, in the platform gives you that data and
gives you the the starting point for all of those things we talked about. you’ve got a single place to go to understand
how all of the network hangs together and interacts with each other to deliver service. Great for the individual who
who needs to use that as within the line of their work.
But then we need to take that beyond that because obviously that that’s fine. Um when you’ve got sufficient
individuals to do that work where you want to share that or out or make it um repeatable or or or automated
you need to be able to appreciate there are data points in IP fabric and any other digital twin that you can pull
those data out and then use them programmatically once you’ve built the
the scripting or or or whatever workflow. it’s then available for others
to use. So you’re not then relying on the one person’s head.
And I guess the point with MCP is we’re taking that step further. We’re not just saying you need to know where all those
data points are because the uh the LLM that uses MCP can reason about that. it
can it can make those decisions for itself, decide what information it needs in order to do the correlation that it
needs to do to build the narratives that it’s about to share with others. Um, and
so, so as a result, you’re creating something that’s much deeper potentially
from an analysis point of view or much more diverse in terms of where it’s
gathering data from and then is able to present that in a way that’s consumable by a much broader audience. That’s
really where where MCP comes in. Now, from an IP fabric perspective, this
is kind of how it all hangs together. So at the bottom of our iceberg, we have in deep in the depths, we have that network
infrastructure that’s, you know, unfathomable really to to many. It’s dark. It’s it’s complex and it’s and
it’s hard to understand. And so IP fabric comes along and creates this data
model based on the network infrastructure that then becomes a little more structured, a bit more
normalized, a bit more manageable. uh IP fabric API on top of that data model
makes that now accessible. So your the UI uh you can interact with it. The API
you can make it programmatically available. But now by placing the MCP server this control layer on top of that
what that now does is opens that up to whoever is interested in network information to be able to
conversationally pull that data through IP fabric’s API and present it outwards.
So as IP fabric is is the digital twin for this MCP becomes the interface into
the LLM which is where that reasoning is going to happen where that correlation is going to happen and of course where
that hallucination has the potential to happen. The key here is that IP Fabric’s
data is deterministic and and bounded. And so as a result,
you’re going to get definitive answers to to questions. And so there is no need for the LLM to to hallucinate about that
data when it has the the um the definitive view.
So hold on to that thought. So, let’s drop into to the first of the
demo use cases and and um this is something that that certainly uh something I I’ve stumbled across many
times in my role as a as a network consultant over the years. this idea of of checking and to make sure that the
network as it’s implemented is as it was originally designed and that can be like
I say full network design or it can be um down to the individual changes.
IP Fabric will support that through each of the of the modes that we’ve talked about. From a UI perspective, you could
just drop into the product, go look at the topology information that comes back, look at the technology tables and
and ensure that those match what what looks what’s in the design document. You
can check then by creating intent checks um on configuration to make sure that
things are configured as they should be. But this is all down to the individual interacting with the product to do that.
The next step up from that would then perhaps be to use the API to script those exceptions. So to look to see
right okay this configuration isn’t as it should be. How do I go fix that and then build that into for example anible
playbook or something to go remediate that based on inventory data that’s pulled from IP fabric.
You might also choose to take that verified data and push it into other systems where it’s useful. This is where
the API really would would be used in that case. It’s about about ensuring that everything is consistent with that
design and with the the the network as implemented. So what does the MCP bring
that’s different? Well, what it’s going to do is take that whole step further. It’s going to be able to produce uh a
report and a remediation plan using those original source materials and best practices that are going to be
consumable by the wider audience. So it could be another uh network engineer, it
could be management, it could be whoever needs change management folk or whoever needs to understand that the network
actually reflects what uh what has been documented. Give you a quick example.
Um, if you’re a network engineer like I I was, you’ll recognize this instantly
as as the kinds of documents that we use to build our our networks from. Uh
there’s information in here about the uh this this document would have been put together by an architect to include
inventory uh connectivity information, configuration information, control plane, management plane, all of those
good things. Um, and if I scroll these through, there’s my diagram. Here are my
here’s my inventory of devices and the versions of code that I want to run on them. Uh, here’s my connectivity matrix,
which interfaces are connected to which. Here’s how span entry is going to be configured, what IP addressing I’m
using, and so on and so forth. Right? So, there’s plenty of information here about how that network is wanting to be
set up and built. This would be a very typical way of that that um being
captured as a word document with a bunch of tables in here with all the information that you need. Um now that
is great, but obviously if we’re then going to go and look at um at IP fabric,
let’s say um to see how that that maps to the
network as it’s been discovered. We can see obviously the diagram looks like the diagram that was in the uh uh
in the product there. Um we can go into our technology tables and we can look at
things like connectivity matrices and and in particular that was for the Paris
site. So let’s let’s you know um focus that down onto onto Paris. We can see
the information here that that matches the information in that uh in that
design document. But it might be in a slightly different form and it might not you know necessarily be exactly the
same. So we have to sit as an individual and do some translation between the two.
We might also decide right actually I need to to to decide in the product
where things match the standards I have and where they don’t. And in this case we’ve got NTP sources here. Um you’ll
see this red and green color coding over here. This is basically my NTP sources are set the way I want them to be. This
is my rule that I’ve created and essentially I’ I’ve filtering uh this
list here. I might choose to only show the red devices and then I might decide right these ones I want to go and
remediate in some shape or form. So I could do that manually by looking at these or if I should so choose I could
go through here um prod that API endpoint with this uh payload and get
that result to to then allow me to automate that process. So this is all about making sure I’ve got the right
data in the right place in order to to automate this. But I have to know which data it is that I’m looking for. That’s
that’s critical to this. So to go to my next stage um to to use
my MCP and and what what I’ve done here is I’ve I’ve used Claude desktop. You could use any of the other um any of the
other platforms, but Claude will help give us an indication of exactly what uh
what’s possible. We use the Summit um uh for 4.6 model because it’s it’s a good
model for this kind of thing. Um, your mileage may vary depending on on which models you use and which uh um which
agents, but this gives us a good example. Now, and what I’ve done here is I’ I’ve basically said to Claude, take
that that LLD document that you’ve that we were just looking at the word document and using IP fabrics snapshot
validate that that low-level design has been implemented correctly. I’ve asked
it to look specifically at a few things. You’ll see topology, VLAN, span entry, so on in there. But essentially, it’s
going to just just do that comparison for us. Now, it’s we’re not we’re not scripting this. We’re not telling IP
Fabric to Claude to look at, you know, specific IP Fabric API endpoints or
specific pieces of data. It’s purely going to use that document to determine where to go look. And so what it’s going
to do here is using the MCP server, it’s going to prod the API of IP fabric to
essentially bring out a load of data. And and this was a really quick one. And what it’s done is it’s gone, it’s looked
at VRP, OBF, span entry, BGP, NTP, SIS log, S&P, all of these things and
assembled a group of findings. Um, and I’ve asked it to basically write that
out to a validation report. So, if I just click through here, scroll it to the top, you’ll see what it’s done. It’s
created a summary and said, “Look, these are there’s some deviations. There’s some, you know, there’s some areas where
we conform to everything.” Um, and then we go into it in a bit more detail. You
can start to see, right, yeah, actually, I’ve got things that are conforming here in terms of my physical connectivity,
but some of my OPF tables are wrong. Now, this is just pointing out that
actually there’s inconsistencies between the tables in the document, but it’s been able to to to do that for us as
well. Um, there’s some some issues around some of the interfaces have been swapped around uh in the tables. But now
we get start to get into the interesting things. Spanning tree, you can see we’ve got a root bridge placed badly here um
and needs fixing. And as well as being able to spot that problem, what it’s also been able to do
is give us the configuration that needs to be deployed and where to in order to fix the issue.
Now, for for all the will in the world, you’re not going to automate this um simply uh through being able to pick
these kinds of things up unless you’ve got essentially template configuration for every platform
um and and every uh every condition, every technology that you’re deploying.
What using the LLM has done here is opened up the door here to because IP
fabric is a vendor agnostic model. we store things in that way. Well, you can
use the LLM here to essentially um work out how to apply the data that comes
from that vendor neutral model to a specific vendor environment. And um we’ll see that as we step through this
further. So these in this case there’s some configuration for a couple of Arista
boxes here that’s needed in order to bring um our span entry in line. Our IP
addressing looks okay according to this, but VRP is broken. So again, we’ve got some remediation configuration to uh to
deploy there. Um what else have we got in here? We’ve got some some issues around OPF on Cisco. So this is now
Cisco IOS configuration in terms of the costs that some Juno uh Junos
configuration as well here. So by by using the LLM, it’s able to to
apply the the right remediation for the right platform. Um and you’ll see that yeah we’ve done
our BGP checks as well. All good. Some more stuff down here around NTP. And this comes back to what we were just
looking at NIP fabric. Um basically there’s a remediation activity here for
certain devices where it’s not got an explicit um uh NTP server defined.
There’s the Arista EOS uh command line. There’s the Cisco ISXE command line in
order to deliver that and so on and so forth. We could go through step through each
one of these, but in in reality, what you’re going to get is this report that tells you the things that are right and
the things that are wrong. And of course, what that can now be done is shared with project managers, with
network managers, with whoever needs to know in order to see progress. So, because you can run this now and then
you can run it tomorrow on on the uh the next snapshot of IP Fabric and so on and so forth to see how progress is being
made. Okay, let’s go to our second um our
second example. And this one is is an interesting one. This is root cause analysis. And this kind of turns the
whole thing on its head. Um because this is now not going to IP fabric and looking for for this specifically for
the data, but looking really at where things have changed and um and and why.
So it’s the symptom rather than the actual um the actual state configuration. So in this case in the UI
it’s all about going to look at our path lookup capability and our snapshot comparisons to say look something’s
changed. Where is it? What is it? And how do I find out what it is? As an individual I I’m doing the exploring but
IP Fabric’s giving me the the tools to do that from an API point of view. we can take
the end points that we find in the UI there and script it. So again, we can we can look at a specific path, show how
it’s changed between snapshots by by scripting the uh the analysis of that
JSON output that comes back from those API endpoints. But again, it’s very very
specific, very narrow focused. soon as we introduce the MCP, it can it
can [clears throat] broaden that that analysis and and and deepen it because it can now look at well actually it’s
not just about the fact that the state has changed but we need to understand why it’s changed what from a network
perspective would have caused that to have happened and really brings then a different level of analysis the the
sorts of things you would get from that sort senior engineer. [gasps] So again, let’s have a quick look at
what that actually means. Let’s start with looking at IP Fabric again.
And in this case, what we’ve got here, um, we’ve got a traffic flow between an on-prem device in this Prague location
at the top left, um, going down to this this, uh, AWS environment in the bottom
right here, and it traverses a number of of stages in the network, goes through the MLS network here, through the Boston
location, over a VPN, and going out into into the wider network. You’ll see
firewalls shown here in green, which is all good. it means the policy uh is
allowing that traffic to pass. And so as a result um we’re able to hit the load balances that we’re seeing down in the
bottom right here in AWS in order to to reach the the the destinations we’re looking for. So that was then. But what
happened overnight? [clears throat] Because this this is what this looks like after uh after a change. Um, Prague
is still where we start obviously, but now we’re traversing into Paris
and then fire a firewall in Paris out to AWS. Well, the AWS doesn’t seem to have changed, but our firewall is now showing
red, which means that that traffic is blocked and isn’t going to work anymore. So, here’s here’s our issue. Something
broke overnight. Something has has caused the traffic to change direction uh go through Paris.
what’s happened now in in op fabric itself what we can do is we can do this comparison of snapshots I’m looking at
day four I’ll compare it with day one and we’ll see what’s happened and you can see very clearly
where that uh where that change has occurred going through Prague I reached this this router and where before I used
to go this way now I go this way so I could start by uh digging into that
routter exploring the behavior and if I just take one of these
um you can see the routting decision that’s been taken and the and the routes that it’s used and now I can look at
more detail at the rooting table, the ARP table, the MAT trade table and so on. So it’s giving me all the data as a
as an individual practitioner that I need to go and work this out. It’s also
of course again we’re able to extract that information through the API. So I
can I can use the API to to extract the information about that path lookup and
go and and make make more sense of it or I can ask Claude to help me. [snorts] So
let’s switch back to Claude and let’s look at our second scenario here. And
basically what I’ve said is look Claude do me a favor using the day one snapshot list out the the path between those two
endpoints um using TCP 443. So that’s that’s working out is this traffic going
to be able to get from here to here using that uh that port list. And you
can see there that it’s that it’s built the path through and it’s showing all the elements the the onrem the MS and so
on to through AWS. And then what I’ve done is I’ve asked it actually can you can you now look at day
four and see what the difference is? And you’ll notice here it’s highlighted some things in the middle. It’s a different
path out of of uh of Prague via Paris in
order to get to to AWS. So now I need to understand well why is that happen? There’s some sort of
migration event that it’s talked about in here. You’ll see the on-prem WAN path has changed. You’ll see the IPSCV VPN
pointer has now shifted as well, but the AWS SP path itself is unchanged. So what
what is that migration? What does it look like? And it’s saying here the pivot point here is the Prague router.
In day one it forwards towards NS. In day two it forwards forwards towards H2X1. Well, what what’s H2X1?
Well, as we look further down, it works it out, right? Same. That’s a that’s a Cisco SD1 environment. So, the migration
appears to be from MS to uh SD1. Awesome. It’s really working this this
through ne nicely. But it’s also talked about this cloud breakout anchor site
changing. This is the VPN tunnel that was in Boston that’s now in Paris. So what’s happened there? And as you scroll
down through here, it it basically points out that in day one you were receiving essentially uh a summary route
via the the path in um through through Boston.
Um this and now what we’re we’re seeing is this new uh path this new VPN tunnel
which is giving me specific routes uh from AWS via the new endpoint and as a
result you can see that the traffic is shifting there as well.
So rather than go into it in any more gory detail here, I’ve with the the thing I’ve said, look, create me a
report. Let’s let’s get to the bottom of this. And this is the report that it’s created. And essentially the overview is
this. There’s a path lookup investigation. Um the results are these.
This is the before. This is the after. This is the summary of the path differences. So how the path has
changed. This is the AWS side. This is the SDWAM stuff that we’re now using the
protocol shifts and so on. These are the prefixes and and as a result of that the
interpretation is this and that can now be presented to someone who can just pick this up consume it and
understand exactly what’s happened whether that’s an incident manager whether that’s the network management people whether it’s the people who are
who are looking at the results of a change in a meaningful way. what we’ve
what um IP uh sorry what the MCP has provided is all of the IP fabric data to
back up this root cause analysis investigation the data is there if you were to do this
as an individual but because the LLM is able to do this we can also uh then go
ahead and and uh and use the data from open fabric for that as well
so appreciate I’m uh I’m running out of time already here so let’s um let’s quickly dash On to the third use case
that I’ve got listed here. And this is the the legend that is the whatif scenario. It’s probably the question
that everybody wants to be able to ask. We know how difficult what if scenarios
are, particularly in real networks because you’ve got such a variety of technologies, but it’s really hard to uh
to emulate those. You have to divide and conquer your network into separate pieces in order to be sure that you’ve
got an understanding of that centralized and distributed control plane and and the data planes and policy planes and
the behaviors of those things. So really if you’re wanting to do this
end to end the real solution here is not to try and emulate at all. It’s a really
tough thing to try and do. It’s uh computationally intractable. So it’s
just such a big a big challenge. So it’s much more sensible to reason probabilistically about this. It’s the
way that you or I would as a network practitioner um if we were asked to try and determine what would happen. We
would sit down and we would we would think it think about it and and weigh up the probabilities.
What IP Fabric is bringing to this is that determinism. It’s saying this is
what the network looks like and this is how it behaves right now. Um you can
trust that the data represents the way that the network behaves. What the LLM
will bring is this reasoning capability on top of that to say well actually I know and understand what these
technologies uh do and the interactions between them assuming you’re using the right models. Um
is what’s going to happen? Let’s let’s let’s think about it. Let’s correlate the data. Let’s let’s reason over it and
give you an answer. So, let me very quickly show you um a
final example. So here we have in our demo environment
we have this this Frankfurt location which is as you can see there’s a a whole mesh of interconnection here using
different protocols a whole bunch of different one different protocols um
relationships between these devices both control plane and data plane um and it
while it’s self-contained it’s also obviously connected through this firewall out into the to the wide area
network. So the first thing I asked um Claude in this case was [snorts]
well what actually is that location? you know, go look at the uh at Frankfurt
site in that in that snapshot, see if you can work out more about what that location is. And so what it’s done is
it’s created its own topology view, its own understanding. And it’s tried to
using the protocols it can see characterize the behavior of that network. And it can see that there’s OPF
running, which is essential for the uh for an underlay environment. It can see BGP running over the top of that. and it
can see vxlan being used to carry data from layer 2 v uh vn v vlanss over vnis
to the uh to the other vte across that and so it’s rightly saying look this is a a modern spine leaf data center fabric
using vxlan using um ibgp for evpn
um and essentially then routting via a checkpoint firewall out into the wide
area network. So what I’ve then asked it to do is is map a path between two
locations across that p that that uh fabric and out into the wider network
which it’s gone ahead and done and understands how to what that means in terms of encapsulation and decapsulation
and so on as it’s coming into and out of the the fabric. Again we can we can
share all of these outputs actually. that might be useful to you to to look through in detail.
But then what I’ve asked it to do is do a switch by switch failure analysis. Look at the the individual switches in
that fabric and have look at the impact that they’ll have on that that traffic
path. Now in that in this particular case it’s clear switch one and switch five are important to this. Switch five
being the top of rack host where top rack where the host lives. the switch one being the the the um the spine
switch that the this traffic is passing through by default and obviously initially if you lose that switch it
will break the path but then what happens and and so I’ve asked it to then go to that next level if that switch
were to go down or the interface go down what happens next and as a result it
then looks right sees OPF will will do its thing and the underlay it will recon
converge and as a result um we’ll be able to still maintain same connectivity and so on. So it’s it’s gradually
iterating away on the uh the behavior of this this network to understand exactly
what’s going to happen. You can see here it’s talking in detail about the different OPF adjacencies about the way
that the VLANs are interconnected with the VNI and the using VXLAN and so on.
Um and then it looks about then I’ve asked it specifically right we’ll look at the underlay routting and make sure
that everything as it should be and again it goes into much more detail here about how OBF interior routting is
working um what changes happen when interfaces drop and so on. Um
so many so many different things it’s pointing out as it goes through and it’s really trying to work this out in
detail. You can see um see here there’s there’s reference at the bottom here about there’s a genuine routting recon
convergence not instantaneous ECMP rehash. This isn’t this isn’t
[clears throat] um a simple superficial view of what’s going on there. And so
now um we arrive at what what really is the um is the the the end point here.
There’s there’s single points of failure that it’s identified. There’s issues here with with how this is deployed. And
what I’ve asked it to do again is is basically write that out as a um as a markdown file as a report. And you can
now step through that in the gorier detail that we’ve talked about. But it really here it’s it’s basically got a
series of recommendations about how to fix this. So dual homing,
firewall clustering, but also adding additional uplinks into the fabric where there are things missing. So it’s really
about getting to the to the bottom of the problem.
Something that probably wouldn’t have been easy or or particularly straightforward to have done by um
without having all of this data available. And I guess this is this is kind of the point here. [sighs]
So I think we’ll we’ll park the the the um the demo piece there. [clears throat]
Um there is a essentially the the next steps if you’re if you’re an IP Fabric
customer are to to go ahead upgrade to the latest version of IP Fabric accept
terms and conditions enable the server and away you go. Really it’s then about setting up your your um your client to
to refer to that. plenty of information in the documentation and plenty of support from our solution architects to
help you get there. Um, you know, we’re really keen to help you break open these new capabilities that that you haven’t
had available to you before. Um, for for those who are not yet IP Fabric
customers, well, you know, you know where to go. I mean the website has has got plenty of of a information but b
means by which you can come talk to us and start to talk about free trials and PC’s and the good and those good things.
So um but yeah um hopefully that’s g you a bit of an idea about what the
capability for in
I think we may be on to our Q&A. I think that’s probably the best thing to do
next. I think that’s Maddie, you’re back. Uh yeah, [laughter]
and it seems like we’ve got a couple questions coming in, especially in the last few minutes. Um but just to start
off with kind of a broad a broad question first. Um you were using Claude throughout these demos.
Yeah. Um but can you use your own custom LLM uh with this MCP server? And is there
anything you should do differently if you are using a custom LLM? Yeah, that’s a good that’s a great question. Um yeah, as you say, we we use
Claude for the demos primarily because the data is all uh demo environments and
and labs. Um and so and so from that perspective, we uh there was there was a
lot of experimentation going on, right? Um we also found that the the models the
anthropic models in particular are very effective and very well trained in uh
network um in in network process. So they they they
have you know they will reach a really good answer. Uh that said we have already got customers who have gone
ahead and um and enabled this in their environments and are using it against
private LLMs in their own pods um using the [clears throat] the open- source
LLMs and are getting good results. Um, as I said before, your your results will
vary, you know, based on on the uh the models you’re using and the the training that’s been done on them, but ultimately
with the right prompts, you are going to get really strong results and and and
address use cases you wouldn’t have been able to before.
Great question. Yeah. Uh, and we have even more coming in. Uh I’m just gonna take in in the
order in which they were received. Uh the next one is also pretty general.
Um but how does IP fabric handle security for the MCP server? Okay. Yeah. So the security is is it’s
really important actually that when you go back to that um the the iceberg slide
um because the the uh MCP server is literally built on top of the API. We
essentially use the same uh authentication that we use for the API in order to get access to data. So you
provide an API token as part of your your M MCP client setup and it will
always use that same API token to access the data which means that um when you
define arbback the role based access control for that API token you’re able to limit or or or basically place the
controls around the data that’s accessible through MCP. So yeah it’s really good question.
Awesome. All right, the next one’s from Normand uh and he’s asking uh does the
MCP server expose uh config management endpoints or just the devices and end
to-end paths and technology tables? No, it’s a really good question, Norman. Thank you. Um yes, the the the config
management endpoints are exposed. Um you can for example we’ve seen um cases
where customers have used um done CVE analysis using the the publicly available CVE
data but then IP fabric’s configuration data to make sure that uh that devices
are are compliant or otherwise right so it’s a it’s a it’s a great use case
all right uh the next one is since IP fabric now has MCP for LLM reasoning.
Are there plans to add batfish like formal validation or is this outside the product scope?
Great question. I I of course um while I work for the product organization um I
probably can’t talk in terms of of formal roadmap but um I guess um yes to
your to your point um that whole what if scenario formal
validation piece is is important um as a capability I think um for now it will
probably we’ll continue to experiment using the LLM in order to deliver that
Um, but I would never say never. I’ll um I’ll that’s probably the the the most I
can do in terms of a commitment for you. Never say never indeed. Um all right,
the last question for now. Uh unless there’s any more. Uh this is maybe the
last chance to ask any questions. Um what resources are necessary to implement an MCP server uh or a client
server solution? Yeah, that’s a really good question as well. Um we’ve we’ve been very um
gosh the team have been very very thorough looking at at the uh the resource requirements and everything in
here. Um what we have managed to do from from an IP fabric appliance standpoint
is to keep the resource requirements the same for where we’ve added the the MCP
capability into the product essentially from a memory perspective from a CPU cycle perspective from a storage
perspective there is no change um there is a an embedded small model um within
the uh within the product now which is used to um essentially do the translation between the the natural
language query and the API endpoints at the back end in order to pull um pull
the correct data through. But that’s that’s already downloaded and and distributed as part of uh part of the
product. So there’s no requirement for example to um to to um drop the air gap
and and connect to the internet if you don’t need to. So, so basically the the short answer is there are no additional
resources at this stage. All right, great question. Thank you, Renato.
Yeah, so many really good ones. Um, thanks everyone for submitting your questions uh for participating in the
chat. Um, again, if anyone wants to take a look at our prompt library, it’s free.
It’s linked in the chat. It’s linked in the docs. Uh, if you have questions, feel free to reach out to the team. Um,
we’ll be sending out um a follow-up with the on demand recording and stuff as well if anyone wants it. Um, and um,
yeah, that’s all from me. Uh, thanks everybody. Yes, thanks very much. Thanks for your
time.