Table of Contents

Le réseau des tenants — du câble au VRF

① Le concept

Le problème de départ : deux clients sur le même fil
Première réponse : le VLAN
Deuxième réponse : l'encapsulation
Qui distribue les enveloppes : EVPN
Le VRF : une table de routage étanche

② Dans Set-OPS

Ce que tu écris, et ce qui se calcule
Trois commandes, trois questions
La strophe FRR

③ Transférable
④ À toi de jouer

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Le réseau des tenants — du câble au VRF

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

C'est la partie de Set-OPS qui emploie le plus de mots obscurs — underlay, VXLAN, VNet, VRF, strophe FRR. Aucun n'est là par goût du jargon : chacun répond à un problème précis, et on peut les rencontrer dans l'ordre où ils sont apparus.

① Le concept

Le problème de départ : deux clients sur le même fil

Deux organisations hébergées sur le même matériel ne doivent pas se voir. Or leurs machines partagent des câbles, des commutateurs, des hyperviseurs. Il faut donc séparer ce qui est physiquement mélangé.

Première réponse : le VLAN

Un VLAN colle une étiquette (un nombre) sur chaque trame. Deux machines n'échangent que si leurs étiquettes correspondent. C'est simple, ça marche, et c'est vieux de trente ans.

Deux limites :

l'étiquette tient sur 12 bits — 4094 VLAN, pas un de plus ;
chaque commutateur du chemin doit connaître chaque VLAN. Ajouter un client, c'est toucher à la configuration de tout le monde.

Deuxième réponse : l'encapsulation

VXLAN prend la trame d'un tenant, la met dans une enveloppe et l'expédie comme un colis ordinaire d'un hyperviseur à l'autre. Le réseau physique ne voit passer que des colis — il n'a plus besoin de connaître les clients.

Deux vocabulaires en découlent, et c'est la distinction la plus utile de cette page :


underlay	le réseau physique : les câbles, les commutateurs, les adresses des hyperviseurs. Il ne connaît aucun tenant.
overlay	les réseaux virtuels des tenants, transportés dans des enveloppes par-dessus l'underlay.

L'enveloppe coûte 50 octets. C'est toute l'explication du mtu_overlay: 1450 : 1450 + 50 = 1500, la taille standard d'une trame. Se tromper là ne casse rien franchement — les petites requêtes passent, les grosses réponses restent suspendues. C'est la panne la plus déroutante du domaine.

Qui distribue les enveloppes : EVPN

Pour expédier un colis, il faut savoir où l'envoyer. EVPN est le mécanisme par lequel les hyperviseurs s'annoncent mutuellement les machines qu'ils hébergent. Sans lui, il faudrait tenir cette table à la main.

Le VRF : une table de routage étanche

Un routeur ordinaire a une table de routage. Un VRF lui en donne plusieurs, hermétiques : dans la table du tenant A, les réseaux du tenant B n'existent pas. Ce n'est pas une règle de pare-feu qu'on pourrait oublier — c'est une ignorance structurelle.

C'est la différence entre « je t'interdis d'y aller » et « la route n'existe pas ».

② Dans Set-OPS

Ce que tu écris, et ce qui se calcule

Tu écris un nombre : index. Tout le reste en découle.

index: 29
  ↓
supernet    10.29.0.0/16
VLAN        1000 + 29×10 + zone     →  1291, 1292, 1293…
zone SDN    t29
VNet        t29fron, t29serv, t29donn, t29appl
sous-réseau 10.29.16.0/24, 10.29.17.0/24 …

Un VNet est le réseau virtuel d'une zone d'un tenant : le point où les cartes réseau des VM se branchent. Une VM de la zone Frontière du tenant 29 se branche sur t29fron, et nulle part ailleurs.

Trois commandes, trois questions

Commande	Question à laquelle elle répond
`make underlay`	mon réseau physique est-il cohérent, et n'empiète-t-il pas sur les tenants ?
`make sdn-plan`	ce que le cluster porte diffère-t-il de ce que le plan décrit ? (aucune écriture)
`make sdn-appliquer`	pose la différence — et retire ce qui est périmé

