Network Intent Isn’t Enough For Automation

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

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.

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

Hey everyone, Chris here, solutions
architect at IP Fabric and today we’re
going to be talking about automation and
a little bit of AI. It seems to be what
everybody’s talking about nowadays, but
the reality is you can’t automate what
you don’t understand and AI is only as
good or as well as the data that you
provide it. IP fabric exists to give you
guys context about the data that you
need to feed into an AI system or use in
your autonomous automations. Right? So
most automation projects they fail for
pretty simple reason, right? I don’t
have the data that I need to automate.
Whether it’s a single unified source for
information that you’re going to use in
another automation runbook or whether or
not it’s just AI and feeding structured
information with context into an AI
system. IP Fabric was built exactly for
that reason right there. All right, so
let’s talk about automation and how IP
Fabric can help out with that
initiative. Right, what you’re looking
at here is the dashboard. It’s the very
first screen you’re going to see after
you run a snapshot. That’s the discovery
process for IP Fabric. And what we get
on this screen here is a bunch of green,
blue, yellow, and red check marks. Uh,
think of them as quality control. We
call them intent checks at IP Fabric.
Now, these intent checks generally speak
to a violation of compliance in the
infrastructure. And if I scroll down
here, we can see we have a very simple
one we can talk about. Uh this would be
NTP configured sources, right? So here I
have 45 devices in my network that do
not have NTP configured. I can click on
that 45 and I’ll get taken to the table
that houses that information. All right.
So, we’re on our NTP table and we have
the 45 devices here that do not have NTP
configured correctly. What I’m going to
do is come into this filter option and
actually create my own filter to use in
an automation playbook or runbook.
Right? So, what I’m going to do here is
first get rid of any devices that are
part of a cloud construct. So, let’s get
rid of anything that is in AWS. So,
we’re going to get rid of those.
And then we want to see only our
synchronized sources where the value of
synchronized sources is less than or
equal to zero. Right? If we have it
configured and it’s working, great. We
want to focus on the ones that are are
having issues. So, I’m going to press
add rule here. I’m going to go to this
synchronized sources column and I’m
going to pick ones that are less than or
equal to zero and apply that filter. And
here we see our four network devices
that are either misconfigured or don’t
have NTP configured at all. Now with IP
Fabric, you get this ability to pull
this information right over a very
simple API interface. On every single
table, not just the NTP table, you’ll
have that table description button that
I just clicked on. And you’ll see the
filter is applied here. And the API we
need to fetch this information is right
here as well. So if I wanted to request
this data, all I need to do is pass this
into a Python script or an Ansible
playbook and utilize these four elements
as a dynamic host to actually run out,
configure these elements, update them,
and complete my automation. Right? Most
of the issues that I see when it comes
to getting started is having this
dynamic inventory of devices to perform
automation against. All right. So once
you’ve ran that playbook, we’re going to
see here again IP fabric snapshotbased
tool. I can flip between snapshots two
different moments in time. And you can
see I have this table filtered down to
where the synchronized sources is read.
So a device has a configured source, but
it’s not synchronized, meaning it’s not
communicating to the NTP source that’s
configured on this device. As I flip
through the snapshots, you can actually
see the amount of devices that have that
are in violation that have this intent
check red, right? They change over time.
So, this is closing the automation loop.
So after you perform your playbook, your
runbook, whatever you want to call it,
your automation, actually validating
that that automation indeed took and ran
successfully, you can actually validate
that piece here by seeing the decrease
in the overall amount of red in this
intent check. And same goes for all the
rest of the intent checks, the 150 built
into the platform today. So, as things
change, so if I flip through the
snapshots here, you’re going to see
these values, these red values change,
this is closing the automation loop for
whatever playbook or runbook that you’re
running and actually gives you a
validation piece and that is
traditionally missing today in most
network infrastructures. Most people run
automations, they don’t have a way to
validate that it actually ran. And IP
Fabric provides that validation piece uh
automatically right out the box. Right.
All right.
Moving on to AI. When it comes to AI,
it’s a it’s pretty big word word that we
hear all throughout the industry today.
Over the past few years, AI has been
brought to our attention, brought to
everybody’s interface every day. And if
you’re not using AI every day, um, you
know, it’s pretty amazing how much it’s
infiltrated the infrastructure or the
organizations today, right? IP fabric
gives AI this context that most other
systems are not able to to give, right?
Uh, again, IP fabric is a snapshot based
tool. So I have two different moments in
time here. And that allows AI to have
context to how the network was
configured at specific time intervals,
right? Um, as things change, we simply
want to ask, you know, our data, what
has changed over time. So if I go over
here to the technology routing routes
table, there’s a lot of data in this
table that if a a human had to go
through manually or even write code to
autonomously go through this data, it
requires a specific knowledge in order
to even understand what data points you
have access to and what the deltas of
those data points even represent in the
network. So being able to speed that
process up by talking in human text,
right, in human format to a chatbot and
just asking what has changed over time
is the goal we’re trying to achieve
here, right? When it comes to AI,
feeding data points that actually have
context is critical here, right? So I
have a chatbot here communicating with
IP fabric and it knows about the
different points in time or the
snapshots that it has access to. Right?
I asked it basically what snapshots do
you know about and it spit out you know
it knows that this snapshot here
represents the sixth this snapshot here
represents the fifth. And if we go back
to our UI here we can actually see those
four snapshots loaded as well. Now if I
ask it what has changed between route
tables, we can actually you know
communicate that to this chatbot in a
very human friendly text, right? So tell
me about the route table and what has
changed
between
these two snapshots.
So, we’re going to tell it, tell me the
delta between this snapshot here,
right?
And maybe this snapshot here.
So, we’re going to ask the chatbot
pretty simple question. What changed
between those two days? We’re going to
see our question pop up here.
The AI is now thinking. And if we look
at the back end, we can see it actually
sending a bunch of requests over to IP
Fabric
and it’s doing its thing. It’s going to
take some time. It’s a lot of data that
it’s got to process through and
understand and eventually we’ll be given
a pretty good summary of what’s changed
between those two specific snapshots or
those two moments in time. I think this
is critical going forward in terms of
utilizing an AI interface to understand
the vast amounts of data that’s
available inside of IP fabric. So we can
actually see some data points really
haven’t changed much. You have maybe 400
added routes between these two
snapshots. We have some info about what
VRFs were deployed between these two
snapshots. We can actually see some
modified routes. for example here as
well. So when it comes to AI the most
important thing is providing it context
about specific moments in time so you
can ask these simple questions. All
right. So, in this video here, we talked
about AI automation, how important it is
to feed contextdriven insights into your
automation, into your AI. And if you
have any more questions, please feel
free to reach out to your IP Fabric
solutions architect, your partner
manager, your account manager, and we’ll
get back to you as soon as we can.