Virtualisation réseau, NFV et data planes ouverts

Virtualiser le réseau, c’est remplacer par du logiciel trois choses jusque-là matérielles : les équipements (commutateurs, routeurs), les fonctions (pare-feu, répartiteurs de charge) et les chemins (tunnels et réseaux superposés). Le gain est réel : déploiement en minutes, densité, automatisation. Le prix aussi : l’isolation devient une affaire de configuration, la performance une affaire de cœurs de processeur, et l’observation une affaire de points de mesure qu’il faut prévoir. Cette fiche parcourt les briques de base, la NFV (Network Functions Virtualisation) et les techniques d’accélération du plan de données.

→ Lire l’explication complète de la marmotte

Virtualiser le réseau

Interfaces, bridges, tunnels

Sur un hyperviseur Linux, chaque machine virtuelle (VM, Virtual Machine) reçoit une interface virtuelle, typiquement une interface tap côté hôte, et chaque conteneur une paire veth, deux interfaces reliées comme les deux bouts d’un câble. Ces interfaces sont branchées sur un bridge virtuel, commutateur logiciel qui apprend les adresses MAC comme un commutateur physique : le bridge Linux natif, ou Open vSwitch, plus riche, programmable par OpenFlow et capable de gérer VLAN et tunnels.

Pour relier des VM réparties sur plusieurs hôtes sans reconfigurer le réseau physique, on crée un overlay (réseau superposé) : les trames du réseau virtuel sont encapsulées dans des paquets IP ordinaires qui traversent le réseau sous-jacent (underlay). Le protocole le plus répandu est VXLAN (Virtual eXtensible LAN, RFC 7348), qui encapsule une trame Ethernet dans UDP sur le port 4789 et identifie chaque réseau par un VNI (VXLAN Network Identifier) de 24 bits, soit environ 16 millions de segments contre 4 094 VLAN. Geneve (RFC 8926, port UDP 6081) en est une version extensible, retenue par plusieurs plateformes récentes.

L’encapsulation a un coût que l’underlay paie : VXLAN sur IPv4 ajoute 50 octets (14 d’Ethernet interne, 8 de VXLAN, 8 d’UDP, 20 d’IP). Sur un underlay limité à 1 500 octets, il faut soit réduire la MTU (Maximum Transmission Unit) des VM à 1 450, soit porter celle de l’underlay à 1 550 ou plus, souvent 9 000 (trames jumbo). Oublier la couche physique sous l’overlay produit le grand classique du genre : le ping passe, les petites requêtes aussi, et les transferts volumineux se figent.

Atelier : un bridge virtuel et deux VM

ip link add br0 type bridge
ip link set tap-vm1 master br0
ip link set tap-vm2 master br0
ip link set br0 up
bridge fdb show br br0

Le schéma est simple : VM1 et VM2 ont chacune une interface (eth0 vue de l’intérieur), reliée à tap-vm1 et tap-vm2 sur l’hôte, toutes deux esclaves de br0. Si l’interface physique enp1s0 est ajoutée au bridge, les VM sortent sur le LAN comme des machines ordinaires ; sinon elles ne se voient qu’entre elles, et l’hôte doit router ou traduire pour elles. bridge fdb show affiche la table d’adresses apprises, exactement comme show mac address-table sur un commutateur.

Isolation : réseau et calcul

L’isolation d’un réseau virtuel repose sur trois couches : l’étiquette (VLAN, VNI) qui sépare les segments, les règles de filtrage appliquées sur l’interface de chaque VM, et l’hyperviseur lui-même, qui ne doit pas laisser une VM écrire dans la mémoire d’une autre. Un réseau virtuel n’est donc pas isolé par nature : deux VM placées par erreur sur le même bridge, ou une interface configurée en mode promiscuité avec les mauvais droits, communiquent sans franchir aucun contrôle. L’isolation se vérifie, comme sur du matériel, par un test de flux et non par la lecture d’un schéma.

OpenStack et réseaux virtualisés

OpenStack, plateforme libre de cloud privé, confie le réseau à son service Neutron. Neutron expose des objets abstraits (réseaux, sous-réseaux, ports, routeurs, groupes de sécurité) et les réalise par des pilotes : Open vSwitch, OVN (Open Virtual Network), ou des contrôleurs tiers. Un locataire crée son réseau privé et ses règles par API, sans toucher au matériel ; les groupes de sécurité sont appliqués au plus près de chaque port de VM. Il suffit ici de retenir le principe : le réseau devient un ensemble d’objets déclarés, que l’on peut versionner et auditer. Les réseaux de conteneurs reprennent la même logique (voir conteneurs, Kubernetes et CNI), comme les réseaux des clouds publics (réseau dans le cloud et VPC).

