5f8efa7579
Companion piece to the AIOps blog series, covering discovery/snapshots and initial use cases (topology, intent checks, path lookup, snapshot diff, Python SDK/MCP server). Structured as a living document for future additions.
80 lines
6.8 KiB
Markdown
80 lines
6.8 KiB
Markdown
---
|
|
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.
|
|
|
|
[[CAPTURE: IP Fabric dashboard overview]]
|
|
|
|
## 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.
|
|
|
|
[[CAPTURE: snapshot list / discovery settings screen]]
|
|
|
|
## 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 is confidently wrong, not cautiously uncertain.
|
|
|
|
[[CAPTURE: IP Fabric topology diagram of the lab]]
|
|
|
|
### 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.
|
|
|
|
This is where 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.
|
|
|
|
[[CAPTURE: intent check results table, colored pass/fail]]
|
|
|
|
### 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.
|
|
|
|
[[CAPTURE: path lookup diagram between two lab hosts]]
|
|
|
|
### 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.
|
|
|
|
This is the practical answer to "what actually changed," which is 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.
|
|
|
|
[[CAPTURE: snapshot diff view showing added/removed items]]
|
|
|
|
### 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.
|
|
|
|
[[CAPTURE: MCP server tool list or example agent query]]
|