Le Web 3.0, technologie opérationnelle

Web 3.0

Dernière modification le 9 janvier 2022

A l’origine, le Web 3.0 a été nommé le Web sémantique par l’inventeur du World Wide Web, Tim Berners-Lee. Il visait à devenir un Internet plus autonome, intelligent et ouvert.

On peut ajouter que les données sont interconnectées de manière décentralisée, ce qui constitue un énorme pas en avant par rapport à notre génération actuelle d’Internet Web 2.0, où les données sont principalement stockées dans des référentiels centralisés.

Les utilisateurs et les machines peuvent interagir avec les données. Mais pour que cela se produise, les programmes doivent comprendre les informations à la fois conceptuellement et contextuellement. Dans cette optique, les deux technologies essentielles du Web 3.0 sont le Web sémantique et l’Intelligence Artificielle (IA).

Comme les réseaux Web 3.0 fonctionnent via des protocoles décentralisés – un des fondamentaux de la technologie blockchain et crypto-monnaie – nous voyons une forte convergence entre ces technologies.

Toutes les personnes qui suivent les projets de la blockchain, savent que le Web 3.0 est déjà là au travers de nombreux projets qui couvrent plusieurs domaines actuellement entre les mains des GAFAM. Il en existe beaucoup, mais pour ne prendre que seulement deux d’entre eux, nous avons une illustration de la décentralisation de la fonction Cloud et de la fonction Recherche.

Continuer la lecture de « Le Web 3.0, technologie opérationnelle »

Quel rapport entre le NetDevOps et le Web 3.0

Web 3.0

Ne regarde pas la télévision de si près, c’est mauvais pour les yeux !

Vous aussi vous avez entendu cette phrase à de nombreuses reprises quand vous étiez plus jeunes ? Et pourtant, nous continuons souvent de regarder de trop près ! Vous êtes vous déjà demandé pourquoi on parlait du NetDevOps, de l’Infrastructure as Code et pourquoi on y utilisait autant de technologies issues du système, du développement, de l’Edge Computing, de l’Intelligence Artificielle et de la Blockchain (croyez moi, vous allez le voir arriver).

Je vous propose de prendre beaucoup de hauteur pour regarder le paysage technologique qui se dessine…

Les informations de fuites de données et de censures sont sorties de la presse spécialisée pour atteindre le grand public, avec une forte accentuation depuis deux ans. Est-ce que le Covid a exacerbé le phénomène ? Peut être !

Nous sommes arrivés bien loin de l’idée première d’Internet qui permettait de disposer d’un espace de liberté visant à contourner la censure et outrepasser les frontières. Des algorithmes, de plus en plus pointus, déterminent les contenus que nous consommons. Des géants du numérique se sont imposés. Les GAFAM (Google, Apple, Facebook, Amazon et Microsoft, aussi appelés « Big Five ») qui pèsent à eux seuls une capitalisation boursière d’environ 5.000 milliards de dollars, vendent nos informations personnelles sans qu’aucune récompense ne nous soit directement rétribuée. On essaye de nous faire croire que grâce à l’argent récolté, on nous propose de plus en plus de services gratuits, mais ce n’est qu’une utopie car ces services permettent de nous cerner encore plus pour récolter toujours plus d’informations sur nos comportements.

Continuer la lecture de « Quel rapport entre le NetDevOps et le Web 3.0 »

Nokia SR Linux

Nokia SR Linux Data Center

SR Linux est un NOS (Network Operating System) qui exploite la pile de protocoles de routage de Nokia SR OS, tout en utilisant également Linux comme système d’exploitation sous-jacent, permettant aux administrateurs d’utiliser des outils de débogage et de configuration qu’ils connaissent bien, même s’ils n’ont aucune expérience avec SR OS.
Les fonctions de routage sur SR Linux s’exécutent comme des applications modulaires et légères, configurables via des API externes. Ces applications utilisent gRPC et des API pour communiquer entre elles et avec des systèmes externes via TCP. Les applications fournies par Nokia peuvent être complétées par des applications développées par des tiers, qui se connectent au framework SR Linux. Les fonctions « Application-based » permettent des mises à jour modulaires et une isolation facile des pannes.

Nokia SR Linux
Source Nokia

SR Linux utilise largement les modèles de données structurées. Chaque application a un modèle YANG qui pilote sa configuration et son état. SR Linux expose les modèles YANG aux API de gestion prises en charge. Par exemple, l’arborescence de commandes dans le CLI est dérivée des modèles SR Linux YANG chargés dans le système, et un client gNMI peut utiliser des RPC définis pour configurer une application en fonction de son modèle YANG. Lorsqu’une configuration est validée, le serveur de gestion SR Linux valide les modèles YANG et les traduit en « protocol buffers » pour la base de données IDB (Impart DataBase).

Modularité Nokia SR Linux
Source Nokia
Continuer la lecture de « Nokia SR Linux »

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 Network Operating System

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 Open Network Linux Open Switch

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 Linux 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 VXLAN

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 Network OS

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 »

Network Operating System SONIC

Network Operating System SONIC

Dernière modification le 23 décembre 2020

La désagrégation entamée par le mouvement du SDN (Software-Defined Networking) a, tout logiquement, entraîné la banalisation de la couche « Infrastructure Layer » ou « Data Plane ». Des fabricants de commutateurs ODM (Original Design Manufacturers) proposent des matériels appelés « Bare-metal » par analogie à des serveurs que l’on a pour habitude d’acheter sans aucun système d’exploitation installé. En tant que ODM on peut citer, par exemple, Dell, Mellanox, Facebook, Supermicro, mais surtout, Edgecore Networks, Quanta Cloud Technology ou Netberg. Les plus grand DataCenters comme Facebook ont été moteurs pour explorer cette voie qui leur laissait présager des économies d’échelle. Facebook a poussé le mouvement « Open Compute Project » pour proposer de couvrir différents aspects d’un DataCenter avec des matériels banalisés et des projets Open Source. Mais il ne faut surtout pas croire que l’approche consistant à fabriquer ses propres commutateurs n’est réservée qu’aux plus grands acteurs.

Dans ce domaine, il y a souvent une confusion entre « Bare-metal », « White box » et « Brite box » (BRanded whITEBOX). L’idée générale reste de ne plus accepter des systèmes propriétaires sur des matériels propriétaires. Les commutateurs « Bare-metal » sont livrés, comme des serveurs, avec un matériel et un firmware prêts à recevoir le « Network Operating System » de son choix. Le firmware qui s’est imposé s’appelle ONIE (Open Network Install Environment) et les « Network Operating Systems » les plus répandus sont OpenSwitch et ONL (Open Network Linux) dans le monde de l’Open Source et Pica8, ainsi que Cumulus Networks pour ce qui est de l’offre commerciale. Le concept de « White box » consiste, pour un acteur hors des fabricants traditionnels de matériel réseau, de prendre des commutateurs « Bare-metal » et d’intégrer un « Network Operating Systems » de leur choix ou même de leur fabrication.

Continuer la lecture de « Network Operating System SONIC »