Étendre les laboratoires SRv6 à Junos
Un laboratoire multi-constructeurs prend tout son sens lorsqu’une même intention réseau peut être testée sur plusieurs systèmes d’exploitation. Dans l’article source, Ivan Pepelnjak revient sur l’ajout de la prise en charge de SRv6 sur Junos dans netlab, désormais incluse dans la version 26.10.
L’implémentation porte sur deux éléments essentiels d’un scénario SRv6 :
La configuration du locator SRv6 sur les nœuds Junos
La configuration de l’IGP nécessaire à la topologie de laboratoire
L’auteur présente cet ajout comme relativement simple et partage les enseignements tirés de la préparation de la pull request. Pour les ingénieurs, l’intérêt dépasse la création d’un modèle de configuration supplémentaire : il devient possible de réutiliser des exemples SRv6 sur davantage de plateformes tout en conservant un modèle de laboratoire cohérent.
Une méthode de validation centrée sur le modèle
L’intégration d’un nouveau système d’exploitation réseau est une bonne occasion de dissocier l’intention d’architecture de la syntaxe propre au constructeur. Une démarche pratique consiste à :
Définir la topologie et l’intention SRv6. Identifier les nœuds Junos et représenter le comportement attendu des locators et de l’IGP dans le modèle du laboratoire.
Générer la configuration Junos. S’appuyer sur la prise en charge introduite dans netlab 26.10 plutôt que de recréer manuellement chaque exemple.
Examiner la configuration produite. Vérifier avant le déploiement que les parties locator et IGP correspondent bien au modèle attendu.
Déployer dans un environnement isolé. Maintenir les expérimentations à l’écart de l’infrastructure de production.
Valider l’état obtenu. Contrôler que les nœuds Junos et le reste de la topologie multi-constructeurs présentent le comportement de routage attendu.
Conserver une référence fonctionnelle. Archiver à la fois l’intention modélisée et la configuration obtenue afin de comparer précisément les modifications ultérieures.
Cette méthode aide à distinguer trois sources d’erreur : le modèle abstrait, la génération propre à la plateforme ou le comportement observé après le déploiement.
L’intérêt d’une modélisation multi-constructeurs
Un exemple limité à une seule plateforme peut démontrer le fonctionnement d’une fonctionnalité, mais il ne révèle pas toujours les différences de structure ou les hypothèses propres à chaque implémentation. L’ajout de Junos à un laboratoire SRv6 fournit un nouveau point de comparaison.
Les ingénieurs peuvent alors examiner des questions précises :
Le locator prévu est-il représenté de manière cohérente sur tous les nœuds concernés ?
La configuration IGP générée correspond-elle au modèle de topologie ?
Les particularités de chaque plateforme restent-elles séparées de l’intention réutilisable ?
Le laboratoire peut-il être reconstruit avec un résultat prévisible ?
Les changements de configuration sont-ils traçables d’un test à l’autre ?
Il ne s’agit pas de rendre tous les systèmes d’exploitation identiques. L’objectif est de préserver une intention réseau commune tout en générant une configuration adaptée à chaque plateforme.
La place de ConnectMyAssets
L’évolution de netlab répond au besoin de modéliser et de générer des configurations SRv6 pour Junos. ConnectMyAssets peut compléter cette démarche en gérant les équipements et les éléments de preuve associés aux tests successifs, sans se substituer au framework de laboratoire.
Plusieurs modules sont directement pertinents :
Dynamic CMDB : inventorier les équipements Junos et les actifs d’autres constructeurs participant au laboratoire, avec leur contexte opérationnel dans un système sur site.
Backup & History : sauvegarder les versions de configuration avant et après les essais SRv6, comparer les changements et restaurer si nécessaire une configuration connue grâce au retour arrière en un clic.
Topology : conserver une vue des actifs administrés et de leurs relations pour comparer la connectivité prévue à celle qui est déployée.
Automation & ZTP : standardiser les tâches répétitives liées au provisionnement du laboratoire et au déploiement des configurations.
Compliance Engine : vérifier les configurations administrées par rapport aux contrôles internes ou aux politiques alignées sur NIS2, ISO 27001, PCI, CISA et NIST.
End-of-Life Tracking : suivre le cycle de vie des plateformes afin de déterminer quels systèmes doivent rester dans un environnement de validation réutilisable.
ConnectMyAssets étant une plateforme multi-constructeurs déployée sur site, les équipes peuvent conserver localement l’historique des configurations et les données d’inventaire d’un laboratoire réunissant Junos et d’autres plateformes.
D’une pull request à une pratique reproductible
La prise en charge de SRv6 sur Junos dans netlab 26.10 élargit le choix de plateformes pour les laboratoires SRv6. L’enseignement le plus réutilisable tient à la méthode : représenter l’intention liée aux locators et à l’IGP dans un modèle commun, examiner le résultat propre à chaque plateforme, le valider dans un environnement mixte et conserver chaque état de référence.
Cette combinaison transforme un exemple ponctuel en ressource d’ingénierie reproductible.
Source : ipSpace.net
