En bref

  • Batfish est un projet open source d’analyse de réseau sous licence Apache 2.0. Il traduit les configurations prises en charge pour les équipements, le cloud et le routage en un modèle commun, puis répond à des questions sur le comportement du réseau entier avant toute modification de la production.
  • L’analyse symbolique peut étudier de vastes classes d’en-têtes de paquets, de routes et de défaillances. Chaque résultat reste cependant conditionnel à l’exhaustivité de l’instantané, à la couverture des analyseurs, à la sémantique prise en charge et à la propriété choisie par l’opérateur.
  • Issu d’un travail présenté à NSDI en 2015, le projet est devenu un moteur activement maintenu, doté de pybatfish, d’une analyse différentielle, d’une modélisation du cloud et d’une couverture croissante de plateformes telles que SONiC, A10 et EVPN/VXLAN.
  • Batfish ne se confond ni avec Intentionet ni avec les produits commerciaux d’assurance réseau. Le projet ouvert peut déplacer certaines erreurs de la production vers la revue, mais la collecte des données, la formulation de l’intention, le déploiement progressif, la télémétrie en direct et la décision finale de faire confiance au modèle restent sous la responsabilité de l’opérateur.

Une modification anodine peut avoir un vaste rayon d’impact

Une modification réseau existe presque toujours d’abord sous forme de texte: route map, ACL, voisin BGP, règle de redistribution ou table de routage cloud. Même correcte localement, elle interagit en production avec les autres politiques, annonces, tunnels, valeurs par défaut, topologies et états de défaillance.

Batfish traite précisément l’écart entre configuration locale et comportement global. L’opérateur fournit un instantané comprenant les configurations et, selon le besoin, des indications de topologie, des routes d’exécution, des données d’hôtes ou l’état du cloud. Le moteur analyse la syntaxe prise en charge, la convertit en représentation indépendante des fournisseurs, calcule le plan de contrôle et les résultats d’acheminement, puis répond à des questions sur les chemins, les filtres, l’accessibilité, les politiques de routage et certains scénarios de panne.

Avec le client Python pybatfish, ces questions peuvent rejoindre le dépôt et le processus de revue où la configuration est préparée. Une fuite de routes, la disparition d’un chemin de secours ou une modification inattendue de politique de sécurité peut alors apparaître dans une pull request plutôt qu’après la fenêtre de maintenance. L’objectif n’est pas de remplacer l’ingénieur par les mathématiques, mais d’apporter à la revue un contexte réseau difficile à reconstruire entièrement à partir de fichiers.

Les résultats les plus puissants sont parfois qualifiés de preuves. Le terme n’est valable qu’avec ses limites: une requête symbolique d’accessibilité peut examiner l’espace d’en-têtes représenté par le modèle et démontrer qu’aucun paquet modélisé d’une classe donnée n’atteint une destination interdite, ou produire un contre-exemple. Cette couverture peut dépasser celle de tests manuels, sans rien établir sur un équipement, une route, une condition physique ou une fonction fournisseur absents de l’instantané.

Batfish n’observe pas non plus la profondeur des files, la puissance optique, la corruption de paquets, le comportement non documenté d’un ASIC ou une erreur applicative. Un résultat positif prouve donc une propriété dans un modèle précis, et non l’immunité de la production. Sa force réside dans la possibilité d’archiver l’instantané, la version du moteur, les avertissements, la question posée et la réponse obtenue.

Cette promesse reste importante. Alors que l’assurance réseau traditionnelle reposait largement sur la lecture des configurations, les laboratoires, les sondes après changement et l’expérience des ingénieurs, Batfish avance une partie de la vérification et devient une infrastructure du processus de changement plutôt qu’un élément du chemin des paquets.

La configuration était déjà du code distribué

Le problème ne se limite pas à l’absence de vérificateurs syntaxiques. Une politique réseau est répartie entre de nombreux équipements et systèmes de contrôle. L’accessibilité d’un flux peut dépendre simultanément de l’origine d’une route, de son importation, de sa transformation, de sa sélection, de son exportation, de son acceptation ailleurs, de son installation dans la table d’acheminement, d’ACL, de NAT et de tunnels.

Une revue équipement par équipement est donc structurellement incomplète. Un vérificateur local peut confirmer qu’un NOS accepte une commande et un linter signaler une syntaxe obsolète, sans calculer les conséquences de bout en bout de l’interaction entre routage, acheminement et filtres.

