Forum Français

Reply
Aruba Employee

How-To AOS-Switch : Gestion des configurations via REST API

Bonjour à tous,

 

La gestion des configurations est un élément important dans une politique d'automatisation du réseau, en plus, entre autre, de des interactions possibles entre les solutions et l'adaptabilité de l'infrastructure.

Je souhaitais faire un focus sur la gestion des templates :

Comment gérer le déploiement de blocs de configuration complète via les API disponibles dans AOS-Switch, ou tout simplement de lignes de configurations ou services, afin de permettre la mise en place d’une politique d’automatisation du réseau plus complète ?

Pour ce faire, il existe différentes façons de réaliser ce type d’opérations, et nous allons donc les voir au travers de ce post.

 

1. Environnement de test

 

L’environnement suivant a été utilisé pour les exemples décrits ci-dessous :

  • Switch : HPE Aruba 2930F, en standalone et en 16.05.0003.
  • IDE : PyCharm Community Edition 2017
  • Python : Version 3.6, avec les packages "requests", "base64", "yaml" et "jinja2". 
  • POSTMAN : Installé comme application dans Google Chrome.
  • Serveurs Tiers : Un serveur FTP et un serveur Web

     

environnement.png

  

Pour rappel, la description des opérations pour la mise en place et la connexion via REST API sur AOS-Switch est décrite dans les 2 posts cités ci-dessous. Je ne reviendrai donc pas dessus dans les parties qui vont suivre.

 

2. Fonctions standards de déploiement de configurations

 

Comme déjà évoqué dans un post précédent, AOS-Switch 16.04 a amené, entre autre, les nouvelles API AnyCLI et Batch_CLI.

Ces API permettent ainsi de pouvoir n'importe quelle commande ou blocs de commandes à un équipement, sous la forme d'une simple requête.

 

Il est de même possible d'utiliser les URI spécifiques afin de déployer des fonctionnalités spécifiques sur un équipement.

   

3. Déploiement d’une startup-config via API RESTful

 

Les API présentées ci-dessus sont extrêmement pratiques, mais peuvent se révéler fastidieuses à utiliser lors d’opérations de déploiement de configurations complètes, car certaines commandes vont par exemple demandées le redémarrage de l’équipement ou un séquencement particulier, ou bien dans le cadre de reconditionnement de certains équipements. Il devient alors intéressant de pousser une configuration complète

C’est notamment dans ce but qu'existe l’API File-Transfer.

 

Mode de fonctionnement

 

Cette API permet en effet de pouvoir demander à l’équipement d’uploader ou de downloader certains éléments sur des serveurs Web tiers, en HTTP ou HTTPS.

 

Au même titre que chaque API, File-Transfer utilise une URI spécifique afin de recevoir les commandes : http(s)://<@IP_switch>/rest/v3/file-transfer

  

L’API va donc demander au switch d'aller chercher un fichier nommé "config" sur le serveur spécifié dans le corps de la requête, le télécharger, et l’appliquer en tant que Startup Configuration. Si le fichier est valide, alors l’équipement est automatiquement redémarré afin que cette nouvelle configuration soit prise en compte.

 

Nota : Attention, dans le cas de la fonction upload, il est nécessaire que la fonction WebDav soit activée sur votre serveur Web.

 file-transfer.png

 

Le JSON doit comporter, à minima, les clés suivantes :

  • "file_type", qui indique le type de fichier qui est à télécharger, et donc le type d'opération.
  • "url": qui indique l'URL complète à laquelle se trouve le fichier "config"
  • "action": qui indique s'il s'agit d'un upload ou d'un download.

Dans notre cas de gestion des configurations, nous utiliserons donc le JSON suivant :

 {
        "file_type":"FTT_CONFIG",
        "url":"http://<@IP_Web_Server>/config",
        "action":"FTA_DOWNLOAD",
 }

 

Exemple

