Set-OPS-Public/wiki/Le-réseau-des-tenants.md
Daniel Allaire 1f47e9bca8
Some checks are pending
verifier / verifier (push) Waiting to run
glossaire : le metier n'etait explique nulle part
Demande de l'exploitant apres une soiree passee a croiser « strophe FRR », VRF, VNet et
nexthop-vrf : cet ecosysteme doit rester pilotable par un humain, idealement un seul ;
que chaque notion sous-jacente soit ENSEIGNEE.

MESURE AVANT D'ECRIRE : 40 termes employes par le depot et absents du glossaire — LDAP
184 fois, playbook 165, underlay 106, EVPN 66, VRF 33, LMTP 25. Le glossaire expliquait le
vocabulaire propre a Set-OPS (plan, index, voute, zone) et laissait dehors tout ce qui
vient du metier. Or c'est le metier qui perd le lecteur.

CE N'EST PAS UN DEFAUT DE REDACTION. La regle fondatrice du depot est qu'un humain pilote
sans IA. Chaque mot obscur retire une personne a la liste de celles qui peuvent reprendre
le systeme : un vocabulaire non explique est un defaut de CONCEPTION.

- Glossaire reecrit : 67 termes groupes par famille (plan, machines, Ansible, reseau,
  noms, confiance, identite, courriel, etat et preuve). Chaque entree dit ce que c'est ET
  pourquoi ce depot s'en sert, avec renvoi vers l'unite qui developpe.
- Unite d'apprentissage manquante : « Le reseau des tenants ». Dix-sept des quarante
  termes y vivaient sans domicile. Elle suit l'ordre ou les problemes se sont poses : deux
  clients sur un cable -> VLAN -> ses deux limites -> encapsulation -> pourquoi 1450 ->
  EVPN -> le VRF, qui n'est pas une interdiction mais une ignorance structurelle.
- Navigation : la nouvelle unite est au sidebar ; le plan de recette regenere (P22 l'a
  exige des l'ajout de la page — le harnais a mordu).

P39 verifie : chaque terme du jargon a une entree ; chaque lien du glossaire mene a une
page existante ; chaque page du wiki est atteignable depuis la navigation.

LA LISTE EST DECLAREE, ET C'EST UN CHOIX MESURE. La derivation automatique a ete essayee :
153 acronymes dans le wiki et le README, dont la moitie sont des mots francais en
capitales (AUCUNE, AVANT, TOUS). Un controle qui exige une entree pour « AUCUNE » finit
desactive, et une preuve desactivee ne garde rien. La preuve dit elle-meme cet angle mort.

EPROUVEE EN NEGATIF contre le glossaire d'avant : 49 termes manquants, nommes un par un.

make verifier 39 OK, 0 echec, 0 saute ; make ci idem.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 12:15:55 -04:00

6.9 KiB
Raw Blame History

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

  1. 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 ?
  2. Regarde sans écrire : make sdn-plan. Si le cluster dit déjà ce que le plan dit, la sortie tient en une ligne.
  3. 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 ?
  4. 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 (référence technique), Le plan & l'adressage dérivé, Multi-instance & fédération.