Automatisation du générateur de trafic TRex

Automatisation 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 de « Automatisation du générateur de trafic TRex »

Programmation Cisco Meraki

Programmation 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 de « Programmation Cisco Meraki »

Programmation Cisco NX-OS

Programmation 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 de « Programmation Cisco NX-OS »

Cisco IOS-XE et RESTCONF / YANG

Cisco IOS-XE 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 de « Cisco IOS-XE et RESTCONF / YANG »

Cisco IOS-XE et NETCONF / YANG

Cisco IOS-XE 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 :

  1. Le client se connecte au sous-système NETCONF SSH.
  2. Le serveur répond avec un « hello » qui inclut les capabilities prises en charge.
  3. Le client répond avec des capabilities prises en charge pour établir une connexion.
  4. Le client émet une requête NETCONF.
  5. Le serveur émet une réponse ou effectue une opération.
Continuer la lecture de « Cisco IOS-XE et NETCONF / YANG »

Python et les formats de données

Formats de données

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 de « Python et les formats de données »

gRPC pour les nuls

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.

gRPC
Continuer la lecture de « gRPC pour les nuls »

Arista cEOS-lab, Python et NETCONF/YANG

Arista Python 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 de « Arista cEOS-lab, Python et NETCONF/YANG »

Webinar Python Université de Nice Côte d’Azur

Webinar Python IUT Nice

Dernière modification le 8 juillet 2020

Webinar Python pour l’Université de Nice Côte d’Azur organisé par Stéphane FRATI, Responsable parcours Licence Pro CyberDéf – Département Réseaux et Télécommunications (RT), le mercredi 24 juin 2020.

L’objectif du Webinar était de proposer une approche de l’automatisation de réseau avec le langage Python, en mettant en évidence un certains nombre de libertés apportées par l’utilisation de librairies spécialisées.

Arista et le framework Nornir

Arista pyeapi Napalm Nornir

Lorsque l’objectif est d’utiliser Python 3 pour automatiser l’accès aux équipements Arista, le framework Python Nornir apporte une aide précieuse. Pour les connexions, Nornir peut utiliser NAPALM, Netmiko, Paramiko ou Netconf.

La librairie NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) est indiqué pour se connecter aux équipements Arista. Il s’appuie sur la librairie pyeapi avec un bon niveau de support des fonctionnalités.

Fichier de configuration Nornir :

---
core:
    num_workers: 100
inventory:
    plugin: nornir.plugins.inventory.simple.SimpleInventory
    options:
        host_file: "inventory/hosts.yaml"
        group_file: "inventory/groups.yaml"
        defaults_file: "inventory/defaults.yaml"
Continuer la lecture de « Arista et le framework Nornir »