Arista – Gilbert MOÏSIO

25 avril 2022

NetPalm, un cocktail pour le NetDevOps

NetPalm a vu le jour en 2020 sous l’impulsion de Tony Nealon et rassemble plusieurs outils, qui ont déjà été évoqués séparément, pour construire une plateforme OpenAPI à destination des équipements réseaux. NetPalm forme une couche d’abstraction pour utiliser napalm, netmiko, ncclient ou requests afin d’accéder aux différents matériels avec la méthode la plus adaptée. L’accès à NetPalm se fait au travers d’une interface OpenAPI v3.

NetPalm utilise Docker pour apporter une touche de modernité et une capacité d’évolution de manière à encaisser une montée en charge.

Continuer la lecture

10 janvier 2022

Nornir, Netmiko et Template Text Parser

Les développements Python, dans le domaine de l’automatisation réseau, ont tout à gagner à utiliser le Framework Nornir. Celui-ci propose plusieurs méthodes pour accéder aux équipements. Chacune de ces méthodes a ses avantages et inconvénients et surtout elles ne sont pas toujours applicables à tous les constructeurs.

La méthode adressant le plus grand nombre de constructeurs est sans aucun doute Netmiko. Cette souplesse vient du fait que l’idée consiste à initier une connexion avec chacun des équipements pour leur envoyer des commandes et récupérer le résultat de la commande au travers du canal qui a été ouvert. Ce qui est reçu en retour est le même texte qui se serait affiché à l’écran si la manipulation avait été faite manuellement.

Analyser les informations qui sont retournées dans ces conditions, relève d’une pratique qui s’appelle le « Screen Scraping ». Il s’agit majoritairement d’utiliser des expressions régulières (regex) pour extraire du texte les informations recherchées. Des librairies ont été mises au point pour simplifier cette analyse et pour retourner les informations recherchées dans une structure de données utilisable programmatiquement. Qui plus est, ces librairies ont été intégrées dans le module Netmiko et par voie de conséquence, elles sont utilisables dans le Framework Nornir.

Continuer la lecture

25 juillet 202110 août 2021

Un lab économique pour le Network as Code

Dernière modification le 10 août 2021

Pratiquer le Network as Code, qui se décline en différentes appellations dans la littérature (NetDevOps, NetOps, Infrastructure as Code, Intent Based Networking, …), fait appel à un simulateur réseau pour monter rapidement un environnement sans pour autant posséder tout le matériel nécessaire.

Si le but recherché est d’accéder à un équipement ou deux pour s’entrainer à la pratique du langage de commande (EOS, IOS, NXOS, Junos…), d’une technologie réseau (VXLAN, EVPN/VXLAN, MLAG,…) ou de techniques et technologies d’automatisation (Ansible, Python/Nornir, RESTCONF, NETCONF, gNMI/gRPC, …), il existe de nombreuses solutions qui peuvent s’accommoder de peu de ressources. Mais lorsqu’il s’agit de monter un véritable lab pour reproduire un environnement de simulation complet, on se rend compte qu’il faut rapidement disposer de ressources CPU et RAM importantes. La quantité nécessaire dépasse facilement les ressources disponibles sur une machine de développement ou d’enseignement.

Pourtant il peut s’avérer pratique d’être autonome et de ne dépendre ni d’un serveur additionnel, ni d’une ressource internet, sans pour autant mettre sa machine en surchauffe. Croyez moi, un MacBook Pro qui chauffe pendant la saison d’été c’est très désagréable pour les poignets et plus globalement pour la température ambiante.

Pour monter un environnement de virtualisation sur le MacBook, rien n’est plus rapide et léger que Multipass de Canonical. C’est la méthode recommandée pour créer des machines virtuelles Ubuntu sur Ubuntu. Il est conçu pour les développeurs qui souhaitent un nouvel environnement Ubuntu avec une seule commande et fonctionne sous Linux, Windows et macOS. Multipass utilise la virtualization native de chaque système d’exploitation sur lequel il est installé : Hyper-V sur Windows, HyperKit sur macOS et KVM sur Linux, pour une surcharge minimale et un temps de démarrage le plus rapide possible.

