Tous mes voeux à tous ! Afin de commencer cette nouvelle année, nous allons poursuivre notre découverte de l'automatisation avec ArubaOS-CX.
Le Network Analytics Engine est un outil qui s’utilise avant tout au travers de la WebUI d’ArubaOS-CX. Il reste cependant disponible au travers de la CLI et des APIs.
Nous allons donc reprendre notre script utilisé dans la partie 4.1, qui permettait de pouvoir monitorer le statut d’une interface spécifiée, et de prendre des actions lorsque cette dernière passe en statut « down ».
Nous allons prendre le script natif, sans l’utilisation des « clear_actions ». Dans ce cadre, le script utilise la methodologie suivante :
- Un monitor, qui monitore le statut d’une interface donnée en paramètre.
- Une premiere règle, qui, si le statut passe de “up” à “down”, lance les actions comprises dans la fonction “action_interface_down”
- Une seconde règle, qui, si le statut passe de “down” à “up”, lance les actions comprises dans la fonction “action_interface_up”
Afin d’uploader un script dans le Network Analytics Engine, il est donc nécessaire de prendre la main sur la WebUI, et de se rendre dans le menu « Analytics » :

A partir de cette page, vous avez accès alors à l’ensemble des informations liées au Network Analytics Engine :
- La liste des agents créés (activés ou desactivés)
- La liste des scripts installés (utilisés ou non)
- La liste des alertes
- Les widgets de certains agents (personnalisable)
- Un lien vers la liste des scripts disponibles sur Aruba Solution Exchange
La première étape est donc d’installer un script sur le Network Analytics Engine.
Pour se faire, allez dans « scripts ». Vous pouvez alors soit uploader le script, soit l’installer via la page dédiée a ASE :

Si vous souhaitez consulter la liste des scripts disponibles sur ASE, cliquez alors sur le logo « ASE ». Vous obtiendrez alors la liste complète des scripts disponibles, avec plusieurs actions possibles :

Si nous revenons sur la méthodologie de gestion de vos scripts, vous devez alors cliquer sur « Upload ». Vous obtiendrez alors la fenêtre suivante, qui vous permet de naviguer jusqu’à votre script, ou simplement de faire un drag-and-drop.
Les informations liées à votre script, contenues dans le dictionnaire « Manifest » apparaissent alors :

Vous avez également la possibilité de faire un « write memory » en cochant la case « copy running configuration to startup ». Sinon, si le switch redémarre de manière inopinée, alors le script, et le ou les agents associés ne seront plus présents.
Une fois le script uploadé, il passe par une phase de validation, afin que NAE vérifie la conformité du script, que ce soit pour vérifier la présence des éléments obligatoires, comme le "manifest" ou qu’il n’y a pas d’erreurs de syntaxe.
Une fois le script présent sur l’équipement, il suffit alors de créer l’agent, en spécifiant le nom de l’agent ou en renseignant les valeurs des paramètres si ceux par défaut ne conviennent pas :

L’agent est donc créé, et la page dédiée est automatiquement générée, incluant la partie graphe.
Étant donné que par défaut l’état de l’agent lors de sa création est sur « Enable », il entre directement en action, sans attendre une action quelconque de l’administrateur :

On y retrouve le listing des paramètres, avec la possibilité de modifier à tout moment les éléments définis lors de la création de l’agent, y compris la possibilité de l’activer ou de le désactiver.
En cliquant sur un paramètre, on retrouve la description donnée dans le script.

Notre agent NAE est désormais actif et opérationnel.
- Les agents NAE en action
L’agent est donc actif, et en statut « Normal ».
Dans notre use case simple, l’agent est là pour superviser le statut de l’interface 1/1/1.
Faisons donc un test afin de vérifier le comportement et les éventuelles actions prises par notre agent. Sur l’équipement :
Switch-CX# conf
Switch-CX(config)# int 1/1/1
Switch-CX(config-if)# shutdown
Au bout de quelques secondes, nous voyons donc le script qui réagit, notamment avec une barre d’alerte qui apparait en bas de la page, informant l’administrateur que le statut de l’agent est passé de « Normal » à « Critical ». Cette barre apparaît quelque soit la page sur laquelle se trouve l’administrateur :