Batfish considère le réseau comme un objet sémantique unique, même si ses données d’origine restent un ensemble de configurations et d’états externes. Cette approche est particulièrement utile dans les environnements multifournisseurs, où une même idée peut être exprimée par des commandes, des valeurs par défaut ou des objets d’API différents.

Les analyseurs et la représentation indépendante des fournisseurs ramènent la sémantique prise en charge à un niveau commun où les mêmes questions peuvent être posées à l’ensemble du réseau. Cette abstraction réduit la dépendance envers un langage de configuration particulier, mais crée une nouvelle limite de confiance: sa justesse dépend de la traduction de chaque fonction pertinente.

Les instructions non prises en charge, les comportements partiellement modélisés et les valeurs par défaut propres aux fournisseurs ne doivent pas disparaître comme du bruit. Les avertissements de conversion font partie du résultat. Un analyseur qui accepte silencieusement un fichier tout en ignorant une commande modifiant l’acheminement peut être plus dangereux qu’un échec explicite.

Le même problème existe dans le cloud, où le dépôt peut ne contenir que des modèles et l’état prévu, tandis que les routes, interfaces, rattachements et objets de sécurité sont créés dynamiquement par les API. Batfish peut intégrer des constructions AWS et Azure, mais l’opérateur reste responsable de la collecte d’un état actuel et complet.

Le cœur de Batfish relève ainsi davantage de l’analyse sémantique que du simple contrôle de configuration. Le moteur calcule ce que ferait le réseau fourni selon la sémantique prise en charge, puis permet de répéter la question avant et après un changement. Le comportement global devient une propriété testable plutôt qu’une simulation mentale de milliers de lignes.

D’une question de recherche à un moteur réutilisable

Batfish provient des travaux ayant conduit à l’article NSDI 2015A General Approach to Network Configuration Analysis, signé par Ari Fogel, Stanley Fung, Luis Pedrosa, Meg Walraed-Sullivan, Ramesh Govindan, Ratul Mahajan et Todd Millstein. Cette liste rappelle que le projet a une origine collective et ne doit pas être réduit au récit d’un seul fondateur.

Le prototype de 2013–2014 associait analyse de configuration, calcul du plan de contrôle et requêtes sur le plan de données. La publication et l’ouverture du code en 2015 ont établi une base publique. De 2015 à 2018, les analyseurs, les bibliothèques de questions et l’utilisation communautaire se sont étendus au-delà des réseaux et fonctions de l’article initial.

Entre 2019 et 2021, les notebooks pybatfish, les workflows Python et l’analyse entre état de base et état candidat ont facilité l’intégration à la CI/CD. L’avancée principale était la possibilité de transformer une propriété réseau en test exécutable à chaque changement de l’état candidat.

L’architecture interne a également évolué. Le modèle initial centré sur Datalog a en grande partie cédé la place à des représentations spécialisées, notamment les diagrammes de décision binaires, ou BDD. Un article de retour d’expérience publié en 2023 a décrit cette refonte et rapporté d’importants gains de vitesse sur les charges étudiées, avec des réseaux de milliers d’équipements analysés en quelques minutes.

Ces chiffres témoignent d’un progrès réel, mais ne définissent pas un temps de réponse universel. La durée dépend de la topologie, des transformations, de la question et de la structure de l’état. Une organisation doit donc déterminer si ses propres contrôles peuvent être exécutés dans sa fenêtre de changement.

De 2024 à 2026, le projet a développé la modélisation du cloud, SONiC, A10 et EVPN/VXLAN. La version étiquetée v2025.07.07 du 7 juillet 2025 a ajouté une prise en charge initiale d’A10 — notamment BGP, ACL, serveurs virtuels, NAT et VRRP-A — ainsi qu’une couverture initiale de SONiC au moyen deconfig_db.jsonetfrr.conf, et une prise en charge élargie des tunnels EVPN/VXLAN de couche 3 et des routes de type 5.

Les qualificatifs « initiale » et « élargie » sont essentiels. La couverture apparaît par couches: aucune de ces plateformes ou fonctions ne doit être considérée comme entièrement modélisée dans toutes les versions et tous les scénarios. Chaque ajout accroît à la fois l’utilité du moteur et la surface de maintenance où une erreur sémantique peut survenir.

À la date de clôture des recherches, le 10 août 2026, le dépôt principal et la documentation restaient actifs après l’étiquette de juillet 2025. La version étiquetée la plus récente dans les documents fournis demeurait v2025.07.07, tandis que le développement se poursuivait sur la branche principale. La documentation pybatfish indiquait la version 0.36.0 du client, et non celle du moteur Batfish, ce qui souligne la nécessité de versionner séparément les composants du système d’assurance.

