Unified Networking Lab

 e développe des émulateurs de réseau depuis 2011, et même si je ne suis pas un programmeur, je peux dire que j'ai fait du bon travail, plaçant iou-web (au début) et UNetLab (enfin) comme un bon concurrent de GNS3 et de VIRL sans n'importe quel budget.
Si vous recherchez EVE-NG , suivez le lien .
Vous trouverez ci-dessous un bref résumé de mes logiciels et de l’architecture de UNetLabv2.
Fondamentalement, UNetLabv2 a les mêmes fonctionnalités de UNetLab, plus:

• des milliers de nœuds pour chaque laboratoire;
• des laboratoires répartis sur des dizaines de nœuds physiques ou virtuels;
• laboratoires en cours d'exécution illimités pour chaque utilisateur;
• support pour les outils d'automatisation Ansible / NAPALM /… 

Précédemment sur WebIOL / iou-web / UNL / UNetLab / EVE-NG

Fin 2011, j'avais besoin d'un outil pour émuler les réseaux. Les conditions préalables étaient:

• portabilité: les laboratoires doivent être exportables et importables;
• stabilité: les laboratoires en cours d'exécution doivent être stables et éviter les collisions;
• performances: les laboratoires doivent pouvoir utiliser un ordinateur portable bon marché ou une machine virtuelle.

GNS3 était la seule option disponible et ne pouvait pas satisfaire toutes les conditions préalables. J'ai décidé de développer un nouveau logiciel d'émulation de réseau basé sur IOL (IOS sur Linux, de Cisco). Je connaissais beaucoup de gars de Cisco et j'aurais adoré faire partie de la famille Cisco tôt ou tard. Entre temps, j'ai réalisé que Cisco avait développé en interne un logiciel similaire, appelé WebIOL.
WebIOL a été développé en Perl et publié pour les employeurs de Cisco uniquement. Il contenait quelques travaux de base du programme Cisco 360.
Après quelques versions alpha, le 23 janvier (2012), iou-web a été rendu public. iou-web (pas webiou ou web-iou) a été développé en PHP et comptait en quelques mois des centaines d'utilisateurs dans le monde entier. Si GNS3 ne prend en charge que les IOS réelles (via Dynamips), iou-web ne prend en charge que les LIO. Mais comme IOL était plus rapide que Dynamips, de nombreux utilisateurs ont préféré iou-web.
En 2013, j'ai réalisé que iou-web était trop limité et qu'il me fallait un moyen «unifié» d'émuler un réseau, notamment des pare-feu, des équilibreurs de charge, etc. De plus, la multidiffusion utilisant IOL a été buggée. J'avais plus de prérequis:

• inclure des appareils virtuels de fournisseurs dans les laboratoires;
• inclure de vrais IOS dans les laboratoires;
• inclure (éventuellement) des émulateurs de différents fournisseurs;
• multi-utilisateur.

J'ai entièrement réécrit iou-web pour créer un système d'émulateur de réseau extensible. L'idée était:

• chaque nœud (périphérique émulé) doit être attaché à une couche commune;
• une belle couche commune pourrait être un pont Ethernet Linux (OVS était également supporté).

Le 6 octobre 2014, UNetLab a été rendu public. Développé en PHP à l'aide d'un framework API REST et d'une application à une seule page (jQuery). En quelques mois, j'ai pu compter entre cinq et six centaines d'utilisateurs quotidiens. Je l'appellerais UNL, mais le site Web n'était pas gratuit.
Au départ, j'ai eu l'idée d'inclure Huawei eNSP, mais comme les nœuds eNSP attendent une chaîne particulière, personne n'a été en mesure d'exécuter des nœuds eNSP en dehors de eNSP.
À partir de 2015, je n'avais plus assez de temps libre pour UNetLab, alors un groupe de gars a lancé UNetLab et le 5 janvier (2017), EVE-NG a été rendu public, mais c'est une autre histoire, car je ne fais pas partie d'EVE- Équipe NG.

Pourquoi UNetLabv2

Au cours des deux dernières années, je me suis concentré sur l'automatisation du réseau. Aujourd'hui, j'ai toujours besoin d'une plate-forme d'émulateur de réseau unifiée, mais les conditions préalables ont changé. Mais avant cela, permettez-moi de souligner les limites de UNetLab:

• limite de pod par hôte: actuellement, chaque hôte peut exécuter jusqu'à 256 pod indépendants, en raison de la limite du port de console;
• Limite par nœud de laboratoire: actuellement, chaque module / laboratoire peut exécuter jusqu'à 128 à 1 nœuds, en raison de la limite du port de console.
• limite de pod par utilisateur: actuellement, chaque utilisateur peut exécuter jusqu'à un pod / laboratoire à la fois, en raison de la limite du port de console;
• un seul hôte: actuellement, il n’existe aucun moyen de réaliser une installation distribuée de UNetLab (OVS peut être utilisé, mais de nombreux types de trames sont filtrés par défaut);
• gestion de la configuration: obtenir et mettre en place la configuration de démarrage se fait à l'aide de scripts attendus, ils sont lents, non prédictifs et ne peuvent pas couvrir tous les types de nœuds;
• Les interfaces série Dynamips ne sont pas prises en charge.
• aucune modification de la topologie n'est autorisée pendant l'exécution du laboratoire, de par sa conception.

