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 »

Un lab économique pour le Network as Code

Lab économique pour le Network as Code

Dernière modification le 31 juillet 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 »

Ansible Collection 1.3.0 pour OmniSwitch AOS

ALE Ansible Collection

La collection est disponible dans la Galaxy Ansible et attend vos tests et propositions d’améliorations, le dépôt officiel des modules étant dans le GitHub public. La licence utilisée permet toutes les améliorations des Network Modules et Filtres sur la branche main, mais n’autorise pas la redistributions des forks, afin d’éviter la perte d’énergie (licence Attribution-NonCommercial-NoDerivatives 4.0 International / CC BY-NC-ND 4.0).

Modules

  • gmoisio.ale.ale_aos_ping : Vérifie la connectivité en SSH à un équipement.
  • gmoisio.ale.ale_aos_command : Exécute une liste de commandes sur un équipement. Il est possible de chercher une chaîne de caractères dans le résultat de chaque commande en passant un dictionnaire dans la liste. Dès qu’une chaine de caractère n’est pas trouvée, l’exécution des commandes s’arrête.
  • gmoisio.ale.ale_aos_config : Exécute un ensemble de commandes, généralement pour effectuer une configuration. L’ensemble des commandes peut être transmis sous la forme d’une liste ou sous la forme d’un fichier texte pouvant être généré via un template Jinja2.
  • gmoisio.ale.ale_aos_facts : Module expérimental permettant de récupérer des informations (vlans, interfaces et serveurs ntp) sous la forme d’un dictionnaire de listes pour effectuer des boucles.

Filtres

gmoisio.ale.validate : Ce filtre permet de valider des variables en les confrontant à un schéma YAML. La génération d’un template Jinja2 s’arrête en affichant les causes d’erreurs si les variables ne sont pas conformes au schéma. Le filtre peut être utilisé dans un playbook pour seulement valider la Source de Vérité.

Continuer la lecture de « Ansible Collection 1.3.0 pour OmniSwitch AOS »

Documenter du code Python

Documenter code Python

Lorsqu’il s’agit de documenter des développements, il existe plusieurs méthodes. Soyons direct, l’approche qui consiste à réaliser un document n’a aucune pérennité. Dès les premières phases de refactoring ou d’amélioration, la documentation ne sera pas mise à jour.

L’approche qui consiste à utiliser un Wiki est déjà plus souple et permet à plusieurs développeurs de collaborer sur la construction documentaire. Cependant, idéalement, il convient de limiter les changements d’environnements qu’un développeur peut être amené à faire pour mener à bien sa mission. Il y a deux environnements dans lequel le développeur évolue depuis son IDE (Integrated Development Environment).

Il y a tout d’abord le répertoire qui contient l’ensemble de l’arborescence du produit et qui se traduit sur le serveur de versioning par une branche dans un repository. Le format le plus utilisé est le markdown qui permet de créer des fichiers documentaires un peu agrémentés de mises en pages, sachant que par convention, un serveur de versioning affiche automatiquement le fichier README.md du répertoire visité.

Le deuxième environnement est le code lui-même, dans lequel il est naturel pour le développeur, d’intégrer au moins des commentaires qui lui permettront de retrouver la logique utilisée lorsqu’il se replongera, plus tard, dans le code. Comme défini dans PEP 8 (Style Guide for Python Code), les commentaires peuvent être de type « Block Comments » ou « Inline Comments ».

Continuer la lecture de « Documenter du code Python »

Ansible Collection 1.2.2 pour OmniSwitch AOS

ALE Ansible Collection

La collection est disponible dans la Galaxy Ansible et attend vos tests et propositions d’améliorations, le dépôt officiel des modules étant dans le GitHub public. La licence utilisée permet toutes les améliorations des Network Modules sur la branche main, mais n’autorise pas la redistributions des forks, afin d’éviter la perte d’énergie (licence Attribution-NonCommercial-NoDerivatives 4.0 International / CC BY-NC-ND 4.0).

  • gmoisio.ale.ale_aos_ping : Vérifie la connectivité en SSH à un équipement.
  • gmoisio.ale.ale_aos_command : Exécute une liste de commandes sur un équipement. Il est possible de chercher une chaîne de caractères dans le résultat de chaque commande en passant un dictionnaire dans la liste. Dès qu’une chaine de caractère n’est pas trouvée, l’exécution des commandes s’arrête.
  • gmoisio.ale.ale_aos_config : Exécute un ensemble de commandes, généralement pour effectuer une configuration. L’ensemble des commandes peut être transmis sous la forme d’une liste ou sous la forme d’un fichier texte pouvant être généré via un template Jinja2.
  • gmoisio.ale.ale_aos_facts : Module expérimental permettant de récupérer des informations (vlans, interfaces et serveurs ntp) sous la forme d’un dictionnaire de listes pour effectuer des boucles.

