Le signe pourcentage ne suffit pas à confirmer un changement
Automatiser une modification de configuration Cisco IOS semble simple : passer en mode configuration, envoyer les commandes, quitter ce mode et communiquer le résultat. La difficulté consiste à déterminer si l’équipement a réellement accepté la configuration attendue sans erreur significative.
La source illustre cette limite avec Netmiko. L’outil peut entrer en mode configuration et en sortir, avec une opération de commit si nécessaire, mais il ne détecte pas nativement les erreurs de configuration.
Une solution apparemment pratique consiste à utiliser % comme error_pattern avec send_config_from_file. Les erreurs de configuration Cisco IOS commençant par un signe pourcentage, ce motif paraît offrir un détecteur d’échec simple.
Les tests d’intégration ont toutefois révélé le problème : Cisco IOS emploie le même préfixe pour les erreurs et les avertissements. D’après la source, ce marqueur ne permet pas de distinguer les deux de manière fiable.
Une ligne commençant par
%exige l’attention de l’automatisation. Elle ne prouve pas, à elle seule, que l’ensemble du changement a échoué.
Pourquoi la détection par motif atteint ses limites
Un workflow qui considère chaque ligne préfixée par un signe pourcentage comme une erreur fatale peut s’arrêter sur un simple avertissement. À l’inverse, ignorer ces lignes peut masquer une véritable erreur de configuration. Le préfixe commun impose une décision binaire alors que la sortie CLI ne fournit pas de classification suffisamment fiable.
La réussite du transport ne garantit pas non plus celle de la configuration. Passer en mode configuration, transmettre les commandes puis retrouver l’invite attendue prouve seulement que la session a suivi son cours. Cela ne démontre pas que chaque commande a produit l’état recherché sur l’équipement.
La bonne question n’est donc plus La sortie contient-elle une chaîne ressemblant à une erreur ?, mais L’équipement a-t-il atteint l’état attendu ?
Un workflow d’automatisation plus robuste
1. Capturer l’intégralité de l’échange
Conservez les commandes envoyées et les réponses CLI brutes. Il ne faut ni supprimer un avertissement parce que la session s’est poursuivie, ni réduire trop tôt l’exécution à un simple statut de réussite ou d’échec.
2. Traiter % comme un signal d’attention
Un message préfixé par un signe pourcentage doit déclencher une évaluation supplémentaire, pas une conclusion automatique. Selon le risque associé au changement, la politique d’automatisation peut suspendre l’exécution, demander une validation humaine ou poursuivre avec des contrôles complémentaires.
3. Vérifier le résultat attendu
Les contrôles après changement doivent être définis avant l’exécution. La validation doit porter sur l’état que la modification était censée produire, et non exclusivement sur le texte renvoyé après chaque commande.
Quelques questions utiles :
La configuration attendue est-elle présente après l’intervention ?
Un ancien paramètre est-il toujours présent alors qu’il devait être remplacé ?
Tous les équipements ciblés ont-ils atteint l’état demandé ?
La configuration obtenue respecte-t-elle la politique applicable ?
4. Comparer les configurations avant et après
La comparaison fournit une preuve concrète des changements réalisés, y compris en cas d’application partielle. Ce contrôle est particulièrement important lorsqu’un lot contient plusieurs commandes et que seule une partie de la modification prévue a pu être acceptée.
5. Conserver la trace de la décision
Pour chaque exécution, conservez l’équipement ciblé, le changement prévu, la sortie CLI brute, les configurations avant et après, les résultats des validations et la décision finale prise par l’opérateur ou le workflow. Ces éléments facilitent le diagnostic et rendent les revues de conformité plus solides qu’un simple message d’échec générique.
6. Déclencher le retour arrière sur un échec vérifié
Le retour arrière doit suivre une politique explicite. Un message ressemblant à un avertissement ne justifie pas forcément une restauration, tandis que l’échec d’un contrôle d’état peut l’exiger. La configuration de référence et les preuves soutenant la décision doivent être disponibles avant de lancer la remédiation.
Comment ConnectMyAssets aide
ConnectMyAssets fournit une base on-prem et indépendante des constructeurs pour encadrer les changements réalisés par CLI :
Automation & ZTP peut servir de couche d’exécution pour des changements contrôlés. Les workflows doivent intégrer une validation explicite du résultat au lieu de dépendre uniquement du motif
%.Backup & History assure le versioning des configurations afin de comparer l’état avant et après une intervention, puis d’utiliser le rollback en un clic lorsqu’un échec vérifié impose une restauration.
Dynamic CMDB maintient l’inventaire des actifs administrés dans la même plateforme opérationnelle, afin d’appliquer les processus de changement et de validation aux bonnes infrastructures.
Compliance Engine évalue les configurations au regard d’exigences telles que NIS2, ISO 27001, PCI, CISA et NIST. La revue après changement peut ainsi considérer la conformité de l’état final, et pas seulement l’exécution des commandes.
SSH Bastion et Credential Vault favorisent un accès administratif contrôlé, sans assimiler la réussite d’une session SSH à la réussite de la configuration.
ConnectMyAssets ne peut pas rendre un message IOS ambigu parfaitement explicite. Son rôle est d’aider les équipes à maîtriser le processus qui l’entoure : conserver l’historique, vérifier l’état obtenu, évaluer la conformité et maintenir une possibilité de restauration.
À retenir
Le signe pourcentage de Cisco IOS ne doit pas être utilisé comme unique critère d’échec. Il signale une sortie à examiner, mais ne permet pas de séparer de façon fiable les avertissements des erreurs.
Une automatisation réseau robuste repose sur plusieurs couches : capture complète de la sortie, validation du résultat, comparaison des configurations, conservation des preuves et retour arrière piloté par une politique. La transcription CLI contribue à la décision ; elle ne constitue pas, à elle seule, le verdict final.
Source : ipSpace.net