Le moteur calcule un réseau, pas une collection de fichiers

Batfish part d’un instantané d’analyse, non d’un flux de paquets en direct. Celui-ci contient généralement les configurations des équipements et peut inclure des informations de topologie, des données d’hôtes, l’état du cloud, des routes BGP d’exécution, LLDP/CDP et d’autres entrées. Une unité d’analyse immuable permet de reproduire l’état ayant fondé une décision.

La première limite est l’analyse syntaxique. Les NOS utilisent leurs propres grammaires et valeurs par défaut. Batfish construit des structures pour les formats pris en charge, puis convertit les instructions comprises en un modèle commun, tout en conservant les avertissements lorsque la traduction est incomplète.

Ce modèle sert au calcul du plan de contrôle: sessions de protocole prises en charge, origine et propagation des routes, politiques d’importation et d’exportation, redistribution, sélection et instances de routage virtuelles. Il ne s’agit pas d’émuler le code propriétaire d’un routeur, mais de produire un modèle indépendant du résultat déduit de la configuration et de la sémantique implémentée par Batfish.

Cette indépendance permet d’étudier plusieurs fournisseurs dans un cadre commun, mais la production peut diverger en raison d’un comportement non documenté, d’un défaut fournisseur, d’une dépendance temporelle ou d’une fonction absente du modèle. La fidélité doit être établie par des tests et une couverture observable.

Le moteur synthétise ensuite le comportement d’acheminement en combinant tables, ACL, NAT, topologie et états de tunnels pris en charge. Il devient possible de demander si des emplacements sont accessibles, quel chemin suit un flux, où un paquet est filtré ou comment une modification de politique change l’acheminement.

L’analyse différentielle applique une même question à un instantané de base et à un instantané candidat. L’opérateur compare alors les comportements plutôt que le seul texte: une modification BGP d’une ligne peut révéler un changement distant de sélection de route.

Batfish est principalement écrit en Java, tandis que pybatfish fournit un client Python pour les notebooks et l’automatisation. Les versions du client, du moteur et des tests internes doivent donc être gérées comme des dépendances liées d’un même système.

L’accessibilité symbolique vérifie une propriété

Un ping demande si un paquet précis a atteint une destination à un instant donné. Les transactions synthétiques et traceroutes élargissent l’observation, mais tout ensemble fini de sondes ne couvre qu’une petite partie des en-têtes, points d’entrée, chemins et états de panne possibles.

Batfish commence par une propriété, par exemple l’interdiction pour les réseaux invités d’atteindre le sous-réseau d’administration. Le moteur représente symboliquement l’espace pertinent des en-têtes, tandis que les BDD décrivent de grands ensembles d’adresses, de ports, de protocoles et de transformations sans énumérer chaque paquet.

Le résultat peut démontrer qu’aucun en-tête représenté ne satisfait un chemin interdit ou fournir un contre-exemple avec source, destination, protocole et trace. Ce cas concret est souvent plus utile qu’un simple échec, car il offre un scénario reproductible et un point de décision de politique à examiner.

Comme la configuration candidate n’a pas besoin d’exister en production, une violation peut être détectée avant le déploiement et bloquer une pull request. Une propriété à l’échelle du réseau devient ainsi un test logiciel préalable au changement.

La recherche symbolique n’est toutefois pas gratuite. Certaines topologies, transformations et questions produisent des espaces d’état coûteux. La refonte fondée sur les BDD a amélioré l’échelle sur les charges publiées, mais un grand parc doit toujours planifier les ressources et la latence de sa plateforme d’assurance.

L’exhaustivité symbolique du modèle ne signifie pas l’exhaustivité physique. Batfish ne mesure ni files d’attente, ni dégradation optique, ni congestion réelle, ni émetteur-récepteur instable, ni temps de réponse applicatif. Il calcule généralement des états de routage stables ou sélectionnés, et non toutes les courses de temporisateurs pendant la convergence.

Modèle et observation sont donc complémentaires: Batfish indique ce que l’état fourni devrait signifier, tandis que les sondes, la télémétrie des équipements et les mesures applicatives montrent ce qui s’est réellement produit. Leur divergence constitue un signal diagnostique utile.

L’analyse différentielle demande ce qui change