Pour exécuter le module gmoisio.ale.ale_aos_command sous sa nouvelle forme, il convient de se conformer aux syntaxes suivantes :

---
- name: This is a test for ale_aos_command module
  hosts: ale
  connection: local
  gather_facts: no
  tasks:
    - name: Test ale_aos_command Python module
      gmoisio.ale.ale_aos_command: 
        host: "{{ ansible_host }}"
        username: "{{ login }}"
        password: "{{ password }}"
        commands:
          - show running-directory
          - show vlan
Continuer la lecture de « Ansible Collection 1.2.2 pour OmniSwitch AOS »

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 »

Ansible Collection pour OmniSwitch

ALE Ansible Collection

J’avais écrit les modules ale_aos pour Ansible disponibles dans la Galaxy pour permettre l’interaction entre Ansible et des OmniSwitchs en AOS6 et AOS8.

Au cours du cycle de développement d’Ansible 2.10, la communauté Ansible a migré avec succès la plupart des modules et plugins vers les collections. Les collections, ainsi que les modules et plugins qu’elles contiennent, peuvent désormais être développées, mises à jour et publiées indépendamment d’Ansible lui-même. Depuis Ansible 2.10, les utilisateurs de la communauté ont deux options: continuer à installer tout avec le package de communauté Ansible, ou installer ansible-base (2.10) ou ansible-core (2.11), puis ajouter les collections sélectionnées individuellement.

Afin de suivre l’évolution d’Ansible, j’ai porté le rôle ale_aos vers une collection en apportant quelques améliorations. La collection est disponible dans la Galaxy Ansible et attend vos tests et propositions d’améliorations, le dépôt officiel des modules étant dans le GitHub public. La licence utilisée permet toutes les améliorations des Network Modules sur la branche main, mais n’autorise pas la redistributions des forks, afin d’éviter la perte d’énergie (licence Attribution-NonCommercial-NoDerivatives 4.0 International / CC BY-NC-ND 4.0).

  • gmoisio.ale.ale_aos_ping : Vérifie la connectivité en SSH à un équipement.
  • gmoisio.ale.ale_aos_command : Exécute une commande sur un équipement. Il est possible de chercher une chaîne de caractères dans le résultat de la commande.
  • gmoisio.ale.ale_aos_config : Exécute un ensemble de commandes, généralement pour effectuer une configuration. L’ensemble des commandes peut être transmis sous la forme d’une liste ou sous la forme d’un fichier texte pouvant être généré via un template Jinja2.
  • gmoisio.ale.ale_aos_facts : Module expérimental permettant de récupérer des informations (vlans, interfaces et serveurs ntp) sous la forme d’un dictionnaire de listes pour effectuer des boucles.
Continuer la lecture de « Ansible Collection pour OmniSwitch »

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 »

Nautobot Inventory dynamique

Nautobot Inventory

Nautobot est une plateforme utilisée en tant que Source de Vérité et d’automatisation réseau extensible et flexible. Que ce soit pour mettre en place une automatisation Python ou Ansible, il est possible et judicieux d’utiliser Nautobot en tant qu’inventory.

Pour programmer en Python, l’utilisation du Framework Nornir est un standard pour l’automatisation réseau. Il existe le plugin nornir-nautobot qui permet de faciliter la connexion à la Source de Vérité et de filtrer les équipements sur lesquels on souhaite travailler.

Continuer la lecture de « Nautobot Inventory dynamique »

Sonde H5 audits sur simulateur

H5 audits EVE-NG

L’utilisation d’un simulateur est un élément incontournable pour une approche NetDevOps. Il est clair que tout constructeur ou fournisseur de logiciel incapable de passer sur un simulateur tel que EVE-NG, pour s’inscrire dans une infrastructure virtualisée, ne peut pas prétendre jouer dans la cours du SDN (Software Defined Network).

Lorsqu’il est question d’analyser le trafic au sein d’une infrastructure simulée, EVE-NG Pro dispose nativement de Wireshark pour effectuer des captures sur les liens inter-équipements. Mon souhait était de pouvoir aller plus loin dans l’analyse avec une sonde virtuelle.

L’avantage d’avoir un constructeur français de sondes, dont la recherche et développement est accessible, est d’avoir réussi à exprimer et défendre ce besoin et d’avoir été entendu. Je remercie Frédéric GUILLOIS (President H5 Audits) et Lionel BARRERE (Chief Technical Officer H5 Audits) de m’avoir écouté et d’avoir mis au point la réponse à ma demande.

Continuer la lecture de « Sonde H5 audits sur simulateur »