Automatisation Juniper – Aéroport Nice Côte d’Azur

ACA

L’aéroport Nice Côte d’Azur est le deuxième aéroport de France avec 14.5 millions de passagers par an et un réseau de plus de 120 destinations, en majorité à l’international.

  • EVPN (Ethernet VPN)-VXLAN (Virtual Extensible LAN)
  • Underlay eBGP
  • Overlay iBGP
  • Centrally Routed Bridging (CBR) Overlay
  • 30 switchs Juniper QFX
  • 10 VRFs
  • 250 VLANs
  • 480 ports
  • 4000+ machines connectées
Grafana ACA
Monitoring Grafana / Prometheus en lab
Écosystème NetDevOps ACA
Écosystème NetDevOps ACA

Écosystème NetDevOps Aéroport Nice Côte d’Azur :

  • EVE-NG Pro
  • GitLab
  • Docker Swarm
  • GlusterFS
  • Juniper
  • Ansible
  • Python
  • Junos PyEZ
  • Robot Framework
  • Grafana
  • Prometheus
  • SNMP Exporter
  • Blackbox Exporter
  • gNMIc

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é 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

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 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 »

Switch virtuel Arista cEOS-lab

Arista cEOS-lab

cEOS-lab est une version conteneurisée de vEOS-lab avec les mêmes limitations fonctionnelles liées au fait que certaines fonctions EOS s’appuient directement sur les capacités des ASICs. Comparé à vEOS-lab, cEOS-lab présente tous les avantages d’un conteneur, comme une empreinte beaucoup plus légère d’environ 470 Mo de RAM par périphérique à sa création, une taille d’image plus petite et une plus grande portabilité.

Le test est lancé nativement sur mon MacBook Pro avec Docker Desktop 2.2.0.3 et Docker Engine 19.03.5.

# importer l'image cEOS-lab tar.xz
docker import cEOS-lab-4.23.2F.tar.xz ceosimage:4.23.2F

# créer une instance Docker avec les variables d'environnement nécessaires
docker create --name=ceos1 --privileged -e INTFTYPE=eth -e ETBA=1 -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e CEOS=1 -e EOS_PLATFORM=ceoslab -e container=docker -p 2000:22/tcp -i -t ceosimage:4.23.2F /sbin/init systemd.setenv=INTFTYPE=eth systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker

Les options utilisées ont les significations suivantes :

  • –name=ceos1
    Il s’agit d’un flag Docker qui permet de créer le conteneur avec le nom ceos1.
  • –privileged
    Il s’agit d’un flag Docker qui lance le conteneur en mode privilégié.
  • -e INTFTYPE=eth
    Il s’agit d’un flag cEOS qui indique à l’OS de libeller les interfaces avec eth.
  • -e ETBA=1
    Il s’agit d’un flag cEOS qui indique à EOS d’utiliser un Data Plane basé sur du logiciel.
  • -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1
    Il s’agit d’un flag cEOS qui indique à EOS de ne pas lancer le ZTP au boot.
  • -e CEOS=1
    Il s’agit d’un flag cEOS qui indique à EOS qu’il s’agit de cEOS et non d’un EOS classique.
  • -e EOS_PLATFORM=ceoslab
    Il s’agit d’un flag cEOS qui indique le type de plateforme. La valeur de ce flag a changé avec les versions.
  • -e container=docker
    Il s’agit d’un flag cEOS qui indique qu’il s’agit d’un conteneur Docker, car il en existe d’autres types.
  • -p 2000:22/tcp
    Il s’agit d’un flag Docker qui expose le port 22 pour être utilisé par SSH, sachant qu’on pourrait exposer aussi le port 443 pour l’utiliser avec eAPI.
  • -i -t ceosimage:4.23.2F
    Il s’agit d’un flag Docker pour indiquer l’image à utiliser.
  • /sbin/init
    Il s’agit d’un flag Docker qui indique la commande à utiliser pour lancer le conteneur, en lui associant les paramètres d’environnements nécessaires.
Continuer la lecture de « Switch virtuel Arista cEOS-lab »

Switch virtuel Arista vEOS-lab

Arista vEOS-lab

Dernière modification le 14 mars 2020

vEOS-lab permet d’utiliser le système EOS des commutateurs Arista sous forme d’une VM. Le système EOS porté à l’origine par Linux Fedora 18, est passé en CentOS 7.5 depuis la release 4.23.0F.

vEOS-lab permet la conception de réseaux et la validation des images EOS, le développement et les tests rapides d’EOS, ainsi que la mise en place de structure de formation et de training. Il ne faut pas le confondre avec vEOS Router qui est un produit NFV (Network Functions Virtualization) s’appuyant sur DPDK pour offrir plusieurs gigabits de débit dans des environnements cloud virtuels et publics.

Comme je l’ai déjà expliqué, mes trois outils de simulation préférés sont EVE-NG, GNS3 et Vagrant/VirtualBox. Chacun a ses avantages et inconvénients, mais EVE-NG a ma préférence dans le domaine professionnel lorsqu’il est nécessaire d’être démonstratif et visuel.

vEOS-lab EVE-NG
Continuer la lecture de « Switch virtuel Arista vEOS-lab »

Automatisation ALE – Métropole et Ville de Perpignan

Metropole et Ville de Perpignan

Dernière modification le 8 février 2021

Outre des objectifs de disponibilité et de performance qui nous avaient été fixés par la direction du numérique de la Métropole et de la Ville de Perpignan, la Direction du Numérique souhaitait mettre en oeuvre une approche DevOps. Dans ce cadre là, notre rôle a consisté à accompagner les équipes sur les nouvelles technologies, méthodologies et outils nécessaires à la mise en œuvre de ces infrastructures innovantes.

Des OmniSwitch OS6900 et OS6450 ont été déployés en mode ZTP en utilisant des serveurs DHCP, FTP et TFTP tournant sur Raspbian. Ansible a été utilisé pour générer les fichiers de configuration des serveurs, ainsi que les configurations des différents équipements. Des scripts Python/Netmiko ont permis de pousser les configurations sur tous les équipements et de générer des tests unitaires pour vérifier le bon fonctionnement de l’infrastructure.

Metropolis and City of Perpignan / Alcatel-Lucent Enterprise web site