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 »

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 »

Pipeline CI/CD

Pipeline CI-CD

DevOps est une nouvelle façon d’approcher la manière dont on conçoit, on exploite et on délivre les services IT. J’ai eu souvent l’occasion de le dire et de l’écrire, mais réaliser des programmes ne fait pas du programmeur un DevOps et encore moins de la société qui l’emploie une société DevOps.

Entrer dans le monde DevOps implique de focaliser sur les objectifs, les personnes, les processus et les outils à mettre en oeuvre. Cet article se voulant plutôt orienté technique, il focalisera sur des éléments appartenant aux domaines des processus et des outils. Dans les processus DevOps, l’approche CI/CD (Continuous Integration / Continuous Delivery ou Deployment) est fondamentale. Le schéma proposé ci-dessus illustre le pipeline du « Continuous Integration » et met en évidence la différence subtile entre « Continuous Delivery » et « Continuous Deployment » et les deux premières étapes vont être expliquées.

Généralement associé à un gestionnaire de versioning, on utilise un outil d’intégration continue comme Jenkins, CircleCI ou l’intégration continue disponible dans GitLab pour mettre en place le pipeline proposé dans l’illustration de cet article.

Continuer la lecture de « Pipeline CI/CD »

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 »

Automatisation Arista

Automatisation Arista

Outre la capacité de Zero-touch Provisioning, le NOS (Network Operating System) EOS d’Arista propose plusieurs possibilités d’automatisation. Nombre de ces possibilités peuvent s’expérimenter sur les commutateurs virtuels proposés sous forme de conteneur (cEOS-lab) ou de machine virtuelle (vEOS-lab).

Automatisation On-box

L’Event Manager est une fonctionnalité des commutateurs Arista qui permet d’exécuter des scripts Bash lorsque certains événements système se produisent. Les Event handlers permettent le déclenchement d’un trigger et d’une action. De plus, il est possible de définir un delay de sorte qu’une durée configurée s’écoule après le déclenchement et avant que l’action ne soit prise.

EOS signifie Extensible Operating System, et à ce titre il est possible d’étendre le système avec des collections de fichiers. Ces fichiers sont regroupés sous la forme d’un package appelé RPM (RedHat Package Manager ou RPM Package Manager). Le package prend en charge la gestion des dépendances. Lorsque plusieurs RPMs sont impliqués, ils sont regroupés dans une collection appelée SWIX (SoftWare Image Extension) et accompagnée d’un manifest.

Continuer la lecture de « Automatisation Arista »

Free Webinar Python et Ansible avec Arista

Webinar Automatisation Arista

Dernière modification le 1 avril 2020

Afin de profiter de la période de confinement pour améliorer les connaissances et revenir dans le circuit économique avec des méthodes encore plus efficaces, je vous propose une série de Webinars gratuits sur l’Automatisation Réseau.

Régulièrement, nous prendrons un sujet et nous le regarderons ensemble. L’objectif n’est pas seulement de participer de manière passive, mais aussi d’essayer soit même de le mettre en place en se faisant assister de la communauté présente dans le webinar.

Rejoignez la communauté Slack du NetDevOps Accelerator.

Continuer la lecture de « Free Webinar Python et Ansible avec Arista »

Arista et automatisation Ansible

Arista Ansible

Dernière modification le 4 avril 2020

Les modules officiels Arista EOS sont intégrés dans les Network Modules natifs et supportés par la Network Team d’Ansible.

Network Modules natifs Ansible :

  • eos_banner – Manage multiline banners on Arista EOS devices
  • eos_bgp – Configure global BGP protocol settings on Arista EOS
  • eos_command – Run arbitrary commands on an Arista EOS device
  • eos_config – Manage Arista EOS configuration sections
  • eos_eapi – Manage and configure Arista EOS eAPI
  • eos_facts – Collect facts from remote devices running Arista EOS
  • eos_interfaces – Manages interface attributes of Arista EOS interfaces
  • eos_l2_interfaces – Manages Layer-2 interface attributes of Arista EOS devices
  • eos_l3_interfaces – Manages L3 interface attributes of Arista EOS devices
  • eos_lacp – Manage Global Link Aggregation Control Protocol (LACP) on Arista EOS devices
  • eos_lacp_interfaces – Manage Link Aggregation Control Protocol (LACP) attributes of interfaces on Arista EOS devices
  • eos_lag_interfaces – Manages link aggregation groups on Arista EOS devices
  • eos_lldp – Manage LLDP configuration on Arista EOS network devices
  • eos_lldp_global – Manage Global Link Layer Discovery Protocol (LLDP) settings on Arista EOS devices
  • eos_lldp_interfaces – Manage Link Layer Discovery Protocol (LLDP) attributes of interfaces on Arista EOS devices
  • eos_logging – Manage logging on network devices
  • eos_static_route – Manage static IP routes on Arista EOS network devices
  • eos_system – Manage the system attributes on Arista EOS devices
  • eos_user – Manage the collection of local users on EOS devices
  • eos_vlans – Manage VLANs on Arista EOS devices
  • eos_vrf – Manage VRFs on Arista EOS network devices
