Où un réseau garde-t-il son cerveau ?

Dans l’exemple de sortie d’un sujet de TP, un ordinateur envoie deux fois le même petit paquet à son voisin. La première réponse arrive en 2,76 millisecondes. La seconde en 0,052 milliseconde. Même câble, mêmes machines, même paquet ; et pourtant le second essai est plus de cinquante fois plus rapide.

L’écart vient d’une question que le premier paquet doit poser en chemin : « que vas-tu faire de moi ? » La réponse ne vient pas des équipements du réseau, mais d’un logiciel qui tourne en dehors. C’est le cœur de ce qu’on appelle un réseau défini par logiciel.

Celui qui décide et celui qui exécute

Dans un réseau classique, chaque commutateur réfléchit seul. Il apprend quelle adresse se trouve derrière quel port et décide lui-même où envoyer chaque paquet. Le cerveau est réparti dans chaque équipement.

Un réseau défini par logiciel sépare ces deux tâches. Le commutateur se contente désormais de consulter une table : « si tel paquet arrive, fais ceci ». Cette table est remplie par un contrôleur placé au centre, c’est-à-dire un simple programme qui tourne sur un serveur ordinaire. La langue commune entre eux s’appelle OpenFlow.

Chaque ligne de la table comporte trois éléments : ce qu’il faut regarder (le port par lequel le paquet est entré, l’adresse vers laquelle il va), ce qu’il faut faire (le sortir par tel port, le jeter ou interroger le contrôleur) et une priorité. Si plusieurs lignes correspondent, la plus prioritaire l’emporte.

Table vide, réseau muet

Nul besoin de matériel réel pour le voir. Un outil nommé Mininet construit virtuellement commutateurs, câbles et serveurs à l’intérieur d’un seul ordinateur.

Construisez un réseau de trois ordinateurs et d’un commutateur sans démarrer de contrôleur : un ping d’un ordinateur à l’autre reste sans réponse. Le commutateur n’est pas en panne. Sa table est vide et il n’a personne à qui demander.

On écrit alors deux lignes à la main : ce qui entre par le port un sort par le port deux, ce qui entre par le port deux sort par le port un. Le même ping obtient cette fois une réponse. Le commutateur n’a rien appris ; il a simplement obéi.

Les règles ont aussi une durée de vie. Dans l’outil utilisé en TP, les lignes écrites à la main sont supprimées par défaut après soixante secondes sans aucun paquet, et le ping redevient muet. OpenFlow définit ici deux délais : le délai d’inactivité, une horloge qui ne tourne que tant que la règle n’est pas utilisée, et le délai absolu, qui supprime la règle à son terme, quel que soit son usage.

Pourquoi le premier paquet est-il lent ?

Le contrôleur est maintenant actif. Quand un ordinateur envoie un premier ping à son voisin, la table du commutateur ne contient aucune ligne correspondant à ce trafic. Il n’y a qu’une règle de secours, de priorité minimale : « si rien ne correspond, demande au contrôleur ».

Le commutateur envoie l’en-tête du paquet au contrôleur. Celui-ci décide où le paquet doit aller, inscrit une nouvelle règle dans le commutateur et lui demande de faire sortir le paquet en attente par le bon port. Quand le second paquet arrive, la règle est déjà dans la table. Le paquet traverse directement le commutateur sans jamais atteindre le contrôleur.

Le contrôleur ne voit pas chaque paquet. Il n’entend que la première question d’un flux et laisse la suite au commutateur.

L’essentiel des 2,76 millisecondes est le prix de cet aller-retour. En réalité, une autre question est posée avant même le premier ping : l’ordinateur ne connaît pas l’adresse matérielle de son voisin, il envoie donc d’abord une requête ARP qui lance à tout le monde « à qui est cette adresse ? ». Cette requête suit le même chemin jusqu’au contrôleur.

Comment un commutateur et un contrôleur font-ils connaissance ?

Au démarrage, le commutateur se connecte au contrôleur et tous deux échangent une courte présentation. Les messages capturés avec Wireshark montrent cette conversation pas à pas.

Un détail curieux : le commutateur n’accuse jamais réception d’un message FLOW_MOD. Le silence vaut succès ; un message d’erreur ne revient que si quelque chose se passe mal. Il y a aussi une différence entre versions : dans OpenFlow 1.0, la liste des ports arrivait dans la première réponse de la présentation, alors qu’en 1.3 elle est obtenue par une requête distincte.

Comment le contrôleur dresse-t-il la carte ?

Pour décider, le contrôleur doit connaître la carte du réseau : quel commutateur est relié à quel autre, et par quel port. Personne ne lui fournit cette carte. Il la dresse lui-même, avec une méthode simple.