La question utile n’est pas seulement de savoir si une nouvelle configuration est valide, mais quel comportement changera et si chaque différence est intentionnelle. L’analyse différentielle compare les routes, l’accessibilité, les chemins, les filtres et d’autres propriétés entre états de base et candidat.

Une communauté BGP, une préférence locale, une redistribution, un filtre ou une table de routage cloud peut produire des effets à plusieurs sauts. La suppression d’un chemin peut aussi éliminer discrètement la seule route survivant à une panne.

Dans un workflow de CI, le dépôt contient la configuration proposée, un état candidat est construit et des tests sont lancés par rapport à l’état approuvé. Parmi les invariants possibles: isoler les réseaux d’administration, refuser l’espace réservé via BGP externe, conserver deux chemins indépendants pour un préfixe critique ou empêcher une route par défaut de fuir vers un domaine protégé.

La qualité dépend moins du nombre de tests que de celle des propriétés. Une suite verte peut ignorer la propriété qui cassera ensuite, tandis que des tests reproduisant mécaniquement le comportement existant peuvent figer une ancienne erreur. Les propriétaires de services, équipes de sécurité et ingénieurs réseau doivent relier les invariants aux objectifs de service, aux incidents et à l’architecture.

Les tests doivent évoluer avec la conception du réseau. Désactiver un test jusqu’à obtenir un résultat vert sans examiner la cause est dangereux. Toute réponse modifiée doit devenir un événement de revue indiquant ce qui a changé: le réseau, le modèle ou la question.

Les questions pybatfish et leurs réponses typées servent aussi d’API aux outils internes. Une mise à niveau du moteur ou du client peut modifier le schéma ou l’interprétation d’un résultat positif. Les déploiements de production doivent donc fixer les versions et tester les mises à niveau sur des instantanés représentatifs.

Enfin, une erreur commune au modèle de base et au modèle candidat peut rester invisible. Si une entrée manque dans les deux ou si un même défaut d’analyseur les affecte, la comparaison peut paraître sûre alors que les deux représentations sont erronées.

La matrice de prise en charge est une carte des risques

Batfish couvre de nombreux systèmes d’exploitation réseau, pare-feu et objets de cloud public. Cette largeur est nécessaire, car un chemin de service moderne peut traverser des routeurs physiques, des équipements virtuels, des tables cloud, des politiques de sécurité et une fabrique EVPN/VXLAN. La fiabilité d’une propriété dépend du composant pertinent le moins fidèlement modélisé.

Le mot « pris en charge » reste trop vague sans précision fonctionnelle. Un analyseur peut reconnaître un format alors que la conversion ne modélise que les instructions courantes. Un protocole peut être implémenté sans certaines extensions, ou un élément lu sans influencer une question donnée.

La version de juillet 2025 illustre cette progression: couverture ciblée d’A10 pour BGP, ACL, serveurs virtuels, NAT et VRRP-A; prise en charge initiale de SONiC avecconfig_db.jsonetfrr.conf; extension d’EVPN/VXLAN autour des tunnels de couche 3 et des routes de type 5. La couverture n’est pas une propriété binaire.

Les avertissements de conversion sont l’interface opérationnelle de cette limite. Certains sont sans effet sur l’invariant étudié, d’autres signalent un comportement non pris en charge sur le chemin même. Les équipes doivent classer les avertissements selon leur incidence et examiner séparément toute nouvelle catégorie.

Les valeurs par défaut créent un risque supplémentaire, notamment lorsqu’un fournisseur ou une version de NOS les modifie. Dans le cloud, des routes ou politiques peuvent provenir d’un état externe. Une analyse complète peut donc exiger inventaire, état des interfaces, exports d’API, adresses d’hôtes et annonces externes, et non les seuls fichiers de configuration.

La prise en charge de nombreux fournisseurs exige des spécialistes, des tests de régression et une revue continue. Les contributeurs open source, utilisateurs commerciaux, fournisseurs et intégrateurs peuvent avoir des priorités différentes. Les documents fournis citent Network to Code dans cet écosystème, sans établir pour autant une propriété formelle du projet ni une fondation gouvernée par ses membres.

L’analyse des pannes dépend de domaines de défaillance réels

Batfish peut modéliser certaines pannes en modifiant l’état d’interfaces, de routes, de nœuds ou de protocoles, puis en recalculant routage et accessibilité. Il peut ainsi révéler un point de défaillance unique, un filtre bloquant la route de secours ou deux chemins partageant une dépendance inattendue.

