SONIC sur EVE-NG

SONIC EVE-NG

J’ai déjà eu l’occasion de parler du NOS (Network Operating System) SONIC. Dans cet article, je proposais de découvrir SONIC en le faisant tourner sur Docker, mais lorsqu’il s’agit de simuler une architecture, il est tout de même plus démonstratif de faire tourner la simulation sur EVE-NG. La version Pro de EVE-NG arrive avec un template déjà prêt : /opt/unetlab/html/templates/intel/sonicsw.yml.

---
type: qemu
name: S-SW
description: Sonic Switch
cpulimit: 1
icon: Switch L32.png
cpu: 2
ram: 4096
ethernet: 10
eth_format: Ethernet{0}
console: telnet
shutdown: 1
qemu_arch: x86_64
qemu_version: 3.1.0
qemu_nic: e1000
qemu_options: -machine type=pc,accel=kvm -vga std -usbdevice tablet -boot order=cd
...

J’ai pour habitude de récupérer l’image sonic-vs.img.gz une fois générée sur l’intégration continue Jenkins de SONIC. Pour respecter le mode de fonctionnement de EVE-NG, un répertoire avec la racine sonicsw est créé afin d’y déposer l’image renommée en virtioa.qcow2.

Continuer la lecture de « SONIC sur EVE-NG »

Dent – Linux SwitchDev

Dent

En tant que nouveau projet de la « Linux Foundation », Dent utilise le noyau Linux, Switchdev et d’autres projets basés sur Linux comme base pour construire un nouveau système d’exploitation réseau normalisé sans abstractions ni surcharge. Toutes les infrastructures sous-jacentes – y compris ASIC et Silicon – sont traitées de la même manière, tandis que les abstractions existantes sont simplifiés. Dent réunit les fournisseurs de silicium, les ODM, les SI, les OEM et les utilisateurs finaux dans tous les secteurs verticaux et permet la transition vers des réseaux désagrégés. Le plan d’action prévisionnel laisse entrevoir un système, avec toutes ses fonctions essentielles, finalisé pour fin 2021.

L’avènement de la désagrégation, c’est à dire du remplacement du modèle propriétaire matériel/logiciel proposé par les acteurs historiques du réseau, a posé le problème de la banalisation de la couche matérielle. En effet, si on est amené à réaliser autant de logiciels spécifiques qu’il y a de types de matériels avec ses SDKs, l’objectif de la désagrégation n’est pas facile à atteindre. La banalisation du matériel passe par une couche d’abstraction qui permet à la couche logicielle de s’adapter à plusieurs types de matériels différents.

On a beaucoup parlé de SAI (Switch Abstraction Interface) qui est un modèle de couche d’abstraction tournant dans le « User space » Linux, ce qui implique qu’une application située dans le « User space » pilote l’ASIC en contournant le Kernel. Une représentation du cache matériel (service d’état de commutation) est également conservée dans l’espace utilisateur. Il s’agit généralement d’un stockage clé-valeur comme Redis (ACS) ou OVSDB (Open vSwitch). Un des avantages de tout faire en « User space » est que le développeur peut prendre une distribution Linux standard et ajouter simplement les modifications nécessaires. Aucune expertise du noyau Linux n’est requise, il y a juste besoin du pilote SAI pour l’ASIC concerné. On peut également changer de matériel en changeant simplement le pilote SAI. SONIC est une exemple de NOS (Network Operating System) qui utilise SAI.

Architecture SONIC
Source SONIC
Continuer la lecture de « Dent – Linux SwitchDev »

Open Compute Project – ONIE

ONIE

Dernière modification le 5 janvier 2021

Créé en 2012 par Cumulus Networks, le projet ONIE (Open Network Install Environment) est un petit système d’exploitation, préinstallé en tant que micrologiciel sur des commutateurs réseau « bare metal », qui fournit un environnement pour l’approvisionnement automatisé du NOS (Network Operating System).

Incubé et adopté par l’Open Compute Project en 2013, le projet ONIE permet un écosystème de commutateurs réseau « bare metal » où les utilisateurs finaux peuvent choisir parmi différents systèmes d’exploitation réseau.

ONIE First Time Boot
Source documentation ONIE
ONIE Subsequent Boots
Source documentation ONIE
Continuer la lecture de « Open Compute Project – ONIE »

Cumulus – EVPN – VXLAN

Cumulus EVPN-VXLAN

