diff --git a/CHANGELOG.md b/CHANGELOG.md index ca5ca08..017b443 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,19 +2,24 @@ ## 2026-08-01 (suite 6) — nommage : `bifrost` aux frontières, `sleipnir` à la fabric -`bifrost-0` et `bifrost-1` sont réservés aux deux frontières OPNsense — Bifröst est le pont +`bifrost-1` et `bifrost-2` sont réservés aux deux frontières OPNsense — Bifröst est le pont vers l'extérieur. Les switches internes deviennent `sleipnir-01…03` : le cheval qui traverse les mondes, pas le pont qui en sort. La division du nom suit celle de l'architecture. -Les deux boîtiers sont déclarés comme hôtes du lien de transit (`10.0.4.2`, `10.0.4.3`) : +Les deux boîtiers sont déclarés comme hôtes du lien de transit (`10.0.4.1`, `10.0.4.2`) : hors flotte Ansible, la déclaration documente le lien et réserve les noms. Le `/29` choisi plus tôt les loge tous les deux, comme prévu. +Le plan du `/29` est réorganisé en conséquence : frontières en bas (`.1`, `.2`), SVI du +switch en haut (`.6`), et `.3` laissée libre pour une future IP virtuelle CARP si les deux +OPNsense passent en haute disponibilité. Ce jour-là, `passerelle_sortie` pointera sur la VIP +plutôt que sur un boîtier nommé — un seul endroit à changer. + Conséquence à traiter : la partie B du devis switch aurait listé les deux pare-feux parmi les « switches d'accès ». Elle ne retient désormais que les hôtes du **réseau de management** — un équipement déclaré ailleurs ne reçoit aucune ligne de configuration de switch. -Le devis frontière nomme le boîtier quand il est déclaré : `frontiere 10.0.4.2 (bifrost-0)`. +Le devis frontière nomme le boîtier quand il est déclaré : `frontiere 10.0.4.1 (bifrost-1)`. ## 2026-08-01 (suite 5) — deux incohérences du devis switch diff --git a/docs/frontiere-opnsense.md b/docs/frontiere-opnsense.md index 389313c..fca7275 100644 --- a/docs/frontiere-opnsense.md +++ b/docs/frontiere-opnsense.md @@ -84,11 +84,25 @@ sur ce lien : - nom: transit-frontiere vlan: 40 sous_reseau: 10.0.4.0/29 - passerelle: 10.0.4.1 # SVI du switch L3 - passerelle_sortie: 10.0.4.2 # la frontière = sortie par défaut de la flotte + passerelle: 10.0.4.6 # SVI du switch L3 (sleipnir-01) + passerelle_sortie: 10.0.4.1 # bifrost-1 = sortie par défaut de la flotte ``` -**Nommage.** `bifrost-0` et `bifrost-1` désignent les deux frontières — Bifröst est le pont +**Plan du `/29`.** Les frontières occupent le bas de la plage, le SVI du switch le haut : + +| Adresse | Qui | +|---|---| +| `10.0.4.1` | `bifrost-1` — frontière active, sortie par défaut de la flotte | +| `10.0.4.2` | `bifrost-2` — seconde frontière | +| `10.0.4.3` | libre, réservée à une IP virtuelle CARP si les deux passent en HA | +| `10.0.4.4-.5` | libres | +| `10.0.4.6` | SVI du switch routeur (`sleipnir-01`) | + +Le jour où les deux OPNsense passent en haute disponibilité, `passerelle_sortie` devra +pointer sur l'**IP virtuelle CARP** et non sur un boîtier nommé — c'est le seul changement +que la bascule exigera, et il se fait à un endroit. + +**Nommage.** `bifrost-1` et `bifrost-2` désignent les deux frontières — Bifröst est le pont vers l'extérieur. La fabric interne porte un autre nom, `sleipnir-01…03` : le cheval qui traverse les mondes, pas le pont qui en sort. Les deux boîtiers sont déclarés comme hôtes du lien de transit ; ils sont **hors flotte Ansible**, la déclaration ne sert qu'à documenter le