Le scénario doit correspondre au domaine de défaillance réel. Perdre une interface n’équivaut pas à perdre une carte, une baie, un conduit de fibre, un bâtiment, une région cloud ou un service de contrôle partagé. Deux liens indépendants dans la configuration peuvent emprunter le même conduit.

Batfish calcule la topologie et les hypothèses reçues; il ne découvre pas automatiquement les causes communes extérieures aux configurations. La qualité de l’inventaire, des dossiers de circuits, des données de sites et de l’architecture cloud fait donc partie des preuves nécessaires.

La convergence ajoute une autre limite. Un état stable après panne peut être sûr alors qu’un chemin transitoire pendant le retrait et le recalcul viole brièvement un objectif de service. Les exercices de panne et la télémétrie des protocoles restent indispensables.

La meilleure utilisation consiste à rendre exécutable une affirmation de résilience: représenter explicitement les zones, supprimer chacune à tour de rôle, modéliser les dépendances pertinentes et vérifier les routes de secours avec les politiques de sécurité. Ces données doivent être révisées après toute modification physique ou logique.

Gouvernance open source et gestion commerciale

Batfish est distribué sous licence Apache 2.0 et reste un projet open source public. Le dépôt, les tickets, la documentation et les notes de version offrent un historique inspectable. L’origine collective et la diversité des contributions ne prouvent toutefois pas l’existence d’une fondation indépendante dont les pouvoirs seraient entièrement publics.

Les éléments fournis ne montrent pas de fondation d’adhérents contrôlant Batfish. L’activité des commits et des versions ne suffit pas non plus à identifier l’autorité finale sur chaque sous-système. Une contribution au dépôt doit être distinguée d’un titre formel de gouvernance.

Ari Fogel et Ratul Mahajan ont cosigné l’article fondateur avant de devenir cofondateurs d’Intentionet. Todd Millstein est associé aux langages de programmation et à l’analyse, Ramesh Govindan à la recherche en réseaux, tandis que Stanley Fung, Luis Pedrosa et Meg Walraed-Sullivan figurent également parmi les auteurs initiaux. L’attribution la plus exacte reste collective.

Intentionet, fondée en 2018 autour de l’utilisation commerciale de Batfish, est une entreprise distincte. Elle développe des produits et services autour du moteur et fournit une voie d’adoption et d’assistance pour les entreprises. Ses revenus, financements, clients et capacités propriétaires ne doivent pas être attribués automatiquement au projet Batfish.

Une gestion commerciale peut financer les analyseurs, intégrations, documents et corrections de production. Elle peut aussi créer des risques d’attribution ou de concentration des connaissances si les utilisateurs assimilent les fonctions commerciales à l’amont ou deviennent dépendants d’une seule organisation.

La licence ouverte autorise l’utilisation, l’étude et la modification du code sans redevance de projet. Elle ne fournit ni équipe d’exploitation, ni collecte de données, ni politique d’assistance. Les compétences, les intégrations et la connaissance des instantanés, avertissements et mises à niveau restent des coûts réels de changement.

Un portefeuille allant de l’analyse syntaxique à l’automatisation

Batfish est plus qu’un outil de contrôle de configuration. Il normalise la syntaxe prise en charge, calcule le plan de contrôle, transforme celui-ci en chemins et accessibilité, compare les états candidat et approuvé, modélise certaines pannes et interroge les ACL, les politiques de routage, les objets cloud et les superpositions. pybatfish relie ces fonctions à l’automatisation.

Les équipes d’automatisation dépendent surtout de la fidélité des analyseurs et de la reproductibilité. Les architectes et spécialistes du routage utilisent les questions de plan de contrôle et de sélection des routes; les équipes de sécurité examinent l’accessibilité et les filtres; les spécialistes de résilience simulent des pannes; les développeurs et SRE intègrent les contrôles aux workflows.

L’instantané est leur point commun. Il lie une réponse à un état, à une version du moteur et à une question. L’analyse syntaxique et la conversion définissent d’abord la limite de confiance, puis le moteur combine routage, filtres, NAT et topologie. Les BDD couvrent des classes de paquets, les questions différentielles distinguent changement sémantique et changement textuel, et l’analyse des politiques montre la transformation des routes.

Chaque fonction a ses limites: temporisation réelle, défauts fournisseur, pertes physiques, erreurs communes aux deux instantanés, identité applicative située au-dessus des champs étudiés, extensions non prises en charge ou couverture partielle d’EVPN/VXLAN.

