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 »

Cisco et l’historique de l’IOS

Historique Logo Cisco

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 (1) 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 (1), 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 (1), 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 de « Cisco et l’historique de l’IOS »

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 »

Arista vEOS-lab et gNMI/gRPC (SubscribeRequest)

Arista 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.

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 de « Arista vEOS-lab et gNMI/gRPC (SubscribeRequest) »

Arista cEOS-lab et gNMI/gRPC

Arista 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 de « Arista cEOS-lab et gNMI/gRPC »

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 »