Représentations UML des modules Arista YANG OpenConfig

Arista YANG UML

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 à :

Je confirme avoir lu et accepté la Politique de confidentialité.

openconfig-interfaces
openconfig-interfaces.uml

Arista vEOS-lab, gNMIc et Prometheus

gNMIc Prometheus

Dernière modification le 30 octobre 2020

La destination Prometheus pour gNMIc avait été promise et elle a été développée. C’est l’occasion de réaliser un test pour voir comment utiliser gNMI/gRPC pour s’abonner à de la télémétrie sur un équipement réseau et stocker les résultats dans Prometheus de manière à l’afficher dans Grafana.

Le test est réalisé sur un commutateur virtuel Arista vEOS-lab version 4.24.2.3F tournant dans le simulateur EVE-NG. Hormis la configuration de base permettant l’accès au commutateur, seules ces quelques lignes suffisent pour utiliser gNMI/gRPC :

!
management api gnmi
   transport grpc default
!

L’objectif étant d’utiliser gNMIc comme un « Exporter » Prometheus, on va commencer par simplifier la ligne de commande au maximum afin de pouvoir le lancer facilement comme un service. Toujours dans un soucis de simplification, le comportement par défaut de gNMIc, par rapport au fichier de configuration, est respecté. Il est de la forme $HOME/gnmic.[yml, toml, json].

# gNMI target address; CLI flag --address
address: "192.168.199.61:6030"
# gNMI target user name; CLI flag --username
username: admin
# gNMI target user password; CLI flag --password
password: arista
# Connection mode; CLI flag --insecure
insecure: true

subscriptions:
  # A named subscription, a key is a name
  port_stats:
    # List of subscription paths for that named subscription
    paths:
      - "/interfaces/interface[name=Management1]/subinterfaces/subinterface/state/counters/in-octets"
      - "/interfaces/interface[name=Management1]/subinterfaces/subinterface/state/counters/out-octets"
    # One of [on-change target-defined sample]
    stream-mode: sample
    sample-interval: 5s
    qos: 0

outputs:
  group1:
    - type: prometheus
      # Address to listen on for incoming scape requests
      listen: :9804
      # Path to query to get the metrics
      path: /metrics
      # Maximum lifetime of metrics in the local cache
      expiration: 60s
      # Enable debug for prometheus output
      debug: false
Continuer la lecture de « Arista vEOS-lab, gNMIc et Prometheus »

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 »