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 »

Appliance EVE-NG v2.0

Appliance EVE-NG

Dernière modification le 11 janvier 2020

La version 2.0 de mon appliance EVE-NG reprend le même serveur bare metal pour faire tourner EVE-NG, mais rajoute un étage sur la base d’un autre serveur, fabriqué à partir du concept de ma nouvelle « Appliance Automation », proposant une fonction DHCP pour distribuer des adresses IP aux personnes utilisant l’appliance via une connexion filaire ou Wi-Fi 5 (vitesse 1,3 Gbps en 5 GHz avec un canal de 80 MHz).

Continuer la lecture de « Appliance EVE-NG v2.0 »

Générateur de trafic

Générateur de Trafic

Dernière modification le 11 janvier 2020

Au début des années 2010, je cherchai une solution pour construire un générateur de trafic Ethernet à haut débit pour des tailles de paquets de 64 octets et le moins cher possible afin de mettre en œuvre le RFC2544. Après de nombreuses approches et de nombreux développements qui n’ont abouti à rien de significatif, c’est en 2014 que la question du générateur de trafic pour tester les matériels en maquette est devenue cruciale. La référence dans ce domaine était Ixia, mais ceux qui connaissent les prix comprennent que ce n’était pas une solution accessible à tout le monde. Dans le domaine commercial, un de ses concurrents intéressant et dont j’ai suivi la progression était Xena. L’avantage de ces solutions n’était pas tant la puissance des générateurs mais le niveau d’intégration et de finition de la couche logicielle qui permettait de lancer facilement des tests conformes aux standards.

Continuer la lecture de « Générateur de trafic »

Simulateurs réseau

Simulateurs

Dernière modification le 11 janvier 2020

L’époque des matériels actifs de spare utilisés pour faire un incubateur servant à simuler un réseau est totalement révolue pour tous les constructeurs leaders du domaine de l’automatisation. Les simulateurs réseau permettent de réaliser virtuellement un réseau.

Il ne faut pas confondre un simulateur et un émulateur. Un simulateur permet de faire tourner une version virtuelle d’un matériel actif (commutateur, routeur, firewall, …) grâce à la virtualization, alors qu’un émulateur reproduit un comportement sans pour autant avoir des versions virtuelles des appareils. Pour illustrer ces propos avec deux exemples très connus, GNS3 est un simulateur alors que Packet Tracer est un émulateur.

Une question fréquente consiste à se demander quel est le meilleur simulateur… Je pense qu’il n’y a pas de réponse valide à cette question. Tout dépend de l’usage qu’on est amené à en faire et au contexte dans lequel on l’utilise. Personnellement j’en utilise trois en fonction des objectifs.

Continuer la lecture de « Simulateurs réseau »

Docker

Docker

Dernière modification le 11 janvier 2020

Docker est un système de gestion de conteneurs incontournable dans le domaine du NetDevOps. La notion de conteneur est utilisée pour faire tourner une application de manière isolée et légère sur l’hôte sur lequel Docker est installé. L’accès aux services internes au conteneur se fait par une redirection de ports sur l’hôte qui fait tourner Docker.

La première préoccupation qui apparaît, avec la notion de conteneur, est la persistance des données. En effet, lorsque le conteneur est détruit, les données sont détruites avec lui. Si ce comportement peut être voulu pour repartir facilement d’une base vierge, il est des cas dans lesquels on veut garder l’historique des données. Pour palier à cela, il est facile d’utiliser la notion de volume, en les stockant dans un répertoire spécifique du serveur hôte Docker plutôt que dans le système de fichiers par défaut du conteneur. Ce stockage externe, appelé volume de données, permet de rendre les données indépendantes de la vie du conteneur, soit en le créant de toute pièce, soit en faisant une correspondance entre un répertoire source existant sur l’hôte et le répertoire destination dans le conteneur. Le volume permet également de partager ces données entre plusieurs conteneurs sur un même hôte.

Continuer la lecture de « Docker »

Télémétrie Juniper

Juniper Télémétrie

Dernière modification le 11 janvier 2020

Le modèle traditionnel de monitoring de réseau est basé sur un modèle dit « pull », utilisant SNMP et CLI pour interroger périodiquement les équipements du réseau. Ces méthodes ont des limites inhérentes en matière d’évolutivité et sont gourmandes en ressources, en particulier lorsqu’un grand nombre de métriques sont interrogées à une fréquence très élevée.

JTI (Junos Telemetry Interface) contourne le problème et élimine le besoin de scrutation, en utilisant plutôt un modèle « push » pour transmettre les données de télémétrie à un collecteur de manière asynchrone sous forme de flux. Cette approche est beaucoup plus évolutive et prend en charge la surveillance de milliers d’objets dans un réseau avec une résolution granulaire.

Cependant, la collecte de données de télémétrie n’est pas une tâche aisée, car elle implique généralement trois types de fonctions :

Continuer la lecture de « Télémétrie Juniper »

Vim

Editeur Vim

Dernière modification le 25 septembre 2020

Je développe sur plateformes macOS, mais tous mes serveurs sont sur Linux et même si j’utilise Sublime Text, PyCharm ou Visual Studio Code sur Mac, c’est Vim qui est mon éditeur préféré sur les serveurs Linux. Avec un petit fichier de configuration .vimrc dans le répertoire racine de l’utilisateur, tout est prêt pour démarrer…

colorscheme desert
syntax on

Vim peut être personnalisé jusqu’à en faire un éditeur très puissant pour développer, en enrichissant les configurations de .vimrc et en rajoutant des plugins.

Comme toujours, il est plus facile de travailler avec des petites fiches contenant les principales commandes utiles :