D-78 : destination ou chemin — et le VLAN 50 pour eviter une collision

D-77 sortait deja le stockage de l'espace derive, mais par une EXCEPTION NOMMEE
plutot que par une regle. La question de l'exploitant — « le VLAN 40 n'a aucune
VM, pourquoi ne pas lui donner une adresse non routee ? » — a fait apparaitre le
critere juste.

Ce n'est pas « y a-t-il des machines dedans » (le VLAN de gestion n'en a pas plus
qu'un autre), c'est : ce reseau est-il jamais une DESTINATION, ou seulement un
CHEMIN ?

  gestion (10)        atteinte depuis ailleurs   -> 10.<index>.0.0/24, UNIQUE
  transit (40)        prochains sauts seulement  -> 192.168.40.0/24
  transport VXLAN(50) VTEP <-> VTEP              -> 192.168.50.0/24
  stockage (20/30/31) baie <-> hyperviseurs      -> 192.168.20/30/31.0/24

Sur six reseaux, CINQ cessent d'exiger la moindre coordination entre deux
hebergeurs, et « unique » redevient signifiant.

L'OS, trouve par l'exploitant avant ecriture : le VLAN 11 aurait produit
192.168.11.0/24, DEJA occupe par la gestion des hyperviseurs sur vmbr0
(passerelle .254). Le 11 se liberera quand cette gestion rejoindra 10.<index>.0.x
— mais faire dependre un plan d'adressage de l'ORDRE d'une migration est le genre
de dette qui se paie un an plus tard. Le transport passe au VLAN 50 : libre,
192.168.50.0/24 libre, et ne depend de rien. Verifie : rien ne code le 11 en dur.

underlay.yml n'est PAS modifie : il decrit le materiel tel qu'il est, et y ecrire
les nouvelles plages avant le deplacement physique le ferait mentir. Les adresses
changeront avec le materiel, dans l'ordre du runbook §6.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,47 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-12 — D-78 : destination ou chemin, et le VLAN 50 pour éviter une collision
+
+D-77 sortait déjà le stockage de l'espace dérivé, mais par une **exception nommée** plutôt
+que par une règle. Une question de l'exploitant — *« le VLAN 40 n'a aucune VM, pourquoi ne
+pas lui donner une adresse non routée ? »* — a fait apparaître le critère juste.
+
+Ce n'est pas « y a-t-il des machines dedans » : le VLAN de gestion n'en a pas plus qu'un
+autre. C'est :
+
+> **Ce réseau est-il jamais une *destination*, ou seulement un *chemin* ?**
+
+| Réseau | Rôle réel | Adressage |
+|---|---|---|
+| **Gestion** (10) | le poste, un VPN, demain le lien inter-sites doivent l'**atteindre** | `10.<index>.0.0/24` — **unique** |
+| Transit (40) | rien que des prochains sauts, deux extrémités adjacentes | `192.168.40.0/24` |
+| Transport VXLAN (**50**) | VTEP ↔ VTEP, destination de rien | `192.168.50.0/24` |
+| Stockage (20/30/31) | baie ↔ hyperviseurs | `192.168.20/30/31.0/24` |
+
+Sur six réseaux, **cinq** cessent d'exiger la moindre coordination entre deux hébergeurs —
+et « unique » redevient signifiant : seul ce qui doit l'être l'est.
+
+### L'os : le VLAN 11 aurait collisionné
+
+Sous la règle `192.168.<vlan>`, le transport VXLAN (VLAN 11) aurait produit
+`192.168.11.0/24` — **déjà occupé** par la gestion des hyperviseurs sur `vmbr0`,
+passerelle `.254`. Trouvé par l'exploitant avant écriture.
+
+Le VLAN 11 se libérera lorsque cette gestion rejoindra `10.<index>.0.x` — mais **faire
+dépendre un plan d'adressage de l'ordre d'une migration** est le genre de dette qui se paie
+un an plus tard. Le transport passe donc au **VLAN 50** : libre, `192.168.50.0/24` libre,
+et ne dépend de rien. Vérifié : rien ne code le 11 en dur, c'est de la donnée d'underlay.
+
+### Ce qui n'est PAS fait, et pourquoi
+
+`underlay.yml` décrit le matériel **tel qu'il est**. Y écrire les nouvelles plages avant le
+déplacement physique le ferait mentir : P23 validerait une fiction et les devis émettraient
+une configuration pour un état inexistant. La décision est consignée ; les adresses
+changeront **avec** le matériel, dans l'ordre du runbook §6.
+
+**Un site neuf, lui, se monte directement au schéma final** — le document de préparation
+d'un site hébergeur porte déjà le VLAN 50 et les `192.168`.
+
 ## 2026-08-12 — P03 regarde TOUTES les instances, et trouve une collision au premier essai
 
 P03 ne vérifiait la fraîcheur de l'inventaire que pour l'instance **active** — laissant un

