Batfish, outil Open Source d’analyse de configuration réseau

Batfish

L’écosystème NetDevOps propose de nombreux outils pouvant être positionnés aux différentes étapes de la boucle interne de l’Intent-Based Networking. Dans une approche NetDevOps, Batfish permet de contrôler des configurations avant leur déploiement.

Batfish détecte les erreurs et garantit l’exactitude des configurations de réseau prévisionnelles ou actuellement utilisées. Il permet une évolution sûre et rapide du réseau, sans crainte de pannes ou de failles de sécurité.

Batfish a été initialement développé par des chercheurs de Microsoft Research, UCLA et USC. Beaucoup d’autres y ont contribué depuis. Il est actuellement maintenu par Intentionet, qui propose également Batfish Enterprise, un service qui étend et améliore les capacités de base de Batfish.

Batfish est un service qui tourne sous la forme d’un conteneur Docker. Batfish est conçu pour analyser une série de snapshots d’un réseau. Il faut voir le réseau comme un regroupement logique d’appareils, que ce soit tous les appareils du réseau ou un sous-ensemble. Un snapshot est un état du réseau à un instant donné. Un réseau peut contenir de nombreux snapshots, pour permettre de comprendre son évolution.

Continuer la lecture de « Batfish, outil Open Source d’analyse de configuration réseau »

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

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 »

Administrer Kubernetes avec Rancher

Kubernetes Rancher

Dernière modification le 10 août 2021

Vous déployez des clusters Kubernetes partout – sur site, dans le cloud et à la périphérie. Rancher unifie ces clusters pour assurer des opérations cohérentes, une gestion de la charge de travail et une sécurité de niveau entreprise…

Rancher est un projet Open Source avec un support disponible pour les entreprises. Pour ceux qui souhaiteraient le tester, voici une procédure simplifiée sur la base d’un serveur Ubuntu 20.04 à jour et disposant d’au moins 2 vCPUs, 4 Go de RAM et 20 Go de disque.

Installer Kubernetes K3s

sudo apt install curl
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--write-kubeconfig-mode 644" sh -

Installer Helm

wget https://get.helm.sh/helm-v3.6.3-linux-amd64.tar.gz
tar -zxvf helm-v3.6.3-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm

Installer Rancher

mkdir .kube
kubectl config view --raw > ~/.kube/config
chmod 600 ~/.kube/config
kubectl create namespace cattle-system
kubectl create namespace cert-manager
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.4.3/cert-manager.crds.yaml
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v1.4.3
kubectl get pods --namespace cert-manager
helm install rancher rancher-latest/rancher --namespace cattle-system --set hostname=k3s-rancher.homelab.int
kubectl -n cattle-system rollout status deploy/rancher
kubectl -n cattle-system get deploy rancher

Il reste à faire pointer l’URL k3s-rancher.homelab.int vers l’adresse IP de la machine grâce au fichier /etc/hosts du poste de travail, puis naviguer vers https://k3s-rancher.homelab.int/.

Kubernetes Rancher Cluster Manager
Rancher Cluster Manager
Kubernetes Rancher Cluster Explorer
Rancher Cluster Explorer

Kubernetes pour le NetDevOps

Kubernetes

Dernière modification le 10 août 2021

Lorsqu’il s’agit d’installer un environnement système et applicatif pour le NetDevOps, la question qui consiste à choisir entre Docker et Kubernetes ne pose plus vraiment de dilemne.

Pendant un certain temps, la réponse la plus adaptée était qu’ils étaient complémentaires, mais ce n’est plus le cas. Depuis début 2021, Kubernetes ne supporte plus Docker en tant qu’environnement d’exécution de conteneur.

Kubernetes fonctionne avec tous les environnements d’exécution de conteneur qui implémentent une norme connue sous le nom de CRI (Container Runtime Interface). Il s’agit essentiellement d’un moyen standard de communication entre Kubernetes et l’environnement d’exécution du conteneur, et tout environnement d’exécution prenant en charge cette norme fonctionne automatiquement avec Kubernetes.

Docker n’implémente pas l’interface d’exécution de conteneur (CRI). Dans le passé, il n’y avait pas autant d’options pour les environnements d’exécution de conteneurs, et Kubernetes avait implémenté le Shim Docker, une couche supplémentaire servant d’interface entre Kubernetes et Docker. Maintenant, cependant, il existe de nombreux runtimes disponibles qui implémentent le CRI, et il n’est plus logique que Kubernetes maintienne un support spécial pour Docker.

Pour vraiment comprendre pourquoi il est logique que Kubernetes se détache de Docker, il faut comprendre que Docker n’est pas vraiment un environnement d’exécution de conteneur. C’est en fait une collection d’outils qui se trouve au-dessus d’un environnement d’exécution de conteneur appelé containerd. Docker n’exécute pas directement les conteneurs. Il crée simplement une interface plus accessible et plus riche en fonctionnalités en plus d’un environnement d’exécution de conteneur sous-jacent séparé. Lorsqu’il est utilisé comme environnement d’exécution de conteneur pour Kubernetes, Docker n’est qu’un intermédiaire entre Kubernetes et containerd. Or, Kubernetes peut utiliser containerd directement comme environnement d’exécution de conteneur, ce qui signifie que Docker n’est plus nécessaire dans ce rôle d’intermédiaire.

Continuer la lecture de « Kubernetes pour le NetDevOps »

Un lab économique pour le Network as Code

Lab économique pour le Network as Code

Dernière modification le 10 août 2021

Pratiquer le Network as Code, qui se décline en différentes appellations dans la littérature (NetDevOps, NetOps, Infrastructure as Code, Intent Based Networking, …), fait appel à un simulateur réseau pour monter rapidement un environnement sans pour autant posséder tout le matériel nécessaire.

Si le but recherché est d’accéder à un équipement ou deux pour s’entrainer à la pratique du langage de commande (EOS, IOS, NXOS, Junos…), d’une technologie réseau (VXLAN, EVPN/VXLAN, MLAG,…) ou de techniques et technologies d’automatisation (Ansible, Python/Nornir, RESTCONF, NETCONF, gNMI/gRPC, …), il existe de nombreuses solutions qui peuvent s’accommoder de peu de ressources. Mais lorsqu’il s’agit de monter un véritable lab pour reproduire un environnement de simulation complet, on se rend compte qu’il faut rapidement disposer de ressources CPU et RAM importantes. La quantité nécessaire dépasse facilement les ressources disponibles sur une machine de développement ou d’enseignement.

Pourtant il peut s’avérer pratique d’être autonome et de ne dépendre ni d’un serveur additionnel, ni d’une ressource internet, sans pour autant mettre sa machine en surchauffe. Croyez moi, un MacBook Pro qui chauffe pendant la saison d’été c’est très désagréable pour les poignets et plus globalement pour la température ambiante.

Pour monter un environnement de virtualisation sur le MacBook, rien n’est plus rapide et léger que Multipass de Canonical. C’est la méthode recommandée pour créer des machines virtuelles Ubuntu sur Ubuntu. Il est conçu pour les développeurs qui souhaitent un nouvel environnement Ubuntu avec une seule commande et fonctionne sous Linux, Windows et macOS. Multipass utilise la virtualization native de chaque système d’exploitation sur lequel il est installé : Hyper-V sur Windows, HyperKit sur macOS et KVM sur Linux, pour une surcharge minimale et un temps de démarrage le plus rapide possible.

Continuer la lecture de « Un lab économique pour le Network as Code »

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 »