python – Page 2 – Gilbert MOÏSIO

12 novembre 20203 mars 2022

ALE AOS8 Web Services

Dernière modification le 3 mars 2022

Alcatel-Lucent Enterprise le rappelle régulièrement : « l’objectif est de n’avoir à terme que des commutateurs Ethernet en AOS8 ». Effectivement, tous les modèles qui sont sortis et se sont rajoutés au catalogue, parfois en remplacement de modèles existants, font tourner la version 8 de l’AOS. Dans ce contexte il était intéressant de voir les possibilités offertes en matière d’automatisation externe en environnement homogène.

Pour rappel, lorsqu’on est dans un contexte de mixité AOS6 et AOS8, les possibilités sont les suivantes :

Utiliser la librairie Netmiko avec Python, pour laquelle j’avais écrit le module AOS en 2017 et qui est toujours maintenu par Kirk Byers lors des différentes montées de version de la librairie.
Utiliser le Network Module ale_aos que j’ai écrit pour Ansible en 2020.

C’est la fonction Web Services qui permet de personnaliser et d’étendre l’interface de gestion sur les dispositifs AOS8. Dans le cas qui nous intéresse, il prend en charge l’utilisation d’une interface web basée sur REST qui interagit avec les variables de gestion AOS (MIB) et les commandes CLI. Donc, il fournit deux méthodes de configuration via la gestion directe des variables MIB ou l’utilisation de commandes CLI et prend en charge à la fois les formats de réponse en XML et en JSON.

Il ne faut pas confondre REST et le protocole RESTCONF qui utilise le modèle de données YANG. REST est un ensemble de directives pour l’architecture logicielle des systèmes distribués et AOS8 supporte les verbes suivants :

GET : pour récupérer des informations. C’est un équivalent grossier de SNMP / MIB GET mais aussi, à un niveau supérieur, un équivalent de la commande show. Ce verbe est utilisé exclusivement pour les commandes en lecture seule et sans autre effet secondaire.
PUT : pour créer de nouvelles informations, comme, par exemple, un nouveau VLAN. Il s’agit d’une opération d’écriture.
POST : fonctionne de la même façon que lors de la soumission de formulaires Web et il est utilisé, dans un contexte de service Web, pour mettre à jour des informations existantes.
DELETE : pour supprimer des informations existantes.

Continuer la lecture

30 octobre 202030 octobre 2020

Représentations UML des modules Arista YANG OpenConfig

Je vous propose une archive contenant des images, au format png, des représentations UML des modules YANG OpenConfig Arista EOS-4.24.2F. Ces 139 images ont été générées avec un script utilisant pyang et plantuml.jar.

Représentations UML des modules Arista YANG OpenConfig

Téléchargement gratuit

Envoyer le lien de téléchargement à :

openconfig-interfaces format UML — openconfig-interfaces.uml

26 octobre 2020

Automatisation du générateur de trafic TRex

Comme je l’ai déjà abordé lors d’un précédent article, lorsque je souhaite utiliser un générateur de trafic en mode « stateless », je fais mon choix entre TRex et Ostinato. Lorsque l’objectif est de générer du trafic sans que la CPU du générateur ne représente un point de contention, TRex a ma préférence du fait qu’il s’appuie sur DPDK. Ostinato propose des APIs Python soumises à licence et cela fait 6 ans qu’une version « turbo » est en gestation, les priorités de son concepteur ayant été focalisées sur d’autres points. Il se pourrait qu’une version « Turbo Transmit » soit en préparation et que la sortie de cette version n’ait jamais été aussi proche.

Nous sommes dans une période d’automatisation durant laquelle aucun produit n’échappe à cette approche, et il en est de même pour les générateurs de trafic. TRex permet d’automatiser la génération de trafic à l’aide de scripts Python.

Ce lab s’appuie sur une de mes appliances générateur faisant tourner Linux Ubuntu 20.04. TRex est un produit qui évolue très régulièrement, non seulement pour l’améliorer, mais aussi pour tenir compte des évolutions de DPDK. L’installation de la dernière version de TRex est rapide avec les deux commandes : wget --no-cache --no-check-certificate https://trex-tgn.cisco.com/trex/release/latest et tar -xzvf latest. Pour pouvoir fonctionner, il est nécessaire de rajouter des dépendances et outils supplémentaires sur Ubuntu « Focal Fossa » avec la commande : sudo apt install python3-distutils build-essential. A la date d’écriture de cet article, c’est la version v2.84 de TRex qui est la dernière disponible.

Continuer la lecture

8 octobre 2020

Programmation Cisco Meraki

Cisco Meraki est une solution réseau complète gérée depuis le cloud avec une interface graphique. En terme d’automatisation, la solution Meraki propose les domaines suivants :

Captive portal API
Scanning API
Dashboard API
Webhooks

