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
Copy Source

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
Copy Source

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
Copy Source

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
Copy Source

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
 telemetry
monitoring configuration with prometheus and grafana
No labels epic
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
Damien (Damien Arnodo)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Damien/arista-evpn-vxlan-clab#31