Cisco – Gilbert MOÏSIO

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

8 octobre 2020

Programmation Cisco 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

5 octobre 2020

Programmation Cisco 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

30 septembre 202030 septembre 2020

Cisco IOS-XE et 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

29 septembre 202029 septembre 2020

Cisco IOS-XE et 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 :

Le client se connecte au sous-système NETCONF SSH.
Le serveur répond avec un « hello » qui inclut les capabilities prises en charge.
Le client répond avec des capabilities prises en charge pour établir une connexion.
Le client émet une requête NETCONF.
Le serveur émet une réponse ou effectue une opération.

Continuer la lecture

27 septembre 202027 septembre 2020

Cisco et l’historique de l’IOS

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 ⁽¹⁾ 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 ⁽¹⁾, 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 ⁽¹⁾, 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