Le « Dashboard API » Meraki est une interface permettant aux programmes extérieurs d’interagir directement avec la plate-forme cloud Meraki et les appareils gérés par Meraki. L’API contient un ensemble d’outils appelés « endpoints » pour créer des logiciels et des applications qui communiquent avec le tableau de bord Meraki. C’est une API RESTful moderne utilisant des requêtes HTTPS vers une URL avec un format de données JSON. Pour tester le Dashboard Meraki, il est possible d’utiliser l’URL https://account.meraki.com/secure/login/dashboard_login avec le compte devnetmeraki@cisco.com et le mode de passe ilovemeraki, puis choisir « DevNet Sandbox ».

Ce qui pourrait nous intéresser, c’est de récupérer une clé API disponible dans Organization/Settings/profile, mais dans notre cas, c’est une clé standard permettant l’accès au Sandbox que nous allons utiliser. Il va sans dire que, comme pour un login/password, une clé API ne doit pas figurer dans les programmes sur une infrastructure en exploitation. Dans les labs, il est fréquent de prendre un raccourci sur le plan de la sécurité, qu’il ne faut pas reproduire sur le terrain. Il existe des solutions pour stocker les informations d’authentification et d’autorisation de manière sécurisée. Le produit Vault de la société HashiCorp en est un très répandu. Il existe des librairies, permettant l’accès à Vault, pour de nombreux langages et outils dont Golang, Python et Ansible qui nous concernent dans le domaine du NetDevOps. De manière plus globale, il est également possible de stocker les secrets dans NetBox qui, en plus, fait office de source de vérité.

Continuer la lecture

5 octobre 2020

Programmation Cisco NX-OS

Il existe plusieurs façon de programmer NX-OS dont celles au travers d’APIs, sachant que celles-ci pourraient se classer en deux catégories :

Controller APIs, dans laquelle on trouve Application Centric Infrastructure (ACI)
Device APIs, dans laquelle on trouve NX-API (CLI et REST) et les standards « Model Driven » NETCONF, RESTCONF et gNMI/gRPC

Entre la date de publication de NETCONF (2006) et celle de RESTCONF (2017), des implémentations d’approches plus personnelles ont été créées : NX-API CLI et NX-API REST. Le passage aux protocoles NETCONF, RESTCONF et gNMI s’appuyant sur des modèles YANG se distingue, dans la littérature, par l’utilisation du terme Open NX-OS.

C’est sur un commutateur Cisco Nexus 9300v version 9.3.5, injecté dans le simulateur EVE-NG que l’ensemble des requêtes sont générées.

NX-API CLI

NX-API CLI offre la possibilité d’incorporer des commandes CLI Cisco NX-OS dans un format de données structuré (JSON ou XML) pour être exécutées sur le commutateur via un transport HTTP ou HTTPS. Les données renvoyées seront également formatées en JSON ou XML, ce qui facilite l’analyse des données avec des langages de programmation modernes. NX-API CLI s’active sur le commutateur à l’aide de la commande feature nxapi. On notera que NX-API CLI ne supporte que l’opération POST.

Continuer la lecture

30 septembre 202030 septembre 2020

Cisco IOS-XE et RESTCONF / YANG

RESTCONF (RFC 8040) fournit une interface de programmation basée sur des mécanismes standard pour accéder aux données de configuration et d’état, mais aussi pour accéder aux opérations et événements RPC spécifiques au modèle de données défini dans le modèle YANG.

RESTCONF peut être vu comme un sous-ensemble de NETCONF qui expose les modèles YANG au travers d’une API REST (URL) à l’aide d’un transport HTTP ou HTTPS avec un encodage XML ou JSON. Il faut rappeler que RESTCONF ne supporte pas toutes les opérations NETCONF qui peuvent aller plus loin dans la granularité. Il faut également noter que RESTCONF ne gère pas de session, chaque requête possède toutes les informations nécessaires à son traitement. Les opérations supportées par le protocole RESTCONF sont les suivantes :

GET – Récupère les données d’une ressource (config / opérationnel).
POST – Crée une ressource de données de configuration.
PUT – Crée ou remplace une ressource de données de configuration.
PATCH – Fusionne les données de configuration avec une ressource cible.
DELETE – Supprime une ressource de données de configuration.

Un des outils le plus évolué pour manipuler RESTCONF est Postman. Avec son interface graphique, il permet de construire un ensemble de requêtes de manière organisée et évoluée pour tester les URLs et leurs comportements. L’authorization est passée avec les « headers », au même titre que le format de données XML ou JSON avec lequel on souhaite travailler (« application/yang-data+xml » ou « application/yang-data+json »).

Continuer la lecture

29 septembre 202029 septembre 2020

Cisco IOS-XE et NETCONF / YANG