Nous allons donc utiliser ce système pour pousser une configuration complète sur un équipement qui est toujours sur une configuration basique. Pour ce faire, nous utiliserons donc le script suivant :

 

# On spécifie l'URI pour le transfert de fichier
url_file = "http://<@IP_Switch>/rest/v3/file-transfer"

# On crée le dictionnaire comportant les informations nécessaires (actions / URL / etc...) - "/config" représentant un fichier, pas un répertoire. data = { "file_type":"FTT_CONFIG", "url":"http://<@IP_Web_Server>/config", "action":"FTA_DOWNLOAD", }

# On lance la requête au format POST post_file = requests.posts(url_file, data=json.dumps(data), headers=headers)

Voici un exemple pour illustrer cette application.

 

Nous avons un switch dans une configuration simple, dont voici le "show run" :show run - before FTT_Config - reformat.png

 

Nous allons utiliser l'API File-Transfer afin de lui appliquer une configuration plus avancée, et ainsi le rendre totalement opérationnel.

 On exécute le script présenté ci-dessus, ce qui nous donne les informations suivantes sur l'équipement :

  

debug good - HTT_CONFIG - cadres.png

   

Dans cette observation du debug, on peut y observer 3 informations importantes :

Dans le cadre rouge, on voit que le template a bien été téléchargé par l'équipement.

Dans le cadre orange, on voit que certaines notifications sont remontées lors de la modification de la Startup Configuration. Dans cet exemple, il s'agit juste de notifications "informationnelles", donc rien de bloquant.

Dans le cadre vert, il est indiqué que la Startup a bien été modifiée, et que l'équipement est redémarré.

 

Une fois de nouveau joignable, on peut constater que la nouvelle configuration est bien appliquée :

 

show run - after FTT_Config - reformat.png

 

Nous venons donc, au travers d'une simple API, de demander à l'équipement de télécharger sa nouvelle configuration sur un serveur distant, de l'appliquer en tant que startup configuration, et de redémarrer pour la prendre en compte.

 

Debug

 

Il peut être nécessaire de bien faire attention à ce que le fichier de configuration comprennent l'ensemble des informations nécessaires à la constitution d'un fichier de configuration valide, comme la commande "module" par exemple, et que le séquencement des commandes soit correct.

Si certains problèmes arrivent lors de l'utilisation d'un script basé sur File-Transfer, il est bien entendu possible de suivre le déroulé des opérations réalisées par l'équipement, et ainsi de voir éventuellement quels ont été les problèmes.

Comme par exemple, dans cet extrait de debug  :

 

debug error - HTT_CONFIG - cadres - reformat.png

  

Dans le cadre rouge, on voit qu'une ligne de la configuration a posé un problème - Ici, la ligne 71, puisque la commande "tagged10" est mal formée. C'est donc une notification de type "Warning".

Dans le cadre vert, on observe une autre notification de type "Warning", qui indique le fichier est corrompu, et que de ce fait, la mise en place de la configuration ne sera pas effectuée.

 

On retrouve également ce type d'informations dans les logs :

 log error - HTT_CONFIG - reformat.png

  

Add-On : Mise à jour d’un équipement

 

Comme évoqué, l'API File-Transfer n'est pas dédiée uniquement au transfert de fichier de configuration.

Il est donc aussi possible, entre autre, de l'utiliser pour réaliser une mise à jour de l'équipement.

Dans ce cadre, on utilisera le script suivant :

 

# On spécifie l'URI pour le transfert de fichier
url_file = "http://<@IP_Switch>/rest/v3/file-transfer"

# On crée le dictionnaire comportant les informations nécessaires (actions / URL / etc...) data = { "file_type":"FTT_FIRMWARE", "url":"http://<@IP_Web_Server>/<file>.swi", "action":"FTA_DOWNLOAD",
"boot_image": "BI_PRIMARY_IMAGE" }

# On lance la requête au format POST post_file = requests.post(url_file, data=json.dumps(data), headers=headers)