Plusieurs éléments nouveaux apparaissent alors.
Sur le graphe, nous avons des triangles qui apparaissent. Lorsque le triangle est rouge, il indique donc un passage de l’état Normal à l’état Critical :

Dans la partie « Alerts », une alerte nommée « Link went down », avec les types d’actions entreprises. Dans notre cas, comme définit dans le script : 1 changement d’alerte, 2 actions CLI, et 1 action de création de log :

Si on clique sur « Details » de l’alerte, alors nous obtenons toutes les informations relatives à cette dernière, avec une description complète de ces éléments, mais également le statut des actions et commandes CLI passées:

Et si on clique sur un « output » en face d’une commande, nous obtenons tout simplement le résultat de cette dernière. Dans notre cas :

Si nous réactivons l’interface, alors le statut revient à « Normal », avec une barre d’alerte l’indiquant.

De la même façon que pour le passage en mode Critical, nous avons une alerte générée, avec les actions réalisées :

2. Optimisation du script
Modifions maintenant notre script, en incluant la notion de « clear_actions » :
self.r1 = Rule('Interface Status changed')
self.r1.condition('transition {} from "up" to "down"', [self.m1])
self.r1.action(self.action_interface_down)
self.r1.clear_condition('transition {} from "down" to "up"', [self.m1])
self.r1.clear_action(self.action_interface_up)
Si nous refaisons la même action de faire un shutdown sur l’interface, alors nous obtenons cette nouvelle alerte :

Et si nous la réactivons :

Nous venons de voir très simplement que nous pouvons simplifier et optimiser facilement notre script en évitant de multiplier les règles de monitoring.
Maintenant, passons sur une action de modification automatique de la configuration. Pour cela, nous souhaitons que le script tente de réactiver l’interface de manière automatique dès que cette dernière est détectée comme « down ». Cela peut alors permettre d’optimiser les temps de recouvrement en cas de modification de la configuration de manière involontaire ou en cas d’erreur humaine.
Pour cela, modifions la fonction d’action de la manière suivante :
ActionCLI("show lldp configuration {}", [self.params['interface_id']])
ActionCLI("show interface {} extended",[self.params['interface_id']])
ActionCLI("config
interface 1/1/1
no shutdown
exit
exit",[self.params['interface_id']], title=Title("No shutdown command on the interface"))
Notre ajout ici permet, comme si nous étions en CLI, d'aller dans le contexte de l'interface définie en tant que paramètre, et de faire un "no shutdown". Un titre, optionnel, est également positionné, afin de donner à cette commande, dans la fenêtre "Details" de l'alerte, une identification plus simple.
Une fois le script mis a jour et uploadé, on désactive l’interface.
Une alerte est alors générée, avec cette fois ci 3 actions, au lieu des 2 initiales :

Si on regarde de plus prêt, en cliquant sur « Details », on peut voir que notre nouvelle commande a été passée avec succès, et on peut même voir le contenu de la commande :


Mais ce n’est pas tout. Si on retourne sur le graphe, on peut voir que le statut de l’interface est automatiquement remonté, après quelques secondes.

Cela est confirmé par les alertes, puisqu’une nouvelle alerte est générée 30 secondes après, sans que l’administrateur n’ait eu a intervenir :

3. Eléments complémentaires
Comme vous pouvez le voir sur la page "Analytics" de la WebUI de votre équipement, plusieurs widgets sont disponibles. Ces widgets permettent d'accéder rapidement à l'information relative à un ou des agent(s) important(s).

Afin d'ajouter un widget, il suffit tout simplement, sur la partie "Agents" de cliquer le symbole "+" situé à côté de votre agent.
Enfin, sur le dashboard de la WebUI, vous disposez également d'un widget relatif au Network Analytics Engine. Il permet de pouvoir disposer rapidement de nombreuses informations sur l'état de l'outil.

En cas de problèmes sur le code Python, alors une alerte apparaît en face du script récemment importé :
