Blog For decades, network operations teams have followed a single mandate: run a network the business can depend on. This hasn’t changed much over the years, but what has changed is the level of complexity.
Modern enterprise networks are always in flux, with near-constant updates across data centers, cloud platforms, SaaS services, and edge environments. All together, this infrastructure powers the applications and services that keep the business running. But if you lose track of a device here, or a dependency there, it gets increasingly difficult to maintain an accurate understanding of what’s actually going on in your network.
Even the most experienced engineers can’t always predict how a given change will impact the customer experience. But there is a way to know—and it starts with better network visibility.
Transcript
I wanted to show you something, some
experiments we’ve been doing on using
MCP as an interface into IP Fabric’s
data to really enable some interesting
use cases very much focused on the kinds
of things that you do or I do as a
network engineer. I’ll very quickly buzz
through the first one. We’ll talk about
root cause analysis. Now, what we’ve got
here is a situation with IP Fabric where
over two snapshots, we’ve got a path
from a host to uh AWS, and it’s changed.
Something’s changed uh during those two
paths. One one time it was going this
way towards this firewall and out. The
other time it’s going uh as you can see
down here into the MS network and across
means that the routing’s changed between
the two and we’ve got all the
information. But rather than dig into it
yourself to go find out, what we can do
instead is ask um ask Claude to help us
out here. So if I just switch this to uh
show you what I’ve done with Claude.
Claude is is now attached to an MCP
server which is hanging off the back of
IP Fabric and it’s able to query the
information and then reason about it. So
I’ve set up a prompt here as you can see
said that this these two devices are in
the network one’s on prem one’s in the
cloud some change has happened a
particular date go find out what
happened and so what it’s actually done
here um if you if I just quickly scroll
this through you’ll be able to see that
it’s got the information about the two
snapshots it’s traced the path in the
two similar to what we saw in the uh
visualization before but then it
actually looks at the reasons why that’s
happened. So it looks at the routting
tables on the devices,
understands that there’s the change,
identifies what that change is, and it
digs into the way that that change has
echoed through the network and
summarized it. Right? So it’s actually
produced an output here which
essentially says that route is
propagated from AWS through um BGP into
a firewall into OPF and it’s understood
all of that and it’s produced me a
report and that report details all of
the information that’s been used in
order to gain uh an understanding of
what’s happened. And what it’s done is
created me an executive summary as you
can see. And then down at the bottom
here, it’s given me some
recommendations, reviewing
redistribution policy, looking at the
design intent, consider root
summarization. So, it’s produced here a
report that basically is is um giving me
that root cause analysis that I’ve been
looking for.
That would have taken you or me as a
network engineer uh several hours to get
to the bottom of. And because we have
the data in IP fabric and because we can
expose it the right way, Claude is able
to do this for us in minutes.
If this is interesting um and you’re in
Amsterdam this week, go and see our team
um at Cisco Live. It’s in booth B 04 in
the world of solutions. They can show
you this and other examples like it of
things that you’re be enabled to do
using the unique data set that’s in IP
Fabric’s digital twin.
See you there.
Learn more about IP Fabric’s enterprise-grade MCP server.
Demand More From Your Network Data
When a NetOps team feels like they’re losing control of their network, automation is often their first attempt to fix it. They’ll take a “divide and conquer” approach: automating what they can, so they have more time to work on what they can’t. This strategy is sound in theory, but in order to succeed, they need to build automation using the right data. And so, we’ve circled back to our original problem: not having an accurate understanding of the network.
The same concern extends to AIOps. AI agents, like humans, need the right data to get the right result. Is your data consistent? Is it complete? Is it up to date? If you answer “no” to any of these three questions, your AI agent is as likely to make mistakes as any human employee.
Transcript
AI does not magically fix bad data. So often times in our modern environments, we’re dealing with multiple vendors, whether those are on prim in the cloud, different vendors for routing, switching, wireless, uh, firewall. So
what we end up with is with a hodgepodge of tools oftent times with different gooies for management, different operating systems, and even different APIs, logs only show a small portion of the picture. Whereas with IP Fabric or network snapshots, you’re getting a complete view of how that network is architectured, configured, and operating. Our mission at IP Fabric is to democratize your network data. We try to empower everyone in the organization, whether they’re admin, engineer, automation engineer, AI developer. We try to democratize that data so they all can have that power to do that automation and make those consistent decisions and understand their network infrastructure.
Learn more about how to build for network automation and AI with IP Fabric.
Close the Network Visibility Gap
The shift from manual operations to automation—and eventually, to autonomy—is a progression that requires a continuously updated understanding of the network. AI agents act on context. If that context is trapped in people’s heads, the AI agent’s output will reflect that.
This is where network digital twins come in. Rather than cobbling together a patchwork view from spreadsheets and fragmented tooling, organizations can trust a network digital twin to be an authoritative simulation of network behavior at a given point in time. Better yet, it’s modeled in structured data so it can serve as a common cognitive substrate for human engineers and AI agents alike.
When your teams and tools are all informed by the same source of truth, it builds a foundation for more reliable and resilient operations. In other words, this shared visibility translates directly to lower risk—and cost—over time.
Transcript
Hi, Darren Fwell from IP Fabric here
again um with another example of some of
the work that we’re doing with our
experimentation around MCP and exposing
IP Fabric’s knowledge and insight of
your network. Um what we’re doing here
today is we’re looking at a design
validation. So, as network engineers,
obviously we’ve all seen many network
design documents containing tables that
look something like this. Um, in this
case, you’ve got information here about
layer 2 connections between switches.
You’ve got layer three connections and
their IP addresses. You’ve got the the
gateway settings, and you’ve got the uh
VRP configuration information, for
example. You could have a bunch of
things here, but what we want to be able
to do is um go to our network and
validate that actually the network has
been deployed the way you would expect
it to. Now um as you can see from our IP
fabric snapshot here, we have
information about that location
is that you can already see there are
things missing obviously with the
resilience back back here in the
switches and that firewall there the the
VPN firewall clearly um isn’t connected
to anything. So what we’ll do is we’ll
just have a look at the the next
snapshot which shows um what happens
once some changes have been made. And
now you can see my firewall is connected
to the rider network. It’s also
connected out to AWS here. Um and I’ve
got some um connections as well, some
redundant connections from uh my
switches out here which I didn’t have
previously. So all good. But are they
configured the way that we need them to
be? Well, what I’m going to do, I’m
gonna te get someone to go and answer me
that question without me having to do it
myself. Um, let’s uh switch across and
show you what we asked uh Claude to do
for us. So, Claude is connected via MCP
to our IP fabric snapshot. Um, and what
we’re going to do is we’re going to ask
it to validate that design uh has been
implemented as expected. the layer two
uh layer three the uh first stop
resolution protocol is all configured as
it should be and that everything is
connected to the right interfaces and
then we’re going to ask it to to
basically summarize that for us and uh
and and tell us what needs to be
remediated.
So it takes the information from the
snapshot. It takes which it’s you can
see it’s found here. You takes the
information from the spreadsheet and
starts querying IP fabric in order to
validate the switch ports, the IP
interfaces, the VRP config and the
neighbor topology. And some really
interesting um detail here when you dig
into it. Um and here you can see it’s
actually completed the analysis. Um it’s
shown that these are all the trunk
links. It pairs those against the uh the
which port configs.
Um it’s gathering information here about
which ports are connected to which and
so on. Going through and doing lots of
validation. You can see lots of ticks
here, some crosses. Um you can see it’s
checking all kinds of information and
then it’s got all the data it needs. So
let me open the resulting report.
that comes from that. And it was
this one, the Paris 1x validation
report.
And if I open this one up, you can see
that it’s actually put together in
markdown a full report of everything.
And it’s saying here, Paris 1x has been
validated against the design spec. Um,
layer 3 infrastructure and SVI are
correctly implemented, but there are
significant discrepancies in layer 2 and
in the VRRP config. and it proceeds here
to to detail all of those here for you.
So, here’s your tables with the
information in um what’s good, what’s
bad. Um you can see VRP, everything’s
the group numbers are all incorrect and
so on. But what it also does is adds our
remediation actions for us. We didn’t
even ask it to do that. Uh but you can
see here the Arista config for those
switches in order to go fix that
information and a little summary at the
bottom here to state the the percentage
of compliance as well. So all of that
done without any inter interaction with
me the user um it’s gone ahead and and
used its knowledge and understanding of
networking in order to produce that. Now
of course we wouldn’t take that
verbatim. We would of course check that
through, but you can see a significant
amount of time been saved just bringing
all that data together.
If that use case is interesting
um and if you’re you want to know more
about the the things that IP Fabric are
doing with uh MCP and you’re in
Amsterdam this week, go to to our booth
at Cisco Live, the World of Solutions
booth B04. the team are there um demoing
MCP and demoing um the solution as a
whole. Um just let them know I I sent
you. Take care.
Get a personalized demo of IP Fabric’s MCP server.
Build For Trust, Not Speed
Many IT organizations are racing to embrace shiny new tech, but the truly forward-thinking leaders are the ones taking a step back and focusing on the quality of their network data.
Once you’re confident in that data, it’s also important to think strategically about where AI makes the most sense in your network. Your infrastructure may vary in its complexity, with different areas carrying different levels of risk.
Think of it as a “crawl, walk, run” approach. By earning confidence in lower-risk areas of the network first, your team can get the evidence you need to expand automation further—along with the judgment to know where not to.
Settle In For the Long Game
Autonomy isn’t a feature you switch on; it’s a destination you build toward.
For decades, the job was simple: keep the lights on. That job has quietly become something far more demanding, and AI tools can only help if they’re built using data that’s current, complete, and consistent.
The teams that figure this out early will gain something you can’t buy: the confidence to make changes quickly, knowing the network will behave the way they expect it to.
This article was originally published in TechIntelPro.