IP Fabric Partners With Illumio to Unify Cloud, Network, and Application Visibility

I can tell there are 127 Phantom devices. Those devices that are in the CMDB but not actually in production anymore. For an enterprise access switch, it’s about $5,000. So, the the maintenance fees could be anywhere from $500 to $1,000 per year. We might be paying maintenance fees on those. Um, you know, often the vendor expects us to kind of true up at the end of the year. This is how I can know I’m chewing up uh in the right way. Um, 30 missing devices. So the opposite problem where I have uh devices that are in production that aren’t in my CMDB. So they’re ghost devices or documentation wasn’t updated. And then this last part is um we have puty changed devices meaning they’re in both the CMDB and in the IP fabric discovery, but the configurations are different. Right? We’ve matched the serial numbers, but maybe one is matching my my security policy and one
is not. Hopefully, you know, the the production is matching our security policy so that we’re not, you know, nervous about a data breach. Um, but we should know about these things, right? And so that’s just a a quick uh demo to show you how this this happens in real time and how real numbers get attached to this type of inventory

Every network change is a bet. You’re
betting that the topology you think you
have is the topology you actually have.
You are betting that redundancy you
configured two years ago still works the
way you expect or that a root change
here won’t cascade into something ugly
elsewhere. In most organizations, that
bet is underwritten by one person, your
most experienced network engineer,
mentally simulating whatif scenarios
against a version of the network they’re
carrying around in their head. It works
until it doesn’t, and it definitely
doesn’t scale when you’re staring down
an integration or a cloud migration with
a hard deadline. Here’s how we approach
it with IP Fabric’s MCP server. We start
with a prompt available in our prompt
guide linked near this demo that defines
a specific traffic path. The path is a
source and destination address and the
snapshot. That snapshot is verified
model of the entire network as it exists
right now, not as it was documented 6
months ago to provide more realistic
whatif scenario. The model runs a full
path lookup query in IP fabric and maps
the response every hop, every site,
every ECMP branch along the way. It
identifies the first hop gateway then
queries the first hop redundancy
configuration to surface the peers
priorities preeemption settings and
whether both gateways share symmetric
uplinks and routing tables. Then it
builds the whatif. What happens if that
primary gateway fails? The report lays
it out in a two column comparison.
Current path versus failover path with
the changed hop highlighted so you can
see exactly where the switchover occurs
and confirm that everything else holds.
You get a failover timeline, detection,
transition, convergence, recovery with
expected timing for each phase. and you
get a risk and recommendation section
that flags gaps. Maybe there’s an
asymmetric uplink or maybe a single
point of failure the team hasn’t
accounted for. The whole thing is
delivered as a structured portable
document or any format you like.
Executive summary with stat cards at the
top, detailed gateway redundancy
configuration tables, the full scenario
analysis and a remediation table at the
bottom. For architecture teams planning
a major change, this turns weeks of
manual analysis into a repeatable
evidence-backed workflow. For IT leaders
who need confidence before signing off,
it’s the difference between we think
it’ll be fine and here’s the proof.
Network confidence shouldn’t be a gut
feeling. With IP Fabric’s MCP server,
it’s a verified fact built from your
actual network at the moment you need it
with the evidence to back every decision
you make

When an outage first hits, of course,
the first question we all ask is what
changed? Device by device, hop by hop.
That’s what drags out meanantime to
repair, MTR, right? In manufacturing,
Seammens puts unplanned downtime
anywhere from 39,000 to 2 million per
hour. Uh, one customer of ours actually
saw their MTR drop from hours to just
about 30 minutes once they had accurate
uh, end-to-end visibility into paths,
dependencies, and config and state,
right? Saving millions in avoided
downtime. In finance, of course, trading
and payments, time is literally money.
Um, McKenzie actually estimates
settlement processing delays cost $1
billion per year. Um, one of our
customers actually cut their MTR by 98%
taking a six-hour interruption down to
just minutes and therefore reducing both
their operational and financial risk.
And of course, in healthcare, downtime
isn’t just about lost revenue. It
impacts, you know, delivery of care. So,
Ponan estimates that downtime cost at at
a clinic is about $7,500 per minute.
Outages can of course though disrupt
EHR, imaging, labs, monitoring, right?
Where where reliability and and delivery
of care ma matter just as much as cost.
So the pattern is always the same. If
your data is wrong, your MTR is long.
And when teams can see the real state
and configuration and dependencies in
the network, those outage outages
actually shrink dramatically.

