Switch virtuel Arista cEOS-lab

Arista cEOS-lab

cEOS-lab est une version conteneurisée de vEOS-lab avec les mêmes limitations fonctionnelles liées au fait que certaines fonctions EOS s’appuient directement sur les capacités des ASICs. Comparé à vEOS-lab, cEOS-lab présente tous les avantages d’un conteneur, comme une empreinte beaucoup plus légère d’environ 470 Mo de RAM par périphérique à sa création, une taille d’image plus petite et une plus grande portabilité.

Le test est lancé nativement sur mon MacBook Pro avec Docker Desktop 2.2.0.3 et Docker Engine 19.03.5.

# importer l'image cEOS-lab tar.xz
docker import cEOS-lab-4.23.2F.tar.xz ceosimage:4.23.2F

# créer une instance Docker avec les variables d'environnement nécessaires
docker create --name=ceos1 --privileged -e INTFTYPE=eth -e ETBA=1 -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e CEOS=1 -e EOS_PLATFORM=ceoslab -e container=docker -p 2000:22/tcp -i -t ceosimage:4.23.2F /sbin/init systemd.setenv=INTFTYPE=eth systemd.setenv=ETBA=1 systemd.setenv=SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 systemd.setenv=CEOS=1 systemd.setenv=EOS_PLATFORM=ceoslab systemd.setenv=container=docker

Les options utilisées ont les significations suivantes :

  • –name=ceos1
    Il s’agit d’un flag Docker qui permet de créer le conteneur avec le nom ceos1.
  • –privileged
    Il s’agit d’un flag Docker qui lance le conteneur en mode privilégié.
  • -e INTFTYPE=eth
    Il s’agit d’un flag cEOS qui indique à l’OS de libeller les interfaces avec eth.
  • -e ETBA=1
    Il s’agit d’un flag cEOS qui indique à EOS d’utiliser un Data Plane basé sur du logiciel.
  • -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1
    Il s’agit d’un flag cEOS qui indique à EOS de ne pas lancer le ZTP au boot.
  • -e CEOS=1
    Il s’agit d’un flag cEOS qui indique à EOS qu’il s’agit de cEOS et non d’un EOS classique.
  • -e EOS_PLATFORM=ceoslab
    Il s’agit d’un flag cEOS qui indique le type de plateforme. La valeur de ce flag a changé avec les versions.
  • -e container=docker
    Il s’agit d’un flag cEOS qui indique qu’il s’agit d’un conteneur Docker, car il en existe d’autres types.
  • -p 2000:22/tcp
    Il s’agit d’un flag Docker qui expose le port 22 pour être utilisé par SSH, sachant qu’on pourrait exposer aussi le port 443 pour l’utiliser avec eAPI.
  • -i -t ceosimage:4.23.2F
    Il s’agit d’un flag Docker pour indiquer l’image à utiliser.
  • /sbin/init
    Il s’agit d’un flag Docker qui indique la commande à utiliser pour lancer le conteneur, en lui associant les paramètres d’environnements nécessaires.
Continuer la lecture de « Switch virtuel Arista cEOS-lab »

Switch virtuel Arista vEOS-lab

Arista vEOS-lab

Dernière modification le 14 mars 2020

vEOS-lab permet d’utiliser le système EOS des commutateurs Arista sous forme d’une VM. Le système EOS porté à l’origine par Linux Fedora 18, est passé en CentOS 7.5 depuis la release 4.23.0F.

vEOS-lab permet la conception de réseaux et la validation des images EOS, le développement et les tests rapides d’EOS, ainsi que la mise en place de structure de formation et de training. Il ne faut pas le confondre avec vEOS Router qui est un produit NFV (Network Functions Virtualization) s’appuyant sur DPDK pour offrir plusieurs gigabits de débit dans des environnements cloud virtuels et publics.

Comme je l’ai déjà expliqué, mes trois outils de simulation préférés sont EVE-NG, GNS3 et Vagrant/VirtualBox. Chacun a ses avantages et inconvénients, mais EVE-NG a ma préférence dans le domaine professionnel lorsqu’il est nécessaire d’être démonstratif et visuel.

vEOS-lab EVE-NG
Continuer la lecture de « Switch virtuel Arista vEOS-lab »

Automatisation ALE – Métropole et Ville de Perpignan

Metropole et Ville de Perpignan

Dernière modification le 21 décembre 2019

Outre des objectifs de disponibilité et de performance qui nous avaient été fixés par la direction du numérique de la Métropole et de la Ville de Perpignan, la Direction du Numérique souhaitait mettre en oeuvre une approche DevOps. Dans ce cadre là, notre rôle a consisté à accompagner les équipes sur les nouvelles technologies, méthodologies et outils nécessaires à la mise en œuvre de ces infrastructures innovantes.

Des OmniSwitch OS6900 et OS6450 ont été déployés en mode ZTP en utilisant des serveurs DHCP, FTP et TFTP tournant sur Raspbian. Ansible a été utilisé pour générer les fichiers de configuration des serveurs, ainsi que les configurations des différents équipements. Des scripts Python/Netmiko ont permis de pousser les configurations sur tous les équipements et de générer des tests unitaires pour vérifier le bon fonctionnement de l’infrastructure.

Metropolis and City of Perpignan / Alcatel-Lucent Enterprise web site

Switch virtuel vQFX

Switch virtuel vQFX

Dernière modification le 11 janvier 2020

Le switch virtuel Juniper vQFX, mis à disposition gratuitement pour les clients et les partenaires aux formats box, qcow2 et vmdk , peut être utilisé en mode light (Routing Engine uniquement) ou en mode full (Routing Engine et Packet Forwarding Engine). En mode full, le vQFX est constitué de deux machines virtuelles qui forment le Control Plane (RE) et le Data Plane (PFE).

vQFX Light et Full

Les deux premières interfaces des VMs sont réservées pour le management Out-of-Band et l’interconnexion des deux VMs. L’interface em2 de la VM RE est réservée. En revanche, la VM RE supporte 12 interfaces supplémentaires pour le trafic Data Plane.

Continuer la lecture de « Switch virtuel vQFX »