Simulateurs réseau

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.

Lorsque je souhaite tester des scripts d’automatisation rapidement, j’utilise Vagrant/VirtualBox pour lancer une petite architecture. L’avantage c’est que c’est très rapide et très reproductible (on peut donner le Vagrantfile à quelqu’un pour qu’il lance le même environnement). L’inconvénient majeur, c’est que ce n’est pas du tout visuel et donc assez peu démonstratif si on explique à quelqu’un l’architecture que l’on a créé.

Pour être plus démonstratif, il est préférable d’utiliser un environnement graphique. Le plus souvent, j’utilise EVE-NG (Emulated Virtual Environment for Network – Next Generation) qui peut tourner sous la forme d’une machine virtuelle ou bare metal sur Ubuntu 16.04 (à la date d’écriture de cet article). C’est un environnement très professionnel qui fonctionne parfaitement bien sous toute les conditions, y compris en utilisant l’interface Wi-Fi de mon MacBook Pro pour le bridge de la VM Fusion ou bare metal sur un serveur Supermicro Xeon basse consommation. Je l’utilise en full HTML5 avec son interface Apache Guacamole. Le produit EVE-NG existe en version communautaire, professionnelle ou corporate/centre de formation. C’est mon choix privilégié pour enseigner, mais il y a cependant une limitation à prendre en compte. Plus on veut construire une architecture ambitieuse ou plus on veut accueillir d’étudiants en simultané sur des architectures personnalisées et plus il faut une plateforme possédant beaucoup de mémoire RAM et de coeurs à disposition, ce qui rend coûteux son utilisation en cloud (même bare metal ou serveur dédié) sur une longue période.

GNS3 est certainement plus connu que EVE-NG par le grand public. C’est un produit, uniquement communautaire, plus facile à mettre en oeuvre pour ceux qui n’aiment pas mettre les mains directement dans le système (l’inclusion des machines sur EVE-NG nécessite un accès SSH et FTP au système). En outre il est possible de construire une architecture dont chacun des éléments peut être hébergé sur des serveurs différents, rendant la solution très évolutive. C’est le fait d’utiliser un client lourd qui permet de pointer vers autant de serveurs que l’on souhaite. Pour ceux qui n’ont pas besoin de cette capacité d’échelle, il est prévu une évolution vers une interface web sur un serveur unique (en version lecture seule dans la version actuelle 2.2). Cependant, j’ai parfois des réticences à l’utiliser pour les raisons suivantes :

• Il a un fonctionnement qui n’est toujours garanti lorsque j’utilise l’interface Wi-Fi de mon MacBook Pro pour bridger l’architecture sur le réseau physique à l’aide de l’objet Cloud. Néanmoins, il faut noter que je n’ai jamais eu de problème lorsque les serveurs GNS3 sont hébergés sur des serveurs locaux en VMware ESXi.
• Il n’a pas de sécurité d’accès intégrée ce qui fait que si on met un serveur GNS3 sur internet, il est fortement recommandé d’y mettre un accès VPN (OpenVPN). Cet aspect ne simplifie pas la connexion de l’architecture virtuelle à l’infrastructure physique pour faire de l’automatisation depuis son poste de travail et non depuis l’intérieur de l’architecture virtuelle.
• La gestion des matériels simulés m’apparait comme étant moins professionnelle sur le plan de l’IHM et la notion de gestion des étudiants n’existe pas vraiment. Soit chacun installe et gère son propre GNS3, soit on peut tous partager la même architecture centralisée. A contrario, EVE-NG permet de simuler plusieurs labs sur un même serveur centralisé avec des droits d’accès par des comptes à chacune des simulations et une supervision globale de tous les labs accordée à l’animateur dans la version pour centre de formation. Qui plus est, il est possible d’exporter un lab pour l’intégrer sur un autre serveur.

Certains pourraient se demander pourquoi je me limite à ces outils sans m’intéresser à d’autres produits comme VIRL (Virtual Internet Routing Lab ) ou même CML (Cisco Modeling Lab). La réponse est simple, je ne souhaite pas utiliser de produit trop fortement orienté vers un constructeur… Quant à des outils très spécialisés comme Mininet, je ne les ai utilisé que pour faire des simulations OpenFlow avec Open vSwitch en vue de tester des contrôleurs SDN.