Damien/fabric-orchestrator
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects 1 Releases Wiki Activity

[Phase 2] Create Infrahub Object Files for Reference Topology Data #52

New Issue
Closed
opened 2026-02-13 19:26:21 +00:00 by Damien · 1 comment
Damien commented 2026-02-13 19:26:21 +00:00
Owner
Copy Link

Description

Créer les object files YAML pour charger les données de la topologie de référence EVPN-VXLAN dans Infrahub via l'entrée objects du .infrahub.yml. Les données sont extraites du repo arista-evpn-vxlan-clab qui contient les configs complètes des 10 devices.

Contexte

Infrahub supporte le chargement déclaratif de données via des Object Files au format :

---
apiVersion: infrahub.app/v1
kind: Object
spec:
  kind: InfraDevice
  data:
    - name: spine1
      role: spine
      platform: arista_eos

Ces fichiers sont référencés dans .infrahub.yml via la clé objects: et chargés automatiquement par Infrahub depuis le repo Git. C'est l'approche Infrastructure-as-Code idéale pour notre cas : les données de la topologie sont versionnées dans Git et synchronisées avec Infrahub.

Source de données

Les configs clab sont la source de vérité pour extraire les données :

  • configs/spine1.cfg, configs/spine2.cfg — Spines
  • configs/leaf1.cfg à configs/leaf8.cfg — Leafs
  • evpn-lab.clab.yml — Topologie physique (liens)
  • Document de référence : overlaid.net EVPN Configuration Example

Inventaire des objets à créer

1. Fondation (objects/01-foundation.yml)

Type Instances Données
InfraFabric 1 evpn-lab
InfraAutonomousSystem 5 AS 65000 (spines), 65001-65004 (leaf pairs)

2. Devices (objects/02-devices.yml)

Type Instances Données
InfraDevice 10 spine1-2, leaf1-8 (role, platform, fabric)

3. Interfaces (objects/03-interfaces.yml)

Type Instances Données clés
InterfaceLoopback 18 Lo0 (router-id) sur chaque device + Lo1 (VTEP) sur leafs
InterfaceEthernet 32+ Spine→Leaf p2p (16) + Leaf uplinks (16) + MLAG peer-links
InterfacePortChannel 8 Po999 (MLAG peer-link) sur chaque leaf
InterfaceVlan 16+ SVI 4090/4091 (MLAG) + SVI 34, 40, 78, 900 (services)

4. IP Addressing (objects/04-ipam.yml)

Type Instances Données
InfraIPAddress 50+ Loopbacks, P2P /31s, SVIs, virtual-router addresses

5. VLANs & VXLAN (objects/05-vlans-vxlan.yml)

Type Instances Données
InfraVLAN 6+ 40 (L2VNI), 34, 78, 900 (services), 4090/4091 (MLAG)
InfraVTEP 8 Un par leaf (4 paires partagent Lo1)
InfraVlanVniMapping ~4 VLAN 40→VNI 100040, etc.
InfraEVPNInstance ~2 L2 (VLAN 40) + L3 (VRF gold)

6. BGP (objects/06-bgp.yml)

Type Instances Données
InfraBGPRouterConfig 10 Un par device (ASN, router-id, distances)
InfraBGPPeerGroup ~28 underlay (8), underlay_ibgp (8), evpn (10+)
InfraBGPSession ~60 Underlay eBGP + iBGP + EVPN overlay
InfraBGPAddressFamily ~20 IPv4 unicast + EVPN

7. VRF (objects/07-vrfs.yml)

Type Instances Données
InfraVRFConfig 4 VRF gold sur leaf3-4, leaf7-8
InfraRouteTarget 2 1:100001 (import/export evpn)

8. MLAG (objects/08-mlag.yml)

Type Instances Données
InfraMLAGDomain 4 Un par paire leaf (domain-id, virtual-mac, peer-vlan)
InfraMLAGPeerConfig 8 Un par leaf (local_ip, peer_ip, peer_link)

Structure fichiers

objects/
├── 01-foundation.yml     # Fabric, ASNs
├── 02-devices.yml        # Devices
├── 03-interfaces.yml     # Toutes les interfaces
├── 04-ipam.yml           # IP addresses
├── 05-vlans-vxlan.yml    # VLANs, VTEPs, VNI mappings
├── 06-bgp.yml            # BGP router configs, peer groups, sessions
├── 07-vrfs.yml           # VRFs, route targets
└── 08-mlag.yml           # MLAG domains, peer configs

Mise à jour .infrahub.yml

schemas:
  - schemas/

objects:
  - objects/01-foundation.yml
  - objects/02-devices.yml
  - objects/03-interfaces.yml
  - objects/04-ipam.yml
  - objects/05-vlans-vxlan.yml
  - objects/06-bgp.yml
  - objects/07-vrfs.yml
  - objects/08-mlag.yml

