Damien/arista-evpn-vxlan-clab
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Phase 0: Analyse et Design — cadrage, contraintes, décisions #31

New Issue
Closed
opened 2026-03-15 12:23:45 +00:00 by Damien · 3 comments
Damien commented 2026-03-15 12:23:45 +00:00
Owner
Copy Link

Parent: #30

Objectif

Fixer les contraintes, le scope du fabric generator, et le modèle IPAM hiérarchique avant de coder.

Décisions à prendre

1. Modèle de switch Arista pour le lab

Containerlab utilise ceos. Fixer un InfraDeviceModel avec un nombre de ports déterminant les limites.

  • Exemple : 7050SX3-48YC12 (48+12 ports) ou profil simplifié pour le lab
  • Le nombre de ports disponibles sur un spine détermine le max de leafs

2. Contraintes de fabric

  • Avec 2 spines : max leafs = ports_spine - ports_réservés
  • Les leafs vont par paire MLAG : avec 8 ports spine = 4 paires = 8 leafs max
  • Règles de validation à formaliser

3. Modèle IPAM hiérarchique (supernets → site → fabric → allocation)

L'idée est de partir de supernets globaux qui se subdivisent automatiquement lorsqu'on crée un site, puis une fabric.

Niveau 0 — Supernets globaux

Blocs de départ définis une seule fois, à la racine :

Rôle Supernet Description
Infrastructure 10.0.0.0/8 Loopbacks, underlay, MLAG
Services 172.16.0.0/12 L2/L3 VXLAN (VLANs utilisateurs, VRFs)

Alternative : un seul supernet 10.0.0.0/8 découpé en rôles. À discuter.

Niveau 1 — Allocation par site

À la création d'un site (ex: paris), un générateur ou un processus alloue depuis les supernets :

Pool site Taille allouée Source
Infra site (loopbacks + underlay + MLAG) /16 depuis 10.0.0.0/8
Services site (L2/L3 VXLAN) /16 depuis 172.16.0.0/12

Niveau 2 — Allocation par fabric

À la création d'une fabric dans un site, on découpe le /16 infra du site :

Pool fabric Taille Usage Allocation unitaire
Loopback0 (Router-ID) /24 1 par device /32 via CoreIPAddressPool
Loopback1 (VTEP) /24 1 par paire leaf (partagé) /32 via CoreIPAddressPool
Underlay P2P /24 1 par lien spine-leaf /31 via CoreIPPrefixPool
MLAG peer-link SVI /24 1 par paire leaf /31 via CoreIPPrefixPool
MLAG iBGP peer /24 1 par paire leaf /31 via CoreIPPrefixPool

Niveau 3 — Allocation par service (L2/L3 VXLAN)

Depuis le pool services du site :

Pool Usage Allocation unitaire
VLANs L2 VXLAN Subnet par VLAN étendu /24 ou custom
VRFs L3 VXLAN Subnet par VRF/SVI /24 ou custom

Implications architecturales

  • 2 générateurs potentiels :
    1. SiteGenerator — déclenché quand un site est ajouté au groupe cible → alloue les préfixes site depuis les supernets
    2. FabricGenerator — déclenché quand une fabric est ajoutée → crée devices, interfaces, IPs depuis les pools du site
  • Chaque allocation utilise un identifier déterministe pour l'idempotence (ex: site-paris-infra, fabric-evpnlab-loopback0-leaf1)
  • Les pools sont branch-agnostic → pas de collision entre branches

Questions ouvertes

  • Un seul supernet /8 découpé en rôles, ou deux supernets distincts (infra vs services) ?
  • Le SiteGenerator est-il nécessaire, ou les pools site peuvent être créés via objets YAML ?
  • Quelle taille pour le pool services par site ? /16 suffit-il ?
  • Faut-il un NumberPool pour les VNIs en plus des ASN ?

4. Scope du générateur

  • Le SiteGenerator crée les préfixes et pools IPAM du site
  • Le FabricGenerator crée l'infra fabric (devices, interfaces, IPs, BGP, MLAG, underlay links)
  • Les services (VLANs utilisateurs, VRFs, EVPN instances) restent déclarés séparément mais consomment les pools services du site

5. ASN

  • Pool CoreNumberPool pour les ASN leaf (ex: 65001-65099)
  • ASN spine fixé sur la fabric (attribut spine_asn)
  • Chaque paire leaf consomme un ASN depuis le pool

