Quand 30 secondes ne suffisent pas
Après avoir choisi Netmiko comme méthode de déploiement de configuration par défaut de netlab pour Cisco IOS XR, l’auteur de l’article source a vu presque tous ses tests d’intégration réussir. Seul le test d’annonce de la route par défaut OSPFv2 restait en échec.
Le problème ne venait pas simplement du déploiement de la configuration. Le délai d’attente par défaut de 30 secondes était trop court : Cisco IOS XR avait besoin de près de 90 secondes après la fin de son redémarrage pour annoncer la route par défaut OSPFv2.
Cette différence est essentielle dans un processus automatisé. Un équipement peut avoir reçu et accepté sa configuration alors que l’état de routage attendu n’est pas encore observable.
Le déploiement de la configuration et la convergence opérationnelle sont deux étapes distinctes, qui ne doivent pas partager le même critère de réussite.
Pourquoi utiliser Netmiko
Netmiko apportait une méthode de déploiement adaptée aux environnements IOS XR décrits dans la source. Ce choix évitait de dépendre du mode d’exécution utilisé :
IOS XRd control-plane, où les scripts fonctionnent directement.
vRouter, où une machine virtuelle s’exécute à l’intérieur du conteneur et empêche l’utilisation de la même approche par scripts.
Une fois les premiers problèmes de déploiement corrigés, l’échec restant mettait donc en évidence un défaut de temporisation dans la validation, et non une défaillance générale de la méthode de configuration.
Adapter l’automatisation aux délais de convergence
Une pause fixe de 30 secondes peut sembler suffisante. Ce test montre pourtant qu’un délai universel risque de produire un faux échec. Pour les changements de routage, le déploiement, la fin du redémarrage, la convergence du protocole et la validation doivent être traités comme des phases distinctes.
Un workflow plus robuste peut suivre les étapes suivantes :
Déployer la configuration prévue. Enregistrer si l’équipement a accepté l’opération de configuration.
Attendre la fin du redémarrage si nécessaire. Ne pas confondre le temps de démarrage de l’équipement avec celui de la convergence du routage.
Interroger régulièrement l’état opérationnel. Rechercher à plusieurs reprises l’annonce de la route par défaut au lieu de s’appuyer sur un seul contrôle précoce.
Définir une échéance adaptée à la plateforme. Tenir compte du délai de près de 90 secondes observé sous IOS XR plutôt que de supposer que 30 secondes suffisent partout.
Qualifier précisément l’échec. Distinguer un refus de configuration, une indisponibilité de l’équipement, une expiration du délai de convergence et un résultat de validation incorrect.
Cette méthode ne masque pas la lenteur de la transition. Elle permet au contraire de la mesurer correctement et évite qu’un test d’intégration assimile un délai attendu à une erreur de configuration.
Éviter les délais globaux arbitraires
Porter tous les délais à 90 secondes résoudrait ce test précis, mais ralentirait potentiellement des workflows sans rapport avec IOS XR. L’enseignement principal consiste plutôt à associer la durée de validation à la plateforme et au scénario concernés.
Les équipes d’automatisation devraient conserver les éléments temporels de chaque étape :
La fin du déploiement de la configuration.
La fin du redémarrage.
Le début de la validation.
L’apparition de la route par défaut OSPFv2 attendue.
L’échéance ayant interrompu le test si la route n’est pas apparue.
Ces repères permettent de déterminer plus facilement si un futur échec provient d’une dérive de configuration, d’un équipement indisponible ou d’un nouveau délai de convergence.
Comment ConnectMyAssets intervient
ConnectMyAssets fournit une base sur site et indépendante des constructeurs pour gérer le cycle de vie des configurations autour de tests comme celui-ci.
Automation & ZTP prend en charge des workflows de configuration reproductibles. Les étapes de validation peuvent être conçues avec des fenêtres de convergence adaptées aux plateformes, plutôt qu’avec un délai global unique.
Backup & History conserve les versions de configuration avant et après une modification, avec une restauration en un clic lorsqu’un déploiement validé doit être annulé.
Dynamic CMDB centralise le contexte des actifs et des plateformes afin d’appliquer le workflow approprié à chaque équipement géré.
Compliance Engine évalue les configurations par rapport aux exigences de l’organisation, indépendamment de l’état de convergence du protocole de routage.
Topology apporte le contexte opérationnel nécessaire pour comprendre où une annonce tardive de la route par défaut affecte l’infrastructure gérée.
Une session de commandes réussie ne prouve pas que l’état réseau recherché est déjà atteint. ConnectMyAssets aide les équipes à gérer le déploiement, l’historique des configurations, le contexte de validation et la remédiation comme des composantes liées, mais distinctes, du processus de changement.
Source: ipSpace.net