On demande au switch de télécharger le code disponible à l'URL spécifiée, et de le placer dans la flash primaire. Une fois téléchargé, il suffit de redémarre l'équipement, ce qui peut bien évidemment se faire via API (".../system/reboot").

Si on souhaite pousser le code dans la flash secondaire, il suffit de spécifier "BI_SECONDARY_IMAGE" comme valeur de la clé "boot_image"

Un pas de plus vers une plus grande automatisation du réseau.

 

4. Déploiement d’une configuration complète sans via Cfg_Restore

 

En plus de toutes les API citées ci-dessus, et permettant de pouvoir déployer des templates plus ou moins complexes sur des équipements, la version AOS-Switch 16.05, qui est désormais disponible au téléchargement, amène la fonctionnalité « Cfg_Restore ».

Au même titre que l’API File-Transfer, l’API Cfg-Restore permet de déployer des templates complets de configuration sur des équipements distants, mais ici sans redémarrage de l’équipement.

 

De plus, l’API « Cfg_Restore » permet de pouvoir télécharger le fichier souhaité, et non plus seulement le fichier « config ». Il est donc possible de générer des templates différents en fonctions du type d’équipements, de la localisation, etc… mais également de les sauvegarder unitairement pour des raisons de backup.

 

La configuration est donc prise immédiatement en compte par l’équipement, sans coupure de service, puisqu'il s'agit tout simplement d'une mise à jour de la Running Configuration.

 

Mode de fonctionnement

 

Au même titre que chaque API, Cfg-Restore utilise une URI spécifique afin de recevoir les commandes : http(s)://<@IP_Switch>/rest/v4/cfg_restore

 

L’API va donc demander au switch d'aller chercher le fichier spécifié sur le serveur également indiqué dans le corps de la requête, le télécharger, et de l'utiliser en tant que support pour adapter la Running Configuration. 

Aucun redémarrage n'est donc nécessaire une fois que les modifications sont appliquées.

 

La structure du JSON doit comporter les clés suivantes :

  • "server_type": indique le type de serveur utilisé pour le téléchargement (TFTP/SFTP)
  • "file_name": indique le nom du fichier à téléchargé
  • "tftp_server_address": Informations IP du serveur utilisé

Ce qui donne :

 {  "server_type": "ST_TFTP",
    "file_name": "template_full.cfg",
    "tftp_server_address":

                {"server_address":

                     {"ip_address":

                           {"version": "IAV_IP_V4",

                            "octets": "<@IP_TFTP>"}}}

}

 

cfg-restore.png

 

Nota 1 : l'API Cfg-Restore est uniquement disponible en v4 des API AOS-Switch.

Nota 2 : TFTP a été utilisé pour cette illustration - Comme évoqué, SFTP peut également être utilisé. 

Nota 3 : Cette fonctionnalité est également disponible via CLI, donc sans l’usage d’API. Son application est donc disponible de manière pus "traditionnelle", mais moins adaptée à une politique d'automatisation du réseau.

 

Exemple

 

Comme pour l'API File-Transfer, nous supposons que notre équipement possède une configuration "basique", et que nous souhaiterions lui appliquer une configuration plus évoluée.

Nous utiliserons donc le script suivant :

  

# Nous créons l'URI qui sera utilisée pour l'opération, avec l'URI "config/cfg_restore", en v4.
url_restore = "http://<@IP_Switch>/rest/v4/system/config/cfg_restore"
# Nous créons notre dictionnaire
data = { "server_type": "ST_TFTP", "file_name": "restore.cfg", "tftp_server_address": {"server_address":
{"ip_address":
{"version":"IAV_IP_V4",
"octets":"<@IP_TFTP>"}}}, }


# Nous lançons la requête de type POST. post_restore = requests.post(url_restore, data=json.dumps(data), headers=headers)

Pour illustrer tout ceci, voici la configuration du switch avant l'opération :