All from IP Fabric.

Welcome everybody for the webinar about
a security audit uh with IP Fabric in
under an hour. Uh welcome everyone. Uh
my name is Milan. I’m from IP Fabric
solution architect and with me uh here
is Christian.
Hello I’m Christian also solution
architect here at IP Fabric and welcome
to our webinar. Happy to show you
around.
Yeah. So uh let’s get started.
So about the IP fabric very very shortly
because uh for those new to IP fabric uh
think of us as uh creating a digital
model of your entire network
infrastructure. We automatically
discover and map the state of every
device connection and create context.
And we we also capture configuration and
state data across your environment
whether it’s on premises in the cloud or
hybrid.
Unlike uh traditional monitoring tools
that only show you what’s happening
right now, IP fabric gives you a
complete understanding of how your
network is designed, configured and
behaves. Uh this comprehensive
visibility becomes the foundation for
everything we will discuss today about a
security and compliance. And uh Mur says
that maybe nine out of 10 CIOS like a
unified view of their infrastructure
which opens organizations up to breaches
and compliance issues. And with IP
fabric we are trying to solve this
fundamental challenge.
IP fabric transform uh network security
by giving you unprecedented visibility
into your security posture. At first we
automatically collect and analyze all
your management protocol configurations
like uh AAA settings S snp community sys
configuration giving you a complete
protocol inventory for device hardening.
Uh think about that way that management
protocols are the ultimate gateway to
your network infrastructure. Uh as
second our platform can simulate network
path end to end showing you exactly how
the traffic flows through your network
including your ACL and we also
understand the security policies that
will affect the traffic or policy based
routing rules. This means that you can
test the security before changes or
changes before implementing them or
validate your segmentation whether is
working as intended and identify
potential security gaps. All of this
discovery data becomes intelligence that
you can leverage for the network
hardening and finding the weak points or
ensuring consistent security policies
and proving compliance with security
frameworks becomes very very standard
and easier to achieve
in the version 7.2 uh which is the main
focus uh throughout this webinar. We uh
significantly enhanced our firewall
capabilities. Uh we now can provide
detailed simulation of uh next
generation firewall behavior including
URL filtering rules and thread feed
configurations. And [snorts] this is
crucial because modern firewalls do much
more than just allow or deny traffic
anymore. Those are not just expanded
ACL. They are making complex decisions
based on application awareness and URL
categories or threat intelligence. IP
fabric now collects data directly from
your firewalls and can simulate this
behavior in our digital twin. And we’ve
also added support for transparent
firewalls. Uh those security devices
that organization often lose track of
because they don’t change IP address on
routing uh by by design. Uh in the
version 7.2 two, we provide uh detailed
mapping and documentation of uh IP
signals as well which are crucial for
understanding how data are encrypted uh
in secure communication channels as is
required by the frameworks like uh ISO
or regulations like Dora or these two.
And thank you for staying with us uh
throughout this brief uh presentation.
And now I I would like to pass the word
to Christian who will show you some very
concrete examples in the way how you can
achieve your goals uh with the current
version. Thank you.
Yeah, many thanks Milan.
[clears throat]
Um and I would like to start to talk
about the enhanced
[clears throat] intent checks. So
basically um in the in the past um an
intent check was always based on a
specific uh table. So you could select
um columns of the table and um define
specific entries um yeah as a success or
as a warning or as an error. Um but
sometimes this was not enough. Um
because sometimes you had that
information okay um I have SNM SNMP
configured ACL is not empty that’s great
but just as an example if you want to
understand on which kind of device do I
have it or um do I have it on specific
types of devices where I’ve added some
attributes to it. um it was not possible
to do. This is now doable. So if I
scroll down um as you can see I can now
select a different uh or additional uh
uh information from the device table or
in this case also add a device attribute
and now um it will match this only
against devices which contain the
attribute I specify here. Let’s say I
put in ABC if that is the name of the
attribute. And now I can say if it
contains [sighs]
uh the word uh checkpoint as an example
um then uh it will show me uh or it will
mark only the devices with that
attribute and where the access control
is is not empty as successfully
configured devices. All the others will
be placed into other or no category
depending on how you continue to
configure your intent check. But this
gives you un uh unprecedented uh uh
freedom to really build intent checks um
in a higher accuracy um and get the data
you want to have.
by the way uh for for yeah for for those
who uh are not really familiar with IP
fabric what we are achieving right now
is that first the attributes are labels
that you can assign to devices based on
your own logic or principles within your
CMDB or your organization and uh to be
able to filter by the device vendor
platform or even operating system wasn’t
possible in the previous releases and
it’s basically we are cross referencing
the network inventory data
with any table or information about a
technology that we collect in IP fabric
and we are combining with the intent
rules. So whether you are applying a
specific rules just to certain
categories of devices based on your
labels, it’s right now doable or whether
you are applying your rules based on a
specific vendor or site, it’s also
available right now.
Thanks for this addition. Okay, let’s
now take a look on how we can visualize
uh the IPC tunnels. Um, of course, we do
have a table where you can see all your
IPs tunnels, the state of your tunnel,
is it up, is it down, which encryption
are you running and all of that, but um
in the past it wasn’t possible to see
them in the diagram. And um I’ve chosen
this diagram where you can see quite a
few firewalls. And now I would like to
show you how quickly and easily you can
show inside the diagram. Um where are my
IPs tunnels so you can visualize them.
Um and I’m just removing layer 1 and
layer two information. uh ungrouping the
layer three uh information as it’s
usually condensed into uh uh one single
line inside this diagram. And now I’m
selecting the IP sec tunnel. So I just
want to see where are my IP SEC tunnels.
I don’t care about the routing
protocols, the default gateway uh and
all of that. I just care about the IP
stack tunnels. And when I click the
submit button, he shows me I have here
my IPSec environment. So I can easily
spot where are the interconnections
uh which firewalls are using secure
communication
uh t uh uh and and tunnel the data um so
I can really um understand where do I
need to expand maybe my IPSec
environment my VPN environment or maybe
where are the where are tunnels which
may be of no no use probably uh and
which can be removed.
[clears throat]
Yeah. Uh by the way, for those who are
not familiar with the previous versions
of the IP fabric, just to clarify, we
already collected in the past
information about the IP6 tunnels and
the gateways. It was already present in
our technology table in a in a very
great detail. Uh the the what’s changed
right now is that uh before 7.2, two, we
were not creating the logical connection
in the map in the visual topologies
which right now we enabled in 7.2
version.
Yep.
Okay. And now let’s take a look at um
how we work with or take a look at our
enhanced firewall capabilities. So um in
the past we had this if you wanted to
check can I reach the the internet um
using https you enter source any
destination in this case I just use the
DNS of Google to simulate an IP address
and you click the submit button and you
see the path okay I’m hitting the
internet um the firewall is letting me
pass all is good but what if you have a
URL filter um and you want to understand
are specific URLs reachable or not. So
um and in this case we added this
functionality. So now you can work with
site categories and or URL or domains
and if I use just as an example this URL
if I get to it. So I didn’t change
anything at source or destination or the
protocol. I just added this URL and now
if I hit the submit button I get a
different result. So the firewall is
blocking that URL. It’s not let letting
me pass through even though the protocol
is the same. Nothing has changed. Um and
if I need some details again I can use
the
path inspector which is uh uh
automatically uh showing you um which
data are we using as source destination
and all of that uh including also the
routting information but also which
firewall rule has been hit and clicking
on it shows me the firewall rule so I
can understand what’s going on um and
therefore uh why is my traffic blocked
or not? And let’s do the test. If I
change the URL
[clears throat]
to a good URL
and hit the submit button again, I get a
different result. Zooming out. So um
it’s really focusing on the URL which
has been entered and which is not
allowed to be accessed.
[clears throat and cough]
I think this shows quite well um how we
uh have incorporated this into our
solution and of course if you want to
work with categories you can also work
with categories here.
You want to add something Milan or are
we good? uh notice not this point. Thank
you Christian. But the only thing may be
that uh in the previous versions we
could understand very well uh this
simulation from source to a URL as a
destination. In that case we had to be
able to match the URL to to a specific
destination IP. But we were completely
unaware of any rules that include the
URL filtering and with the 72 version
that changed.
Yep.
Okay. And now let’s uh create a or let’s
give a small sneak peek.
Um so what’s uh also um what also is
already added to IP fabric is the
creation of manual links which allows
you to incorporate your layer 2
filtering um into our solution. And as
it’s usually not that easy to discover
it and uh place the devices, a
transparent firewall is a transparent
device obviously. Um so we uh have built
in this uh feature that you can add
these devices and the links to it um
manually. So you select the device you
want to have and as you can see I’ve
already prepared something but just to
show you quickly you select the device
you want to have you select the
appropriate interface you define is it a
layer 1 or layer 2 connection which is
present and after you have created this
link you run your snapshot uh we will
discover uh the device and then also
incorporate this incorporate this link
um into the um view and again I’ve
prepared it already. So the link I’ve
created manually um and I didn’t want to
torture you uh watching a snapshot being
taken. So everything is prepared here.
You can see that’s the manual link I
have entered. So it’s visualized. You
can now understand okay where uh is my
transparency hiding basically. Mhm.
Yeah. U maybe a little clarification why
this is a little sneak peek because uh
we can already discover transparent
firewalls uh starting version 7.2. Uh
let me say this transparent firewalls
are always a challenging environment and
they have uh their own goals of course
you know there are IPS gateways and they
have other functions and they’re
essential in some places. uh we have a
great discovery engine but for us even
for our great discovery engine they are
hard to discover they’re they’re hard to
understand especially uh the way how
they connect to other environments if
they are connect to ACI leaves or other
environment they require some IPS
filtering. We thought a long time uh
about how to resolve that issue and how
to understand what interfaces of the
transparent firewalls are in in reality
connect to our environment and we came
out with a concept of uh creating the
manual links. Uh there are two types of
manual links. one is layer one which
will only appear as a map on a map like
a standard like CDP or LDP connection
with no real traffic functionality and
then we can also create a layer two
links that will help us uh to really use
the transparent firewalls as uh uh
throughout the traffic path simulations.
So that’s for the future. uh it will be
available starting version 7.3 which is
going to be released I would say quite
soon and since then you will be able to
to discover your transparent firewalls
you’ll be able to create connections to
your environment and use them uh for the
path simulations as well which is the
ultimate goal
yeah and I would like to and uh I’ve
just seen Meline already put it in the
chat but um If there are any questions,
feel free to submit them in the Q&A
section. Um, and I see um a question,
are compliance checks a point in time or
are they continuously monitored? So um
our compliance checks are based on the
intent checks and the intent checks are
applied on every snapshot. So whenever
we discover a network, we gather all the
data. We apply the desired state of the
network and match it against the state
that we just collected and show you
where there are mismatches or where you
need to improve um your network to be
compliant and where are you already
successfully uh uh um yeah matching the
requirements of any given regulation
being list 2 being a DORA uh PCI, you
name it basically. And as you can create
now even more powerful uh uh checks,
intent checks, this gives you even
better detail in regards to compliance.
So let’s see.
Okay, I see there’s another one
in the Q&A section.
[clears throat]
Milan,
yeah, I see I see the Yeah. Yeah, I see
the question. Uh can IP fabric handle
automated path simulations over tunnels
when there are multiple sources and
multiple destinations at scale? Well uh
that’s a great question. Thank you for
that. So the way the IP fabric operates
uh is that you can use the UI and of
course there’s a limit because if you’re
a UI user you can only at a certain time
you can only simulate one thing or you
can open multiple tabs and uh simulate
many things but that doesn’t scale
really well. What our customers are
sometimes using is that they are
leveraging our API capabilities because
anything you can do in UI in terms of
task simulation, data extraction and so
on, you can also operate over API and
the API skills very very well. So we
have use cases where uh a customer
wanted to test if the firewall was
implemented correctly which means the
test included uh 50 or it can be 200
different sources. there was one certain
destinations and they they wanted to
verify that all the 200 simulations were
always traversing the firewall with the
exact source uh interface and
destination interface and uh to to be
using the correct policy. So they
leverage our API capabilities. They use
it over the API and they simulated 200
different simulations over API and got
the result within couple of minutes uh
by using our engine. So it can be it can
be pretty quick. So yes, uh the API
simulation can scale very well, but you
need to leverage our API.
Mhm. And there’s another one. Um will
there be selectable example intent
checks such as the ones you had in mind
when developing this or are supposed to
dream up how to utilize these new
features in the best way ourselves? Um,
as we are usually supporting you with
our customer success team, of course, we
will support you in developing the right
intent checks for your purposes. Um as
these enhanced capabilities especially
when it comes comes to the attributes
we can’t create some preconfigured
attributebased
intent checks as these are really unique
to your environment. Um so it will be
very hard to create something up front
but we will always support you our
customers in enhancing what they have um
using uh of course the knowledge we have
as we are really um working together
with you and of course um also showing
you how to use it, where to use it,
where does it make sense, what’s the
experience we see and stuff like that.
So um you don’t have to dream them up
yourselves. We will support you in
building them.
Yeah. [clears throat] Uh thank you
George. I I would only maybe uh add uh
other other part for it. Uh the the in
rules we saw in the in the presentations
was the was specifically related to to
the attributes or to the capability that
we can now use attributes uh as an
additional filter in the intent checks.
Uh however there are already like more
than 100 plus best practice intern rules
inside e fabric by default but the
attributes are are a little bit special
because uh attributes are as Christian
pointed out they are a very specific
thing for every environment because
every customer defines their attribute
uh differently. So it’s a custom thing.
[snorts] However, what I would recommend
is not really uh try to uh think about
the attributes or providing multiple
intern rules based on the attributes in
the UI. what what we are always
recommending is to create a set of rules
outside of IP fabric uh on a on a places
like Git where you can really think
about how to uh think about uh of
programmatic compliance and from there
you can easily pick up the rules and you
can leverage that and populate all the
attributes and all the intent rules into
IP fabric over API from the source of
your uh compliance programmatic uh
database. So that’s the the way that we
are trying to uh promote is that every
customer first create their own concepts
of the compliance and their own rules uh
let’s say you know on paper or on git
and then programmatically pushes that
through to IP fabric uh which allows for
more u manageability I would say
uh for the second question which I’m
seeing from from Desmond Chan thank you
for that uh the question is can we
define a generic router or gateway that
is not being supported by app fabric. Uh
unfortunately uh I I know where it’s
coming from. We can right now create a
manual link which in fact is not
generated by discovery. So uh you may
think that we can also add a devices or
we can add a concept of adding virtual
devices or gateway that are uh in fact
not available uh in the snapshot.
Unfortunately, uh this is not possible
as of now, but uh possibly we will think
about it in the future. Thank you for
that.
And there’s another one. Are there
published examples, white papers of
utilizing the API for mass testing the
firewall rules? As you referenced
earlier in the Q&A answer, I’m curious
to know more about that.
Yeah. Uh great uh great question. Thanks
for that. Uh we we have examples uh
internally uh based on our interaction
with our customer. Uh unfortunately
there’s no white papers yet. Uh but uh
we can always uh we are happy to share
that information once we form formalize
uh that uh or those scripts that we used
with the customer. So it doesn’t contain
any code that we we cannot share. But uh
uh long story short, we are only really
leveraging our SDK to do that and uh all
the documentations
and our SDK is uh available online. But
in any case, uh feel free to get in
touch and uh we can we we’re more than
happy then uh follow up on that. It’s
it’s not that that complicated.
Okay, I would say let’s wait another
minute or two um if some questions come
up. [clears throat]
Okay. Um let me start the wrap up or or
the way you say it. Uh again, thanks
everybody for participating. Uh thanks
everyone joining the webinar and uh
listening. Thanks for for the question.
Uh thanks to Meline uh who uh made the
webinar possible. Um thanks to
Christian.
Yeah, many thanks from me 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.