NETCONF est défini dans le RFC 6241. Il s’agit d’un protocole transporté via TLS et SSH, qui comprend des concepts d’opérations et de configuration de datastore permettant la gestion d’un périphérique réseau. Le protocole est présenté comme une API que les applications peuvent utiliser pour envoyer et recevoir des ensembles de données de configuration et recevoir des ensembles de données d’état et de fonctionnement. NETCONF définit l’existence d’un ou plusieurs datastores de configuration et autorise les opérations de configuration dessus. Le RFC 6241 définit trois datastores :

<running>, présent dans le modèle de base
<startup>, optionnel et annoncé dans les capabilities
<candidate>, optionnel et annoncé dans les capabilities

SSH est le principal protocole de transport utilisé par NETCONF. Les étapes suivantes se produisent lors d’une session NETCONF :

Le client se connecte au sous-système NETCONF SSH.
Le serveur répond avec un « hello » qui inclut les capabilities prises en charge.
Le client répond avec des capabilities prises en charge pour établir une connexion.
Le client émet une requête NETCONF.
Le serveur émet une réponse ou effectue une opération.

Continuer la lecture

25 septembre 202013 mai 2021

Python et les formats de données

Dernière modification le 13 mai 2021

Dès que l’on utilise le langage Python pour faire de l’automatisation réseau, on se retrouve confronté au format utilisé pour représenter les données. Il en existe trois qui sont populaires et qui représentent un bon compromis entre la lisibilité pour l’être humain et pour la machine :

XML (eXtensible Markup Language)
JSON (JavaScript Object Notation)
YAML (Yet Another Markup Language)

Chacun de ces formats possède son historique avec ses avantages et ses inconvénients. Si le format YAML parait plus lisible pour un être humain, il ne peut pas se compresser car le formatage doit être respecté pour garder son intégrité. Voici une même donnée représentée dans chacun des formats :

<?xml version="1.0" encoding="UTF-8" ?>
<root>
  <user>
    <name>Gilbert</name>
    <location>
      <city>Toulouse</city>
      <country>France</country>
    </location>
    <roles>admin</roles>
    <roles>user</roles>
  </user>
</root>

{
    "user": {
        "name": "Gilbert", 
        "location": {
            "city": "Toulouse", 
            "country": "France"
        },
        "roles": [
            "admin",
            "user"
        ]
    }
}

---
user:
  name: Gilbert
  location:
    city: Toulouse
    country: France
  roles:
    - admin
    - user

Continuer la lecture

31 août 202031 août 2020

gRPC pour les nuls

Ce titre n’a pas pour vocation d’être provocateur mais plutôt de reprendre l’humour de cette série de livres qui proposent de rendre accessibles à tous des sujets qui peuvent paraître complexes au premier abord. Pour illustrer le concept gRPC, nous allons construire une calculatrice gRPC.

Dans gRPC, une application cliente peut appeler directement une méthode sur une application serveur d’une machine différente comme s’il s’agissait d’un objet local, ce qui vous permet de créer plus facilement des applications et des services distribués. Comme dans de nombreux systèmes RPC, gRPC est basé sur l’idée de définir un service, en spécifiant les méthodes qui peuvent être appelées à distance avec leurs paramètres et leurs types de retour. Côté serveur, le serveur implémente cette interface et exécute un serveur gRPC pour gérer les appels clients. Du côté client, le client dispose d’un stub (appelé simplement client dans certaines langues) qui fournit les mêmes méthodes que le serveur.

Continuer la lecture

29 août 202030 août 2020

Arista cEOS-lab, Python et NETCONF/YANG

En parcourant la littérature Arista sur le sujet YANG, il apparait une forte orientation gNMI/gRPC. Ceci étant, NETCONF est également supporté et si l’objectif n’est pas expressément de faire de la télémétrie, il peut parfaitement convenir d’utiliser le protocole NETCONF, avec des avantages uniques, pour interagir avec les équipements EOS.

Les tests vont s’appliquer sur un switch virtuel cEOS-lab pour des questions de légèreté d’empreinte CPU et mémoire. De même, plutôt que de partir d’une feuille blanche en Python avec la librairie ncclient et devoir gérer des fichiers de configuration YAML et des itérations sur un inventory, je propose d’utiliser mon framework d’automatisation Python préféré : nornir et son plugin de connexion NETCONF.

Après avoir téléchargé la dernière version de cEOS-lab en 64 bits (4.24.2.1F), il convient de l’importer dans Docker et de la lancer.

docker import cEOS64-lab-4.24.2.1F.tar ceosimage:4.24.2.1F

docker create --name=ceos1 --privileged -e INTFTYPE=eth -e ETBA=1 -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e CEOS=1 -e EOS_PLATFORM=ceoslab -e container=docker -p 2000:22/tcp -i -t ceosimage:4.24.2.1F /sbin/init systemd.setenv=INTFTYPE=eth systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker

docker network create net1
docker network create net2
docker network connect net1 ceos1
docker network connect net2 ceos1

docker start ceos1

Continuer la lecture