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 »

Network Operating System SONIC

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 »