---
title: "IP Fabric"
date: 2026-07-20T09:00:00+02:00
cascade:
  type: docs
---

<!-- markdownlint-disable MD033 MD034-->

IP Fabric is the network discovery and assurance platform I run on my lab. It's also the tool sitting behind the phrase "topological source of truth" in my [AIOps and Network Observability series](/en/blog/aiops-observabilite-reseau-ia/) — this page is the technical companion to that series, gathering what I learn about the tool as I actually use it, rather than a one-off tutorial.

> [!NOTE] **Living document**
> I'm adding to this page as I explore more of IP Fabric myself. Expect new use-case sections to show up over time rather than a finished, all-at-once guide.

## What IP Fabric is

IP Fabric is a network assurance platform: it connects to your devices, pulls their configuration and operational state through the same CLI/API access you'd use yourself, and rebuilds a structured model of the network from that raw data — topology, routing tables, VLANs, VRFs, ACLs, and more. Official documentation lives at [docs.ipfabric.io](https://docs.ipfabric.io/latest/).

The distinction that matters most, coming from a monitoring background, is that IP Fabric isn't a telemetry tool. It doesn't care about counters, utilization, or time series — that's what a metrics stack is for. What it cares about is **state**: what's configured, what's actually running, and how everything connects. It answers "what is the network, right now" rather than "how busy is the network, right now."

That distinction is exactly why it slots into the "topology as source of truth" layer of the AIOps stack described in the blog series: an agent that needs to reason about the network needs this structured state before it needs metrics.

![IP Fabric dashboard with discovery statistics, vendor mix, and compliance reports](ipfabric_dashboard.en.png#center)

## How discovery and snapshots work, at a high level

IP Fabric works from two core concepts: discovery and snapshots.

**Discovery** is the crawl. IP Fabric seeds itself from a list of reachable devices (or a seed subnet), logs into each one over SSH/API, and walks outward via CDP/LLDP neighbors, routing adjacencies, and other protocol-level breadcrumbs to find the rest of the network. It parses the output the way an engineer would read a `show` command, and turns that into structured, queryable data.

**Snapshots** are the result of a discovery run, frozen at a point in time. Each snapshot is a complete, self-contained picture of the network as it looked when discovery finished — every table, every diagram, every intent check result, all scoped to that snapshot. Nothing is overwritten: past snapshots stay around so you can go back and compare.

That snapshot model is what makes several of the use cases below possible: because history isn't discarded, questions like "what changed since yesterday" have a direct answer instead of requiring you to have thought ahead and set up your own diffing.

![Discovery settings: IP scope, seeds, and advanced options](ipfabric_snap_config.en.png#center)

## Use cases

### Topology as source of truth

This is the use case that started it all for me, and the one referenced directly in the blog series. IP Fabric builds a topology diagram and a set of relational tables (devices, interfaces, neighbors, VLANs, VRFs) from live discovery, not from a manually maintained spreadsheet or a Visio diagram someone forgot to update.

For my EVPN/VXLAN lab, that means I have an always-current answer to "what's connected to what" without trusting my own memory or an out-of-date diagram. This is the layer an AI agent would need to query first, before anything else, if it's going to reason correctly about the network — which is the whole point of the "blind agent" problem from the blog series: an agent working off stale topology data answers with confidence even when it's wrong.

![Topology diagram of the EVPN/VXLAN lab, generated by IP Fabric](ipfabric_network_diagram.en.png#center)

### Intent checks

Intent checks are rules you define once, things like "no unused VLANs," "STP root should be on the core switches," "every access port should have BPDU guard" — and IP Fabric evaluates them against every snapshot going forward. Failures show up as color-coded checks you can drill into, all the way down to the specific device and interface that broke the rule.

Here, IP Fabric moves from "descriptive" (what's out there) to "normative" (is what's out there correct). It's a natural fit for the standardization principle I keep coming back to in the blog series: intent checks are a way to enforce naming and configuration consistency automatically, instead of relying on a human to notice drift.

![Intent check rules and their results, color-coded pass/fail](ipfabric_intent.en.png#center)

### Path lookup

Given a source, a destination, and optionally a protocol/port, IP Fabric simulates the forwarding path across the whole discovered network, hop by hop, including the specific routing/switching decision at each device — without sending a single test packet. It's a computed answer, from the collected state, not a live trace.

This turns "why can't this host reach that host" from a multi-device, multi-`show`-command investigation into a single query. It also validates security posture: a path lookup will tell you if an ACL or firewall rule blocks traffic somewhere along the way.

![Path lookup between two lab hosts, showing the hop-by-hop forwarding path](ipfabric_path2path.en.png#center)

### Snapshot comparison

Because every discovery run is preserved as its own snapshot, IP Fabric can diff two of them directly (one from before a change window, one from after, for example) and surface exactly what's different: new or removed devices, VLAN changes, routing table deltas, interface state changes.

That's the practical answer to "what actually changed," normally the hardest question to answer after an incident. Instead of reconstructing a timeline from memory or from scattered change tickets, the diff is already sitting there.

![Diff between two snapshots, with added and removed elements highlighted](ipfabric_snapshot_diff.en.png#center)

### Programmatic access: Python SDK and MCP server

Everything IP Fabric exposes through its UI is also reachable through its REST API, and there's an official [Python SDK (ipfabric)](https://docs.ipfabric.io/latest/integrations/python-sdk/) that wraps it into a more ergonomic client — pulling tables as pandas dataframes, running intent checks, triggering discovery, all from a script.

More relevant to the AIOps angle of the blog series: IP Fabric also ships an [MCP server](https://docs.ipfabric.io/latest/integrations/mcp-server/), which exposes the platform's data directly as tools an LLM agent can call. That's a fairly direct answer to the "making the network visible to an agent" problem the last article in the series is going to tackle — instead of me hand-rolling a wrapper around the API, IP Fabric already speaks the protocol an agent needs.

I haven't wired this up on my lab yet; that's future work, and future sections here.

![An agent querying IP Fabric through its MCP server to compare two snapshots](claude_mcp.en.png#center)