pybatfish renvoie des tableaux, traces et propriétés typés, mais exige toujours un moteur et un instantané correct. Un notebook fonctionnant sur une topologie d’exemple ne prouve pas la fidélité d’un réseau privé. Intentionet et d’autres intégrateurs peuvent ajouter collecte, tableaux de bord et assistance, mais ces offres doivent rester distinctes du projet ouvert.

Entre linting, émulation et observabilité en direct

Un linter de configuration repère rapidement erreurs syntaxiques, commandes obsolètes, violations de style et motifs risqués. Batfish va plus loin en calculant les interactions dans un modèle global, au prix d’entrées plus complètes et d’une couverture sémantique plus large.

Des plateformes telles que Cisco CML ou EVE-NG exécutent des images NOS et peuvent reproduire une partie du comportement et de la temporisation propres aux fournisseurs. Elles demandent davantage de ressources pour explorer d’immenses espaces de paquets, de topologies et de pannes. Batfish opère à un niveau plus abstrait, avec une autre échelle et d’autres angles morts.

Les plateformes commerciales Forward Networks et IP Fabric poursuivent des objectifs voisins sous forme de produits intégrés. Les documents fournis présentent Forward Networks comme un pair de jumeau numérique avec collecte en direct, et IP Fabric comme une plateforme d’assurance et de découverte axée sur les instantanés opérationnels et la visualisation. Elles peuvent réduire le travail d’intégration grâce à la collecte, la découverte de topologie, les tableaux de bord et l’assistance.

L’avantage de Batfish est son moteur ouvert et inspectable. Son inconvénient est le travail périphérique: collecte, normalisation, identité, workflow, interface, gestion des versions et vérification en direct. Un cœur ouvert n’est pas un produit d’exploitation prêt à l’emploi.

Les outils de méthodes formelles peuvent fournir des garanties mathématiques très fortes sur des propriétés ou protocoles plus étroits. L’intérêt de Batfish réside dans la combinaison pratique d’une sémantique multifournisseur, du comportement des paquets et de questions destinées aux opérateurs.

Les plateformes de télémétrie observent les routes, interfaces, latences, flux, journaux et services réels. Elles détectent des dégradations optiques, pannes transitoires ou congestions que Batfish ne modélise pas, mais n’analysent pas toujours une configuration candidate encore absente de la production.

Le meilleur modèle opérationnel associe donc modélisation avant changement et mesures en direct. Batfish vérifie le routage et l’acheminement prévus; la télémétrie et les sondes confirment ensuite les résultats réels. Le terme « jumeau numérique » doit rester limité: Batfish est plus précisément un modèle réseau ou un jumeau d’analyse de configuration aux frontières explicites.

Gérer le modèle revient à gérer le réseau lorsqu’un test bloque une version

Lorsqu’une question Batfish peut arrêter un changement de production, le modèle acquiert un pouvoir institutionnel. Une décision d’analyseur détermine si une configuration est comprise, une question peut encoder une politique de sécurité ou de résilience, et une mise à niveau du moteur peut modifier un résultat auparavant positif.

Cette autorité exige une discipline logicielle: versionner et faire relire les questions, leur attribuer des responsables, conserver des jeux de tests reproduisant les défauts importants et valider les mises à niveau sur des instantanés représentatifs. Une procédure de retour arrière est nécessaire pour le système d’assurance lui-même.

Lorsqu’une route, une trace ou une observation de paquet contredit Batfish, aucune partie ne doit gagner automatiquement. Qualifier toute divergence de défaut de l’équipement détruirait la confiance dans le modèle; l’expliquer systématiquement par une limite du modèle lui retirerait toute autorité.

Il faut conserver la configuration, les entrées externes, la version du moteur, les avertissements, la question et les preuves de production. L’écart peut venir d’une syntaxe ignorée, d’une approximation de conversion, d’un état d’exécution absent, d’un comportement non documenté, d’un déploiement divergent ou d’un invariant mal formulé.

Un programme mature transforme l’incident en test de régression, entrée corrigée, invariant révisé ou limite documentée. L’intention devient alors un objet séparé de la configuration. Les propriétaires de services définissent la propriété, les ingénieurs la relient à la topologie et aux politiques, la sécurité fixe les chemins interdits, l’automatisation construit les instantanés et l’exploitation vérifie le résultat déployé.

Les dérogations doivent elles aussi être gouvernées. Une exception doit indiquer la propriété touchée, les preuves, le responsable et sa condition d’expiration. Sans possibilité de dérogation, les équipes contourneront le système; sans trace ni échéance, le système perdra sa valeur.