Livrables

  • Choix du modèle de switch (nombre de ports, type)
  • Limites fixées : max spines, max leafs, validation rules
  • Schéma IPAM hiérarchique validé (supernets, tailles, rôles)
  • Réponses aux questions ouvertes IPAM
  • Scope défini : SiteGenerator vs FabricGenerator vs déclaratif
  • Convention de nommage des identifier pour l'idempotence
  • Documentation de l'architecture dans cette issue
Parent: #30 ## Objectif Fixer les contraintes, le scope du fabric generator, et le **modèle IPAM hiérarchique** avant de coder. ## Décisions à prendre ### 1. Modèle de switch Arista pour le lab Containerlab utilise `ceos`. Fixer un `InfraDeviceModel` avec un nombre de ports déterminant les limites. - Exemple : 7050SX3-48YC12 (48+12 ports) ou profil simplifié pour le lab - Le nombre de ports disponibles sur un spine détermine le max de leafs ### 2. Contraintes de fabric - Avec 2 spines : max leafs = ports_spine - ports_réservés - Les leafs vont par paire MLAG : avec 8 ports spine = 4 paires = 8 leafs max - Règles de validation à formaliser ### 3. Modèle IPAM hiérarchique (supernets → site → fabric → allocation) L'idée est de partir de **supernets globaux** qui se subdivisent automatiquement lorsqu'on crée un site, puis une fabric. #### Niveau 0 — Supernets globaux Blocs de départ définis une seule fois, à la racine : | Rôle | Supernet | Description | |------|----------|-------------| | Infrastructure | `10.0.0.0/8` | Loopbacks, underlay, MLAG | | Services | `172.16.0.0/12` | L2/L3 VXLAN (VLANs utilisateurs, VRFs) | > Alternative : un seul supernet `10.0.0.0/8` découpé en rôles. À discuter. #### Niveau 1 — Allocation par site À la **création d'un site** (ex: `paris`), un générateur ou un processus alloue depuis les supernets : | Pool site | Taille allouée | Source | |-----------|----------------|--------| | Infra site (loopbacks + underlay + MLAG) | `/16` | depuis `10.0.0.0/8` | | Services site (L2/L3 VXLAN) | `/16` | depuis `172.16.0.0/12` | #### Niveau 2 — Allocation par fabric À la **création d'une fabric** dans un site, on découpe le `/16` infra du site : | Pool fabric | Taille | Usage | Allocation unitaire | |-------------|--------|-------|---------------------| | Loopback0 (Router-ID) | `/24` | 1 par device | `/32` via `CoreIPAddressPool` | | Loopback1 (VTEP) | `/24` | 1 par paire leaf (partagé) | `/32` via `CoreIPAddressPool` | | Underlay P2P | `/24` | 1 par lien spine-leaf | `/31` via `CoreIPPrefixPool` | | MLAG peer-link SVI | `/24` | 1 par paire leaf | `/31` via `CoreIPPrefixPool` | | MLAG iBGP peer | `/24` | 1 par paire leaf | `/31` via `CoreIPPrefixPool` | #### Niveau 3 — Allocation par service (L2/L3 VXLAN) Depuis le pool services du site : | Pool | Usage | Allocation unitaire | |------|-------|---------------------| | VLANs L2 VXLAN | Subnet par VLAN étendu | `/24` ou custom | | VRFs L3 VXLAN | Subnet par VRF/SVI | `/24` ou custom | #### Implications architecturales - **2 générateurs potentiels** : 1. `SiteGenerator` — déclenché quand un site est ajouté au groupe cible → alloue les préfixes site depuis les supernets 2. `FabricGenerator` — déclenché quand une fabric est ajoutée → crée devices, interfaces, IPs depuis les pools du site - Chaque allocation utilise un `identifier` déterministe pour l'**idempotence** (ex: `site-paris-infra`, `fabric-evpnlab-loopback0-leaf1`) - Les pools sont **branch-agnostic** → pas de collision entre branches #### Questions ouvertes - [x] Un seul supernet `/8` découpé en rôles, ou deux supernets distincts (infra vs services) ? - [x] Le `SiteGenerator` est-il nécessaire, ou les pools site peuvent être créés via objets YAML ? - [x] Quelle taille pour le pool services par site ? `/16` suffit-il ? - [x] Faut-il un `NumberPool` pour les VNIs en plus des ASN ? ### 4. Scope du générateur - Le **SiteGenerator** crée les préfixes et pools IPAM du site - Le **FabricGenerator** crée l'infra fabric (devices, interfaces, IPs, BGP, MLAG, underlay links) - Les **services** (VLANs utilisateurs, VRFs, EVPN instances) restent déclarés séparément mais consomment les pools services du site ### 5. ASN - Pool `CoreNumberPool` pour les ASN leaf (ex: `65001-65099`) - ASN spine fixé sur la fabric (attribut `spine_asn`) - Chaque paire leaf consomme un ASN depuis le pool ## Livrables - [x] Choix du modèle de switch (nombre de ports, type) - [x] Limites fixées : max spines, max leafs, validation rules - [x] Schéma IPAM hiérarchique validé (supernets, tailles, rôles) - [x] Réponses aux questions ouvertes IPAM - [x] Scope défini : SiteGenerator vs FabricGenerator vs déclaratif - [x] Convention de nommage des `identifier` pour l'idempotence - [x] Documentation de l'architecture dans cette issue
Damien added the epic label 2026-03-15 12:50:43 +00:00
Damien commented 2026-03-15 15:37:05 +00:00
Author
Owner
Copy Link

