Lab de réseaux définis par logiciel : Open vSwitch, Mininet et un contrôleur OpenFlow dans une VM

Ce lab donne à chaque élève un commutateur qu’il peut programmer. Open vSwitch, un vrai commutateur logiciel, et trois petites machines sont construits dans l’unique VM Ubuntu de l’élève, avec Mininet et une bibliothèque pour écrire un contrôleur OpenFlow. Au départ, la table de flux du commutateur est vide : il ne transmet rien. L’élève écrit les flux à la main, puis termine un contrôleur qui fait apprendre le commutateur.

Rien n’est installé sur l’ordinateur de l’élève et aucun équipement réseau n’est nécessaire. Les machines sont des espaces de noms réseau, le commutateur est Open vSwitch avec le chemin de données du noyau, et les commandes sont les vraies : ovs-ofctl, ovs-vsctl et mn.

Ce que les élèves apprennent

Ce que change le réseau défini par logiciel : les règles de transmission sont des données dans une table de flux, écrite par une personne ou par un programme. En trois parties. D’abord Mininet, un outil qui construit tout un réseau de test, avec son test pingall. Ensuite une table de flux écrite à la main avec ovs-ofctl, en OpenFlow 1.3 : une condition et une action pour chaque flux, ARP comme IP, et un flux qui bloque exprès une machine. Enfin un contrôleur, une application écrite avec la bibliothèque os-ken, terminée pour qu’elle apprenne sur quel port se trouve chaque adresse MAC et installe un flux, que les élèves relisent avec ovs-ofctl dump-flows.

La topologie

Le commutateur br0 a trois ports. Les machines h1, h2 et h3 ont les adresses 10.0.0.1, 10.0.0.2 et 10.0.0.3 et des adresses MAC finissant par 01, 02 et 03, si bien qu’un flux peut s’écrire à partir du README. Le commutateur est en fail-mode secure : sans flux, il abandonne tous les paquets, ce qu’un commutateur ordinaire ne fait jamais. Le travail de l’élève tient dans deux fichiers, un pour la table de flux et un pour le contrôleur, chargés à chaque démarrage du lab.

Le lancer dans votre navigateur

Les labs VM se donnent comme tâche de lab dans un module, et l’exemple se trouve sur la page du lab. La machine est petite : un processeur, 1 Go de mémoire et 10 Go de disque. Le commutateur, sa base de données et le contrôleur n’en utilisent ensemble qu’environ un dixième de la mémoire.

  1. Ajouter le lab. Dans un module que vous enseignez, ajoutez une tâche et choisissez la carte Lab VM Ubuntu. La page affiche une courte description de la machine au lieu d’un fichier compose.
  2. Partir de l’exemple. La page propose des labs prêts à l’emploi pour démarrer. Choisissez Software-defined networking. Utiliser un exemple remplace le texte, et Annuler rend le vôtre.
  3. Publier et démarrer votre propre copie. Publiez, puis Démarrez. Le script setup du lab installe Open vSwitch, Mininet et la bibliothèque de contrôleur os-ken depuis l’archive d’Ubuntu, et écrit la commande sdnlab, les deux fichiers à modifier et le README, au premier démarrage de la VM, en quelques minutes.
  4. Ouvrir le terminal. Ouvrez son terminal et lisez README.md dans le dossier personnel : il dit quoi faire en trois parties et ne donne aucune réponse.

Une leçon de base sur ce lab

SDN Basics est une petite leçon donnée dans ce lab, une VM Ubuntu. Elle a une accroche, un objectif « Je peux », des mots-clés, une question de départ, une vérification après chaque idée, une erreur courante et une vérification finale, et chaque étape a un bouton Exécuter qui tape sa commande dans le terminal de la machine. L’élève lit la table de flux vide, voit un ping échouer parce que rien ne correspond, lance le pingall de Mininet et démarre le contrôleur du lab tel qu’il est fourni pour voir l’unique flux qu’il laisse.

La leçon regarde autour d’elle et laisse à l’élève la tâche propre au lab, les flux et le commutateur à apprentissage : elle ne donne donc aucune réponse.

