Arista cEOS-lab et 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.

Ne nous voilons pas la face, le protocole gNMI est, actuellement, plus implémenté à l’aide du langage Golang que du langage Python, il est donc plus naturel de faire des expérimentations à l’aide d’outils écrits en Golang.

gnmic est un client CLI gNMI, écrit en Golang, qui fournit un support complet pour les RPCs Capabilities, Get, Set et Subscribe avec des capacités de collecteur. Pour l’installer, on peut utiliser la ligne de commande rapide suivante : sudo curl -sL https://github.com/karimra/gnmic/raw/master/install.sh | sudo bash

Toujours pour des questions d’empreinte CPU et mémoire, les tests vont s’appliquer sur un switch virtuel cEOS-lab. Le port 6030 est le port gNMI par défaut sur EOS et on se contentera d’un username/password sans imposer l’utilisation de TLS pour le transport.

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 6030:6030/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

Une configuration minimum de l’équipement virtuel, permettra d’effectuer les tests gNMI/gRPC.

docker exec -it ceos1 Cli

enable

configure
username admin secret arista
management api gnmi
transport grpc default
end

write memory

La première étape de l’exploration, va consister à interroger l’équipement virtuel pour connaître ses capacités gNMI. Cette étape est assez mécanique car elle découvre quelle version gNMI le périphérique exécute, quels modèles sont chargés et quel encodage il comprend : gnmic -a 127.0.0.1:6030 -u admin -p arista --insecure capabilities

À en juger par la réponse renvoyée, nous voyons que :

• La version 4.24.2.1F de cEOS-lab que j’utilise exécute la version 0.7.0 de gNMI
• Elle est configurée avec des modèles OpenConfig et natifs Arista
• Elle prend en charge deux variantes d’encodage JSON et un encodage ASCII qui nous sera inutile

Arista publie ses modèles YANG dans un dépôt GitHub. Pour analyser et comprendre la structure des modèles, l’outil Python pyang reste le meilleur allié. Lorsqu’on regarde la version 4.24.2F, on note la forte orientation OpenConfig, alors que les modèles natifs sont classés comme expérimentaux. A titre d’exemple, on peut analyser le module openconfig-interfaces.yang à l’aide de la commande pyang : pyang -f tree -p yang yang/EOS-4.24.2F/openconfig/public/release/models/interfaces/openconfig-interfaces.yang

Supposons que nous voulions connaître la description associée à l’interface Ethernet1 :

gnmic -a 127.0.0.1:6030 -u admin -p arista --insecure get \
--path "/interfaces/interface[name=Ethernet1]/config/description"

De façon prévisible, il n’y a aucune description configurée pour l’interface Ethernet1. Notre objectif va consister à utiliser le service RPC Set pour appliquer une configuration.

gnmic -a 127.0.0.1:6030 -u admin -p arista --insecure set \
        --update-path "/interfaces/interface[name=Ethernet1]/config/description" \
        --update-value "Ma description gNMI"

De la même manière, il est possible de supprimer une configuration à l’aide d’un gnmic set --delete.

La partie la plus intéressante pour la télémétrie est la capacité SubscribeRequest de gNMI. Il est possible de jouer à l’infini avec les commandes gnmic subscribe --stream-mode sample et gnmic subscribe --stream-mode on_change. La première commande permet de s’abonner à une valeur qui est reçue selon un intervalle d’échantillonnage indiqué. La deuxième commande permet de s’abonner à une valeur qui ne sera envoyée par l’équipement que lorsqu’elle aura changé. Ces aspects sont abordés dans le deuxième article sur ce sujet.