IP Fabric est la plateforme de discovery et d’assurance réseau que je fais tourner sur mon lab. C’est aussi l’outil qui se cache derrière l’expression « source de vérité topologique » dans ma série AIOps et observabilité réseau : cette page en est le complément technique : j’y consigne ce que j’apprends de l’outil au fil de son usage réel, plutôt qu’un tutoriel figé.

Ce qu’est IP Fabric

IP Fabric est une plateforme d’assurance réseau : elle se connecte à vos équipements, en récupère la configuration et l’état opérationnel via les mêmes accès CLI/API que vous utiliseriez vous-même, et reconstruit à partir de ces données brutes un modèle structuré du réseau : topologie, tables de routage, VLANs, VRFs, ACLs, et plus encore. La documentation officielle se trouve sur docs.ipfabric.io.

La distinction qui compte le plus, quand on vient du monde du monitoring, c’est qu’IP Fabric n’est pas un outil de télémétrie. Les compteurs, l’utilisation, les séries temporelles, ça ne le concerne pas : c’est le rôle d’une stack de métriques. Ce qui l’intéresse, c’est l’état : ce qui est configuré, ce qui tourne réellement, et comment tout ça est connecté. Il répond à « qu’est-ce que le réseau, là, maintenant » plutôt qu’à « à quel point le réseau est-il chargé, là, maintenant ».

Cette distinction est précisément ce qui place l’outil dans la couche « topologie comme source de vérité » de la stack AIOps décrite dans la série de blog : un agent qui doit raisonner sur le réseau a besoin de cet état structuré avant d’avoir besoin de métriques.

Comment fonctionnent discovery et snapshots, à haut niveau

IP Fabric repose sur deux notions centrales : la discovery et les snapshots.

La discovery, c’est l’exploration. IP Fabric part d’une liste d’équipements joignables (ou d’un sous-réseau de départ), se connecte à chacun via SSH/API, et remonte le fil via les voisinages CDP/LLDP, les adjacences de routage et d’autres indices au niveau protocole pour découvrir le reste du réseau. L’outil parse la sortie un peu comme le ferait un ingénieur en lisant une commande show, et transforme ça en données structurées et interrogeables.

Un snapshot, c’est le résultat d’une exécution de discovery, figé à un instant donné. Chaque snapshot est une photo complète et autonome du réseau tel qu’il était à la fin de cette discovery : toutes les tables, tous les diagrammes, tous les résultats d’intent checks, circonscrits à ce snapshot précis. Rien n’est écrasé : les anciens snapshots restent disponibles, ce qui permet de revenir en arrière et de comparer.

C’est ce modèle de snapshots qui rend possibles plusieurs des cas d’usage ci-dessous : comme l’historique n’est jamais jeté, une question du type « qu’est-ce qui a changé depuis hier » a une réponse directe, sans qu’il ait fallu anticiper et bricoler son propre système de diff.

Cas d’usage

La topologie comme source de vérité

C’est le cas d’usage qui a tout déclenché pour moi, et celui référencé directement dans la série de blog. IP Fabric construit un diagramme de topologie et un ensemble de tables relationnelles (équipements, interfaces, voisins, VLANs, VRFs) à partir de la discovery en direct, pas depuis un tableur maintenu à la main ou un schéma Visio que personne n’a pensé à mettre à jour.

Sur mon lab EVPN/VXLAN, ça veut dire que j’ai une réponse toujours à jour à la question « qu’est-ce qui est connecté à quoi », sans avoir à me fier à ma mémoire ou à un schéma périmé. C’est la couche qu’un agent IA devrait interroger en premier, avant tout le reste, s’il doit raisonner correctement sur le réseau : c’est tout l’enjeu du problème de « l’agent aveugle » évoqué dans la série de blog, un agent qui travaille sur une topologie obsolète répond avec assurance, même quand il se trompe.

Les intent checks

Les intent checks sont des règles qu’on définit une seule fois, du genre « pas de VLAN inutilisé », « la racine STP doit être sur les switches core », « chaque port d’accès doit avoir BPDU guard activé », et IP Fabric les évalue automatiquement sur chaque nouveau snapshot. Les échecs remontent sous forme de vérifications colorées, avec possibilité de descendre jusqu’à l’équipement et l’interface précise qui enfreint la règle.

Ici, IP Fabric bascule du « descriptif » (ce qui existe) au « normatif » (ce qui existe est-il correct). Ça rejoint naturellement le principe de standardisation que je répète souvent dans la série de blog : les intent checks permettent d’imposer la cohérence de nommage et de configuration automatiquement, plutôt que de compter sur un humain pour repérer une dérive.

Le path lookup

Avec une source, une destination et, en option, un protocole/port, IP Fabric simule le chemin de forwarding à travers tout le réseau découvert, saut par saut, en incluant la décision précise de routage/commutation prise à chaque équipement, sans envoyer le moindre paquet de test. C’est une réponse calculée à partir de l’état collecté, pas une trace en direct.

Ça transforme un « pourquoi cet hôte ne peut-il pas joindre cet autre hôte » (normalement une investigation multi-équipements et multi-commandes show) en une seule requête. Ça permet aussi de vérifier la posture de sécurité : un path lookup indique si une ACL ou une règle de pare-feu bloque le trafic quelque part sur le chemin.

La comparaison de snapshots

Comme chaque exécution de discovery est conservée sous forme de snapshot, IP Fabric peut comparer directement deux d’entre eux (un avant une fenêtre de changement, un après, par exemple) et faire ressortir précisément ce qui diffère : équipements ajoutés ou retirés, changements de VLAN, écarts dans les tables de routage, changements d’état d’interface.

Ça donne une réponse concrète à « qu’est-ce qui a vraiment changé », d’ordinaire la question la plus difficile à répondre après un incident. Plutôt que de reconstituer une chronologie de mémoire ou à partir de tickets de changement épars, le diff est déjà là.

L’accès programmatique : SDK Python et serveur MCP

Tout ce qu’IP Fabric expose via son interface est aussi accessible via son API REST, et il existe un SDK Python officiel (ipfabric) qui l’enveloppe dans un client plus ergonomique : récupérer des tables sous forme de dataframes pandas, lancer des intent checks, déclencher une discovery, le tout depuis un script.

Plus pertinent encore pour l’angle AIOps de la série de blog : IP Fabric propose aussi un serveur MCP, qui expose directement les données de la plateforme comme des outils qu’un agent LLM peut appeler. C’est une réponse assez directe au problème de « rendre le réseau visible à un agent » que le dernier article de la série doit aborder, au lieu de coder moi-même un wrapper autour de l’API : IP Fabric parle déjà le protocole dont un agent a besoin.

Je n’ai pas encore branché ça sur mon lab ; c’est un chantier à venir, et de futures sections ici.