2026-07-24 14:56:38 -04:00
|
|
|
# Underlay — la fabric physique partagee par les instances federees.
|
|
|
|
|
#
|
|
|
|
|
# Cluster-global : ces reseaux portent TOUTE la flotte, ils n'appartiennent a aucun
|
|
|
|
|
# tenant et ne derivent d'aucun `index`. Ils vivent dans le *sous-sol* du modele.
|
|
|
|
|
#
|
|
|
|
|
# Copier vers `underlay.yml` (a la racine du moteur ; gitignore) et adapter a ta fabric.
|
|
|
|
|
# Surchargeable par SETOPS_UNDERLAY=/chemin/underlay.yml. Absent => le devis switch
|
|
|
|
|
# omet simplement la section underlay (retro-compatible).
|
|
|
|
|
#
|
|
|
|
|
# Regles (prouvees par P23 / `make underlay`) :
|
|
|
|
|
# - VLAN < 1000 : franchement SOUS la plage tenant (VLAN tenant = 1000+index*10+zone).
|
|
|
|
|
# - sous_reseau : ne chevauche aucun supernet tenant (10.(10+index).0.0/16, index >= 1).
|
|
|
|
|
# => la plage 10.0.0.0/16 .. 10.10.0.0/16 est libre pour l'underlay.
|
|
|
|
|
# - passerelle : OPTIONNELLE. Presente => un SVI est genere (routage inter-VLAN).
|
|
|
|
|
# Storage/Ceph restent en general L2 pur (pas de passerelle).
|
|
|
|
|
---
|
|
|
|
|
underlay:
|
2026-08-01 20:36:02 -04:00
|
|
|
# FABRICS PHYSIQUES. Chaque reseau appartient a une fabric (`principal` par defaut).
|
|
|
|
|
# Deux fabrics ne partagent aucun cable : le devis d'une fabric ne declare ni ne
|
|
|
|
|
# transporte les VLAN d'une autre, et leurs spanning-tree sont independants.
|
|
|
|
|
# Cas typique : le stockage jumbo (iSCSI, Ceph) sur ses propres switches 10G.
|
|
|
|
|
#
|
devis switch : un seul routeur, les autres en L2 pur
Sans MLAG, le routage est porté par un unique switch (`underlay.routeur`).
Le devis émettait un jeu unique de SVI sans dire à quel switch il
s'adressait : appliqué sur les trois, il aurait créé autant de conflits
d'adresses qu'il y a de zones.
Il se scinde désormais en deux :
- partie A (switch routeur) : VLANs, SVI, ACL, trunks, routes ;
- partie B (switches d'accès, L2 pur) : mêmes VLANs pour commuter les trames
étiquetées, une adresse de gestion par switch tirée de `underlay.hotes`
avec `ip default-gateway` vers le routeur, et les trunks. Aucun SVI de
zone, aucune ACL, aucune route.
Gardes : `make underlay` refuse un `routeur` inconnu des hôtes déclarés ; la
partie B avertit qu'un seul de ses blocs de gestion va sur chaque machine.
Sans routeur désigné, l'en-tête signale le risque de duplication au lieu de
laisser croire que le devis est applicable partout.
Preuves : 24 OK, 0 échec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 20:04:38 -04:00
|
|
|
# Switch qui porte le routage : SVI de zone, ACL d'isolation, routes. Sans MLAG,
|
|
|
|
|
# UN SEUL switch route ; les autres restent en L2 pur et reçoivent la partie B du
|
|
|
|
|
# devis. Dupliquer les SVI sur plusieurs switches creerait autant de conflits
|
|
|
|
|
# d'adresses qu'il y a de zones. Doit nommer un hote declare dans `hotes:`.
|
|
|
|
|
routeur: switch-01
|
|
|
|
|
|
2026-08-01 20:50:55 -04:00
|
|
|
# Spanning-tree de la fabric principale. `topologie` documente le cablage :
|
|
|
|
|
# `etoile` = rayons depuis le routeur (aucun lien redondant, donc aucune boucle),
|
|
|
|
|
# `anneau`/`maille` = liens redondants, RSTP devient indispensable. Le routeur est
|
|
|
|
|
# toujours designe pont racine : l'arbre logique suit alors le cablage physique.
|
|
|
|
|
stp:
|
|
|
|
|
mode: rstp # rstp | mstp | pvst
|
|
|
|
|
topologie: etoile # etoile | anneau | maille
|
|
|
|
|
|
2026-07-24 14:56:38 -04:00
|
|
|
reseaux:
|
|
|
|
|
- nom: management
|
|
|
|
|
description: Switches, mgmt Proxmox, OOB/IPMI
|
|
|
|
|
vlan: 10
|
|
|
|
|
sous_reseau: 10.0.0.0/24
|
|
|
|
|
passerelle: 10.0.0.1 # SVI (retirer pour du L2 pur)
|
|
|
|
|
mtu: 1500
|
|
|
|
|
- nom: stockage-iscsi
|
2026-08-01 20:36:02 -04:00
|
|
|
fabric: stockage # switches dedies, hors fabric principale
|
2026-07-24 14:56:38 -04:00
|
|
|
description: iSCSI MPIO
|
|
|
|
|
vlan: 20
|
|
|
|
|
sous_reseau: 10.0.1.0/24
|
|
|
|
|
mtu: 9000 # jumbo
|
|
|
|
|
- nom: ceph-public
|
2026-08-01 20:36:02 -04:00
|
|
|
fabric: stockage # switches dedies, hors fabric principale
|
2026-07-24 14:56:38 -04:00
|
|
|
description: Clients <-> MON/OSD
|
|
|
|
|
vlan: 30
|
|
|
|
|
sous_reseau: 10.0.2.0/24
|
|
|
|
|
mtu: 9000
|
|
|
|
|
- nom: ceph-cluster
|
2026-08-01 20:36:02 -04:00
|
|
|
fabric: stockage # switches dedies, hors fabric principale
|
2026-07-24 14:56:38 -04:00
|
|
|
description: OSD <-> OSD (replication, backfill, recovery)
|
|
|
|
|
vlan: 31
|
|
|
|
|
sous_reseau: 10.0.3.0/24
|
|
|
|
|
mtu: 9000
|
frontière nord/sud : devis dérivé, lien de transit et les deux routes
La bordure devient un artefact dérivé, comme le devis switch — et le chemin
qui y mène est enfin déclaré.
`make devis-opnsense` (+ preuve P24) dérive la politique de bordure du
registre des flux : les flux `pair: externe`, que `resoudre_flux.py` saute
volontairement parce qu'ils relèvent de la frontière et non du pare-feu
d'hôte. Aucun port, aucune adresse, aucun nom d'hôte dans le générateur.
Le lien manquait dans tous les fichiers : le devis switch ne contenait pas
une seule `ip route`. Un réseau underlay portant `passerelle_sortie` le
déclare — il vit dans l'underlay et non dans un tenant parce que la
frontière route vers TOUS les supernets tenants par le même saut, donc il
ne peut dériver d'aucun `index`. `devis-reseau` en tire deux routes :
l'aller (sortie générale) et le retour vers l'administration, dont l'absence
a coûté la passe de déploiement du 2026-07-29 — la réponse revient au
pare-feu par une autre interface que celle où l'état a été créé, et se fait
jeter en silence.
Les réseaux d'administration viennent de l'intrant `nftables_admin_ssh` :
même source unique que la garde anti-lockout des nftables et l'alias
SETOPS_ADMIN. Les trois pare-feux et les routes ne peuvent plus diverger.
La frontière est réglable depuis la console (section « Frontière » du
panneau Intrants) ; les identifiants d'API restent interdits d'écriture par
le GUI et vivent dans la voûte.
Correctifs de la même passe :
- le panneau refusait d'enregistrer les intrants de la frontière : le
garde-fou confondait une référence de voûte `{{ vault_* }}` préservée
avec un secret soumis. Il regarde désormais la valeur, pas le nom.
- `supprimer_vm_debian.yml` ne chargeait que `proxmox.vault.yml` pour ses
secrets ; retirer ce reliquat aurait cassé `make detruire`. Aligné sur le
playbook de clonage, voûte unique en dernier.
- documentation : la voûte est unique, `proxmox.vault.yml` n'est qu'un
reliquat de compatibilité.
Preuves : 24 OK, 0 échec. Cas de rejet du validateur d'underlay exercés un
par un ; résolution du jeton Proxmox vérifiée en exécution réelle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 19:32:04 -04:00
|
|
|
# Transit vers la frontiere nord/sud (pare-feu de bordure). OPTIONNEL, mais sans lui
|
|
|
|
|
# la flotte n'a ni sortie ni chemin de retour vers l'administration.
|
|
|
|
|
# Il vit dans l'underlay parce qu'il est PARTAGE : la frontiere route vers TOUS les
|
|
|
|
|
# supernets tenants par ce meme saut — il ne peut donc deriver d'aucun `index`.
|
|
|
|
|
# `passerelle_sortie` = adresse du pare-feu sur le lien ; c'est elle qui fait emettre
|
|
|
|
|
# la route par defaut et les routes de retour (section 5 de `make devis-reseau`).
|
|
|
|
|
# Prevoir large : /29 laisse la place aux deux pare-feux pendant une transition.
|
|
|
|
|
- nom: transit-frontiere
|
|
|
|
|
description: Lien routeur est-ouest (switches L3) <-> frontiere nord/sud
|
|
|
|
|
vlan: 40
|
|
|
|
|
sous_reseau: 10.0.4.0/29
|
|
|
|
|
passerelle: 10.0.4.1 # SVI du switch L3
|
|
|
|
|
passerelle_sortie: 10.0.4.2 # pare-feu de bordure = sortie par defaut de la flotte
|
|
|
|
|
mtu: 1500
|
2026-07-24 14:56:38 -04:00
|
|
|
|
|
|
|
|
# Hotes fixes documentes (optionnel) : IP hors DHCP, verifiees dans leur reseau.
|
underlay : les ports physiques entrent dans le modèle
Les noms de ports n'étaient modélisés nulle part — des marqueurs littéraux
dans le générateur, remplacés à la main dans la sortie et perdus à chaque
régénération. Seul endroit du devis où le travail était refait à répétition.
Ils se déclarent par équipement sous quatre clefs correspondant aux quatre
natures de lien : `hyperviseurs` et `frontiere` (terminaux, portfast),
`rayons` (côté routeur), `montante` (côté switch d'accès).
Le devis émet les vrais ports, y compris PLUSIEURS vers les hyperviseurs —
il n'en supposait qu'un, alors que le cluster en compte trois. Non déclarés,
les marqueurs reviennent, par équipement : un switch renseigné et un autre
non cohabitent.
La partie B devient par switch : gestion, montante et ports terminaux
diffèrent d'une machine à l'autre, un bloc commun n'avait plus de sens.
Gardes exercées : port déclaré deux fois, rayon vers un switch inconnu,
`rayons` sur autre chose que le routeur, `montante` sur le routeur.
Preuves : 24 OK, 0 échec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 21:47:15 -04:00
|
|
|
# PORTS PHYSIQUES (optionnel). Sans eux, le devis emet des marqueurs
|
|
|
|
|
# `<PORT-VERS-...>` a remplacer a la main — et le travail est perdu a chaque
|
|
|
|
|
# regeneration. Declares ici, le devis sort applicable tel quel.
|
|
|
|
|
# hyperviseurs : ports terminaux vers Proxmox (portfast)
|
|
|
|
|
# frontiere : port(s) vers le pare-feu de bordure (portfast)
|
|
|
|
|
# rayons : {switch d'acces: port}, cote ROUTEUR uniquement
|
|
|
|
|
# montante : port vers le routeur, cote SWITCH D'ACCES uniquement
|
|
|
|
|
# `make underlay` refuse un port declare deux fois sur un meme equipement, un rayon
|
|
|
|
|
# vers un switch inconnu, et une confusion rayons/montante.
|
2026-07-24 14:56:38 -04:00
|
|
|
hotes:
|
2026-08-01 20:10:42 -04:00
|
|
|
# Le switch designe `routeur` porte le SVI de management : son adresse de gestion
|
|
|
|
|
# EST la passerelle du reseau. `make underlay` refuse les deux valeurs divergentes.
|
underlay : les ports physiques entrent dans le modèle
Les noms de ports n'étaient modélisés nulle part — des marqueurs littéraux
dans le générateur, remplacés à la main dans la sortie et perdus à chaque
régénération. Seul endroit du devis où le travail était refait à répétition.
Ils se déclarent par équipement sous quatre clefs correspondant aux quatre
natures de lien : `hyperviseurs` et `frontiere` (terminaux, portfast),
`rayons` (côté routeur), `montante` (côté switch d'accès).
Le devis émet les vrais ports, y compris PLUSIEURS vers les hyperviseurs —
il n'en supposait qu'un, alors que le cluster en compte trois. Non déclarés,
les marqueurs reviennent, par équipement : un switch renseigné et un autre
non cohabitent.
La partie B devient par switch : gestion, montante et ports terminaux
diffèrent d'une machine à l'autre, un bloc commun n'avait plus de sens.
Gardes exercées : port déclaré deux fois, rayon vers un switch inconnu,
`rayons` sur autre chose que le routeur, `montante` sur le routeur.
Preuves : 24 OK, 0 échec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 21:47:15 -04:00
|
|
|
- nom: switch-01
|
|
|
|
|
reseau: management
|
|
|
|
|
ip: 10.0.0.1
|
|
|
|
|
ports:
|
|
|
|
|
hyperviseurs: [Te1/0/1, Te1/0/2, Te1/0/3]
|
|
|
|
|
frontiere: [Gi1/0/23]
|
|
|
|
|
rayons: { switch-02: Te1/0/47, switch-03: Te1/0/48 }
|
|
|
|
|
- nom: switch-02
|
|
|
|
|
reseau: management
|
|
|
|
|
ip: 10.0.0.3
|
|
|
|
|
ports:
|
|
|
|
|
montante: Te1/0/48
|
|
|
|
|
hyperviseurs: [Te1/0/1, Te1/0/2, Te1/0/3]
|
2026-07-24 14:56:38 -04:00
|
|
|
- { nom: switch-03, reseau: management, ip: 10.0.0.4 }
|