Gilbert MOISIO – Page 6 – Gilbert MOÏSIO

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

27 septembre 202027 septembre 2020

Cisco et l’historique de l’IOS

Que ce soit lié à des améliorations technologiques ou à des rachats de sociétés, l’IOS de Cisco, au sens du système d’exploitation de matériels actifs réseau, a connu de nombreuses versions et évolutions. L’objectif n’est pas de retracer tous les détails de son histoire, mais de positionner les différents systèmes auxquels on fait référence lorsqu’on parle d’IOS aujourd’hui.

L’IOS, que nous avons tous connu, était un système d’exploitation monolithique qui exécutait un seul thread sur une large gamme de processeurs. Conçu et développé à une époque différente, il supporte maintenant certains matériels d’accès ⁽¹⁾ et sert à maintenir un parc existant.

Le système IOS-XE traite l’aspect monolithique de l’IOS. Bien que non-directement accessible, le système d’exploitation sous-jacent est basé sur une distribution Linux qui fonctionne sur des processeurs multicœurs. IOS-XE fonctionne sur plusieurs plateformes matérielles de différentes unités commerciales ⁽¹⁾, comme par exemple, le Catalyst 9000.

Le système NX-OS est un système d’exploitation extensible, ouvert et programmable conçu pour répondre aux exigences des déploiements physiques et virtuels des DataCenters. Il offre des fonctionnalités essentielles, telles qu’une architecture modulaire et flexible, une disponibilité continue du système, des capacités de virtualisation des commutateurs, l’automatisation du réseau, ainsi que l’approvisionnement et la configuration programmatique des commutateurs via des API complètes. Il prend principalement en charge la famille de produits Cisco Nexus ⁽¹⁾, dont le Nexus 9000. NX-OS fonctionne dans l’un des deux modes : le mode autonome ou le mode Application Centric Infrastructure (ACI). Le mode ACI est conçu et optimisé pour une utilisation avec les contrôleurs APIC (Application Policy Infrastructure Controllers) de Cisco.

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

3 septembre 20204 septembre 2020

Arista vEOS-lab et gNMI/gRPC (SubscribeRequest)

Arista switch virtuel vEOS-lab gnmi grpc

Cet article fait suite au premier sur gNMI/gRPC. La partie la plus riche de gNMI/gRCP est sa capacité à provisionner de la télémétrie sur les équipements. Pour cette démonstration, j’ai choisi de passer sur le simulateur EVE-NG avec des commutateurs virtuels Arista vEOS-lab en version 4.24.2.1F. Ce simulateur permet une représentation plus vivante pour une architecture.

Arista vEOS-lab gNMI gRPC — Architecture vEOS-lab dans EVE-NG

L’objectif va consister à provisionner la télémétrie sur les interfaces Ethernet1 de chaque équipement. L’outil gnmic écrit en Golang est parfaitement adapté pour ce genre de manipulation. Il permet d’effectuer la démonstration avec beaucoup de facilité. Sa capacité multi-cibles et le mode « sample » vont être mis en oeuvre dans ce premier exercice.

Continuer la lecture

2 septembre 20203 septembre 2020

Arista cEOS-lab et gNMI/gRPC

Arista switch virtuel cEOS-lab gNMI/gRPC

Dernière modification le 3 septembre 2020

Comme évoqué précédemment, gNMI/gRPC est le terrain de jeu préféré d’Arista. Comme vous le savez, les protocoles de gestion de réseau NETCONF et RESTCONF sont spécifiés par l’IETF. Bien que l’IETF soit un géant dans le monde des spécifications Internet, il est loin d’être la seule organisation de normalisation (SDO) à avoir établi des normes dans le domaine des réseaux. gNMI est le protocole de gestion de réseau gRPC développé par Google et porté par le consortium OpenConfig. gNMI fournit le mécanisme pour installer, manipuler et supprimer la configuration des périphériques réseau, ainsi que pour afficher les données opérationnelles. Le contenu fourni via gNMI peut être modélisé à l’aide de YANG.

Vu de haut, le protocole gNMI ressemble à NETCONF et RESTCONF à bien des égards et constitue une alternative possible à ceux-ci. La majorité des utilisations de gNMI semble être associée aux modèles YANG, mais les auteurs de gNMI soulignent expressément que YANG est l’un des nombreux langages de description d’interface (IDL) possibles.

gNMI définit un ensemble particulier d’opérations gRPC, à savoir, CapabilityRequest, GetRequest, SetRequest et SubscribeRequest. Ces opérations correspondent plus ou moins aux messages NETCONF / RESTCONF pour hello, get / get-config, edit-config et un mécanisme d’abonnement qui a beaucoup plus de capacités que la spécification de base IETF pour les notifications NETCONF. Chaque message de requête a évidemment également un message de réponse, chacun défini dans gRPC.

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