Comment il est noté

Le lab a une vérification. Elle s’exécute sur une copie de la machine enregistrée après un démarrage neuf et charge elle-même les deux fichiers de l’élève : un flux tapé à la main et jamais enregistré ne compte pas. Avec le seul fichier de flux et sans contrôleur, h1 et h2 doivent se joindre, h3 ne doit joindre personne et personne ne doit joindre h3, et un flux qui correspond à h3 doit l’abandonner et avoir reçu des paquets de h3. L’action NORMAL ne passe pas. Ensuite la vérification démarre le contrôleur de l’élève, donne à h2 une adresse MAC que personne n’a vue, si bien qu’une table écrite d’avance ne sert à rien, et fait des pings entre chaque paire. Le contrôleur doit avoir appris chaque adresse et installé un flux avec le bon port de sortie, sans flux qui diffuse. La première ligne de ce que la vérification a affiché dit pourquoi.

  1. Le distribuer. Attribuez le lab comme n’importe quelle tâche, avec une échéance si vous le souhaitez. Chaque élève reçoit une VM à lui, conservée d’une séance à l’autre.
  2. Lancer la vérification. Sur la ligne d’un élève dans la liste de la classe, appuyez sur Lancer la vérification. Elle démarre une copie de sa machine enregistrée, qui n’est pas sauvegardée ensuite, exécute le script de vérification du lab en root et indique s’il a réussi, ce qu’il a affiché et quand. L’élève n’est pas informé du résultat.
  3. Noter. Lisez la première ligne de ce que la vérification a affiché : elle dit ce qui ne va pas, par exemple une machine qui n’en joint pas une autre avec les flux du fichier, ou un flux appris qui manque. Renvoyez le travail avec un motif s’il faut aller plus loin.

La définition sur GitHub

Le fichier est toute la définition du lab, le texte même que la plateforme exécute : taille, script setup, outil sdnlab, lanceur de contrôleur, README et vérification. Copiez-le et changez les flux, les machines ou la tâche du contrôleur pour faire un lab plus long.

Essayer ce lab, et ce qu’il coûte

Un compte personnel gratuit permet de suivre les leçons de base de ce lab, avec chaque mois assez de crédit gratuit pour suivre la plupart des leçons, sans carte. Pour une classe, un établissement a ses 365 premiers jours gratuits pour 50 élèves au plus, puis paie par élève et par an, tous les labs compris et les enseignants gratuits.

Questions fréquentes

Le lab demande-t-il un commutateur OpenFlow ou une licence ?
Non. Le commutateur est Open vSwitch, libre et dans l’archive d’Ubuntu, et Mininet comme la bibliothèque de contrôleur viennent de la même archive. Ils sont installés au démarrage de la VM de l’élève, et nous n’en distribuons rien.
Pourquoi le lab fournit-il son propre lanceur de contrôleur ?
Le paquet os-ken d’Ubuntu est seulement une bibliothèque, sans commande pour lancer une application. Le lab ajoute un court lanceur, ctl.py, lisible dans la définition. os-ken dépend d’eventlet, qui est obsolète et affiche un avertissement dans le journal du contrôleur. C’est pourquoi le lab enseigne d’abord ovs-ofctl et Mininet : ces parties n’en dépendent pas.
Les élèves peuvent-ils casser quelque chose ?
Seulement leur propre copie. Le réseau entre les machines est virtuel et interne à la VM, qui joint l’archive d’Ubuntu, PyPI, npm et GitHub, et rien d’autre. Si un élève casse le lab, sdnlab reset remet les deux fichiers en place.
Le lab a-t-il été testé dans une vraie VM d’élève ?
Le script setup, les commandes de la leçon et la vérification ont été exécutés dans un vrai Ubuntu 26.04 avec le chemin de données Open vSwitch du noyau, dans un conteneur qui tient lieu de VM. Une VM d’élève démarrée, qui lance le lab depuis une unité systemd et charge le module du noyau d’Ubuntu, mérite un essai avant un cours.