Standardisation document created

The fabric standardization draft has been committed to feat/fabric-generator:
→ docs/fabric-standardization.md

Covers

  1. Topology constraints — 2 spines, 3-4 MLAG leaf pairs, no access switches
  2. Port assignments — Spine (Eth1-N → leafs) / Leaf (Eth1-9 hosts, Eth10 MLAG peer-link, Eth11-12 spines)
  3. Naming conventions — devices, fabrics, IPAM identifiers
  4. IPAM plan — supernets, site pools, fabric pools, reserved VLANs
  5. BGP standards — ASN model, peer-groups, AFIs, all config parameters
  6. MLAG standards — domain-id, VLANs 4090/4091, dual-primary, virtual MAC
  7. VXLAN standards — VTEP config, VNI ranges (L2: 100k, L3: 200k), RD/RT formats
  8. Global parameters — MTU 9214, multi-agent routing, gNMI
  9. Out of scope — access switches, multi-fabric, IPv6, BFD

Also committed: docs/diagrams/ipam_hierarchy_model.svg

## Standardisation document created The fabric standardization draft has been committed to `feat/fabric-generator`: → [`docs/fabric-standardization.md`](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab/src/branch/feat/fabric-generator/docs/fabric-standardization.md) ### Covers 1. **Topology constraints** — 2 spines, 3-4 MLAG leaf pairs, no access switches 2. **Port assignments** — Spine (Eth1-N → leafs) / Leaf (Eth1-9 hosts, Eth10 MLAG peer-link, Eth11-12 spines) 3. **Naming conventions** — devices, fabrics, IPAM identifiers 4. **IPAM plan** — supernets, site pools, fabric pools, reserved VLANs 5. **BGP standards** — ASN model, peer-groups, AFIs, all config parameters 6. **MLAG standards** — domain-id, VLANs 4090/4091, dual-primary, virtual MAC 7. **VXLAN standards** — VTEP config, VNI ranges (L2: 100k, L3: 200k), RD/RT formats 8. **Global parameters** — MTU 9214, multi-agent routing, gNMI 9. **Out of scope** — access switches, multi-fabric, IPv6, BFD Also committed: [`docs/diagrams/ipam_hierarchy_model.svg`](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab/src/branch/feat/fabric-generator/docs/diagrams/ipam_hierarchy_model.svg)
Damien commented 2026-03-16 06:40:30 +00:00
Author
Owner
Copy Link

Progress update — decisions & open questions

Standardization document updated

docs/fabric-standardization.md has been reworked on feat/fabric-generator. Key changes:

  • §1 Device model — Reference platform: Arista 7050SX3-48YC12 (48x 25G + 12x 100G). Production and clab port layouts formalized with deterministic formulas based on spine count.
  • §2 Topology — Spines: 2 to 4 (was fixed at 2). All limits derived from hardware. Validation rules explicit.
  • §6 IPAM — Only the 2 supernets are fixed (10.0.0.0/8 infra, 172.16.0.0/12 services). All intermediate allocations delegated to Infrahub resource manager — no hardcoded prefix sizes.
  • §7 BGP — maximum-paths now {N_spines × 2} ecmp 64. Added bgp log-neighbor-changes. RD/RT for L3 VXLAN uses L3_VNI (not arbitrary index).
  • §9 VXLAN — VNI pool names and deterministic identifiers added.

Questions resolved