show run - cfg-restore - before - reformat.png

  

Nous exécutons le script, ce qui nous donne le JSON de retour suivant :cfg-restore - json success.PNG

 La clé "failure_reason" est vide, donc tout s'est bien passé - Vérification :

show run - cfg-restore - after - reformat.png

 

Pour visualiser le fait qu'aucun redémarrage n'a été nécessaire, j'ai donc laissé la commande utilisée pour illustrer l'état avant le script, et taper directement la commande "show run" après exécution. Nous sommes donc toujours dans la même session, et les "show run" sont bien différents. 

La nouvelle configuration a bien été appliquée avec succès, sans aucun redémarrage.

 

Debug

 

La fonctionnalité "Cfg-Restore" a la particularité d'embarquer également une fonction de debug dédiée.

Il est donc possible de suivre en direct l'application de la nouvelle configuration.

 

Sur cette première capture, la fonction cfg-restore réalise en premier lieu la différence entre la configuration courante et la configuration cible, et indique le nombre de changements à effectuer.

debug cfg-restore - 1.PNG

 

Sur cette seconde capture, on voit l'application des différentes lignes de commandes pour mettre à niveau la running-configuration. Et au final, que l'application s'est correctement déroulée.debug cfg-restore - 2 - cadres.png

  

Mais les fonctions de troubleshooting sont également là pour aider à debugguer lors de problèmes d'application de la nouvelle configuration.

 

Tout d'abord, dans le JSON de retour de la requête, où la clé "failure_reason" est alors renseignée avec la cause de l'échec :

 

cfg-restore - json failure.PNG

 

Nous pouvons également retrouver les informations nécessaires dans les logs de l'équipement :cfg-restore - log failure - cadres.png

  

Comme pour File-Transfer, nous retrouvons dans le cadre vert les lignes qui ont posées problèmes.

Nous retrouvons également dans le cadre rouge la notification indiquant que le fichier est corrompu, et donc non appliquable.

 

Add-On : Fonctionnalités additionnelles de « Cfg_Restore »

 

La fonctionnalité Cfg-Restore vient également avec des fonctions annexes, notamment une très intéressante : "Cg_Restore_Diff".

Cette fonction permet de soumettre à l'équipement le fichier cible, sans qu'il soit appliquer, et d'en ressortir les différents, aussi bien en ajout qu'en suppression.

Par exemple, nous utilisons le script suivant :

  

# Nous créons l'URI utilisée pour soumettre le fichier cible.
url_restore = "http://<@IP_Switch>/rest/v4/system/config/cfg_restore/latest_diff"

# Nous créons le dictionnaire utilisé pour spécifier les informations de connexion et le nom du fichier cible. data = { "server_type": "ST_TFTP", "file_name": "restore.cfg", "tftp_server_address":
{"server_address":
{"ip_address":
{"version":"IAV_IP_V4",
"octets":"<@IP_TFTP"}}}, }
# Nous soumettons la requête sous forme de POST
post_restore = requests.post(url_restore, data=json.dumps(data), headers=headers)

Cette seule requête ne sert qu'à soumettre la configuration cible et lancer le calcul des différences :script - restore diff.PNG

  

Il est donc nécessaire ensuite de faire une nouvelle requête, sur une nouvelle URI pour récupérer le résultat de ce calcul de différence. Nous utisons donc : 

 

# Nous créons donc une nouvelle URL, qui pointe vers l'URI "status"
url_diff_status = "http://<@IP_Switch/rest/v4/system/config/cfg_restore/latest_diff/status"

# Nous lançons la requête sous forme de GET get_diff = requests.get(url_diff_status, headers=headers)

Ce qui nous donne :

script - restore diff status - reformat.png

  

La requête nous retourne le résultat du calcul au format JSON, avec notamment une clé "diff_add_list", ainsi qu'une clé "diff_remove_list", ce qui nous permet donc de pouvoir obtenir la liste des différences qui seront appliquées, avant mise en production, notamment à des fins de contrôle.

  

