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 »

GraphQL et Nautobot

GraphQL Nautobot

GraphQL est un langage de requête et un environnement d’exécution côté serveur pour les API (Application Programming Interface) qui s’attache à fournir aux clients les données qui ont été demandées. Utilisé à la place de REST, GraphQL permet aux développeurs de créer des requêtes qui extraient les données de plusieurs sources à l’aide d’une seule requête API. Les requêtes GraphQL renvoient toujours des résultats prévisibles. Alors que les API REST typiques nécessitent un chargement à partir de plusieurs URL, les API GraphQL obtiennent toutes les données dont l’application a besoin en une seule demande. De plus, avec GraphQL, les équipes chargées de la maintenance des API peuvent librement ajouter ou retirer des champs sans perturber les requêtes existantes.

GraphQL a été développé par Facebook, qui a commencé à l’utiliser pour les applications mobiles en 2012. La spécification de GraphQL est devenue Open Source en 2015. Elle est désormais supervisée par la GraphQL Foundation.

Un service GraphQL est créé en définissant des types et des champs sur ces types, puis en fournissant des fonctions pour chaque champ sur chaque type. Par exemple, un service GraphQL qui indique qui est l’utilisateur connecté (me) ainsi que le nom de cet utilisateur peut ressembler à ceci :

type Query {
  me: User
}
 
type User {
  id: ID
  name: String
}

Avec des fonctions pour chaque champ sur chaque type :

function Query_me(request) {
  return request.auth.user;
}
 
function User_name(user) {
  return user.getName();
}
Continuer la lecture de « GraphQL et Nautobot »

Nautobot – Network to Code

Nautobot NTC

La solution communautaire NetBox a été supportée pendant plusieurs années par la société Network to Code qui a finalement décidé de procéder à un fork de manière à créer un nouveau produit appelé Nautobot avec une nouvelle orientation stratégique : proposer une plateforme d’automatisation avec un support de qualité.

Source de vérité flexible
À la base, Nautobot est une source de vérité qui définit l’état qui est prévu pour le réseau (Intent-Based Networking).


Plateforme de données extensible pour l’automatisation de réseau
Nautobot est plus que de la documentation du réseau. Nautobot propose des intégrations et une extensibilité pour véritablement alimenter des solutions d’automatisation de réseau. Nautobot possède des API de plateforme robustes qui incluent des API RESTful (HTTP) traditionnelles, des API GraphQL, des webhooks basés sur les événements et de nombreuses fonctionnalités d’extensibilité pour permettre une plus grande automatisation du réseau. Nautobot utilise également son extensibilité pour agréger des systèmes de données disparates créant une source unique de vérité pour les solutions d’automatisation de réseau.


Plateforme pour les applications d’automatisation de réseau
La plateforme d’applications Nautobot fournit une architecture à partir de laquelle des applications d’automatisation de réseau peuvent être créées. Les applications Nautobot sont des augmentations ou des ajouts flexibles et personnalisés. Grâce à la plateforme d’applications Nautobot, les entreprises peuvent fournir des extensions et des applications d’automatisation de réseau personnalisables 65 à 70% plus rapidement.

Continuer la lecture de « Nautobot – Network to Code »

Cluster EVE-NG Pro

EVE-NG Pro cluster

Avec la version 4 de EVE-NG Pro, une nouvelle fonctionnalité attendue depuis longtemps est disponible. Il est, maintenant, possible de monter un cluster de serveur EVE-NG afin d’augmenter la capacité disponible pour faire tourner une simulation.

L’installation standard de EVE-NG Pro portant la licence devient d’office le « master » du cluster et toutes les autres installations doivent se faire en mode « agent » en suivant la dernière version de la documentation.

La gestion du cluster et l’intégration de nouveaux agents se fait depuis le « master ».

eve-ng-sat01
Cluster EVE-NG
Continuer la lecture de « Cluster EVE-NG Pro »

Cisco et l’historique de l’IOS

