# 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` 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.*