D'autres fonctions sont également associées à la fonctionnalité "Cfg_Restore", mais feront l'objet d'un post ultérieur.

 

5. Gestion dynamique des templates via Jinja2 et YAML

 

La gestion des templates et le provisioning des équipements sont des fonctionnalités importantes de l’automatisation du réseau.

Mais cela peut très vite devenir fastidieux dès lors qu’un certain nombre d’équipements sont à provisionner, notamment lorsque certaines valeurs de la configuration sont différentes en fonction de la localisation, du type d’équipement, ou de la volumétrie de ports.

Pour cela, et afin de simplifier grandement les choses, il devient nécessaire de générer dynamiquement des templates de configuration qui seront appliqués aux équipements.

 

Deux notions sont alors importantes à prendre en compte lorsque l’on commence à manipuler et mettre en production ce type de solution :

  1. Générer un fichier inventaire, dans lequel l’ensemble des informations nécessaires à la génération des templates seront présentes. On parle alors de Représentation de Données (Data Format). Le format utilisé ici sera YAML, car reconnu comme étant un des plus simples à mettre en place, mais également à comprendre/lire.
  2. Se baser sur un moteur de génération de templates, permettant de prendre en compte dynamiquement les valeurs nécessaires à la création du template requis, mais permettant également la gestion des cas spécifiques, comme les conditions ou les boucles. Le moteur utilisé dans ce post sera Jinja2.

YAML

 