Historique Logo Cisco

Que ce soit lié à des améliorations technologiques ou à des rachats de sociétés, l’IOS de Cisco, au sens du système d’exploitation de matériels actifs réseau, a connu de nombreuses versions et évolutions. L’objectif n’est pas de retracer tous les détails de son histoire, mais de positionner les différents systèmes auxquels on fait référence lorsqu’on parle d’IOS aujourd’hui.

L’IOS, que nous avons tous connu, était un système d’exploitation monolithique qui exécutait un seul thread sur une large gamme de processeurs. Conçu et développé à une époque différente, il supporte maintenant certains matériels d’accès (1) et sert à maintenir un parc existant.

Le système IOS-XE traite l’aspect monolithique de l’IOS. Bien que non-directement accessible, le système d’exploitation sous-jacent est basé sur une distribution Linux qui fonctionne sur des processeurs multicœurs. IOS-XE fonctionne sur plusieurs plateformes matérielles de différentes unités commerciales (1), comme par exemple, le Catalyst 9000.

Le système NX-OS est un système d’exploitation extensible, ouvert et programmable conçu pour répondre aux exigences des déploiements physiques et virtuels des DataCenters. Il offre des fonctionnalités essentielles, telles qu’une architecture modulaire et flexible, une disponibilité continue du système, des capacités de virtualisation des commutateurs, l’automatisation du réseau, ainsi que l’approvisionnement et la configuration programmatique des commutateurs via des API complètes. Il prend principalement en charge la famille de produits Cisco Nexus (1), dont le Nexus 9000. NX-OS fonctionne dans l’un des deux modes : le mode autonome ou le mode Application Centric Infrastructure (ACI). Le mode ACI est conçu et optimisé pour une utilisation avec les contrôleurs APIC (Application Policy Infrastructure Controllers) de Cisco.

Continuer la lecture de « Cisco et l’historique de l’IOS »

Appliance v3.0

Appliance v3.0

L’objectif de cette nouvelle appliance n’est pas de remplacer l’Appliance Automation v2.0, ni l’Appliance EVE-NG v2.0. C’est une autre approche dont l’objectif est de concentrer de la puissance dans une plateforme miniature qui permet d’offrir la quasi-totalité des fonctionnalités des deux autres plateformes réunies. De même, le coût de cette plateforme est approximativement équivalente aux deux autres réunies.

Le premier étage sert à offrir des services de connexion réseau indépendamment des possibilités de l’infrastructure d’accueil.

Premier Etage Appliance v3.0
Continuer la lecture de « Appliance v3.0 »

Kubernetes

Kubernetes

Dernière modification le 11 janvier 2020

Très rapidement, je me suis intéressé à Docker pour faire de la conteneurisation et plus particulièrement pour déployer des architectures microservices ou cloud-native. Dès que Swarm a été intégré dans la distribution Docker-ce, c’est devenu mon orchestrateur de prédilection. N’ayant pas été le seul a raisonner comme ça, il était facile de trouver de nombreux exemples Dockerfile et Docker Compose pour travailler dans le domaine du réseau.

A postériori, force est de constater que Docker a perdu la bataille des orchestrateurs qui n’aurait pas du être la sienne. Kubernetes (K8S) a été largement adopté pour l’orchestration de conteneurs.

Continuer la lecture de « Kubernetes »

Appliance Automation v2.0

Appliance Automation v2.0

Dernière modification le 11 janvier 2020

Les étapes alpha et bêta sont terminées, mon Appliance Automation v2.0 est finie. Le brevet prévoyait déjà une fragmentation de la solution. Dans la version v1.0, ce sont les fonctions qui étaient fragmentées, mais la solution matérielle reposait sur un serveur unique. Dans la version v2.0, la partie matérielle a été répartie sur plusieurs serveurs, ce qui rend la solution facilement évolutive par ajout de modules.

Appliance Automation
Continuer la lecture de « Appliance Automation v2.0 »