sdn-plan avant sdn-appliquer, toujours. La seconde écrit sur le cluster et sur les hyperviseurs ; la première ne fait que regarder.

La strophe FRR

FRR est le démon de routage des hyperviseurs. Set-OPS lui pose un bloc par tenant — ce que le dépôt appelle une strophe — dans /etc/frr/frr.conf.local, sur chaque nœud de sortie :

vrf vrf_t29
 ip route 0.0.0.0/0 10.0.4.1 nexthop-vrf default
 ip route 10.29.0.0/16 blackhole
exit-vrf

La première ligne, c'est la sortie. Tout ce qui ne concerne pas le tenant part vers la frontière. nexthop-vrf default emprunte une seule adresse à la table principale au lieu de l'importer en entier : importer aurait fait entrer dans le VRF le transport VXLAN, le plan de gestion et les VLAN hérités — et permis de contourner la frontière.

La deuxième ligne, c'est un puits. Elle attrape les adresses non attribuées du tenant. Elle est moins précise que les /24 des VNets, donc le trafic légitime ne la voit jamais.

Sans ce puits (mesuré le 2026-08-09) : une adresse inexistante ne trouvait aucune route locale, sortait par le défaut, revenait de la frontière vers l'hyperviseur, atterrissait dans la table principale — et repartait vers la passerelle du réseau d'administration. Deux conséquences : le trafic d'un tenant pouvait atteindre le plan de gestion par une faute de frappe, et connect() réussissait vers n'importe quelle adresse inexistante. Ce qu'on avait longtemps pris pour une protection de la frontière n'était qu'une route manquante ici.

Le fichier ne se sauvegarde pas : il se régénère. Il porte son avertissement en tête — « NE PAS ÉDITER À LA MAIN ». La source de vérité est le plan.

③ Transférable

Rien de tout ça n'appartient à Set-OPS. Ce sont les briques de n'importe quel réseau multi-locataire :

underlay / overlay : le vocabulaire de tous les centres de données depuis 2015 ;
VXLAN + EVPN : la même paire chez tous les hébergeurs, du garage à AWS ;
VRF : présent sur tout routeur professionnel, et sur Linux depuis 2016 ;
le puits (blackhole) : une pratique standard d'anti-fuite.

Ce que Set-OPS ajoute n'est pas de la technologie, c'est une dérivation : ailleurs, ces objets se saisissent à la main, un par un, dans quatre interfaces différentes. Ici, ils descendent tous d'un seul nombre — donc ils ne peuvent pas se contredire.

④ À toi de jouer

Lis ton réseau physique : make underlay. Repère les VLAN sous 1000 (l'underlay) et les MTU. Pourquoi le transport doit-il être à 1500 quand l'overlay est à 1450 ?
Regarde sans écrire : make sdn-plan. Si le cluster dit déjà ce que le plan dit, la sortie tient en une ligne.
Trouve la sortie d'un tenant : dans make devis-sdn, repère la strophe FRR et l'adresse du prochain saut. À quel équipement appartient-elle ?
Change index dans un modèle (jamais en production) et régénère : combien de valeurs ont bougé ? C'est la mesure exacte de ce que la dérivation t'épargne.

Pour aller plus loin : docs/sdn-evpn.md dans le dépôt (référence technique), Le plan & l'adressage dérivé, Multi-instance & fédération.

Le lien vers docs/ était relatif (../docs/…) : il fonctionne dans le dépôt et casse une fois le wiki publié, la forge ne recevant que le contenu de wiki/. C'est pourquoi le corpus cite docs/ en texte, jamais en lien — une seule page dérogeait.

Set-OPS

🏠 Accueil

Tu viens d'arriver

🔑 Reprendre l'écosystème

Unités d'apprentissage

Fondations

Communication

Données

Observabilité

Socle & méthode

Flotte & preuve

Opérations

Runbooks → dépôt docs/runbooks-exploitation.md

Repères

Glossaire
Référence technique → dépôt docs/