Question Decision
Switch model 7050SX3-48YC12 — 25G for hosts/downlinks, 100G for fabric
Max spines 2–4 (flexible), POC default: 2
One or two supernets? Two: 10.0.0.0/8 (infra) + 172.16.0.0/12 (services)
Pool prefix sizes (/16, /24…)? Not fixed — delegated to Infrahub resource manager
SiteGenerator needed? Yes — good exercise for learning generators
NumberPool for VNIs? No — VNI logic implemented in the generator
L2 VNI calculation 100000 + vlan_id (deterministic, derived from VLAN ID)
L3 VNI calculation Sequential from 200001

Remaining open question

Generator scope: what does each generator create exactly?

This is the last structural decision before implementation. Proposed split to discuss:

Generator Trigger Creates
SiteGenerator LocationSite added to target group Site infra prefix (from 10.0.0.0/8), site services prefix (from 172.16.0.0/12), IPAM pools for the site
FabricGenerator InfraFabric added to target group Devices, loopbacks, underlay P2P links, MLAG config, BGP sessions, VTEP interfaces — consuming pools created by SiteGenerator

Services (VLANs, VRFs, EVPN instances) remain declarative / separate from both generators.

Updated livrables checklist

  • Choix du modèle de switch
  • Limites fixées : max spines, max leafs, validation rules
  • Schéma IPAM hiérarchique validé
  • Réponses aux questions ouvertes IPAM
  • Convention de nommage des identifiers
  • Documentation de l'architecture (docs/fabric-standardization.md)
  • Scope défini : SiteGenerator vs FabricGenerator → à finaliser
## Progress update — decisions & open questions ### Standardization document updated [`docs/fabric-standardization.md`](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab/src/branch/feat/fabric-generator/docs/fabric-standardization.md) has been reworked on `feat/fabric-generator`. Key changes: - **§1 Device model** — Reference platform: Arista 7050SX3-48YC12 (48x 25G + 12x 100G). Production and clab port layouts formalized with deterministic formulas based on spine count. - **§2 Topology** — Spines: 2 to 4 (was fixed at 2). All limits derived from hardware. Validation rules explicit. - **§6 IPAM** — Only the 2 supernets are fixed (`10.0.0.0/8` infra, `172.16.0.0/12` services). All intermediate allocations delegated to Infrahub resource manager — no hardcoded prefix sizes. - **§7 BGP** — `maximum-paths` now `{N_spines × 2} ecmp 64`. Added `bgp log-neighbor-changes`. RD/RT for L3 VXLAN uses `L3_VNI` (not arbitrary index). - **§9 VXLAN** — VNI pool names and deterministic identifiers added. --- ### Questions resolved | Question | Decision | |----------|----------| | Switch model | 7050SX3-48YC12 — 25G for hosts/downlinks, 100G for fabric | | Max spines | 2–4 (flexible), POC default: 2 | | One or two supernets? | Two: `10.0.0.0/8` (infra) + `172.16.0.0/12` (services) | | Pool prefix sizes (/16, /24…)? | Not fixed — delegated to Infrahub resource manager | | SiteGenerator needed? | **Yes** — good exercise for learning generators | | NumberPool for VNIs? | **No** — VNI logic implemented in the generator | | L2 VNI calculation | `100000 + vlan_id` (deterministic, derived from VLAN ID) | | L3 VNI calculation | Sequential from `200001` | --- ### Remaining open question **Generator scope**: what does each generator create exactly? This is the last structural decision before implementation. Proposed split to discuss: | Generator | Trigger | Creates | |-----------|---------|---------| | **SiteGenerator** | `LocationSite` added to target group | Site infra prefix (from `10.0.0.0/8`), site services prefix (from `172.16.0.0/12`), IPAM pools for the site | | **FabricGenerator** | `InfraFabric` added to target group | Devices, loopbacks, underlay P2P links, MLAG config, BGP sessions, VTEP interfaces — consuming pools created by SiteGenerator | Services (VLANs, VRFs, EVPN instances) remain declarative / separate from both generators. --- ### Updated livrables checklist - [x] Choix du modèle de switch - [x] Limites fixées : max spines, max leafs, validation rules - [x] Schéma IPAM hiérarchique validé - [x] Réponses aux questions ouvertes IPAM - [x] Convention de nommage des identifiers - [x] Documentation de l'architecture (`docs/fabric-standardization.md`) - [ ] **Scope défini : SiteGenerator vs FabricGenerator** → à finaliser
Damien commented 2026-03-16 20:33:57 +00:00
Author
Owner
Copy Link

Generator scope — final decision

