Toujours dans cette volonté de rendre ses solutions le plus programmable possible, et donc automatisables et integrables facilement dans des solutions tierces, afin d'obtenir une infrastructure encore plus agile, Aruba a, au travers du nouvel OS ArubaOS-CX, permis d'aller encore plus loin dans cette stratégie, en permettant d'avoir un OS rendant les équipements totalement programmables, aussi bien d'un point de vue Software que Hardware.
Cette capacité se traduit par plusieurs aspects, comme :
- Les API REST embarquées
- Le Network Analytics Engine
- Les Websockets
Nous allons donc, au travers de plusieurs posts, découvrir ces fonctionnalités, en commençant ici par la découverte des API REST, et leur puissance.
1. Comment activer l'accès aux APIs d'ArubaOS-CX
Par défaut, l'accès aux APIs d'ArubaOS-CX n'est pas autorisé.
Pour l'activer, il est nécessaire de réaliser/valider certains aspects de configuration.
3 choses sont obligatoires :
- Le HTTPS-Server doit être activé
- L'acces aux REST API doit être activé
- Un utilisateur doitêtre présent (Soit via une authentification locale ou une authentification via TACACS ou RADIUS)
Mais ces 3 éléments sont extrêmement simples à mettre en place :
Switch(config)# user <votre_user> password plaintext <votre_password>
Switch(config)# https-server vrf default
Switch(config)# https-server rest access-mode read-write
Pour vérifier la bonne activation, vous pouvez utiliser la commande suivante :
Switch# show https-server
HTTPS Server Configuration
----------------------------
VRF : mgmt, default
REST Access Mode : read-write
Attention : Le nombre de sessions simultanées sur ArubaOS-CX est limité à 2.
Si ces deux sessions sont prises, par exemple parce que des sessions précédentes ont été mal fermées, il est possible de détruire les sessions en cours, en utilisant la commande suivante :
Switch# https-server session close all
2. Acces aux APIs via WebUI
L'accès aux APIs via WebUI se fait de manière extrêmement simple.
A partir de maintenant, vous pouvez prendre la main sur votre équipement via l’interface HTTPS, et de fait accéder à l’interface Swagger :
Lorsque vous avez cliqué sur ce lien, vous aurez alors accès au Swagger d'ArubaOS-CX :
ArubaOS-CX utilise un mode d’authentification pour l’accès aux APIs basé sur la création d’un cookie persistant.
Cette méthode implique qu’un cookie est généré lorsque l’authentification est réussie, et que ce dernier est alors géré par le navigateur.
Cela implique que lorsque vous accédez au Swagger après avoir ouvert une session sur l’interface web de management, vous n’avez pas besoin de vous réauthentifier, puisque le cookie est déjà présent dans le navigateur.
Cependant, si au contraire vous accédez au Swagger sans être passé par l’interface web de management (ce qui est possible, en tapant : https://<votre _switch>/api/), vous devez ouvrir une session, au travers de l’URI “login” :
Si l’authentification est réussie, vous obtenez alors un « Response Code » de 200, qui indique que l’objet session a bien été créé – Vous observerez que le « Response Body » ne possède aucun contenu.
Vous avez maintenant accès aux API d’ArubaOS-CX.
Au travers du Swagger d’ArubaOS-CX, vous avez accès à l’ensemble des API disponibles.
Afin de manipuler les APIs, 3 notions sont importantes à connaitre :
- Attributes : Cette option de requête permet de sélectionner les valeurs que l’on souhaite récupérer au travers de la requête. Par défaut, toutes les valeurs de la ressource seront renvoyées.
- Filters : Cette option de requête permet d’intégrer des notions de filtre sur des attributs. Par défaut, aucun filtre n’est appliqué.
- Depth : Cette option permet de déterminer la profondeur des résultats renvoyés. Plus la profondeur est élevée, plus il y aura d’informations renvoyées. Par défaut fixée à 0 – Seule le nom du dictionnaire est renvoyé.
Prenons un exemple :
Sélectionnons l’API VLAN, méthode GET :
Si on clique sur "Submit" en laissant tout par défaut, vous observerez qu'il y a assez peu d'informations remontées :
Maintenant, mettons 1 comme valeur dans le champs “depth”.
Nous avons maintenant de quoi exploiter plus précisément cette API.
Vous pouvez modifier cette valeur, jusqu’à 3, pour voir la différence.
Maintenant, en laissant la valeur “depth” sur 1, sélectionnons les attributs “id”, “name” et “type” :
Maintenant, appliquons un filtre, en mettant le VLAN_ID que nous recherchons sur notre équipement, comme “id”.
Voici ce que nous devons obtenir :
Il est également important de voir que ces options sont disponibles au travers des URI que vous utiliserez dans vos différentes requêtes :
Lorsque vous utilisez lez API d’ArubaOS-CX, l’ensemble des informations liées à la ressource recherchée sont retournées.
Par exemple, lorsque l’on fait une requête pour un VLAN, vous obtenez les informations de configuration, mais également les informations de statut et les statistiques – Ce qui explique le côté extrêmement complet des JSON retournés.
Vous avez la possibilité de sélectionner le type, ou catégorie, d’informations que vous souhaitez obtenir, en utilisant le champs « selector ».
Remettons à zéro les filtres et attributs que nous avions sélectionnés, et remplissons le champs « selector » avec « configuration », comme par exemple ici un VLAN particulier :
Vous devez alors obtenir un résultat équivalent à ce qui suit :
Vous obtenez alors une information complète sur la façon dont est configuré le VLAN.
Si vous modifiez « selector » par « status », vous aurez le résultat suivant, relatif au statut réel de la ressource VLAN :
En enfin, en modifiant « selector » par « statistics », vous obtiendrez des informations uniquement sur les statistiques liées au VLAN :
La notion de « selector » est exclusive : Vous ne pouvez utiliser d’attributs, sous peine d’obtenir une erreur de type 500. Il en est de même avec notion de « depth » - Que vous sélectionniez 0, 1, 2 ou 3, cela n’aura aucun impact sur la profondeur des informations renvoyées.
Pour finir, une dernière option intéressante dans le filtrage ou la qualification des résultats renvoyés par votre équipement : l'argument count.
Cet argument sert tout simplement à vous renvoyer le nombre d'éléments retournés par équipement.
Par exemple, vous souhaitez uniquement savoir le nombre de VLAN existants sur votre équipement. Il suffit alors juste de mettre le filtre "Count" a True :
et vous obtenez tres simplement la reponse :
L'argument "Count" est bien entendu utilisable avec des attributs autres. Comme par exemple si nous souhaitons savoir le nombre de VLAN avec un "oper_state" à "up" uniquement.
Nous en avons terminé avec cette première découverte des APIs d'ArubaOS-CX, qui permet de bien voir toute la puissance de ces dernières.
Si vous souhaitez en savoir plus :