Le pire endroit pour essayer une modification d’un réseau, c’est le réseau lui-même. Une règle erronée peut priver tout un bâtiment d’internet. Monter à côté un réseau d’essai avec de vrais commutateurs, câbles et serveurs coûte cher et prend du temps.
Mininet apporte une réponse étonnamment simple : construire le réseau à l’intérieur d’un seul ordinateur. Et pas sous forme de simulation de jouet, mais avec un logiciel de commutation utilisé aussi dans de vrais réseaux, un vrai contrôleur et n’importe quel programme que l’ordinateur sait exécuter.
Un serveur virtuel est en réalité un processus
Chaque « serveur » de Mininet est un processus ordinaire du système d’exploitation. Ce qui le fait se comporter comme un ordinateur à part, c’est une fonction de Linux appelée espace de noms réseau.
Espace de noms réseau Un processus qui voit son propre réseau
Un processus placé dans un espace de noms réseau ne voit que les interfaces réseau qu’on lui a attribuées, sa propre table d’adresses et ses propres règles de routage. Il ignore tout des réglages réseau extérieurs. Deux processus peuvent tourner sur le même ordinateur et apparaître pourtant, du point de vue du réseau, comme deux machines distinctes.
C’est facile à constater. Listez les interfaces de l’un des serveurs virtuels : seules deux apparaissent, sa carte réseau virtuelle et sa propre interface de bouclage. Le système principal ne voit pas cette carte virtuelle. Le commutateur, lui, tourne par défaut dans l’espace de noms principal ; sa fenêtre affiche toutes les interfaces de l’ordinateur, y compris la connexion vers l’extérieur.
Mais seul le réseau est séparé. Listez les processus d’un serveur virtuel : vous obtenez exactement la même liste que dans la fenêtre du commutateur. Les fichiers sont partagés eux aussi. Ce n’est pas un défaut, c’est tout l’intérêt : n’importe quel programme qui tourne sur l’ordinateur tourne aussi sur un serveur virtuel. Lancer un petit serveur web sur l’un et télécharger la page depuis l’autre revient à faire la même chose qu’entre deux vraies machines.
Un réseau en une commande
Le plus petit réseau démarre sans aucune option : un commutateur, deux serveurs et un contrôleur. Autrement dit, quatre processus distincts sur l’ordinateur.
Pour plus grand, il existe des modèles tout prêts. single relie autant de serveurs qu’on veut à un seul commutateur, en étoile. linear aligne les commutateurs bout à bout comme une chaîne et branche un serveur sur chacun. tree construit un arbre avec racine, branches et feuilles. Si aucun ne convient, on décrit commutateurs, serveurs et liens un par un dans un fichier Python pour dessiner sa propre organisation.
Le moyen le plus rapide de vérifier que le réseau fonctionne vraiment est pingall : chaque serveur envoie un ping à tous les autres, et le résultat tient en une ligne.
Écouter la conversation sur le câble
Comme le trafic du réseau virtuel est un vrai trafic, Wireshark peut le capturer. Filtre OpenFlow activé, envoyez un premier ping d’un serveur à un autre : la conversation entre le commutateur et le contrôleur s’affiche à l’écran.
D’abord, le serveur émetteur diffuse une requête ARP pour connaître l’adresse matérielle de l’autre. Le commutateur ne sait pas quoi faire de ce paquet et interroge le contrôleur. Le contrôleur lui dit de le diffuser par tous les ports. Quand la réponse revient, elle passe elle aussi par le contrôleur, qui cette fois inscrit une règle dans le commutateur. Puis le ping proprement dit suit le même chemin.
Répétez le même ping : le temps tombe sous les cent microsecondes. Les règles sont désormais dans la table du commutateur ; aucun trafic de contrôle n’est généré et les paquets passent directement.
Le premier ping est une question, le second une habitude. La différence tient en une seule ligne inscrite dans la table du commutateur.
Régler le délai à la main
Les câbles virtuels ne sont pas infiniment rapides ; on peut les régler à volonté. Chaque lien peut recevoir une bande passante et un délai. C’est l’outil de contrôle du trafic de Linux qui s’en charge : il retient les paquets pendant la durée indiquée et les empêche de dépasser le débit fixé.
Donnez à chaque lien un délai de 10 millisecondes : un ping entre deux serveurs devrait prendre environ 40 millisecondes. Le calcul est simple : la requête traverse deux liens, du serveur au commutateur puis du commutateur à l’autre serveur, et la réponse traverse les mêmes deux liens au retour. Quatre traversées de 10 millisecondes chacune.
La même logique s’applique aux organisations mixtes. Dans l’une de celles du TP, un seul lien est réglé à 10 mégabits et 50 millisecondes, et l’un des serveurs est limité à vingt pour cent du processeur. Un ping passant par ce lien devrait durer autour de 100 millisecondes : la requête traverse le lien lent une fois à l’aller, la réponse une fois au retour. La limite de processeur, elle, ralentit les programmes gourmands en calcul, pas une opération aussi légère qu’un ping.
Provoquer une panne sans débrancher de câble
Pour tester une rupture de câble sur un vrai réseau, il faut débrancher le câble. Dans Mininet, une seule commande suffit : le lien entre un commutateur et un serveur est coupé, et les deux extrémités du câble virtuel tombent en même temps.
À cet instant, le commutateur envoie au contrôleur un message signalant que l’état de l’un de ses ports a changé. Quand le lien est rétabli, le même avis revient. La réaction d’un réseau à une panne s’étudie ainsi sans toucher au moindre matériel, et autant de fois qu’on le souhaite.
Adresses lisibles Un petit détail qui aide beaucoup
À chaque démarrage, Mininet attribue aux cartes réseau virtuelles des adresses matérielles aléatoires, comme f6:9d:5a:7f:41:42. Comme elles changent à chaque reconstruction du réseau, il devient difficile de suivre quel paquet vient de quel serveur dans une capture. Une seule option les transforme en valeurs séquentielles alignées sur l’adresse IP, comme 00:00:00:00:00:01 : le serveur 10.0.0.1 reçoit une adresse matérielle qui se termine par 01.
Que ne peut pas montrer un ordinateur portable ?
La force de Mininet est de reproduire de si près la logique d’un réseau. Même logiciel de commutation, mêmes messages OpenFlow, mêmes programmes. Un contrôleur développé dans Mininet peut être relié tel quel à de vrais commutateurs OpenFlow.
Ce qu’il ne peut pas montrer, c’est le matériel lui-même. Tous les serveurs et commutateurs virtuels partagent le même processeur ; quand le réseau grandit ou que le trafic s’alourdit, l’ordinateur devient le goulot d’étranglement. Les délais viennent des réglages donnés, pas de la physique d’un câble. Les chiffres donnés ici décrivent le comportement d’un réseau, pas sa vitesse.
Sur quoi repose cet article ?
Cet article s’appuie sur le premier TP du cours de réseaux définis par logiciel que suit Zhipeng Wang dans le master Computer and Network Systems de l’Université d’Évry Paris-Saclay. Le temps de ping et les exemples d’adresses proviennent du sujet de TP ; les valeurs de 40 et 100 millisecondes sont calculées à partir des réglages de liens qui y figurent.
- Lantz, Heller, McKeown, A Network in a Laptop: Rapid Prototyping for Software-Defined Networks, HotNets, 2010.
- McKeown et coll., OpenFlow: Enabling Innovation in Campus Networks, ACM SIGCOMM Computer Communication Review, 2008.
- Pfaff et coll., The Design and Implementation of Open vSwitch, NSDI, 2015.
- Hemminger, Network Emulation with NetEm, linux.conf.au, 2005.
- Linux man-pages, network_namespaces(7).
Zhipeng Wang
Étudie les systèmes et réseaux informatiques à Paris-Saclay, parcours Systèmes et réseaux. Parle chinois, français et anglais.
Voir tous ses articles