menus:
  - menus/fabric-menu.yml

L'ordre est important : les objets sont chargés séquentiellement, donc les dépendances (devices avant interfaces, interfaces avant IPs, etc.) doivent être respectées.

Ordre de dépendance

01-foundation (Fabric, ASN)
  └→ 02-devices (référence Fabric + ASN)
       └→ 03-interfaces (référence Device)
            └→ 04-ipam (référence Interface)
       └→ 05-vlans-vxlan (référence Device)
       └→ 06-bgp (référence Device, Interface, ASN)
       └→ 07-vrfs (référence Device)
       └→ 08-mlag (référence Device, Interface)

Prérequis

  • Schema défini (#41 / PR #51)
  • Corrections critiques du schema (#43, #44, #45) — les objects ne pourront pas se charger sans les human_friendly_id uniques

Validation

# Charger manuellement pour tester
infrahubctl object load objects/01-foundation.yml
infrahubctl object load objects/02-devices.yml
# ... etc.

# Ou via le repo Git (après merge et connexion repo)
# Infrahub charge automatiquement les objects déclarés dans .infrahub.yml

Critères d'acceptation

  • Tous les object files chargent sans erreur dans Infrahub
  • Les 10 devices sont créés avec les bonnes relations
  • Les sessions BGP reflètent la topologie complète (underlay + overlay)
  • Les MLAG domains associent correctement les paires de leafs
  • Les VTEPs partagent les bonnes loopback Lo1 (shared IP par paire)
  • Le VRF gold est configuré sur les bons leafs avec L3VNI 100001
  • Les données correspondent aux configs du repo arista-evpn-vxlan-clab

Related

## Description Créer les **object files** YAML pour charger les données de la topologie de référence EVPN-VXLAN dans Infrahub via l'entrée `objects` du `.infrahub.yml`. Les données sont extraites du repo [arista-evpn-vxlan-clab](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab) qui contient les configs complètes des 10 devices. ## Contexte Infrahub supporte le chargement déclaratif de données via des [Object Files](https://docs.infrahub.app/guides/object-load) au format : ```yaml --- apiVersion: infrahub.app/v1 kind: Object spec: kind: InfraDevice data: - name: spine1 role: spine platform: arista_eos ``` Ces fichiers sont référencés dans `.infrahub.yml` via la clé `objects:` et chargés automatiquement par Infrahub depuis le repo Git. C'est l'approche **Infrastructure-as-Code** idéale pour notre cas : les données de la topologie sont versionnées dans Git et synchronisées avec Infrahub. ## Source de données Les configs clab sont la source de vérité pour extraire les données : - `configs/spine1.cfg`, `configs/spine2.cfg` — Spines - `configs/leaf1.cfg` à `configs/leaf8.cfg` — Leafs - `evpn-lab.clab.yml` — Topologie physique (liens) - Document de référence : [overlaid.net EVPN Configuration Example](https://overlaid.net/2019/01/27/arista-bgp-evpn-configuration-example/) ## Inventaire des objets à créer ### 1. Fondation (`objects/01-foundation.yml`) | Type | Instances | Données | |------|-----------|---------| | `InfraFabric` | 1 | `evpn-lab` | | `InfraAutonomousSystem` | 5 | AS 65000 (spines), 65001-65004 (leaf pairs) | ### 2. Devices (`objects/02-devices.yml`) | Type | Instances | Données | |------|-----------|---------| | `InfraDevice` | 10 | spine1-2, leaf1-8 (role, platform, fabric) | ### 3. Interfaces (`objects/03-interfaces.yml`) | Type | Instances | Données clés | |------|-----------|------| | `InterfaceLoopback` | 18 | Lo0 (router-id) sur chaque device + Lo1 (VTEP) sur leafs | | `InterfaceEthernet` | 32+ | Spine→Leaf p2p (16) + Leaf uplinks (16) + MLAG peer-links | | `InterfacePortChannel` | 8 | Po999 (MLAG peer-link) sur chaque leaf | | `InterfaceVlan` | 16+ | SVI 4090/4091 (MLAG) + SVI 34, 40, 78, 900 (services) | ### 4. IP Addressing (`objects/04-ipam.yml`) | Type | Instances | Données | |------|-----------|---------| | `InfraIPAddress` | 50+ | Loopbacks, P2P /31s, SVIs, virtual-router addresses | ### 5. VLANs & VXLAN (`objects/05-vlans-vxlan.yml`) | Type | Instances | Données | |------|-----------|---------| | `InfraVLAN` | 6+ | 40 (L2VNI), 34, 78, 900 (services), 4090/4091 (MLAG) | | `InfraVTEP` | 8 | Un par leaf (4 paires partagent Lo1) | | `InfraVlanVniMapping` | ~4 | VLAN 40→VNI 100040, etc. | | `InfraEVPNInstance` | ~2 | L2 (VLAN 40) + L3 (VRF gold) | ### 6. BGP (`objects/06-bgp.yml`) | Type | Instances | Données | |------|-----------|---------| | `InfraBGPRouterConfig` | 10 | Un par device (ASN, router-id, distances) | | `InfraBGPPeerGroup` | ~28 | `underlay` (8), `underlay_ibgp` (8), `evpn` (10+) | | `InfraBGPSession` | ~60 | Underlay eBGP + iBGP + EVPN overlay | | `InfraBGPAddressFamily` | ~20 | IPv4 unicast + EVPN | ### 7. VRF (`objects/07-vrfs.yml`) | Type | Instances | Données | |------|-----------|---------| | `InfraVRFConfig` | 4 | VRF `gold` sur leaf3-4, leaf7-8 | | `InfraRouteTarget` | 2 | `1:100001` (import/export evpn) | ### 8. MLAG (`objects/08-mlag.yml`) | Type | Instances | Données | |------|-----------|---------| | `InfraMLAGDomain` | 4 | Un par paire leaf (domain-id, virtual-mac, peer-vlan) | | `InfraMLAGPeerConfig` | 8 | Un par leaf (local_ip, peer_ip, peer_link) | ## Structure fichiers ``` objects/ ├── 01-foundation.yml # Fabric, ASNs ├── 02-devices.yml # Devices ├── 03-interfaces.yml # Toutes les interfaces ├── 04-ipam.yml # IP addresses ├── 05-vlans-vxlan.yml # VLANs, VTEPs, VNI mappings ├── 06-bgp.yml # BGP router configs, peer groups, sessions ├── 07-vrfs.yml # VRFs, route targets └── 08-mlag.yml # MLAG domains, peer configs ``` ## Mise à jour `.infrahub.yml` ```yaml schemas: - schemas/ objects: - objects/01-foundation.yml - objects/02-devices.yml - objects/03-interfaces.yml - objects/04-ipam.yml - objects/05-vlans-vxlan.yml - objects/06-bgp.yml - objects/07-vrfs.yml - objects/08-mlag.yml menus: - menus/fabric-menu.yml ``` L'ordre est important : les objets sont chargés séquentiellement, donc les dépendances (devices avant interfaces, interfaces avant IPs, etc.) doivent être respectées. ## Ordre de dépendance ``` 01-foundation (Fabric, ASN) └→ 02-devices (référence Fabric + ASN) └→ 03-interfaces (référence Device) └→ 04-ipam (référence Interface) └→ 05-vlans-vxlan (référence Device) └→ 06-bgp (référence Device, Interface, ASN) └→ 07-vrfs (référence Device) └→ 08-mlag (référence Device, Interface) ``` ## Prérequis - [x] Schema défini (#41 / PR #51) - [ ] Corrections critiques du schema (#43, #44, #45) — les objects ne pourront pas se charger sans les `human_friendly_id` uniques ## Validation ```bash # Charger manuellement pour tester infrahubctl object load objects/01-foundation.yml infrahubctl object load objects/02-devices.yml # ... etc. # Ou via le repo Git (après merge et connexion repo) # Infrahub charge automatiquement les objects déclarés dans .infrahub.yml ``` ## Critères d'acceptation - [ ] Tous les object files chargent sans erreur dans Infrahub - [ ] Les 10 devices sont créés avec les bonnes relations - [ ] Les sessions BGP reflètent la topologie complète (underlay + overlay) - [ ] Les MLAG domains associent correctement les paires de leafs - [ ] Les VTEPs partagent les bonnes loopback Lo1 (shared IP par paire) - [ ] Le VRF `gold` est configuré sur les bons leafs avec L3VNI 100001 - [ ] Les données correspondent aux configs du repo `arista-evpn-vxlan-clab` ## Related - Depends on: #41 (Schema), #43 (BGP human_friendly_id fix), #44 (VTEP dedup), #45 (VLAN unique) - Source: https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab - Enables: #42 (Infrahub Client), #30 (Transforms) - Doc: https://docs.infrahub.app/guides/object-load
Damien added the phase-2-minimal-reconciler label 2026-02-13 19:26:32 +00:00
Damien commented 2026-02-27 12:25:08 +00:00
Author
Owner
Copy Link

Done directly on main Arista VXLAN Repository

Done directly on main[ Arista VXLAN Repository](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
documentation
Documentation tasks
 phase-1-yang-discovery
Phase 1: YANG Path Discovery and Validation
 phase-2-minimal-reconciler
Phase 2: Minimal Reconciler (VLANs, VNIs)
 phase-3-full-fabric
Phase 3: Full Fabric Coverage (BGP, MLAG, VRFs)
 phase-4-event-driven
Phase 4: Event-Driven Automation and CLI
 research
Research and investigation tasks
No Label phase-2-minimal-reconciler
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/fabric-orchestrator#52
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?