La source de vérité détermine quel réseau est prouvé

Batfish peut calculer un instantané plus systématiquement qu’un humain ne peut interpréter des milliers de lignes, mais cet instantané doit représenter le système réellement déployé. Une réponse logiquement exacte sur un monde ancien ou incomplet peut être opérationnellement fausse.

Le décalage entre contrôle de source et production est un exemple évident: le dépôt peut contenir l’état prévu tandis que des modifications d’urgence locales subsistent sur les équipements. L’analyse porte alors sur le dépôt, non sur le véritable point de départ.

Dans le cloud, des routes, rattachements de sécurité, interfaces et objets générés peuvent provenir d’API extérieures au dépôt. Un instantané limité aux modèles peut ignorer le chemin qui détermine réellement l’accessibilité.

L’inventaire peut également attribuer à tort une diversité physique à deux circuits empruntant le même conduit, ou à des équipements partageant une alimentation. Batfish peut démontrer sans erreur une redondance fondée sur des étiquettes pourtant fausses.

Un workflow rigoureux relie intention, livraison et observation: définir la propriété, construire l’état candidat à partir de la configuration et des données externes, exécuter les questions, conserver versions, avertissements et réponses, puis capturer l’état réel après déploiement et le comparer à l’intention au moyen de sondes et de télémétrie.

Cette chaîne distingue une modification prévue erronée, un déploiement divergent, une fonction ou condition physique absente du modèle et une question ne représentant pas le besoin réel. Les avertissements doivent être reliés aux propriétés qu’ils peuvent invalider, et chaque question doit avoir un responsable.

Une nouvelle version de Batfish peut corriger une erreur de modélisation et modifier les réponses sans changement de configuration. Il peut s’agir d’une amélioration, mais le moteur reste une dépendance versionnée: l’organisation doit savoir quelle version a approuvé chaque changement.

La confiance naît d’une mémoire commune des désaccords

Aucun moteur ne reste correct par inertie. Les fournisseurs ajoutent des commandes, les clouds évoluent, les opérateurs adoptent de nouveaux protocoles et les systèmes internes génèrent l’état autrement. Batfish doit être maintenu aussi activement que les réseaux qu’il décrit.

Un défaut d’analyseur constitue un test utile de la culture d’ingénierie. La configuration, la sémantique attendue et le comportement observé peuvent devenir un cas de régression et, s’ils sont intégrés en amont, transformer un incident privé en connaissance partagée.

Une question mal formulée appelle la même réponse. Après une panne, l’équipe peut découvrir que l’assertion autorisait un chemin que l’entreprise croyait interdit. La correction concerne alors à la fois la technique et la manière dont les propriétaires de services transmettent leur intention.

Un produit d’assurance fermé peut simplifier l’expérience quotidienne. Le code ouvert et les résultats typés de Batfish permettent toutefois aux équipes avancées d’examiner le raisonnement, de reproduire les contre-exemples et de proposer des corrections. Un emballage commercial peut ajouter de la commodité sans supprimer le besoin d’une analyse transparente des échecs.

La portabilité doit être vérifiée concrètement: disponibilité des instantanés, questions et résultats, distinction entre Batfish en amont et services propriétaires, maintien des compétences, des collectes, des jeux de tests et de la connaissance d’exploitation.

La charge d’exploitation reste importante: adaptateurs, identifiants, inventaire, calcul, tri des avertissements, responsables des tests en échec et validation des mises à niveau. Le bénéfice n’est pas une automatisation gratuite, mais le déplacement d’une partie de l’effort depuis le diagnostic d’urgence vers un modèle et des tests capables d’échouer avant la production.

Financement, propriété et géographie

Batfish est un projet open source sans chiffre d’affaires ni bénéfice public autonome. Le code est disponible sous Apache 2.0 sans redevance de projet. Son développement combine temps financé par des employeurs, recherche, produits et services commerciaux, travail d’intégrateurs et contributions communautaires. Les éléments fournis ne donnent aucun budget consolidé.

Les données économiques d’Intentionet doivent rester séparées. Le financement, le chiffre d’affaires, la clientèle, la valorisation ou les marges de l’entreprise ne peuvent être attribués à Batfish sans source décrivant explicitement l’économie du projet.

Les économies liées à une panne évitée peuvent être importantes, mais ne permettent pas de calculer un retour sur investissement général sans cas client nommé, incident évité ou étude mesurée de validation des changements.