Three generators, each with a clear trigger and responsibility:

Generator Trigger Creates
SiteGenerator LocationSite added to target group Site infra prefix (from 10.0.0.0/8), site services prefix (from 172.16.0.0/12), IPAM pools for the site
FabricGenerator InfraFabric added to target group Devices (spines + leafs), Loopback0/1, underlay P2P links, MLAG config (VLANs 4090/4091, Po999, domain-id), BGP sessions (underlay, iBGP, EVPN overlay), VTEP interfaces — all consuming pools created by SiteGenerator
ServiceGenerator L2 or L3 service object declared L2: VLAN + VNI (100000 + vlan_id) + VLAN-to-VNI mapping + IP from services pool. L3: VRF + VNI (sequential from 200001) + L3VNI mapping + IP from services pool

Key boundaries

  • SiteGenerator owns IPAM — no other generator creates prefixes or pools
  • FabricGenerator owns infrastructure — consumes IPAM pools, creates everything needed for a working underlay + overlay fabric (no services)
  • ServiceGenerator owns services — consumes VLANs, VNIs, and service IPs. No CoreNumberPool for VNIs; the generator computes them directly (L2: deterministic from VLAN ID, L3: sequential)

VNI logic (in ServiceGenerator, no NumberPool)

Type Formula Example
L2 VNI 100000 + vlan_id VLAN 40 → VNI 100040
L3 VNI Sequential from 200001 First VRF → 200001, second → 200002

All open questions from this issue are now resolved. ✅

Final livrables checklist

  • Choix du modèle de switch (7050SX3-48YC12)
  • Limites fixées : 2-4 spines, leafs en paires, validation rules
  • Schéma IPAM hiérarchique validé (2 supernets fixes, rest dynamique)
  • Réponses aux questions ouvertes IPAM
  • Scope défini : SiteGenerator / FabricGenerator / ServiceGenerator
  • Convention de nommage des identifiers (incl. VNI)
  • Documentation (docs/fabric-standardization.md)
## Generator scope — final decision Three generators, each with a clear trigger and responsibility: | Generator | Trigger | Creates | |-----------|---------|---------| | **SiteGenerator** | `LocationSite` added to target group | Site infra prefix (from `10.0.0.0/8`), site services prefix (from `172.16.0.0/12`), IPAM pools for the site | | **FabricGenerator** | `InfraFabric` added to target group | Devices (spines + leafs), Loopback0/1, underlay P2P links, MLAG config (VLANs 4090/4091, Po999, domain-id), BGP sessions (underlay, iBGP, EVPN overlay), VTEP interfaces — all consuming pools created by SiteGenerator | | **ServiceGenerator** | L2 or L3 service object declared | L2: VLAN + VNI (`100000 + vlan_id`) + VLAN-to-VNI mapping + IP from services pool. L3: VRF + VNI (sequential from `200001`) + L3VNI mapping + IP from services pool | ### Key boundaries - **SiteGenerator** owns IPAM — no other generator creates prefixes or pools - **FabricGenerator** owns infrastructure — consumes IPAM pools, creates everything needed for a working underlay + overlay fabric (no services) - **ServiceGenerator** owns services — consumes VLANs, VNIs, and service IPs. No `CoreNumberPool` for VNIs; the generator computes them directly (L2: deterministic from VLAN ID, L3: sequential) ### VNI logic (in ServiceGenerator, no NumberPool) | Type | Formula | Example | |------|---------|---------| | L2 VNI | `100000 + vlan_id` | VLAN 40 → VNI 100040 | | L3 VNI | Sequential from `200001` | First VRF → 200001, second → 200002 | --- **All open questions from this issue are now resolved.** ✅ ### Final livrables checklist - [x] Choix du modèle de switch (7050SX3-48YC12) - [x] Limites fixées : 2-4 spines, leafs en paires, validation rules - [x] Schéma IPAM hiérarchique validé (2 supernets fixes, rest dynamique) - [x] Réponses aux questions ouvertes IPAM - [x] Scope défini : SiteGenerator / FabricGenerator / ServiceGenerator - [x] Convention de nommage des identifiers (incl. VNI) - [x] Documentation (`docs/fabric-standardization.md`)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
containerlab
Containerlab topology et configs
 epic
Epic / Phase de projet
 generator
Infrahub Generator Python code
 resource-manager
Resource Manager / IPAM pools
 schema
Modifications de schéma Infrahub
No Label epic
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Damien
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Damien/arista-evpn-vxlan-clab#31
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?