Daniel Allaire
1f47e9bca8
Some checks are pending
verifier / verifier (push) Waiting to run
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>
161 lines
6.9 KiB
Markdown
161 lines
6.9 KiB
Markdown
# 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`](../docs/sdn-evpn.md) (référence
|
||
technique), [Le plan & l'adressage dérivé](Le-plan-et-l-adressage-dérivé),
|
||
[Multi-instance & fédération](Multi-instance-et-fédération).
|