Dans un précédent article, nous avons vu comment mettre en place du VXLAN statique, mais on comprend que cette solution peut atteindre ses limites dans une infrastructure plus large avec de nombreux Leafs, pouvant rendre complexe la liste des variables pour l’automatisation. La définition initiale de VXLAN (RFC 7348) n’incluait aucun plan de contrôle et reposait sur une approche « flood-and-learn  » pour l’apprentissage d’adresses MAC. EVPN (Ethernet Virtual Private Network), souvent appelé « controller-less VXLAN », est un plan de contrôle basé sur des normes pour VXLAN défini dans le RFC 7432 et dans le document « draft-ietf-bess-evpn-overlay » qui permet de créer et de déployer des VXLANs à plus grande échelle et apporte des fonctionnalités avancées. Il repose sur le protocole MP-BGP (Multi-Protocol BGP) pour échanger des informations et il est basé sur BGP-MPLS IP VPNs (RFC 4364). Il permet non seulement le pontage entre les systèmes d’extrémité pour un même segment de niveau 2, mais également le routage entre différents segments (sous-réseaux). Le plan de contrôle de routage (y compris EVPN) est inclus dans le package FRRouting (FRR) présent dans Cumulus Linux.

Cumulus Static VXLAN
Architecture de simulation

Tous les commutateurs sont remis dans leur configuration d’origine à l’aide de la commande net del all, et comme pour le VXLAN statique, la partie underlay est assurée par une approche « eBGP unumbered » dans laquelle une adresse loopback est définie sur chaque noeud, L’AS (Autonomous System) est configuré comme décrit sur le schéma de la simulation, des sessions sont établies vers les différents AS et les adresses locales sont annoncées aux voisins. Pour la partie overlay une différence apparait dans l’activation du plan de contrôle EVPN sur les interfaces infrastructures de tous les commutateurs, tous les VNIs sont automatiquement annoncés sur les Leafs et seules les origines des tunnels sont définies sur les Leafs.

Continuer la lecture de « Cumulus – EVPN – VXLAN »

Cumulus – VXLAN statique

Cumulus Linux permet de construire des architectures traditionnelles avec des agrégations de liens appelées « Bonds » et la fonction MLAG (Multi-chassis Link Aggregation), mais son terrain de prédilection est la réalisation d’architectures IP Fabric (Clos Network) avec le concept Underlay/Overlay et le protocole VXLAN (Virtual Extensible LAN).

Traditionnellement, la virtualisation réseau est assurée par la notion de VLAN sur un réseau de niveau 2, mais les limitations de ce modèle ont ouvert la voie à la virtualisation de réseau VXLAN (RFC 7348 – A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks) assurant la connectivité des réseaux logiques de niveau 2 par dessus un underlay en niveau 3. VXLAN utilise une identification de 24 bits appelée VNI (VXLAN Network Identifier) qui a une signification globale sur l’infrastructure et qui permet de réaliser 16.777.216 réseaux virtuels différents. VXLAN encapsule la trame (adresse MAC) dans un paquet IP/UDP et la correspondance VLAN/VNI n’a de valeur que locale à l’équipement qui supporte VXLAN et qui assure l’encapsulation et la désencapsulation. Cet équipement est appelé un VTEP (Virtual Tunnel Endpoint). En outre, le VTEP supprime le tag de VLAN en entrée et le remplace par l’entête VXLAN qui contient le VNI. Le VTEP d’arrivée effectue la manipulation inverse, sachant que le tag de VLAN de sortie n’est pas obligatoirement le même que celui d’entrée.

Dans une approche de VXLAN statique sans « Control Plane », l’utilisation de BGP pour l’underlay n’est pas obligatoire, mais autant commencer à l’implémenter pour un usage ultérieur. C’est le protocole eBGP (external BGP) qui est utilisé. Il a la particularité d’échanger des informations entre les AS (Autonomous Systems) qui doivent être directement connectés. Dans cette approche, les tunnels entre les VTEP sont créés manuellement pour mettre en relation les équipements en niveau 2. Pour router entre les VXLANs, il est possible d’utiliser le routage asymétrique ou le routage symétrique.

Continuer la lecture de « Cumulus – VXLAN statique »

Cumulus Linux

Cumulus Linux

Dernière modification le 10 janvier 2021

Cumulus Networks est une société de logiciels informatiques fondée en 2010 par JR Rivers et Nolan Leake. La société conçoit et vend un système d’exploitation Linux pour les commutateurs réseau standards, un logiciel de gestion et sa propre gamme de commutateurs Ethernet appelée Cumulus Express.

En 2012, Cumulus a lancé le projet ONIE (Open Network Install Environment). OCP (Open Compute Project) a transformé ONIE en une initiative visant à définir un environnement d’installation open source pour les commutateurs Ethernet bare metal. Un commutateur avec un environnement d’installation ONIE donne aux clients le choix du système d’exploitation réseau, en désagrégeant le matériel réseau du système d’exploitation. Le système d’exploitation Cumulus Linux peut être installé sur tous les commutateurs compatibles ONIE.

En 2016, Mellanox a commencé à proposer Cumulus Linux sur ses propres commutateurs Spectrum.