Comme évoqué ci-dessus, YAML (YAML Ain't Markup Language) est une representation de données très fréquemment utilisée car extrêmement simple à mettre en place, comprendre/lire, mais également à maintenir. 

L’idée du formatage est très simple et se base sur une hiérarchisation des données très claires, comme par exemple :

  

Devices :
    - serial: ABCDEFG
hostname: Switch1 site: Site1 model: 2930F-24G ip: 192.168.10.1 gateway: 192.68.10.254 vlan: 1,10,20,30,50 - serial: HIJKLMN
hostname: Switch2 site: Site1 model: 2930F-24G ip: 192.168.10.1 gateway: 192.68.10.254 vlan: 1,10,20,30,50 

Dans cette représentation, nous avons donc créé un inventaire des équipements, avec des informations spécifiques à chacun. Notre script de provisioning pourra donc récupérer ce fichier, et les intégrer dans le template de configuration.

Si la lecture est préférée sous format « liste», il également possible d’écrire avec la formalisation suivante :

  

devices : [{"serial" : "ABCDEFG",
            "hostname": "Switch1",
            "Site": "Site1",
            "model": "2930F-24G",
            "ip": "192.168.10.1",
            "gateway": "192.68.10.254",
            "vlan": "1,10,20,30,50"},
           {"serial": "HIJKLMN",
            "hostname": "Switch2",
            "site": "Site1",
            "model": "2930F-8G",
            "ip" : "192.168.10.2",
            "gateway" : "192.68.10.254",
            "vlan": "1,10,20,30,50"}]

Pour plus d'informations, le site officiel de YAML est disponible à l’URL suivante : http://www.yaml.org/

 

Joe Neville, de la Win Team Aruba, a également fait une vidéo autour de l'utilisation de fichier YAML avec Python et les API AOs-Switch sur la (très bonne) chaîne YouTube "ABC Networking". Je vous invite donc à la visionner si vous désirez en savoir plus : https://youtu.be/m24wj6JSiUU

 

Exemple d’utilisation

 

Voici un exemple d’utilisation de YAML avec Python :

  

# On importe le module yaml
import yaml
# On ouvre le fichier inventaire "data.yml", et on le charge dans un objet Python with open("data.yml") as stream:     data = yaml.load(stream)

# Un fichier YAML pouvant inclure plusieurs listes, on choisit de prendre la liste "devices", et la charger dans la variable data_values data_values = data['devices’]

# On parcourt avec une boucle "for" pour récupérer les données nécessaires. for device in data_values: print(“Hostname : {} - IP Address {}”.format(device[‘hostname’],device[‘ip’])

Ce qui nous donnera :

  

Hostname : Switch1 - IP Address : 192.168.10.1
Hostname : Switch2 - IP Address : 192.168.10.2

JINJA

 

Jinja est un moteur de templating pour Python, qui permet de pouvoir générer des templates complet de manière extrêmement dynamique.

La puissance de Jinja, et du coup du principe de moteur, est de pouvoir embarquer nativement, et directement dans le template source, qui un « .j2 », des règles de design et de complétion, tels que des conditions ou des boucles.

Jinja2 peut récupèrer les valeurs à intégrer dans une source de données tierces, telle qu’un fichier YAML.

Voici un exemple de template au format Jinja2 :

  

{%- if temp.download %}
aaa authorization user-role enable download
{%- else %}
aaa authorization user-role enable
{%- endif %}
aaa port-access authenticator 1-{{ temp.ports }}
{%- for n in range(temp.ports) %}
aaa port-access authenticator {{ n+1 }} client-limit 3
{%- endfor %}
aaa port-access authenticator active
vlan 1
   name "DEFAULT_VLAN"
   untagged 1-{{ temp.access_ports }}
   no ip address
   exit
vlan 100
   name "Management "
   tagged {{ temp.uplink_ports }}
   ip address {{ temp.mgmt_ip }}
   exit

De très nombreuses autres règles de personnalisation du templating via Jinja sont disponibles à l’URL suivante :

http://jinja.pocoo.org/docs/2.10/

 

Exemple d’utilisation

Voici un exemple d’utilisation de Jinja2 :

  

# Import des fonctions nécessaires à partir du module Jinja2
from jinja2 import Environment, FileSystemLoader

# Création du dictionnaire inventaire
valeurs = {"download": True, 
"mgmt_ip": "192.168.1.10",
"access_ports": "8",
"uplink_ports": "9-10"}
# Création de l'environnement Jinja ENV = Environment(loader=FileSystemLoader('.'))
# Import du fichier template dans une variable "template" template = ENV.get_template("template.j2")
# Création du template final avec les valeurs contenues dans le dictionnaire "valeurs" - Ces valeurs sont positionnées dans un objet "temp", qui sera utilisé par le moteur, et que l'on retrouve dans le template. conf = template.render(temp=valeurs)

 Dans ce cas, le template généré sera le suivant :

 

aaa authorization user-role enable download
aaa port-access authenticator 1-8
aaa port-access authenticator 1 client-limit 3
aaa port-access authenticator 2 client-limit 3
aaa port-access authenticator 3 client-limit 3
aaa port-access authenticator 4 client-limit 3
aaa port-access authenticator 5 client-limit 3
aaa port-access authenticator 6 client-limit 3
aaa port-access authenticator 7 client-limit 3
aaa port-access authenticator 8 client-limit 3
aaa port-access authenticator active
vlan 1
   name "DEFAULT_VLAN"
   untagged 1-8
   no ip address
   exit
vlan 100
   name "Management "
   tagged 9-10
   ip address 192.168.1.10 255.255.255.0
   exit

Combinaison Jinja2 et YAML

 

On peut donc aisément imaginer la combinaison des deux, de manière à très grandement simplifier un déploiement automatisé massif :

  

import yaml
from jinja2 import Environment, FileSystemLoader

with open("data.yml") as stream:
    data = yaml.load(stream)

devices_values = data['devices']

jinja_env = Environment(loader=FileSystemLoader('.'))
template = jinja_env.get_template("template.j2")

for device in devices_values:
     conf = template.render(temp=device)

6. Résumé

  

Nous venons donc de voir au travers de ce post qu'il existe de très nombreuses façons de pouvoir déployer des configurations plus ou moins complètes sur les équipements AOS-Switch grâce à la puissance des API, mais également, grâce à des solutions comme YAML ou Jinja2, de gérer aisément ce type de déploiement de manière massive et totalement dynamique.

 

Bien que la gestion des configurations n'est qu'une partie d'une politique  d'automatisation d'un réseau, cela en reste tout de même une partie importante.

 

N'hésitez pas à revenir vers l'équipe Avant-Vente Aruba France si vous avez la moindre question.

 

Et maintenant, Let's Automate !!

New Contributor

Re: How-To AOS-Switch : Gestion des configurations via REST API

Bonjour,

 

Merci pour ce post très complet et très éclairant sur cette fonctionnalité de cfg restore.

 

J'aurais quelques petites questions :

- en cli, il est possible de lancer un cfg-restore suivi d'une option force, qui provoque un reboot si une option le nécessite. Cette fonctionnalité existe-t-elle aussi via l'api REST ? En effet, si la config nécessite un reboot, celle-ci risque d'être rejetée sans l'option force.

 

" force                 Apply the configuration with reboot if the configuration has reboot required commands or system-wide change commands present."

 

- quelles sont les options à spécifier pour lancer un restore par sftp ? En particulier, le login et le mdp ? 

 

Cordialement,

 

Aruba Employee

Re: How-To AOS-Switch : Gestion des configurations via REST API

Bonjour,

 

1. Option Force - C'est un bon point. Oui la fonction "force" existe egalement via l'API REST. Il faut pour cela utiliser la clé "is_forced_reboot_enabled", et la fixer a True ou False.

 

2. Pour utiliser SFTP au lieu de TFTP, alors il faut utiliser la clé suivante, qui pointe vers le schema sftpServer :

"sftp_server_address":
{
"server_address": "<SFTP_IP_Address>",
"user_name": "<votre_user>",
"port_number": "<Eventuellement_port_specifique>",
"password": "<votre_password>"
}

 

Ce qui donnerait, au global, en prenant en compte le Force_Reboot :

data = {
           "server_type": "ST_SFTP",
           "file_name": "restore.cfg",
           "sftp_server_address": {
                   "server_address": {"ip_address":
                                                       {"version":"IAV_IP_V4",
                                                        "octets":"<@IP_SFTP"}}},
                   "user_name": "<votre_user>",
                   "port_number": "<Eventuellement_port_specifique>",
                   "password": "<votre_password>"
                    },
         "is_forced_reboot_enabled": True
}

 

