Daniel Allaire
aab1bcc83a
README reduit au role du projet et au demarrage rapide. docs/architecture.md (schemas Mermaid), docs/setup.md, docs/usage.md (154 cibles en 13 familles), docs/README.md (index). Documents ranges en conception/, exploitation/, hebergement/, projet/ ; 598 chemins suivis. QUICKSTART.md, SOLUTION.md, architecture-set-ops.md et la carte fondus puis retires. Preuves : P48 lit l'index et conception/mecanismes.md ; les gardes parcourent docs/ sous- dossiers compris (_documents) ; usage.md suit le Makefile dans les deux sens. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
165 lines
7.2 KiB
Markdown
165 lines
7.2 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/conception/sdn-evpn.md` dans le dépôt (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).
|
||
|
||
> *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.*
|