docs/decisions-architecture.md

@@ -119,6 +119,28 @@ sont les seules vérifiables.
 
 | **D-77** | **L'underlay d'un site dérive du même `index` que son tenant**, dans la **bande basse** `10.<index>.0–15.x` ; les réseaux de **stockage** en sortent et sont **identiques partout**, en `192.168.<vlan>.0/24` | tant qu'il n'existait qu'un site, `10.0.x.x` suffisait. Deux sites qui doivent se joindre — reprise mutuelle, sauvegardes croisées, exploitation à distance — **ne peuvent pas** porter les mêmes plages : chaque routeur croit que le réseau est chez lui. Un « numéro de site » a d'abord été proposé : **rejeté**, c'était un SECOND SEED à tenir et à synchroniser, alors que tout dérive déjà d'`index` (D-17). La bande basse est sûre **par la règle, pas par chance** : les zones valent `10.<index>.(15+categorie).0/24`, donc troisième octet ≥ 16 — les octets 0 à 15 ne sont jamais alloués. Les troisièmes et derniers octets de l'underlay actuel sont ainsi **préservés** : seul le deuxième change, et l'invariant `.1` (D-04) survit intact. Le **stockage** en est sorti parce qu'il est jumbo, non routé, et ne quitte jamais son site : il n'a aucun besoin d'être unique, et l'aligner sur le VLAN (`192.168.20.x` ↔ VLAN 20) fait dire son VLAN à l'adresse. Contrepartie assumée : ces réseaux ne pourront jamais traverser un lien inter-sites — sans conséquence, puisque ce qui voyage entre deux sites est l'**état**, par le dépôt de sauvegarde, pas le stockage bloc | `underlay.yml` (`index`), `scripts/underlay.py`, `docs/preparer-un-site-hebergeur.md` | **P23** |
 
+| **D-78** | Un réseau d'underlay est soit une **destination**, soit un **chemin**. Les destinations gardent l'adressage dérivé (`10.<index>.0–15.x`) ; les chemins sortent de cet espace en **`192.168.<vlan>.0/24`, identiques à tous les sites** — décidée le 2026-08-12, **appliquée au déplacement physique** | D-77 sortait déjà le stockage, mais par une exception nommée plutôt que par une règle. Le critère n'est pas « y a-t-il des VM dedans » — le VLAN de gestion n'en a pas non plus — c'est : **ce réseau est-il jamais une destination, ou seulement un chemin ?** Transit (40) : rien que des prochains sauts, deux extrémités adjacentes en L2. Transport VXLAN (**VLAN 50**) : VTEP ↔ VTEP, destination de rien. Stockage (20/30/31) : baie ↔ hyperviseurs. **Gestion (10) : le poste de l'exploitant, un VPN, demain le lien inter-sites doivent l'atteindre** — elle reste dérivée et unique. Effet : sur six réseaux, **cinq** cessent d'exiger la moindre coordination entre deux hébergeurs, et « unique » redevient signifiant — seul ce qui doit l'être l'est | `underlay.yml`, `docs/preparer-un-site-hebergeur.md` | P23 *(la borne de bande basse ne s'applique qu'aux destinations)* |
+
+> **Ce que D-78 coûte, et ce qui la renverserait.** Le jour où l'un de ces liens devrait
+> **franchir un site**, il redeviendrait une destination et exigerait une adresse unique.
+> Concrètement : un EVPN **multi-sites** (un VTEP en peering avec le VTEP d'un autre
+> hébergeur), ou deux frontières échangeant des routes **par le tunnel** au lieu de routes
+> statiques. Ni l'un ni l'autre n'est au plan — la fabric EVPN est mono-site par
+> hébergeur, et le tunnel relie les frontières, pas les liens de transit. C'est néanmoins
+> la seule chose qui forcerait un retour en arrière, et elle est écrite ici pour qu'on la
+> reconnaisse si elle arrive.
+>
+> **Un site NEUF se monte directement au schéma final** : il n'a aucune transition à
+> subir. Seuls les sites existants ont un déplacement à faire.
+>
+> **Pourquoi le transport VXLAN passe du VLAN 11 au VLAN 50.** Sous la règle
+> `192.168.<vlan>`, le VLAN 11 aurait produit `192.168.11.0/24` — **déjà occupé** par la
+> gestion des hyperviseurs sur `vmbr0` (passerelle `.254`). Collision frontale. Le VLAN 11
+> se libérera bien lorsque cette gestion rejoindra `10.<index>.0.x`, mais faire dépendre
+> un plan d'adressage de l'ORDRE d'une migration est exactement le genre de dette qui se
+> paie un an plus tard. Le VLAN 50 est libre, son `192.168.50.0/24` aussi, et il ne
+> dépend de rien.
+
 > **Ce que D-77 rend possible, et ce qu'elle coûte.** Elle est la condition de la reprise
 > mutuelle : sans plages distinctes, aucun lien entre deux sites ne peut router. Elle est
 > **gratuite pour un site neuf** et **coûteuse pour un site vivant** — renuméroter, c'est