Dans un rapport Gartner de 2017, Cumulus Networks a été présenté comme un pionnier de la mise en réseau open source pour le développement d’un système d’exploitation réseau sur un marché où les fournisseurs de matériel livraient généralement des systèmes d’exploitation propriétaires préinstallés. Selon Gartner, Cumulus Networks avait contourné le manque de support des fournisseurs pour les réseaux open source en déployant des commutateurs bare metal avec le système d’exploitation Cumulus Linux dans les grands réseaux d’entreprise. 32% des entreprises du Fortune 50 ont utilisé le système d’exploitation Cumulus Linux dans leurs DataCenters en 2017.

En mai 2020, quelques mois après le rachat de Mellanox, le fabricant américain de semi-conducteurs Nvidia a annoncé l’acquisition de Cumulus. Ces rapprochements vont faire bouger les lignes vis à vis de Broadcom et engendrer des conséquences que l’année 2021 va devoir éclaircir.

Continuer la lecture de « Cumulus Linux »

Salt Junos Proxy Minion

Salt

Salt, de la société SaltStack, est un sujet dont je n’ai pas parlé depuis plus d’un an car le support de Python3 pour le « Syslog Engine » n’était pas fonctionnel et nécessitait d’utiliser un environnement de développement spécifique.

Entre le fait que ce problème soit réglé et que SaltStack ait été rachetée par VMWare, c’est le bon moment pour proposer un rappel sur cette solution qui ne manque pas d’intérêt pour faire du « Human-driven Automation », du « Event-driven Automation » et du « Machine-driven Automation » avec un outil structurant.

Salt utilise un modèle de communication serveur-agent, bien qu’il fonctionne aussi en tant qu’utilitaire de gestion de serveur unique autonome, et offre également la possibilité de s’exécuter sans agent via SSH.

Flexible Network Control
Source SaltStack

Le composant serveur s’appelle « Salt master » et l’agent s’appelle « Salt minion ». Le « Salt master » est responsable de l’envoi des commandes aux « Salt minions », puis de l’agrégation et de l’affichage des résultats de ces commandes. Un seul « Salt Master » peut gérer des milliers de systèmes. Salt communique avec les systèmes gérés à l’aide d’un modèle « publish-subscribe ». Les connexions sont initiées par le « Salt Minion », ce qui signifie que vous n’avez pas besoin d’ouvrir de ports entrants sur ces systèmes (réduisant ainsi le vecteur d’attaque). Le « Salt Master » utilise les ports 4505 et 4506, qui doivent être ouverts pour accepter les connexions entrantes.

Continuer la lecture de « Salt Junos Proxy Minion »

ALE AOS8 Web Services

ALE AOS8 Web Services

Alcatel-Lucent Enterprise le rappelle régulièrement : « l’objectif est de n’avoir à terme que des commutateurs Ethernet en AOS8 ». Effectivement, tous les modèles qui sont sortis et se sont rajoutés au catalogue, parfois en remplacement de modèles existants, font tourner la version 8 de l’AOS. Dans ce contexte il était intéressant de voir les possibilités offertes en matière d’automatisation externe en environnement homogène.

Pour rappel, lorsqu’on est dans un contexte de mixité AOS6 et AOS8, les possibilités sont les suivantes :

  • Utiliser la librairie Netmiko avec Python, pour laquelle j’avais écrit le module AOS en 2017 et qui est toujours maintenu par Kirk Byers lors des différentes montées de version de la librairie.
  • Utiliser le Network Module ale_aos que j’ai écrit pour Ansible en 2020.

C’est la fonction Web Services qui permet de personnaliser et d’étendre l’interface de gestion sur les dispositifs AOS8. Dans le cas qui nous intéresse, il prend en charge l’utilisation d’une interface web basée sur REST qui interagit avec les variables de gestion AOS (MIB) et les commandes CLI. Donc, il fournit deux méthodes de configuration via la gestion directe des variables MIB ou l’utilisation de commandes CLI et prend en charge à la fois les formats de réponse en XML et en JSON.

Il ne faut pas confondre REST et le protocole RESTCONF qui utilise le modèle de données YANG. REST est un ensemble de directives pour l’architecture logicielle des systèmes distribués et AOS8 supporte les verbes suivants :

  • GET : pour récupérer des informations. C’est un équivalent grossier de SNMP / MIB GET mais aussi, à un niveau supérieur, un équivalent de la commande show. Ce verbe est utilisé exclusivement pour les commandes en lecture seule et sans autre effet secondaire.
  • PUT : pour créer de nouvelles informations, comme, par exemple, un nouveau VLAN. Il s’agit d’une opération d’écriture.
  • POST : fonctionne de la même façon que lors de la soumission de formulaires Web et il est utilisé, dans un contexte de service Web, pour mettre à jour des informations existantes.
  • DELETE : pour supprimer des informations existantes.
Continuer la lecture de « ALE AOS8 Web Services »

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 »