De l'intent au BGP Established - Partie 1 : Intent-Based Networking en pratique
Démonstration de bout en bout d'un pipeline IBN open source : De la source de vérité jusqu'au BGP Established sur les équipements. Avec ce qui se passe quand ça ne marche pas : rollback, circuit breaker, correction de l'intent et reconvergence. La stack : Infrahub, Gitea, ArgoCD, K3S, ContainerLab avec cEOS
Image non disponible
URL: /blog-assets/ibn-lab/schema_article_white_bg.jpg
Introduction
Dans un précédent article, nous avions dessiné le cadre. La RFC 9315, ses boucles de contrôle, l'Intent-Based Networking comme horizon. Nous avions expliqué le pourquoi sans entrer dans le comment. Aujourd'hui, on construit la maison.
L'objectif est concret : à partir d'un laptop et d'une poignée d'outils open source, monter une chaîne d'automatisation continue pour le réseau. Pas une maquette conceptuelle - une démonstration de bout en bout où un nouveau site est provisionné par un simple Proposed Change dans la source de vérité, et où un rollback s'exécute automatiquement si le réseau ne converge pas. Le tout sans écrire une seule ligne de configuration CLI à la main.
Pour les équipes réseau habituées au terminal et au copier-coller de snippets entre équipements, ce qui suit propose un changement de paradigme, progressif et illustré pas à pas.
La stack du lab - Cinq briques open source
Chaque outil de cette démonstration occupe un rôle précis dans le pipeline. Les voici, dans l'ordre où le changement les traverse.
Infrahub est notre source de vérité. Développé par OpsMill, c'est une plateforme de gestion de données d'infrastructure qui prend le relais là où les tableurs et les wikis internes montrent leurs limites. C'est ici que l'on formalise l'intent - les interfaces, les adresses, les peerings BGP - avant qu'il ne devienne de la configuration.
Infrahub se distingue par son approche versionnée de la donnée. Il dispose de son propre modèle de branches, appliqué non pas à des fichiers mais aux données structurées du graphe. On crée une branche dans Infrahub, on y apporte des modifications, on soumet un Proposed Change - l'équivalent d'une pull request sur la source de vérité - qui déclenche des validations automatiques et permet une revue humaine avant la fusion. C'est cette fusion qui, via un webhook, déclenchera l'automatisation chargée de produire les commits Git.
Gitea joue le rôle de forge Git auto-hébergée. Léger et simple à déployer, Gitea héberge le dépôt où atterrissent les configurations rendues par Infrahub. Chaque changement d'intent produit un ou plusieurs commits sur la branche principale - un par device affecté, pas de pull request à ce stade, puisque la revue a déjà eu lieu en amont, dans Infrahub. Git n'est pas la source de vérité : c'est le support de traçabilité et le point de synchronisation pour ArgoCD.
ArgoCD est le moteur GitOps. Il surveille en permanence le dépôt Gitea et orchestre la réconciliation lorsqu'un écart apparaît entre l'état désiré (les configurations dans Git) et l'état déployé. Kubernetes sert ici d'intermédiaire de déploiement : ArgoCD y applique les ConfigMaps, et un job se charge de les pousser vers les équipements via eAPI puis de vérifier l'état opérationnel du réseau. In fine, c'est bien l'écart entre l'intended state et l'état réel du réseau qui est détecté et corrigé - la boucle d'assurance que la RFC 9315 décrit.
K3S est le socle Kubernetes qui porte Gitea, ArgoCD et Infrahub. Distribution légère de Kubernetes conçue par Rancher, K3S s'installe en une commande et consomme peu de ressources.
ContainerLab avec cEOS constitue notre réseau virtuel. ContainerLab permet de déployer des topologies réseau conteneurisées en quelques secondes. Couplé aux images cEOS d'Arista, il offre un environnement de test réaliste - les mêmes commandes CLI, le même comportement protocolaire qu'en production.
Les outils retenus ici reflètent des affinités techniques du moment, pas des partenariats commerciaux. Nous n'entretenons aucun lien avec les éditeurs de ces solutions.
La chaîne d'automatisation en six étapes : de l'intent à l'équipement.
L'architecture du lab - Le réseau de départ
Notre topologie de départ reproduit une fabric spine-leaf minimaliste : deux spines et deux leafs, interconnectés en full-mesh. C'est l'existant - le réseau qui tourne et qui fonctionne.
ArgoCD surveille le dépôt Gitea dès le déploiement. À ce stade, les 4 devices sont configurés et le dashboard affiche Synced / Healthy :
Le scénario - Un nouveau site à raccorder
La situation est banale : un troisième leaf doit rejoindre la fabric. Nouveau rack, nouvel équipement, nouvelles interconnexions. Dans un workflow traditionnel, un ingénieur se connecterait en SSH sur spine1, puis spine2, ajusterait les configurations BGP, ajouterait les interfaces, vérifierait manuellement que les sessions montent. Ensuite il documenterait le changement - quand il y pense - dans un tableur ou un wiki.
Ici, rien de tout cela. Le provisioning de leaf3 va traverser le pipeline de bout en bout : de la source de vérité jusqu'aux équipements, en passant par un dépôt Git et une revue humaine.
La démonstration
Étape 1 - Déclarer l'intent dans Infrahub
Tout commence dans Infrahub. On y crée le device leaf3 avec ses attributs : les interfaces Ethernet vers spine1 et spine2, les adresses IP des liens point-à-point, la loopback, l'AS BGP (65003), les peerings vers les spines. Personne n'a écrit de configuration réseau. On a déclaré un intent - ce que le réseau doit devenir.
Étape 2 - Proposed Change : la revue sur l'intent
Le changement passe par un Proposed Change dans Infrahub. Ce mécanisme est l'équivalent d'une pull request, mais appliqué à la source de vérité elle-même - pas aux fichiers de configuration rendus, mais aux données structurées qui les engendrent.
Diff des données dans le Proposed Change
Artifact diff - section BGP de leaf3
Étape 3 - De l'intent au commit : le bridge webhook
Une fois le Proposed Change mergé, Infrahub génère les Artifacts. Le webhook receiver les commite directement sur la branche main de Gitea - sans ouvrir de pull request.
Commits automatiques dans Gitea après le merge
Étape 4 - ArgoCD prend le relais
ArgoCD détecte le changement et orchestre le déploiement : les nouvelles configurations sont poussées vers les équipements cEOS via eAPI (configure replace). Le job vérifie ensuite que les sessions BGP sont Established - un mini-NRFU intégré au pipeline.
ArgoCD - Synced/Healthy, deploy job Completed
Étape 5 - Vérification : le réseau est opérationnel
spine1 - 3 peers BGP Established
Leaf3 est là, session Established, préfixes échangés. Du moment où nous avons cliqué Merge au moment où leaf3 est joignable, tout est automatique. Le réseau s'est reconfiguré sans qu'un seul ingénieur ne se connecte en SSH.
La cerise - Rollback et protection contre le drift
Une chaîne de déploiement qui ne sait pas revenir en arrière n'est qu'un canon pointé vers la production. Testons le filet de sécurité.
On simule une erreur de saisie dans Infrahub : l'ASN de leaf3 est modifié de 65003 à 65099 via un Proposed Change qui passe la revue. Le configure replace applique fidèlement la mauvaise configuration - puis la vérification NRFU détecte le problème.
Logs du deploy job - NRFU FAIL, rollback automatique, circuit breaker activé
Le réseau est déjà revenu à son état opérationnel. On corrige l'ASN dans Infrahub, le pipeline repropage la bonne configuration, le NRFU passe, l'auto-sync est réactivé.
ArgoCD - Synced/Healthy après correction de l'intent
La correction durable se fait dans la source de vérité, jamais dans Git directement - ce serait court-circuiter le modèle.
Prise de recul - Ce que cette démo raconte
Replaçons ce que nous venons de faire dans le cadre de la RFC 9315. Le Proposed Change dans Infrahub correspond à la phase de spécification et de validation de l'intent. Les Transforms (Jinja2 + GraphQL) assurent la traduction de l'intent en configuration réseau. Le déploiement par ArgoCD et la vérification NRFU incarnent l'installation et l'assurance au sens de la RFC 9315 : la plateforme applique l'état voulu et vérifie que le réseau y a effectivement convergé.
Ce modèle tranche avec une approche où la revue s'exercerait en aval - sur les fichiers de configuration rendus plutôt que sur les données qui les engendrent. Ici, la revue est en amont. On raisonne sur l'intent (leaf3 doit rejoindre la fabric avec l'AS 65003), pas sur le rendu (ajouter ces 40 lignes dans ce ConfigMap). C'est la différence entre relire une intention et déchiffrer une traduction.
Ce lab est une démonstration, mais l'approche qu'il illustre n'est pas théorique. L'équipe NANO de NXO accompagne des organisations de taille critique dans cette démarche d'industrialisation.
Conclusion
L'outillage est mature, open source, et tient sur un laptop. La complexité n'est pas dans les outils - elle est dans le changement de culture qu'ils impliquent.
Pour des équipes réseau rompues au CLI depuis des années, adopter un modèle où la configuration naît d'une source de vérité, transite par Git et s'applique sans intervention manuelle demande un effort d'adaptation réel. Mais les bénéfices - traçabilité, réversibilité, collaboration - valent le voyage.
Le lab complet est disponible en open source avec l'article suivant et détaille la mise en œuvre technique pas à pas.
La boucle tourne. À vous de jouer.
Audric Vernet - Architecte logiciels NXO / Team NANO