Observabilité du réseau (part.3)

Suzieq Architecture

Cet article fait suite à la première partie qui présente la notion d’observabilité et à la deuxième partie qui présente la solution commerciale IP Fabric.

SuzieQ est une application open source proposée par la société Startdust Systems située à Sunnyvale en Californie. L’application collecte, normalise et stocke des données horodatées qui ne sont autrement disponibles qu’en se connectant à chaque équipement. Elle peut s’installer sous la forme d’un conteneur ou d’une VM dans laquelle elle est mise en place en tant que package Python.

Avec SuzieQ, il est possible d’acquérir une compréhension approfondie du réseau, remédier rapidement aux défaillances et identifier de manière proactive les problèmes du réseau avant que leurs effets ne se fassent sentir. Lors de la mise en place du modèle Intent-Based Networking, il est possible de s’assurer que chaque modification du réseau est automatiquement validée après avoir été effectuée.

SuzieQ fonctionne avec plusieurs constructeurs et collecte les données depuis Arista EOS (version 20.0 ou ultérieure), IOS, IOS-XE, IOS-XR et NXOS de Cisco (N7K avec les versions 8.4.4 ou supérieures et N9K avec les versions 9.3.1 ou supérieures), Cumulus Linux , Junos de Juniper (plates-formes QFX, EX, MX et SRX) et les plateformes SONiC. SuzieQ prend également en charge la collecte de données à partir de serveurs Linux. Le poller SuzieQ utilise SSH ou l’API REST d’un équipement pour collecter les données.

Suzieq Constructeurs
Constructeurs supportés
Continuer la lecture de « Observabilité du réseau (part.3) »

Observabilité du réseau (part.2)

IP Fabric Architecture

Cet article fait suite à la première partie et présente une des deux solutions évoquées.

IP Fabric, dont le siège Européen est situé à Prague en République Tchèque, est à la fois une société et un produit commercial soumis à licence. L’application s’installe avec les prérequis minimum suivants :

IP Fabric requirements
Dimensionnement

Les fonctionnalités sont articulées autour de trois grands domaines :

  • Découverte du réseau
    Après la phase de découverte, la plateforme crée un modèle mathématique du réseau à partir des données d’état et de configuration du réseau. Le modèle de réseau créé, appelé snapshot, intègre une logique de commutation, de routage et de sécurité permettant une visualisation avancée et des simulations de trafic réseau, ainsi que des chemins empruntés.
    La fonction de découverte cartographie l’infrastructure réseau de la même manière que le ferait un ingénieur réseau. En commençant par un périphérique de départ, le logiciel suit les relations réseau actives pour découvrir naturellement tous les chemins, périphériques et utilisateurs existants. Avec un algorithme de découverte avancé entièrement automatisé, la plateforme explore le réseau à l’aide de SSH (ou Telnet) et collecte les données opérationnelles et de configuration de tous les appareils. Cette partie du processus ne nécessite pas le protocole SNMP (Simple Network Management Protocol) et ne nécessite aucune modification du pare-feu non plus. Tout ce dont IP Fabric a besoin pour se mettre au travail, ce sont des informations d’identification en lecture seule et un accès à l’infrastructure.
    Le processus de découverte de réseau d’IP Fabric fonctionne sur les périphériques réseau actifs, tels que les commutateurs, les routeurs, les pare-feu, les équilibreurs de charge ou les contrôleurs Wi-Fi. Il collecte également des données sur les serveurs et autres appareils connectés au réseau. Le processus de découverte est évolutif et peut découvrir plus de 3000 appareils par heure.
    Afin d’être le plus agnostique possible, la liste des constructeurs et des configurations pris en charge est en constante évolution.
Continuer la lecture de « Observabilité du réseau (part.2) »

Observabilité du réseau (part.1)

Observabilité du réseau

Dernière modification le 16 avril 2022

Dans la boucle interne de l’Intent-Based Networking, il y a la partie « Intent Fulfillment » qui consiste à partir d’une Source de Vérité unique pour générer des configurations en direction des équipements (directement vers les équipements ou en passant pas une station de management) à l’aide d’un ensemble de programme et la partie « Intent Assurance » qui comprend, entre autre, le « Monitoring ».

Que ce soit dans ou en dehors de la démarche NetDevOps , le chapitre « Monitoring », qui comprend l’observabilité du réseau, est souvent mal compris et mal pris en compte.

Lorsque le sujet de la visibilité du réseau est abordé, la plupart des professionnels pensent à la surveillance du réseau en terme de monitoring traduit par « surveillance ». Les outils de monitoring fournissent une vue centralisée de la santé opérationnelle de l’infrastructure sous-jacente.

Les protocoles et technologies courants de surveillance du réseau incluent entre autre : SNMP (Simple Network Management Protocol), NetFlow, sFlow et syslog. Ils se retrouvent dans des produits aussi divers que Grafana/Prometheus, Zabbix, sFlow-RT, ntopng, Graylog…
La surveillance du réseau nécessite généralement une intervention humaine pour établir le comportement normal du réseau et du trafic. Ensuite, des outils de surveillance identifient et alertent les équipes sur les modifications du comportement attendu. Par exemple, les équipes peuvent utiliser SNMP pour référencer le comportement de débit d’une liaison réseau critique au fil du temps. Une fois que les administrateurs ont déterminé le comportement de base, l’outil de surveillance peut les alerter lorsque le comportement de débit dépasse ce qui est typique.

