Publié le

Cumulus – EVPN – VXLAN

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 de « Cumulus – EVPN – VXLAN »
Publié le

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 de « Cumulus – VXLAN statique »
Publié le

ALE AOS8 Web Services

ALE AOS8 Web Services

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 de « ALE AOS8 Web Services »
Publié le

Webinar Université de Nice Côte d’Azur

Webinar Université 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.

Publié le

Free Webinar Ansible avec Juniper Networks

Free Webinar Juniper

Dernière modification le 21 avril 2020

Afin de profiter de la période de confinement pour améliorer les connaissances et revenir dans le circuit économique avec des méthodes encore plus efficaces, je vous propose une série de Webinars gratuits sur l’Automatisation Réseau.

Régulièrement, nous prendrons un sujet et nous le regarderons ensemble. L’objectif n’est pas seulement de participer de manière passive, mais aussi d’essayer soit même de le mettre en place en se faisant assister de la communauté présente dans le webinar.

Rejoignez la communauté Slack du NetDevOps Accelerator.

Continuer la lecture de « Free Webinar Ansible avec Juniper Networks »
Publié le

Automatisation Arista

Automatisation Arista

Outre la capacité de Zero-touch Provisioning, le NOS (Network Operating System) EOS d’Arista propose plusieurs possibilités d’automatisation. Nombre de ces possibilités peuvent s’expérimenter sur les commutateurs virtuels proposés sous forme de conteneur (cEOS-lab) ou de machine virtuelle (vEOS-lab).

Automatisation On-box

L’Event Manager est une fonctionnalité des commutateurs Arista qui permet d’exécuter des scripts Bash lorsque certains événements système se produisent. Les Event handlers permettent le déclenchement d’un trigger et d’une action. De plus, il est possible de définir un delay de sorte qu’une durée configurée s’écoule après le déclenchement et avant que l’action ne soit prise.

EOS signifie Extensible Operating System, et à ce titre il est possible d’étendre le système avec des collections de fichiers. Ces fichiers sont regroupés sous la forme d’un package appelé RPM (RedHat Package Manager ou RPM Package Manager). Le package prend en charge la gestion des dépendances. Lorsque plusieurs RPMs sont impliqués, ils sont regroupés dans une collection appelée SWIX (SoftWare Image Extension) et accompagnée d’un manifest.

Continuer la lecture de « Automatisation Arista »
Publié le

Free Webinar Python et Ansible avec Arista

Webinar Automatisation Arista

Dernière modification le 1 avril 2020

Afin de profiter de la période de confinement pour améliorer les connaissances et revenir dans le circuit économique avec des méthodes encore plus efficaces, je vous propose une série de Webinars gratuits sur l’Automatisation Réseau.

Régulièrement, nous prendrons un sujet et nous le regarderons ensemble. L’objectif n’est pas seulement de participer de manière passive, mais aussi d’essayer soit même de le mettre en place en se faisant assister de la communauté présente dans le webinar.

Rejoignez la communauté Slack du NetDevOps Accelerator.

Continuer la lecture de « Free Webinar Python et Ansible avec Arista »
Publié le

Free Webinar Python et Ansible avec ALE

Webinar Automatisation ALE

Dernière modification le 30 mars 2020

Afin de profiter de la période de confinement pour améliorer les connaissances et revenir dans le circuit économique avec des méthodes encore plus efficaces, je vous propose une série de Webinars gratuits sur l’Automatisation Réseau.

Régulièrement, nous prendrons un sujet et nous le regarderons ensemble. L’objectif n’est pas seulement de participer de manière passive, mais aussi d’essayer soit même de le mettre en place en se faisant assister de la communauté présente dans le webinar.

Rejoignez la communauté Slack du NetDevOps Accelerator.

Continuer la lecture de « Free Webinar Python et Ansible avec ALE »
Publié le

Arista et automatisation Ansible

Arista Ansible

Dernière modification le 4 avril 2020

Les modules officiels Arista EOS sont intégrés dans les Network Modules natifs et supportés par la Network Team d’Ansible.

Network Modules natifs Ansible :

  • eos_banner – Manage multiline banners on Arista EOS devices
  • eos_bgp – Configure global BGP protocol settings on Arista EOS
  • eos_command – Run arbitrary commands on an Arista EOS device
  • eos_config – Manage Arista EOS configuration sections
  • eos_eapi – Manage and configure Arista EOS eAPI
  • eos_facts – Collect facts from remote devices running Arista EOS
  • eos_interfaces – Manages interface attributes of Arista EOS interfaces
  • eos_l2_interfaces – Manages Layer-2 interface attributes of Arista EOS devices
  • eos_l3_interfaces – Manages L3 interface attributes of Arista EOS devices
  • eos_lacp – Manage Global Link Aggregation Control Protocol (LACP) on Arista EOS devices
  • eos_lacp_interfaces – Manage Link Aggregation Control Protocol (LACP) attributes of interfaces on Arista EOS devices
  • eos_lag_interfaces – Manages link aggregation groups on Arista EOS devices
  • eos_lldp – Manage LLDP configuration on Arista EOS network devices
  • eos_lldp_global – Manage Global Link Layer Discovery Protocol (LLDP) settings on Arista EOS devices
  • eos_lldp_interfaces – Manage Link Layer Discovery Protocol (LLDP) attributes of interfaces on Arista EOS devices
  • eos_logging – Manage logging on network devices
  • eos_static_route – Manage static IP routes on Arista EOS network devices
  • eos_system – Manage the system attributes on Arista EOS devices
  • eos_user – Manage the collection of local users on EOS devices
  • eos_vlans – Manage VLANs on Arista EOS devices
  • eos_vrf – Manage VRFs on Arista EOS network devices
Continuer la lecture de « Arista et automatisation Ansible »
Publié le

Ansible ALE Galaxy

ALE OmniSwitch Ansible Galaxy

Dernière modification le 28 mars 2020

Depuis plusieurs années, il y a une absence de module réseau pour Alcatel-Lucent Enterprise dans Ansible. Lorsque j’avais travaillé sur le module alcatel_aos pour Netmiko, l’idée était de permettre de faire de l’automatisation en utilisant le langage Python. L’adjonction du framework Nornir offrait une structuration du code qui reprenait certaines logiques d’Ansible. Trois ans plus tard, force est de constater qu’une grande majorité de personnes partent plus facilement sur le chemin du « Human-driven Automation » avec un outil comme Ansible et son pseudo langage en YAML qu’avec un langage direct comme Python qui reste réservé aux personnes plus expérimentées dans le développement.

C’est pour combler ce manque que j’ai écrit les modules ale_aos pour Ansible, en restant le plus générique possible afin de laisser plus de souplesse dans l’utilisation de ces modules. Ils sont disponibles dans la Galaxy Ansible, et attendent vos tests et propositions d’amélioration, le dépôt officiel des modules de la Galaxy étant dans un Github public. La licence utilisée permet toutes les améliorations sur la branche master des Network Modules, 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).

Continuer la lecture de « Ansible ALE Galaxy »