Le contrôleur demande à chaque commutateur d’envoyer une petite trame par chacun de ses ports. La trame porte une étiquette : « je suis sortie de tel commutateur par tel port ». Le commutateur à l’autre bout du câble ne reconnaît pas cette trame, ne trouve aucune règle et la transmet au contrôleur en y ajoutant sa propre information : « elle est arrivée sur tel de mes ports ».

Le contrôleur rapproche les deux informations et en déduit un câble. En répétant l’opération pour chaque port, la carte entière apparaît. Ces trames parlent un langage appelé LLDP. Elles portent la valeur 0x88CC dans le champ de type Ethernet et sont adressées à 01:80:C2:00:00:0E. Les commutateurs standard ne relaient jamais les trames envoyées à cette adresse : l’étiquette ne parcourt qu’un seul câble avant que le commutateur d’en face la remette au contrôleur.

Cette découverte n’est pas faite une fois pour toutes : elle se répète à intervalles réguliers, toutes les trois secondes par défaut dans ONOS. Un intervalle plus court permet de repérer plus vite un câble coupé, mais ajoute davantage de trafic de contrôle. Un intervalle plus long allège la charge, au prix d’une carte qui peut rester obsolète plus longtemps.

Comment un réseau se brise-t-il ?

Les deux expériences les plus instructives du TP consistent à casser le réseau exprès.

Dans la première, des commutateurs bon marché sont reliés en anneau, et aucun n’exécute le protocole qui empêche les boucles. La mise en place n’affiche aucune erreur. Les ennuis commencent au premier ping.

La requête ARP qui précède le ping est une diffusion envoyée à tous. Chaque commutateur la renvoie par tous ses ports sauf celui d’arrivée. Dans un anneau, la trame fait le tour, revient à son point de départ et est diffusée à nouveau, en se multipliant à chaque passage. C’est une tempête de diffusion : les liens saturent et les pings restent sans réponse.

Un paquet IP perd une unité de vie à chaque routeur traversé et finit par disparaître. Une trame Ethernet n’a pas de tel compteur ; une fois dans une boucle, elle tourne indéfiniment.

Dans les réseaux réels, le protocole de l’arbre recouvrant l’empêche. Décrit par Radia Perlman en 1985, il désactive certains liens redondants et transforme l’anneau en arbre ; les câbles de secours restent en place mais ne servent qu’en cas de rupture.

La seconde expérience imite l’organisation d’un centre de données. Tout en haut, un unique commutateur de cœur ; en dessous, des commutateurs d’agrégation ; puis les commutateurs de baie ; et tout en bas, les serveurs. Chaque niveau se divise n fois ; avec n égal à deux, le réseau compte sept commutateurs et huit serveurs, avec quatre, vingt et un commutateurs et soixante-quatre serveurs.

Tant que tout fonctionne, chaque serveur atteint tous les autres. Puis on arrête le commutateur de cœur. Le réseau se coupe en deux : les quatre serveurs placés sous le même commutateur d’agrégation communiquent toujours, car leurs chemins ne passent jamais par le cœur. Mais plus aucun paquet ne passe d’une moitié à l’autre. Sur les cinquante-six sens possibles entre huit serveurs, trente-deux sont coupés.

C’est précisément le point faible d’une topologie en arbre : un seul équipement se trouve à la racine, et s’il tombe, le réseau éclate en îlots. Les grands centres de données sont donc construits avec plusieurs cœurs et des chemins de secours entre les niveaux.

Un seul cerveau au centre, est-ce une bonne idée ?

Rassembler les décisions au centre présente des avantages évidents. Le contrôleur voit tout le réseau depuis un seul endroit. Pour obtenir un nouveau comportement, on modifie un programme au lieu de se connecter aux équipements un par un. Le trafic peut être orienté en ayant le réseau entier sous les yeux.

Cette même centralisation soulève une nouvelle question. Le point de défaillance unique observé avec le commutateur de cœur réapparaît côté logiciel : si le contrôleur est injoignable, personne ne peut décider du sort des nouveaux flux. C’est pourquoi, dans les déploiements réels, les contrôleurs tournent sur plusieurs serveurs qui se secourent mutuellement.

L’échelle a aussi ses limites. Un réseau construit dans un seul ordinateur montre fidèlement les concepts, mais pas la latence, le trafic ni les pannes d’un vrai centre de données. Les temps donnés ici décrivent le fonctionnement du mécanisme, pas ce qui se passera sur de vrais câbles.

Zhipeng Wang

Fondateur et auteur 2 contenus

É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