ansible – Gilbert MOÏSIO

3 octobre 2021

Automatisation Juniper – Aéroport Nice 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

18 juillet 202118 juillet 2021

Ansible Collection 1.3.0 pour OmniSwitch AOS

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

27 juin 202127 juin 2021

Ansible Collection 1.2.2 pour OmniSwitch AOS

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

7 juin 20217 juin 2021

Ansible Collection pour OmniSwitch

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

24 mai 202125 mai 2021

Nautobot Inventory dynamique

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

1 mars 20211 mars 2021

Ansible 3.0.0

La version 3.0.0 du package communautaire Ansible marque la fin de la restructuration de l’écosystème Ansible. Ce travail achève ce qui a commencé en 2019 pour restructurer le projet Ansible et façonner la manière dont le contenu Ansible est livré.

Dans Ansible 2.9 et les versions antérieures, chaque plugin et module se trouvait dans le projet Ansible (https://github.com/ansible/ansible) lui-même. Lorsque vous installiez le package « ansible », vous aviez le langage, le runtime et tout le contenu (modules et autres plugins). Au fil du temps, le succès d’Ansible a créé des problèmes d’évolutivité. Les utilisateurs devaient attendre plusieurs mois pour un contenu mis à jour.

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. Le package de la communauté Ansible 2.10 comprenait ansible-base 2.10 ainsi que toutes les collections qui contiennent des modules et des plugins qui ont été migrés hors du référentiel d’origine. Depuis Ansible 2.10, les utilisateurs de la communauté avaient deux options: continuer à installer tout avec le package de communauté Ansible, ou installer ansible-base, puis ajouter les collections sélectionnées individuellement.

Continuer la lecture

23 décembre 202023 décembre 2020

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

22 décembre 202022 décembre 2020

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

12 novembre 20203 mars 2022

ALE AOS8 Web Services

Dernière modification le 3 mars 2022

Alcatel-Lucent Enterprise le rappelle régulièrement : « l’objectif est de n’avoir à terme que des commutateurs Ethernet en AOS8 ». Effectivement, tous les modèles qui sont sortis et se sont rajoutés au catalogue, parfois en remplacement de modèles existants, font tourner la version 8 de l’AOS. Dans ce contexte il était intéressant de voir les possibilités offertes en matière d’automatisation externe en environnement homogène.

Pour rappel, lorsqu’on est dans un contexte de mixité AOS6 et AOS8, les possibilités sont les suivantes :

Utiliser la librairie Netmiko avec Python, pour laquelle j’avais écrit le module AOS en 2017 et qui est toujours maintenu par Kirk Byers lors des différentes montées de version de la librairie.
Utiliser le Network Module ale_aos que j’ai écrit pour Ansible en 2020.

C’est la fonction Web Services qui permet de personnaliser et d’étendre l’interface de gestion sur les dispositifs AOS8. Dans le cas qui nous intéresse, il prend en charge l’utilisation d’une interface web basée sur REST qui interagit avec les variables de gestion AOS (MIB) et les commandes CLI. Donc, il fournit deux méthodes de configuration via la gestion directe des variables MIB ou l’utilisation de commandes CLI et prend en charge à la fois les formats de réponse en XML et en JSON.

Il ne faut pas confondre REST et le protocole RESTCONF qui utilise le modèle de données YANG. REST est un ensemble de directives pour l’architecture logicielle des systèmes distribués et AOS8 supporte les verbes suivants :

GET : pour récupérer des informations. C’est un équivalent grossier de SNMP / MIB GET mais aussi, à un niveau supérieur, un équivalent de la commande show. Ce verbe est utilisé exclusivement pour les commandes en lecture seule et sans autre effet secondaire.
PUT : pour créer de nouvelles informations, comme, par exemple, un nouveau VLAN. Il s’agit d’une opération d’écriture.
POST : fonctionne de la même façon que lors de la soumission de formulaires Web et il est utilisé, dans un contexte de service Web, pour mettre à jour des informations existantes.
DELETE : pour supprimer des informations existantes.

Continuer la lecture

10 juin 202010 juin 2020

Webinar Université de Nice Côte d’Azur

Webinar pour l’Université de Nice Côte d’Azur organisé par Stéphane FRATI, Responsable parcours Licence Pro CyberDéf – Département Réseaux et Télécommunications (RT), le vendredi 5 juin 2020.

Outre une évaluation de connaissance dans le domaine du NetDevOps et plus particulièrement de l’automatisation réseau, l’objectif du Webinar était de proposer une présentation théorique de certains sujets parfois illustrés d’une démonstration visant à préparer une séance de travaux pratiques pour permettre aux étudiants de mettre en place leur propre plateforme de simulation et d’automatisation.