NFV et fonctions réseau

Des boîtiers aux logiciels

La NFV est née d’un livre blanc publié en 2012 par un groupe d’opérateurs, sous l’égide de l’ETSI (European Telecommunications Standards Institute). L’idée : remplacer les boîtiers dédiés par des VNF (Virtualised Network Functions) exécutées sur des serveurs standard. Pare-feu, routeur, répartiteur de charge, concentrateur VPN, cœur de réseau mobile deviennent des images logicielles. Le vCPE (virtual Customer Premises Equipment) applique l’idée au boîtier installé chez le client : au lieu d’un routeur riche en fonctions sur chaque site, un équipement minimal et des fonctions hébergées dans le réseau de l’opérateur.

L’architecture de référence de l’ETSI distingue l’infrastructure (NFVI), les fonctions elles-mêmes, et la couche MANO (Management and Orchestration) qui les déploie, les dimensionne et les enchaîne. Deux projets libres ont marqué ce domaine. OPNFV, lancé en 2014 sous la Linux Foundation pour intégrer et tester une pile NFV complète, a fusionné en 2021 avec l’initiative CNTT pour former le projet Anuket. OSM (Open Source MANO), hébergé par l’ETSI, fournit un orchestrateur conforme à cette architecture.

Atelier : appliance physique ou fonction virtualisée

Critère	Appliance physique	Fonction virtualisée
Déploiement	commande, livraison, câblage	instanciation par API en minutes
Performance	accélération matérielle dédiée	dépend des cœurs, de la mémoire, de l’accélération
Mise à l’échelle	changer de boîtier	ajouter des instances
Mises à jour	firmware du constructeur	image logicielle, plus fréquente, à tester
Panne	matériel identifiable	dépend de l’hôte, de l’hyperviseur, du réseau virtuel
Inventaire	étiquette, numéro de série	instance éphémère, souvent oubliée des inventaires réseau

La dernière ligne compte plus qu’elle n’en a l’air : une VNF est un logiciel, avec ses vulnérabilités et son cycle de correctifs, et elle doit figurer dans l’inventaire et la gestion des vulnérabilités au même titre qu’un serveur.

Cycle de vie et supervision

Une fonction virtualisée se crée, se met à l’échelle, se déplace et se détruit. La supervision doit suivre : identifiants stables malgré les recréations, métriques exportées automatiquement, journaux envoyés vers un collecteur externe plutôt que stockés dans l’instance qui peut disparaître. Pour un pare-feu virtuel, les points de supervision à lister sont au minimum : l’état et la charge de l’instance (processeur, mémoire, table d’états), les compteurs de chaque interface virtuelle, les journaux d’autorisations et de refus, les changements de règles et leur auteur, la version de l’image et des signatures, la santé de l’hôte sous-jacent et la cohérence de la configuration avec la référence versionnée. Voir aussi gestion de réseau et supervision.

Data plane performant

Plan de données et plan de contrôle

Le plan de contrôle décide : protocoles de routage, calcul des tables, politique. Le plan de données exécute : il reçoit chaque paquet, consulte les tables et le transmet. Le premier traite quelques messages par seconde, le second des millions de paquets. Un plan de données rapide n’est pas une politique correcte : il applique à grande vitesse ce qu’on lui a dit, y compris une erreur.

Accélérer en logiciel

Dans le chemin classique, chaque paquet traverse la pile réseau du noyau, avec interruptions et copies. À 10 Gbit/s et en paquets de 64 octets, cela représente près de 15 millions de paquets par seconde, soit quelques dizaines de nanosecondes par paquet : le noyau généraliste ne suit pas. Plusieurs approches contournent cette limite.

DPDK (Data Plane Development Kit), initié par Intel puis hébergé par la Linux Foundation, fait lire la carte réseau directement par l’application en espace utilisateur, par interrogation active (pilotes en mode poll) et avec des pages mémoire larges. Les cœurs dédiés tournent à 100 % en permanence, ce qui surprend toujours la supervision.
FD.io (Fast Data input/output), projet de la Linux Foundation, héberge notamment VPP (Vector Packet Processing), qui traite les paquets par lots pour tirer parti des caches du processeur.
ODP (OpenDataPlane) définit une interface de programmation commune pour le plan de données, destinée à rendre les applications portables entre processeurs et accélérateurs différents.
eBPF (extended Berkeley Packet Filter) et son point d’accroche XDP (eXpress Data Path) exécutent des programmes vérifiés dans le noyau, au plus tôt dans la réception. Ils servent autant à filtrer et à répartir qu’à observer, ce qui en fait aussi un outil de diagnostic et d’automatisation.