Continuer la lecture de « Arista et automatisation Ansible »

Arista eAPI ou EOS API

Arista eAPI

Dernière modification le 15 mars 2020

Arista EOS propose des interfaces programmables pour les applications. Ces interfaces peuvent être exploitées par des applications exécutées sur le commutateur ou externes à EOS. L’interface API EOS (eAPI) permet aux applications et aux scripts d’avoir un contrôle programmatique complet sur EOS, avec une syntaxe stable et facile à utiliser. Une fois l’API activée, le commutateur accepte les commandes utilisant la syntaxe CLI d’Arista et répond avec une sortie sérialisée en JSON et servie via HTTP.

Le client envoie une requête HTTP POST au serveur, en utilisant le protocole JSON-RPC 2.0. La requête spécifie :

  • La méthode à utiliser (pour l’instant « runCmds »)
  • Une liste de commande à executer, par exemple [‘show interfaces’] ou [‘configure’, ‘interface Ethernet 1’, ‘shutdown’]
  • Un numéro de version, spécifiant à quelle révision du modèle de sortie le script doit s’attendre (pour l’instant, toujours « 1 »)

Le serveur traite la demande et collecte un modèle de données structuré, sérialisé en JSON, pour chaque commande. Si une commande renvoie une erreur, le champ JSON-RPC 2.0 « errors » sera correctement défini, sinon la réponse est placée dans le champ « result ».

localhost>enable
localhost#configure
localhost(config)#management api http-commands
localhost(config-mgmt-api-http-cmds)#no shutdown
localhost(config-mgmt-api-http-cmds)#end
localhost#write memory
Continuer la lecture de « Arista eAPI ou EOS API »

Switch virtuel Arista cEOS-lab

Arista cEOS-lab

cEOS-lab est une version conteneurisée de vEOS-lab avec les mêmes limitations fonctionnelles liées au fait que certaines fonctions EOS s’appuient directement sur les capacités des ASICs. Comparé à vEOS-lab, cEOS-lab présente tous les avantages d’un conteneur, comme une empreinte beaucoup plus légère d’environ 470 Mo de RAM par périphérique à sa création, une taille d’image plus petite et une plus grande portabilité.

Le test est lancé nativement sur mon MacBook Pro avec Docker Desktop 2.2.0.3 et Docker Engine 19.03.5.

# importer l'image cEOS-lab tar.xz
docker import cEOS-lab-4.23.2F.tar.xz ceosimage:4.23.2F

# créer une instance Docker avec les variables d'environnement nécessaires
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.23.2F /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

Les options utilisées ont les significations suivantes :

  • –name=ceos1
    Il s’agit d’un flag Docker qui permet de créer le conteneur avec le nom ceos1.
  • –privileged
    Il s’agit d’un flag Docker qui lance le conteneur en mode privilégié.
  • -e INTFTYPE=eth
    Il s’agit d’un flag cEOS qui indique à l’OS de libeller les interfaces avec eth.
  • -e ETBA=1
    Il s’agit d’un flag cEOS qui indique à EOS d’utiliser un Data Plane basé sur du logiciel.
  • -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1
    Il s’agit d’un flag cEOS qui indique à EOS de ne pas lancer le ZTP au boot.
  • -e CEOS=1
    Il s’agit d’un flag cEOS qui indique à EOS qu’il s’agit de cEOS et non d’un EOS classique.
  • -e EOS_PLATFORM=ceoslab
    Il s’agit d’un flag cEOS qui indique le type de plateforme. La valeur de ce flag a changé avec les versions.
  • -e container=docker
    Il s’agit d’un flag cEOS qui indique qu’il s’agit d’un conteneur Docker, car il en existe d’autres types.
  • -p 2000:22/tcp
    Il s’agit d’un flag Docker qui expose le port 22 pour être utilisé par SSH, sachant qu’on pourrait exposer aussi le port 443 pour l’utiliser avec eAPI.
  • -i -t ceosimage:4.23.2F
    Il s’agit d’un flag Docker pour indiquer l’image à utiliser.
  • /sbin/init
    Il s’agit d’un flag Docker qui indique la commande à utiliser pour lancer le conteneur, en lui associant les paramètres d’environnements nécessaires.
Continuer la lecture de « Switch virtuel Arista cEOS-lab »