La maintenance de nombreux analyseurs représente un risque de pérennité: chaque NOS évolue et peu de spécialistes peuvent vérifier sa sémantique. Les priorités commerciales et celles de l’amont peuvent diverger, des régressions survenir et la documentation prendre du retard.

Les plateformes intégrées vendent collecte, découverte, visualisation, assistance et workflow. L’avantage économique de Batfish n’est donc pas une « assurance gratuite », mais la possibilité de bâtir sur un cœur réutilisable et inspectable sans redevance de projet, en assumant davantage d’intégration en interne.

Le logiciel a une portée mondiale. Ses origines de recherche et Intentionet sont liées aux États-Unis, mais le lieu du dépôt ou l’affiliation des contributeurs ne détermine pas la géographie des déploiements. Batfish peut analyser des réseaux dans tout pays où l’opérateur l’exécute. Il peut modéliser des constructions AWS et Azure sans posséder ni exploiter les réseaux cloud concernés.

Des limites qui demeurent

Premièrement, le modèle ne voit que les configurations et données d’environnement fournies. Un équipement, une route externe, un état généré ou une étiquette de topologie manquants peuvent produire une réponse cohérente mais incomplète.

Deuxièmement, la couverture des analyseurs varie selon la fonction, la version et la question. Les avertissements et tests de régression réduisent le risque sans rendre cette couverture définitivement binaire.

Troisièmement, Batfish répond à des questions explicites; il ne déduit pas automatiquement tous les besoins métier. Une équipe peut vérifier parfaitement la mauvaise propriété.

Quatrièmement, les réseaux réels subissent temporisateurs, mises à jour asynchrones, particularités d’implémentation et convergence transitoire. Un état stable sûr ne garantit pas une transition sûre.

Cinquièmement, la configuration ne montre ni fibre sale, ni optique défaillante, ni délai de file, ni carte surchauffée, ni corruption de paquets, ni défaut d’ASIC. L’observabilité physique reste nécessaire.

Sixièmement, les BDD compressent de grands espaces de paquets, mais certaines topologies et requêtes restent coûteuses. Une plateforme servant de contrôle obligatoire doit disposer de ressources et de budgets de temps propres.

Septièmement, l’état du cloud dépend d’exports récents et d’une couverture actuelle des fonctions. Collecte et maintenance des analyseurs sont indissociables.

Huitièmement, les produits commerciaux autour de Batfish peuvent posséder des fonctions et engagements absents de l’amont. Confondre entreprise et projet fausse l’attribution.

Neuvièmement, le langage formel peut donner une impression d’absolu et inciter à abandonner le déploiement progressif ou la validation en direct. Une réponse formelle vaut justement parce que ses conditions sont explicites.

Dixièmement, dépôts, téléchargements et études visibles ne révèlent ni le nombre de déploiements privés en production ni leurs versions. Les affirmations de leadership de marché restent difficiles à vérifier.

La promesse pratique est une chaîne d’assurance progressive

L’apport le plus durable de Batfish est le changement de question par défaut: au lieu de demander si une configuration paraît raisonnable, il demande ce que le réseau entier fera selon le modèle. Les attentes de routage, de sécurité et de résilience deviennent des propriétés vérifiables avant le déploiement.

La chaîne comporte plusieurs étapes: analyse syntaxique, modèle commun, calcul du plan de contrôle, vérification de l’acheminement, déploiement et observation des paquets, optiques et applications. La conservation des résultats de chaque étape rend les divergences diagnostiquables.

Un résultat positif signifie littéralement qu’une propriété précise tient dans un modèle explicite d’un état réseau donné sous une version donnée du moteur. Cette affirmation est plus étroite que « le changement est sûr », mais elle est reproductible, contestable et améliorable.

Batfish peut prévoir qu’un flux est autorisé par le routage et les filtres; la télémétrie montre si les paquets réels, les files, les optiques et les applications fournissent le service attendu. En cas d’écart, l’organisation peut distinguer une intention erronée, un déploiement divergent, un modèle incomplet ou une défaillance physique.

Le succès ne se mesure donc pas au nombre de fichiers analysés, mais au nombre de propriétés importantes que les équipes savent formuler, vérifier, faire relire, déployer et confirmer en production. Batfish peut déplacer une grande classe de défaillances vers la revue, rendre les hypothèses explicites et fournir des contre-exemples avant l’impact client. Il ne remplace ni le réseau physique, ni le jugement opérationnel, ni les preuves en direct; il est le plus utile lorsque ces limites restent visibles.