La limite du port de console est due au fait que chaque console de noeud possède un port de console fixe, calculé comme suit: ts_port = 32768 + 128 * tenant_id + id_périphérique. En outre, pas plus de 512 nœuds IOL ne peuvent s'exécuter dans le même laboratoire, car device_id doit être unique pour chaque client hébergé.
Donc, UNetLab v2 doit pouvoir:

• exécuter un laboratoire distribué (entre des nœuds locaux ou géographiquement répartis);
• exécuter un laboratoire avec un nombre non limité de nœuds;
• permettre à chaque utilisateur de personnaliser un laboratoire sans affecter la copie originale;
• reliez les interfaces série entre IOL et Dynamips;
• configurer les nœuds via Ansible / NAPALM / que ce soit.

Je savais comment faire un émulateur de réseau distribué, mais je manquais un peu: comment exécuter facilement des nœuds dans un espace de noms dédié? Vrnetlab m'a donné la réponse suivante: utiliser Docker.
À cause des limites de UNetLab, j'ai préféré réécrire UNetLab à partir de rien. Même si EVE-NG est une fourchette UNetLab, l’équipe EVE-NG s’efforce de surmonter les limites décrites précédemment.

Architecture UNetLabv2

L'architecture peut sembler un peu complexe, mais ce n'est pas vrai, j'ai été capable de la mettre en œuvre par moi-même et dans un délai relativement court.

UNetLabv2 est basé sur:

• Docker: le contrôleur, les routeurs et les nœuds de laboratoire s'exécutent dans un conteneur Docker;
• Python: plus de C, PHP ou Bash, seulement Python 3;
• Python-Flask + NGINX implémente et expose les API;
• Memcached met en cache l'authentification pour une meilleure expérience utilisateur;
• Celery + Redis gère les tâches longues asynchrones en arrière-plan;
• MariaDB stocke toutes les données / utilisateurs et laboratoires en cours d'exécution;
• Git stocke les laboratoires originaux avec un contrôle de version;
• jQuery + Bootstrap implémentera l'interface utilisateur en tant qu'application à page unique;
• Le pont iptables + Linux permet de se connecter aux nœuds de laboratoire qui viennent d’être démarrés via SSH;
• IOL, QEMU et Dynamips exécutent des nœuds de laboratoire.

Un cluster UNetLabv2 doit avoir au moins un nœud: il peut s'agir d'un système physique ou virtuel. Chaque nœud UNetLabv2 exécute Docker: le premier nœud UNetLabv2 est le nœud maître et contient un contrôleur et un routeur, chaque nœud UNetLabv2 supplémentaire contenant un routeur uniquement. Chaque nœud UNetLabv2 exécute également de nombreux nœuds de laboratoire. Les contrôleurs, les routeurs et les nœuds de laboratoire sont des instances de Docker.
Le conteneur de contrôleur:

• expose l'interface utilisateur Web et les API aux clients utilisateurs, aux routeurs et aux nœuds de laboratoire;
• recevoir les demandes de registre des routeurs et des nœuds de laboratoire;
• fournir et gérer des nœuds de laboratoire via des routeurs;
• contacter des nœuds de laboratoire via Ansible / NAPALM /… via des routeurs;
• fournit une table de routage aux routeurs;
• peut être atteint via SSH via le port 2222.

Les conteneurs du routeur:

• s'inscrire contre le contrôleur;
• exposer l'API à distance de Docker;
• exposer l'API de nœud de laboratoire;
• obtenir les routeurs et la table de routage du contrôleur;
• acheminer les paquets de laboratoire entre les nœuds et les routeurs;
• permettre l'accessibilité entre les nœuds du contrôleur et du laboratoire distant via OpenVPN.

Les conteneurs de noeuds:

• s'inscrire contre le contrôleur;
• exécuter le nœud émulé (IOL, Dynamips ou QEMU);
• lier une interface de gestion de note émulée à un pont local;
• acheminer les paquets sNAT / dNAT vers l'interface de gestion du noeud émulé;
• routez les paquets entre le routeur local et le nœud émulé pour les interfaces de non-gestion;
• gérer les liens émulés (haut / bas).

Parce que le contrôleur et les routeurs connaissent les adresses IP intérieures et extérieures; les utilisateurs peuvent déployer les nœuds UNetLabv2 où ils le souhaitent (dans le même réseau local, dans AWS, Google Compute Engine, Azure, derrière un pare-feu…). Comme l'explique le diagramme ci-dessus, chaque cluster UNetLabv2 a besoin des ports suivants:

• TCP: 2222 pour se connecter au contrôleur via SSH;
• TCP: ⁸⁰ ₄₄₃ pour les requêtes HTTP / HTTPS au contrôleur;
• TCP: 5443 pour les demandes HTTPS au routeur;
• UDP: 5005 pour les paquets routés entre différents nœuds UNetLabv2;
• UDP: 1194 pour l'accessibilité au réseau entre le contrôleur et les nœuds de laboratoire distants.

UNetLabv2 est arrêté et n'est donc pas disponible au public. Ne le demandez pas et utilisez GNS3, VIRL ou EVE-NG.

                     SOFTWARE
   
================================
 UNL VM -Cisco Switch/Router IOS images -
Switch -
Router -
IOURC (Cisco License) KeyGen -
Telnet browser integration (REG file) -
VMWare -
WinSCP - 


===================================