Tester en prod, c’est mal. Mais monter un lab réseau peut revenir très cher pour un intérêt limité dans le temps. Entre le matériel, les câbles et les optiques, rares sont les entreprises qui acceptent d’allouer un budget suffisant pour faire tourner une demi-douzaine de switchs habituellement destinés au data-center.
Et si vous êtes un étudiant ou une startup avec le budget associé, c’est tout simplement peine perdue sans acheter du matériel dépassé sur eBay, et encore…
Heureusement, il existe des solutions, et nous allons en aborder une ici. Elle se base sur l’excellent logiciel de virtualisation de réseaux GNS3 ainsi que sur le constructeur Arista.
Dans cet article, nous allons apprendre à créer un lab simulant une infrastructure réseau spine / leaf, avec un réseau out-of-band et une machine de déploiement basée sur Debian GNU/Linux.
Installation de GNS3
L’installation dépend de votre système d’exploitation, suivez la documentation officielle pour vous guider. Quelques informations cependant…
Sous Linux
Si vous êtes sous Linux, les wikis des différentes distributions peuvent vous aider. Sachez que nous aurons besoin de Qemu pour virtualiser les switchs et un serveur. La dépendance vpcs (pour Virtual PC Simulator) pourra vous être utile afin de simuler un simple PC générant des pings.
Pour avoir du NAT il faut également installer la dépendance libvirt, lancer libvirtd, et activer le réseau default :
sudo virsh net-start default && sudo virsh net-autostart default
Vérifiez ensuite que le réseau default est en état active :
sudo virsh net-list
Dans le cas contraire, GNS3 va se plaindre avec le message suivant : virbr0 is missing. You need to install libvirt quand nous ajouterons un device NAT.
Sous Windows
L’équipe de GNS3 impose Qemu sous Linux pour virtualiser (entre autres) les switchs vEOS. Ils proposent donc une machine virtuelle, la GNS3 VM qui est en réalité une VM Linux avec tous les outils nécessaires, à laquelle votre client GNS3 va se connecter. Choisissez donc l’option appropriée Run modern IOS […] lors du setup wizard et laissez-vous guider.
Création de l’appliance vEOS Lab
Il existe plusieurs solutions permettant de virtualiser un équipement réseau, mais nous allons ici utilier le produit vEOS Lab d’Arista (chez Enix, Arista, on aime bien). L’OS d’Arista (EOS, pour Extensible Operating System) est l’image software unique exécutée sur l’ensemble des équipements de la marque. vEOS en est la version virtualisée, destinée à un usage en production (sur des cloud publics ou privés par exemple) mais il existe aussi une déclinaison spécifique pour les infras de test qui porte d’ailleurs bien son nom : vEOS Lab.
Fort heureusement pour nous, Arista met à disposition gratuitement les images de vEOS Lab sur son site internet. Il vous faudra cependant créer un compte de type Guest. Une fois fait, téléchargez l’image vEOS-lab-4.20.10M-combined.vmdk. Sous Linux, vous pouvez laisser ce fichier dans votre dossier Téléchargements, GNS3 va y chercher ses images en supplément de son dossier images paramétré. Sous Windows, nous l’importerons plus tard.
Il faut ensuite créer une appliance -un modèle d’équipement réseau pouvant être ajouté à une topologie- dans GNS3. Il existe déjà des appliances vEOS Lab pré-configurées dans GNS3 mais nous allons créer la notre, car :
- les appliances existantes nécessitent une image Aboot (le bootloader d’Arista) séparée, à la différence de notre image combined;
- la version d’EOS 4.20.10M n’est pas disponible (les sous-versions M pour Maintenance sont des bugfix releases, à la différence des sous versions F pour Feature);
- c’était l’occasion de regarder un peu sous le capot de GNS3 !
Créez donc le fichier texte arista-veos-combined.gns3a avec le contenu suivant (basé sur l’appliance d’origine) :
{
"name": "Arista vEOS Combined",
"category": "multilayer_switch",
"description": "Arista vEOS using the combined image (Aboot included).",
"vendor_name": "Arista",
"vendor_url": "http://www.arista.com/",
"documentation_url": "https://www.arista.com/assets/data/pdf/user-manual/um-books/EOS-4.21.0F-Manual.pdf",
"product_name": "vEOS",
"product_url": "https://eos.arista.com/",
"registry_version": 1,
"status": "experimental",
"maintainer": "Benjamin Abadie",
"maintainer_email": "benjamin.abadie@enix.fr",
"usage": "The login is admin, with no password by default",
"symbol": ":/symbols/multilayer_switch.svg",
"first_port_name": "Management1",
"port_name_format": "Ethernet{port1}",
"qemu": {
"adapter_type": "e1000",
"adapters": 13,
"ram": 2048,
"arch": "x86_64",
"console_type": "telnet",
"kvm": "require"
},
"images": [
{
"filename": "vEOS-lab-4.20.10M-combined.vmdk",
"version": "4.20.10M",
"md5sum": "d1f2d650f93dbf24e04fdd2c9d62bd62",
"filesize": 334626816,
"download_url": "https://www.arista.com/en/support/software-download"
}
],
"versions": [
{
"name": "4.20.10M",
"images": {
"hda_disk_image": "vEOS-lab-4.20.10M-combined.vmdk"
}
}
]
}
Et importez-le dans GNS3 à l’aide du menu File > Import appliance. Ceux d’entre vous qui ont le plaisir d’être sous Windows devront importer l’image vEOS-lab-4.20.10M-combined.vmdk à l’étape Required files : séléctionnez la deuxième ligne du tableau et cliquez sur Import.
Vous pouvez tester que votre image fonctionne en créant un projet de test dans lequel vous glissez-déposez un device Arista vEOS Combined 4.20.10M. Démarrez-la et lancez la console. Une fois booté, connectez vous à l’équipement avec l’utilisateur admin sans mot de passe. Après avoir fait un enable, lancez les commandes classiques show running-config, show version ou encore show interfaces description.
Création de l’appliance Debian
Il est toujours utile d’avoir une image Linux sous la main dans GNS3, pour simuler un serveur et réaliser des tests plus poussés qu’un simple ping (réalisable plus facilement avec l’appliance VPCS). Dans notre cas, nous allons également simuler un serveur-à-tout-faire dans le réseau Out of Band qui servira de gateway à ce dernier.
Pour cela, téléchargez et décompressez l’image disque Debian 9.6.0 installée par votre serviteur. Il s’agit d’une Debian tout ce qu’il y a de plus classique, avec quelques paquets supplémentaires comme mtr ou tcpdump, et dont la ligne série a été activée. Même chose que précédemment, sous Linux vous pouvez laisser l’image dans votre dossier de téléchargements, ou la déplacer dans le dossier images de GNS3 dont l’emplacement exact est spécifié dans les paramètres.
Dans GNS3, ouvrez le panneau latéral Devices en cliquant sur une des icônes de gauches, et cliquez sur New appliance template. Choisissez Add a Qemu virtual machine, donnez lui le nom Debian 9.6.0. Mettez lui 512 Mo de RAM et choisissez l’image debian-9.6.0.qcow dans le menu déroulant (ou New Image si vous êtes sous Windows). Vous pouvez laisser les autres options par défaut. Une dernière chose : dans la fenêtre Qemu VM templates qui s’est ouverte, éditez notre nouvelle appliance toute fraîche et dans l’onglet Network, passez le nombre d’adapters à 4. Une seule interface, c’est trop peu pour nous.
Une fois encore, vous pouvez tester votre image en la démarrant dans un projet temporaire.
Rackage et câblage
Je plaisante bien sûr ! Avec GNS3 cette étape est tellement simple que c’en est presque déprimant. Pour faciliter encore plus les choses vous pouvez importer ce projet, ou bien le re-créer à partir de cette capture d’écran :
Cette architecture servira de base à de futurs articles, essayez donc de conserver le même nommage et le même schéma de connexions.
Création du réseau d’administration out-of-band
Notre lab virtuel se voulant le plus proche de la réalité, nous allons le doter d’un réseau d’administration propre, dit out of band ou OOB car totalement séparé de la production. Dans la réalité, un simple switch sans VLAN suffit, nous allons donc exploiter les capacités de bridging de notre OS et les devices de type cloud de GNS3.
Malheureusement, GNS3 ne permet pas d’exporter un projet s’il contient des objets cloud : nous allons devoir les re-créer à la main.
Cliquez sur l’icône en forme d’écran (Browse End Devices) dans la barre d’outils verticale de gauche, et glissez-déposez deux objets de type cloud et modifiez leur hostname en OOB-1 et OOB-2. Notez qu’ils représenteront un seul et même réseau OOB, mais le schéma perdrait en clarté avec un seul objet.
Faitez un clic droit sur OOB-1 et choisissez configure. Dans l’onglet TAP interfaces, entrez oob-gw dans le champ texte et cliquez sur Add. Renouvellez l’opération avec oob-spine-1 et oob-spine-2. Cliquez sur OK.
De la même façon, créez les interfaces suivantes dans l’objet OOB-2 :
oob-lf-1-pod1oob-lf-2-pod1oob-lf-1-pod2oob-lf-2-pod2
(Attention si vous choisissez de les nommer différement : la taille semble limitée à 15 caractères.)
Ajoutez également un objet de type NAT dans notre topologie, ainsi qu’une applicance Debian 9.6.0 que nous appellerons gw.
Toujours depuis la barre d’outils de gauche, cliquez maintenant sur l’icône representant un cable (Add a Link) puis connectez chaque interface Management1 des switchs sur leurs interfaces respectives des objets OOB-*, ainsi que l’interface e1 de la machine gw. Enfin, l’interface e0 de gw doit être connectée sur NAT-1. Correctement placé, cela devrait ressembler à ça :
Dans cette configuration, gw a accès à Internet et est accessible depuis la machine hôte (ou la VM GNS3), simulant un serveur rackable avec un accès de secours. Dans un prochain article, c’est lui qui nous servira à provisionner nos switchs Arista.
Les interfaces oob-* des objets cloud devraient être apparues dans votre système d’exploitation. Nous allons les bridger ensemble pour émuler un (ou plusieurs) switch(s) out of band. Sous Linux, en root :
brctl addbr oob
brctl addif oob oob-gw oob-spine-1 oob-spine-2 oob-lf-1-pod1 oob-lf-2-pod1 oob-lf-1-pod2 oob-lf-2-pod2
for i in oob oob-gw oob-spine-1 oob-spine-2 oob-lf-1-pod1 oob-lf-2-pod1 oob-lf-1-pod2 oob-lf-2-pod2; do ip link set $i up; done
Si, comme moi, vous avez des règles de firewall présentes sur votre machine et remarquez que certains paquets ne passent pas le bridge, vous pouvez indiquer à votre kernel d’ignorer ces règles :
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
Sous Windows, connectez-vous à la VM GNS3 à l’aide des informations affichées dans VMware ou Virtualbox, choisissez Shell et rentrez les commandes ci-dessus.
Suite et fin
Un dernier conseil : faites un snapshot du projet via GNS3 (Edit puis Manage snapshots) avant de démarrer les VM, afin d’avoir une topologie vierge de toute config à laquelle retourner pour repartir de zéro.
Voilà ! Votre lab Spine / Leaf est prêt à être utilisé. Vous pouvez d’ores et déjà commencer à configurer les switchs à la main. Attention cependant, nous avons “câblé” des boucles ! Par défaut les ports sont activés mais heureusement les switchs sont en mode ZeroTouch Provisioning donc ils ne commutent pas les paquets. Pas de tempête de broadcast pour l’instant, donc, mais prenez garde…
J’espère que ce petit lab vous servira comme il me sert actuellement. Eh oui, mon objectif n’est pas uniquement de monter un lab pour le plaisir ! Mon but inavoué est de tester et valider différentes architectures et technologies à intégrer (ou pas !) dans le futur réseau d’Enix. Au programme et dans le désordre : de l’Ansible, du ZTP, de l’EVPN, du Python, et bien plus encore. Je ne manquerai pas de publier un ou deux articles pour vous tenir au courant, bien sûr. Vous pouvez suivre @enixsas ou moi même pour en être averti en exclusivité ! ;-)
Ne ratez pas nos prochains articles DevOps et Cloud Native! Suivez Enix sur Twitter!