New Contributor

Re: How-To AOS-Switch : Gestion des configurations via REST API

Bonjour,


Merci beaucoup ! Il existe une doc complète sur toutes les options de l'api rest v4, du cfg restore etc ? Ou bien les fonctionnalités sont encore en beta ? 

 

Cordialement,

Aruba Employee

Re: How-To AOS-Switch : Gestion des configurations via REST API

L'ensemble des API REST sont décrites dans l'archive suivante :

REST API and JSON Schema

 

Vous y trouverez le descriptif de l'ensemble des API disponibles, ainsi que les JSON associés.

 

Elle est disponible sur le site de telechargement du support, pour chaque equipement AOS-Switch.

Par exemple pour, le 2930M :

https://h10145.www1.hpe.com/Downloads/SoftwareReleases.aspx?ProductNumber=JL319A&lang=fr&cc=fr&prodSeriesId=7399420

 

La derniere archive en date est pour la 16.05.

L'archive liée à la 16.06 devrait arriver rapidement.

New Contributor

Re: How-To AOS-Switch : Gestion des configurations via REST API

Bonjour,

Parmis les modèles compatibles avec l'api v4 rest ne figure visiblement pas le 2620, ni le cfg-restore d'ailleurs; une raison à cela ? Sauf erreur de ma part, il est toujours maintenu par HPE et ses carractéristiques internes semblent pas limitantes ?

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: