Ansible 3.0.0

Ansible 3.0.0

La version 3.0.0 du package communautaire Ansible marque la fin de la restructuration de l’écosystème Ansible. Ce travail achève ce qui a commencé en 2019 pour restructurer le projet Ansible et façonner la manière dont le contenu Ansible est livré.

Dans Ansible 2.9 et les versions antérieures, chaque plugin et module se trouvait dans le projet Ansible (https://github.com/ansible/ansible) lui-même. Lorsque vous installiez le package « ansible », vous aviez le langage, le runtime et tout le contenu (modules et autres plugins). Au fil du temps, le succès d’Ansible a créé des problèmes d’évolutivité. Les utilisateurs devaient attendre plusieurs mois pour un contenu mis à jour.

Au cours du cycle de développement d’Ansible 2.10, la communauté Ansible a migré avec succès la plupart des modules et plugins vers les collections. Les collections, ainsi que les modules et plugins qu’elles contiennent, peuvent désormais être développées, mises à jour et publiées indépendamment d’Ansible lui-même. Le package de la communauté Ansible 2.10 comprenait ansible-base 2.10 ainsi que toutes les collections qui contiennent des modules et des plugins qui ont été migrés hors du référentiel d’origine. Depuis Ansible 2.10, les utilisateurs de la communauté avaient deux options: continuer à installer tout avec le package de communauté Ansible, ou installer ansible-base, puis ajouter les collections sélectionnées individuellement.

Continuer la lecture de « Ansible 3.0.0 »

Nautobot – Network to Code

Nautobot NTC

La solution communautaire NetBox a été supportée pendant plusieurs années par la société Network to Code qui a finalement décidé de procéder à un fork de manière à créer un nouveau produit appelé Nautobot avec une nouvelle orientation stratégique : proposer une plateforme d’automatisation avec un support de qualité.

Source de vérité flexible
À la base, Nautobot est une source de vérité qui définit l’état qui est prévu pour le réseau (Intent-Based Networking).


Plateforme de données extensible pour l’automatisation de réseau
Nautobot est plus que de la documentation du réseau. Nautobot propose des intégrations et une extensibilité pour véritablement alimenter des solutions d’automatisation de réseau. Nautobot possède des API de plateforme robustes qui incluent des API RESTful (HTTP) traditionnelles, des API GraphQL, des webhooks basés sur les événements et de nombreuses fonctionnalités d’extensibilité pour permettre une plus grande automatisation du réseau. Nautobot utilise également son extensibilité pour agréger des systèmes de données disparates créant une source unique de vérité pour les solutions d’automatisation de réseau.


Plateforme pour les applications d’automatisation de réseau
La plateforme d’applications Nautobot fournit une architecture à partir de laquelle des applications d’automatisation de réseau peuvent être créées. Les applications Nautobot sont des augmentations ou des ajouts flexibles et personnalisés. Grâce à la plateforme d’applications Nautobot, les entreprises peuvent fournir des extensions et des applications d’automatisation de réseau personnalisables 65 à 70% plus rapidement.

Continuer la lecture de « Nautobot – Network to Code »

YANG Suite

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 de « YANG Suite »

Cluster EVE-NG Pro

EVE-NG Pro cluster

Avec la version 4 de EVE-NG Pro, une nouvelle fonctionnalité attendue depuis longtemps est disponible. Il est, maintenant, possible de monter un cluster de serveur EVE-NG afin d’augmenter la capacité disponible pour faire tourner une simulation.

L’installation standard de EVE-NG Pro portant la licence devient d’office le « master » du cluster et toutes les autres installations doivent se faire en mode « agent » en suivant la dernière version de la documentation.

La gestion du cluster et l’intégration de nouveaux agents se fait depuis le « master ».

eve-ng-sat01
Cluster EVE-NG
Continuer la lecture de « Cluster EVE-NG Pro »

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 »