Continuer la lecture de « Observabilité du réseau (part.1) »

Intent-Based Networking, concepts et définitions

Internet Research Task Force

Dernière modification le 9 janvier 2022

Les bases de la définition de l’IBN (Intent-Based Networking) ont été posées en décembre 2019 dans le groupe de recherche NMRG (Network Management Research Group) de l’IRTF (Internet Research Task Force). Elle a évolué pendant deux ans et à la date d’écriture de cet article, c’est la version 06 du 15/12/2021 qui est active.

Alors que les réseaux qui acceptent les ordres sous forme d’intentions s’appellent « Intent-Based Networks » (IBN), les systèmes qui permettent cette implémentation se nomment « Intent-Based Systems » (IBS). L’intention se définit comme un ensemble d’objectifs opérationnels qu’un réseau doit atteindre et les résultats qu’un réseau est censé fournir, sans préciser comment les atteindre ou les mettre en œuvre. Le terme « Intent » est apparu la première fois en juin 2015 dans le RFC 7575 « Autonomic Networking ».

L’intention applique plusieurs concepts simultanément :

  • Fournir une abstraction des données : les utilisateurs n’ont pas besoin de s’inquiéter de la configuration de bas niveau des équipements.
  • Fournir une abstraction fonctionnelle : les utilisateurs n’ont pas besoin de se préoccuper de la manière d’atteindre une intention donnée. Ce qui est spécifié est le résultat souhaité, avec l’IBS qui détermine automatiquement un plan d’action (par exemple, en utilisant un algorithme ou en appliquant un ensemble de règles dérivées de l’intention) pour savoir comment atteindre le résultat.
Continuer la lecture de « Intent-Based Networking, concepts et définitions »

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 »

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

ACA - Aéroports de la Côte d'Azur

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 Aéroports de la Côte d'Azur
Monitoring Grafana / Prometheus en lab
Écosystème NetDevOps Aéroports de la Côte d'Azur
É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

Intent-Based Networking

Intent-Based Networking

Dernière modification le 17 juin 2021

Vous vous souvenez des étapes de l’implémentation DevOps pour les infrastructures réseaux déjà présentées dans cet article. Bien que tout ceci puisse vous faire penser à du marketing ou même à du buzzword, il s’agit bien de réalités terrains qui sont concrètement mises en oeuvre avec des étapes intermédiaires supplémentaires.

Etapes Automatisation
Source Juniper Networks

Si nous remontons dans l’histoire, le scripting n’est pas un phénomène nouveau. Dès le début de ma carrière, j’utilisai déjà le scripting pour automatiser les déploiements. Il s’agissait de programmes écrits en perl (1987) ou en Visual Basic (1991) finalement associé avec SecureCRT (1995) dont l’objectif était d’envoyer des commandes CLI sur les équipements et d’analyser les réponses (méthode appelée Screen Scraping). Ce qui a changé avec le temps, c’est le fait d’utiliser des protocoles de communication optimisés (NETCONF, RESTCONF ou gNMI) et des formats de données adaptés (XML, JSON ou protobuf), pour parler de « Human-driven Automation ».

Bien que de nombreuses idées fondamentales des approches DevOps, comme les pratiques Lean, le mode Agile ou le cycle Plan-Do-Check-Act de la roue de Deming, ont été popularisés dans les années 1990, le terme DevOps que nous connaissons est né en 2009. Après avoir été appliqué aux développement, puis au système, le DevOps a finalement été appliqué au réseau. Le mouvement NetDevOps avait pour objectif de supprimer le goulot d’étranglement que représentait le réseau dans les cycles rapides d’adaptation imposés par les applications et les infrastructures de serveurs en mouvements permanents pour suivre les besoins métiers et marchés. Le NetDevOps propose l’idée de considérer l’infrastructure réseau en tant que IaC (Infrastructure as Code) ou plus spécifiquement NaC (Network as Code), avec tous les principes techniques, technologiques, méthodologiques, organisationnels et humains sous-jacents. Le NetDevOps a apporté un tournant dans les nouveaux profils de compétences nécessaires à son application concrète.

Continuer la lecture de « Intent-Based Networking »

Containerlab, topologie de lab sur Docker

Containerlab

Avec le nombre croissant de switchs virtuels conteneurisés, le besoin de les exécuter facilement dans des topologies de simulation augmente. Je l’avais déjà évoqué en présentant le cEOS-lab Arista, les outils d’orchestration de conteneurs tels que docker-compose ne conviennent pas, car ils ne permettent pas de créer facilement des connexions entre les conteneurs pour définir une topologie.

Containerlab fournit une interface IaaC (Infrastructure as a Code) sous forme d’un langage de commande pour l’orchestration et la gestion des simulations réseau basées sur des conteneurs. Il démarre les conteneurs, construit un câblage virtuel entre eux pour créer des topologies et gère le cycle de vie des simulations.

Containerlab se concentre sur les NOS (Network Operating System) conteneurisés qui sont généralement utilisés pour tester les fonctionnalités réseau, tels que :

  • Nokia SR-Linux
  • Arista cEOS
  • Azure SONiC
  • Juniper cRPD
Continuer la lecture de « Containerlab, topologie de lab sur Docker »