Si la grande majorité des clients adoptent des solutions de management clé-en-main comme Catalyst Center ou le dashboard Meraki (SaaS), d’autres choisissent de développer leur propre solution de management pour configurer et monitorer directement les équipements réseau. Ceux-ci ont à l’origine été conçus pour être administrés par des humains, experts dans ce domaine. C’est la raison pour laquelle les interfaces CLI (Command Line Interface) ont été développées et sont si puissantes. Elles permettent à un humain de facilement configurer un équipement, via une syntaxe compréhensible, tout en offrant un minimum d’automatisation. Mais quand il s’agit de programmer le réseau depuis une application, il devient plus efficace d’utiliser des interfaces programmatiques et des données modélisées. Modélisation YANG… protocoles NETCONF, RESTconf, gRPC, gNMI… si ces termes sont un peu obscures pour vous je ne peux que vous recommander de visionner ce Webinar Community Live que j’ai animé sur ce sujet avant de poursuivre.
IOS-XE programmable interfaces
Une fois que vous aurez commencé à automatiser votre réseau en utilisant l’un des protocoles mentionnés ci-dessus, vous réaliserez vite qu’appliquer des configurations n’est pas suffisant. Vous souhaiterez également comprendre l’état de votre réseau en utilisant également des interfaces programmables. C’est exactement le constat d’un client qui m’a contacté récemment pour comprendre comment il pouvait utiliser également NETCONF pour recevoir des notifications en plus de l’utiliser pour configurer son réseau. Le premier besoin était d’être notifié quand la configuration de l’équipement était modifiée en local sur l’équipement. C’est ce que je me propose de partager dans cet article.
Tout d’abord je vous recommande d’installer YangSuite quand vous voulez tester ces protocoles, cela vous simplifiera grandement la vie. YangSuite a été développé par Cisco pour vous aider à tirer profit des interfaces programmables des équipements et vous y repérer parmi les nombreux modèles YANG.
NETCONF permet une télémétrie en mode Dial-in. C’est-à-dire que le manager doit appeler pour souscrire à des flux de télémétrie. Ceux-ci sont envoyés en réponse dans la session NETCONF ouverte par le manager. La connexion NETCONF (TCP 830 par défaut) est entrante vers l’équipement.
Dial-in versus Dial-out
Pour permettre de souscrire à ces flux de télémetrie, vous devez utiliser module ietf-event-notifications décrit dans le RFC 5277, NETCONF Event Notifications.
Ce module me permet de créer un payload NETCONF (format XML) pour s’abonner à des flux de télémétrie. Le payload ci-dessous demande à être notifié immédiatement en cas de changement de configuration. C’est le xpath-filter qui me permet de spécifier l’élément qui m’intéresse (ici /ios:native). En jouant simplement sur ce champ je peux ainsi récupérer tout ce qui m’intéresse (voisins CDP, CPU, état des interfaces…) et multiplier les flux de télémétrie. Catalyst Center crée plus d’une centaine de souscriptions de télémétrie..
En réponse à ce payload NETCONF, mon commutateur Catalyst 9000 m’informe que la demande est validée et me donne l’identifiant de souscription créé.
Je peux alors en CLI sur l’équipement vérifier que la souscription est bien présente et voir les détails.
Notez que cette souscription sera automatiquement supprimée en cas coupure de la session NETCONF. Il est temps de passer au test. Je fais une modification de configuration sur mon équipement réseau.
Je reçois immédiatement une notification dans ma session NETCONF avec les détails de ce qui a été modifié. On note que l’identifiant de souscription est conservé pour permettre au manager de comprendre à quoi correspond le payload reçu.
A chaque modification de configuration un payload similaire sera envoyé, permettant au manager de comprendre toutes les modifications effectuées sur l’équipement en temps réel et potentiellement déclencher des actions. Mais ça ce sera à vous de le développer! Si vous optez pour une approche clé-en-main, notez que Catalyst Center est notifié automatiquement en cas modification de configuration sur un équipement via un principe similaire et déclenche alors une resynchronisation de l’équipement pour en comprendre le nouveau statut.
Références
- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1715/b_1715_programmability_cg/m_1715_prog_ietf_telemetry.html#id_90658
- https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xe-17/217427-configure-model-driven-telemetry-on-cisc.html
Authors