docs/preparer-un-site-hebergeur.md

@@ -29,14 +29,14 @@ listes de stockages et de ponts différentes. Un hébergeur décrit son matérie
 tenir : le seul seed de tout l'adressage reste l'`index`, et l'underlay occupe la **bande
 basse** du supernet — celle que la dérivation des tenants n'alloue jamais.
 
-| Rôle | VLAN | Sous-réseau | MTU | Qui y vit |
+| Rôle | VLAN | Sous-réseau | MTU | Nature |
 |---|---|---|---|---|
-| Gestion | 10 | `10.<index>.0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur |
+| **Gestion** | 10 | `10.<index>.0.0/24` | 1500 | **destination** — unique par site |
-| Sortie des tenants | 40 | `10.<index>.4.0/24` | 1500 | frontière `.1`, nœuds de sortie |
+| Sortie des tenants | 40 | `192.168.40.0/24` | 1500 | chemin — identique partout |
-| Transport VXLAN | 11 | `10.<index>.5.0/24` | 1500 | hyperviseurs seulement |
+| Transport VXLAN | 50 | `192.168.50.0/24` | 1500 | chemin — identique partout |
-| Stockage iSCSI | 20 | `192.168.20.0/24` | 9000 | baie ↔ hyperviseurs |
+| Stockage iSCSI | 20 | `192.168.20.0/24` | 9000 | chemin — identique partout |
-| Ceph public | 30 | `192.168.30.0/24` | 9000 | clients ↔ MON/OSD |
+| Ceph public | 30 | `192.168.30.0/24` | 9000 | chemin — identique partout |
-| Ceph cluster | 31 | `192.168.31.0/24` | 9000 | OSD ↔ OSD |
+| Ceph cluster | 31 | `192.168.31.0/24` | 9000 | chemin — identique partout |
 
 Index 17 → gestion en `10.17.0.0/24` ; index 11 → `10.11.0.0/24`. Deux sites ne peuvent
 donc **pas** se chevaucher, sans qu'on ait rien de plus à décider.
@@ -51,11 +51,20 @@ numéro de VLAN — `192.168.20.x` est sur le VLAN 20.
 > ne sont **jamais** alloués — c'est une propriété de la règle, pas une place restée
 > vide. L'underlay y tient largement.
 
-> **Pourquoi le stockage sort de cet espace.** Ces réseaux sont jumbo, non routés, et ne
+> **Un seul réseau doit être unique, et c'est la gestion.** Le critère n'est pas « y a-t-il
-> quittent jamais leur site. Ils n'ont donc aucun besoin d'être uniques — et les rendre
+> des machines dedans » — le VLAN de gestion n'en a pas plus qu'un autre — c'est : **ce
-> **identiques partout** épargne une coordination inutile. Contrepartie assumée : ils ne
+> réseau est-il jamais une destination, ou seulement un chemin ?**
-> pourront jamais traverser un lien inter-sites. Sans conséquence, puisque ce qui voyage
+>
-> entre deux sites, c'est l'**état** (par le dépôt de sauvegarde), pas le stockage bloc.
+> La gestion est une destination : le poste de l'exploitant, un VPN, demain un lien
+> inter-sites doivent l'**atteindre**. Les autres ne sont que traversés — le transit ne
+> porte que des prochains sauts entre deux voisins directs, le VXLAN va d'un hyperviseur
+> à l'autre, le stockage de la baie aux hyperviseurs. Aucun n'est jamais joint depuis
+> l'extérieur de son propre lien.
+>
+> D'où `192.168.<vlan>.0/24`, **identique chez tous les hébergeurs** : l'adresse dit son
+> VLAN, et cinq réseaux sur six cessent d'exiger la moindre coordination. Contrepartie
+> assumée : ils ne pourront jamais franchir un lien inter-sites. Sans conséquence — ce qui
+> voyage entre deux sites, c'est l'**état** (par le dépôt de sauvegarde), pas la plomberie.
 
 Un hébergeur qui n'exploite lui-même **aucun** tenant prend quand même un `index` : c'est
 le seed de son site. Une seule règle, aucun cas particulier.
@@ -77,7 +86,7 @@ l'intérieur. Set-OPS **pilote ses règles par API** : le boîtier reste à l'h
 n'y est installé.
 
 **Interfaces :** le WAN (noter l'IP publique) ; la gestion en `10.<index>.0.1/24` ; le
-transit en `10.<index>.4.1/24`, par où sortent les machines du tenant.
+transit en `192.168.40.1/24`, par où sortent les machines du tenant.
 
 > **Un point de routage porte le même dernier octet partout** : `.1`, quel que soit
 > l'équipement qui l'assure. Invariant porté par la preuve `P23`.

docs/runbooks-exploitation.md

@@ -173,12 +173,24 @@ défaut, et l'outil qui devait faire la bascule.
 
 ### Ce qui reste à déplacer, et dans quel ordre
 
-1. le poste de l'exploitant — une seconde adresse `10.17.0.x/24` ;
+| # | À déplacer | Vers | Nature (D-78) |
-2. les commutateurs (`10.0.0.3`, `.4`) et leur `ip default-gateway` ;
+|---|---|---|---|
-3. l'administration des hyperviseurs (`vmbr0`), l'OOB/IPMI ;
+| 1 | le poste de l'exploitant | `10.17.0.x/24` (seconde adresse) | — |
-4. le transit (`10.0.4.x`) et le transport VXLAN (`10.0.5.x`) ;
+| 2 | les commutateurs `10.0.0.3/.4` **et leur `ip default-gateway`** | `10.17.0.3/.4`, passerelle `10.17.0.1` | destination |
-5. le stockage vers `192.168.<vlan>.0/24` ;
+| 3 | l'administration des hyperviseurs (`vmbr0`, aujourd'hui `192.168.11.x`), l'OOB/IPMI | `10.17.0.41/.43/.47` | destination |
-6. **en dernier seulement**, retirer `10.0.0.1`.
+| 4 | le transit `10.0.4.x` | **`192.168.40.x`** | chemin |
+| 5 | le transport VXLAN `10.0.5.x`, **VLAN 11 → 50** | **`192.168.50.x`** | chemin |
+| 6 | le stockage `10.0.1–3.x` | **`192.168.20/30/31.x`** | chemin |
+| 7 | **en dernier seulement**, retirer `10.0.0.1` | — | — |
+
+Les étapes 4 à 6 sortent définitivement de l'espace dérivé (D-78) : ces réseaux ne sont
+jamais des destinations, seulement des chemins. Une fois faites, **seule la gestion** doit
+rester unique d'un site à l'autre.
+
+> **L'étape 5 change aussi le numéro de VLAN**, côté commutateur (trunk) et côté
+> hyperviseurs (`bond3.11` → `bond3.50`). Le 11 est écarté parce que `192.168.11.0/24` est
+> occupé par l'étape 3 tant qu'elle n'est pas faite — et un plan d'adressage ne doit pas
+> dépendre de l'ordre d'une migration.
 
 ### Ce qui ne dépend PAS de cette bascule
 

scripts/underlay.py

@@ -25,9 +25,18 @@ Le site declare son index par `underlay.index`. **Sans lui**, on retombe sur la
 stricte d'avant D-77 (aucun chevauchement) : c'est le comportement sur pour un
 underlay qui n'a pas encore migre.
 
-Les reseaux de STOCKAGE sortent de cet espace (192.168.<vlan>.0/24, identiques a tous
+DESTINATION OU CHEMIN (D-78). Ce qui sort de l'espace derive n'est pas « le stockage »
-les sites) : jumbo, non routes, ils ne quittent jamais leur site, donc ils n'ont aucun
+mais tout reseau qui n'est jamais une DESTINATION. Le critere n'est pas la presence de
-besoin d'etre uniques.
+machines — le VLAN de gestion n'en a pas plus qu'un autre :
+
+  destination : on doit pouvoir l'ATTEINDRE depuis ailleurs (gestion : poste de
+                l'exploitant, VPN, lien inter-sites)  -> 10.<index>.0-15.x, UNIQUE
+  chemin      : seulement traverse, jamais joint depuis l'exterieur de son propre lien
+                (transit, transport VXLAN, stockage)  -> 192.168.<vlan>.0/24, IDENTIQUE
+                a tous les sites — l'adresse dit son VLAN
+
+La borne de bande basse ne concerne donc que les DESTINATIONS : un reseau en 192.168 est
+hors de tout supernet tenant et passe par la branche « hors de tout supernet ».
 
 EMPLACEMENT : l'underlay appartient a l'HEBERGEUR — ses switches, ses cables. Il vit
 donc dans SON depot, et le moteur le monte par symlink :