Continuer la lecture

31 mai 2021

Containerlab, topologie de lab sur Docker

Avec le nombre croissant de switchs virtuels conteneurisés, le besoin de les exécuter facilement dans des topologies de simulation augmente. Je l’avais déjà évoqué en présentant le cEOS-lab Arista, les outils d’orchestration de conteneurs tels que docker-compose ne conviennent pas, car ils ne permettent pas de créer facilement des connexions entre les conteneurs pour définir une topologie.

Containerlab fournit une interface IaaC (Infrastructure as a Code) sous forme d’un langage de commande pour l’orchestration et la gestion des simulations réseau basées sur des conteneurs. Il démarre les conteneurs, construit un câblage virtuel entre eux pour créer des topologies et gère le cycle de vie des simulations.

Containerlab se concentre sur les NOS (Network Operating System) conteneurisés qui sont généralement utilisés pour tester les fonctionnalités réseau, tels que :

Nokia SR-Linux
Arista cEOS
Azure SONiC
Juniper cRPD

Continuer la lecture

22 mai 202122 mai 2021

Sonde H5 audits sur simulateur

L’utilisation d’un simulateur est un élément incontournable pour une approche NetDevOps. Il est clair que tout constructeur ou fournisseur de logiciel incapable de passer sur un simulateur tel que EVE-NG, pour s’inscrire dans une infrastructure virtualisée, ne peut pas prétendre jouer dans la cours du SDN (Software Defined Network).

Lorsqu’il est question d’analyser le trafic au sein d’une infrastructure simulée, EVE-NG Pro dispose nativement de Wireshark pour effectuer des captures sur les liens inter-équipements. Mon souhait était de pouvoir aller plus loin dans l’analyse avec une sonde virtuelle.

L’avantage d’avoir un constructeur français de sondes, dont la recherche et développement est accessible, est d’avoir réussi à exprimer et défendre ce besoin et d’avoir été entendu. Je remercie Frédéric GUILLOIS (President H5 Audits) et Lionel BARRERE (Chief Technical Officer H5 Audits) de m’avoir écouté et d’avoir mis au point la réponse à ma demande.

Continuer la lecture

8 février 20218 février 2021

YANG Suite

On attendait le remplaçant de YANG Explorer et il vient de sortir. YANG Suite remplace l’interface flash par du HTML5 et permet d’aborder l’automatisation réseau à l’aide de modèles YANG en navigant dans les modules depuis une interface graphique, en créant des requêtes RPC pour interagir avec les équipements et en testant la télémétrie à l’aide de gRPC.

L’usage de conteneurs Docker facilite grandement la mise en place de YANG Suite. Sur la base d’une machine virtuelle Ubuntu 20.04 à jour, Docker est installé :

sudo apt update
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"
sudo apt update
sudo apt install docker-ce
sudo apt install docker-compose
sudo usermod -aG docker ${USER}
sudo reboot

L’installation la plus simple de YANG Suite, consiste à cloner le dépôt de GitHub.

git clone https://github.com/CiscoDevNet/yangsuite
cd yangsuite/docker/
./gen_test_certs.sh

Par défaut, YANG Suite, ou plus exactement Django, est configuré pour répondre aux requêtes sur l’adresse locale 127.0.0.1. Afin de permettre un accès depuis le réseau sur l’adresse IP de la machine virtuelle, il conviendra de modifier le fichier docker-compose.yml avant le premier lancement pour changer la valeur d’une des lignes environment de la manière suivante : DJANGO_ALLOWED_HOSTS=*.

Continuer la lecture

30 octobre 202030 octobre 2020

Représentations UML des modules Arista YANG OpenConfig

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

openconfig-interfaces format UML — openconfig-interfaces.uml

29 octobre 202030 octobre 2020

Arista vEOS-lab, gNMIc et Prometheus

Arista vEOS-lab gNMIc Prometheus Grafana

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

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