Offload et SR-IOV

L’offload confie des tâches à la carte réseau : calcul des sommes de contrôle, segmentation TCP (TSO), regroupement à la réception (GRO), encapsulation VXLAN. SR-IOV (Single Root I/O Virtualization), spécification du PCI-SIG, découpe une carte physique en fonctions virtuelles (VF) attribuées directement aux VM, qui contournent ainsi le bridge de l’hôte. Le débit y gagne, la visibilité y perd : le trafic d’une VF ne passe ni par le bridge, ni par ses règles, ni par la sonde qui l’écoutait. Les captures faites sur l’hôte avec offload actif montrent d’ailleurs des paquets plus grands que la MTU ou des sommes de contrôle « fausses », simplement parce que le travail n’est pas encore fait au moment de la capture.

Accélérer sans perdre la vue

Chaque accélération retire un point d’observation. La règle de conception est donc de décider où l’on observe avant d’accélérer : export de flux depuis l’application DPDK ou VPP, compteurs de la carte, programme eBPF de mesure, port miroir physique. Un réseau très rapide dont personne ne sait ce qu’il transporte n’est pas performant, il est opaque.

À ne pas confondre

La virtualisation de serveurs découpe une machine en plusieurs systèmes ; la virtualisation réseau découpe un réseau en plusieurs segments et fonctions, et les deux se combinent sans se confondre. Un overlay n’est pas un chiffrement : VXLAN transporte en clair, et seul un IPsec, un MACsec ou un chiffrement applicatif protège la confidentialité. Enfin, un overlay mal isolé reste un réseau plat, simplement plus difficile à dessiner.

🐝 Ce qui arrive si on s’en passe

Tenir un réseau virtuel pour isolé par nature, c’est laisser deux environnements censés être séparés partager un commutateur logiciel dont personne n’a vérifié la configuration ; une erreur d’étiquetage suffit alors à faire communiquer ce qui ne devait jamais se voir. Les fonctions réseau virtualisées héritent aussi des faiblesses de tout logiciel : un pare-feu virtuel non mis à jour reste vulnérable, sans que l’inventaire des équipements réseau le mentionne. Et une accélération déployée sans point d’observation fait circuler le trafic hors de toute sonde ; le jour d’un incident, le chemin le plus rapide se révèle aussi celui dont il ne reste aucune trace.

🦫 Explication de la marmotte 🍫

La virtualisation réseau remplace des équipements physiques par des logiciels. Sur un serveur, un commutateur virtuel relie des machines virtuelles comme le ferait un appareil réel : chaque machine reçoit une interface virtuelle branchée sur ce commutateur. Pour relier des machines situées sur des serveurs différents, on crée des tunnels : les données d’un réseau virtuel sont emballées dans des paquets ordinaires, transportées par le réseau physique, puis déballées à l’arrivée. Un réseau construit ainsi au-dessus d’un autre s’appelle un réseau superposé. Plusieurs réseaux virtuels peuvent partager le même matériel en restant séparés, à condition que la configuration soit correcte : l’isolation n’est pas automatique. La virtualisation des fonctions réseau va plus loin : pare-feu, routeurs, répartiteurs de charge ou boîtiers d’accès client deviennent des programmes installés, mis à jour et surveillés comme d’autres logiciels. Des plateformes libres organisent leur déploiement et leur cycle de vie. Le traitement logiciel des paquets est plus lent que celui d’un matériel spécialisé ; des techniques d’accélération font lire les paquets directement par les programmes, ou confient une partie du travail à la carte réseau. Ces raccourcis contournent parfois les points où l’on observait le trafic : il faut conserver un endroit pour le surveiller. Enfin, le réseau superposé dépend toujours du réseau physique en dessous, et un tunnel n’est pas chiffré par nature.

Pages voisines

La citent

Virtualisation réseau, NFV et data planes ouverts

Elle cite

Virtualisation réseau, NFV et data planes ouverts

Virtualisation réseau, NFV et data planes ouverts

Virtualiser le réseau

Interfaces, bridges, tunnels

Atelier : un bridge virtuel et deux VM

Isolation : réseau et calcul

OpenStack et réseaux virtualisés

NFV et fonctions réseau

Des boîtiers aux logiciels

Atelier : appliance physique ou fonction virtualisée

Cycle de vie et supervision

Data plane performant

Plan de données et plan de contrôle

Accélérer en logiciel

Offload et SR-IOV

Accélérer sans perdre la vue

À ne pas confondre

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines