Support BGP sessions in VRF context (BGP VRF peering) #50

New Issue

Damien · 2026-02-13T10:43:36Z

Damien commented

2026-02-13 10:43:36 +00:00

Problem

The current schema models BGPSession exclusively under BGPRouterConfig (global BGP process). However, the reference topology includes BGP peerings within a VRF context, specifically:

leaf7/leaf8: neighbor 10.90.90.1 remote-as 64999 under vrf gold in router bgp 65004

This is a common pattern in EVPN-VXLAN fabrics where border leafs peer with external routers (firewalls, WAN routers, etc.) inside a tenant VRF to inject routes (e.g. default route) that are then distributed across the EVPN overlay.

Current Limitation

BGPSession is scoped under BGPRouterConfig which represents the global BGP process. There is no way to associate a BGP session with a specific VRF, making it impossible to model:

router bgp 65004
  vrf gold
    neighbor 10.90.90.1 remote-as 64999
    redistribute connected
    address-family ipv4
      neighbor 10.90.90.1 activate

Proposed Solution

Two approaches are possible:

Option A — Add optional `vrf` relation on `BGPSession`

Add a Relationship from BGPSession to VRFConfig (optional, cardinality one)
When vrf is set, the session is rendered under the VRF block in the BGP config
When vrf is null, the session belongs to the global BGP process (current behavior)
Pro: minimal schema change, backward compatible
Con: less structured, VRF-specific BGP settings (rd, route-target, redistribute) remain on VRFConfig

Option B — Create a `BGPVRFConfig` node

New node BGPVRFConfig with relations to VRFConfig and BGPRouterConfig
BGPVRFConfig owns VRF-scoped BGP sessions, rd, route-targets, redistribute policies
BGP sessions under a VRF become children of BGPVRFConfig
Pro: cleaner separation of global vs VRF BGP config, extensible
Con: more schema nodes, more complex data loading

Recommendation

Option A is simpler and sufficient for the current topology. It can be evolved to Option B later if needed. The VRF-level BGP attributes (rd, route-target) are already on VRFConfig / EVPNInstance, so only the session placement is missing.

Reference Config (from overlaid.net topology)

# leaf7
router bgp 65004
   vrf gold
      rd 10.0.250.18:1
      route-target import evpn 1:100001
      route-target export evpn 1:100001
      neighbor 10.90.90.1 remote-as 64999
      redistribute connected
      address-family ipv4
         neighbor 10.90.90.1 activate

Acceptance Criteria

A BGP session can be associated with a VRF
VRF BGP sessions are distinguishable from global BGP sessions
The leaf7/leaf8 → AS 64999 peering in VRF gold can be modeled
Schema validates with infrahubctl schema check
Data for the reference topology loads successfully

Reference topology: overlaid.net EVPN configuration example
Branch: feature/41-infrahub-schema

## Problem The current schema models `BGPSession` exclusively under `BGPRouterConfig` (global BGP process). However, the reference topology includes BGP peerings **within a VRF context**, specifically: - **leaf7/leaf8**: `neighbor 10.90.90.1 remote-as 64999` under `vrf gold` in `router bgp 65004` This is a common pattern in EVPN-VXLAN fabrics where border leafs peer with external routers (firewalls, WAN routers, etc.) inside a tenant VRF to inject routes (e.g. default route) that are then distributed across the EVPN overlay. ## Current Limitation `BGPSession` is scoped under `BGPRouterConfig` which represents the global BGP process. There is no way to associate a BGP session with a specific VRF, making it impossible to model: ``` router bgp 65004 vrf gold neighbor 10.90.90.1 remote-as 64999 redistribute connected address-family ipv4 neighbor 10.90.90.1 activate ``` ## Proposed Solution Two approaches are possible: ### Option A — Add optional `vrf` relation on `BGPSession` - Add a `Relationship` from `BGPSession` to `VRFConfig` (optional, cardinality one) - When `vrf` is set, the session is rendered under the VRF block in the BGP config - When `vrf` is null, the session belongs to the global BGP process (current behavior) - **Pro**: minimal schema change, backward compatible - **Con**: less structured, VRF-specific BGP settings (rd, route-target, redistribute) remain on `VRFConfig` ### Option B — Create a `BGPVRFConfig` node - New node `BGPVRFConfig` with relations to `VRFConfig` and `BGPRouterConfig` - `BGPVRFConfig` owns VRF-scoped BGP sessions, rd, route-targets, redistribute policies - BGP sessions under a VRF become children of `BGPVRFConfig` - **Pro**: cleaner separation of global vs VRF BGP config, extensible - **Con**: more schema nodes, more complex data loading ## Recommendation **Option A** is simpler and sufficient for the current topology. It can be evolved to Option B later if needed. The VRF-level BGP attributes (rd, route-target) are already on `VRFConfig` / `EVPNInstance`, so only the session placement is missing. ## Reference Config (from overlaid.net topology) ``` # leaf7 router bgp 65004 vrf gold rd 10.0.250.18:1 route-target import evpn 1:100001 route-target export evpn 1:100001 neighbor 10.90.90.1 remote-as 64999 redistribute connected address-family ipv4 neighbor 10.90.90.1 activate ``` ## Acceptance Criteria - [x] A BGP session can be associated with a VRF - [x] VRF BGP sessions are distinguishable from global BGP sessions - [x] The leaf7/leaf8 → AS 64999 peering in VRF gold can be modeled - [x] Schema validates with `infrahubctl schema check` - [x] Data for the reference topology loads successfully ## Related - Reference topology: overlaid.net EVPN configuration example - Branch: `feature/41-infrahub-schema`

Damien added reference feature/41-infrahub-schema

2026-02-13 10:49:22 +00:00

Damien added this to the Fabric Orchestrator project 2026-02-13 10:49:36 +00:00

Damien added the phase-2-minimal-reconciler label 2026-02-13 10:49:46 +00:00

Damien moved this to In Progress in Fabric Orchestrator on 2026-02-13 10:49:53 +00:00

Damien referenced this issue from a commit

2026-02-13 14:06:32 +00:00

fix(schema): add optional VRF relation on BGPSession — refs #50

Damien commented

2026-02-13 14:09:53 +00:00

Implémenté ✅

Commit: e32da46

Changements dans `schemas/bgp.yml` — BGPSession

Ajout relation vrf → InfraVRF (kind: Attribute, cardinality: one, optional: true)
Quand vrf est null : session dans le processus BGP global (comportement existant)
Quand vrf est défini : session dans le contexte VRF (ex: leaf7 → AS 64999 dans VRF gold)

Option A retenue comme recommandé dans l'issue.

Validation

Schema check passé. Le peering border leaf7/8 → AS 64999 dans VRF gold est maintenant modélisable.

## Implémenté ✅ **Commit:** [`e32da46`](https://gitea.arnodo.fr/Damien/fabric-orchestrator/commit/e32da46bd7b44ccda5194b91c6bbf89bc54aafc2) ### Changements dans `schemas/bgp.yml` — BGPSession - Ajout relation `vrf` → `InfraVRF` (kind: Attribute, cardinality: one, optional: true) - Quand `vrf` est null : session dans le processus BGP global (comportement existant) - Quand `vrf` est défini : session dans le contexte VRF (ex: leaf7 → AS 64999 dans VRF gold) **Option A retenue** comme recommandé dans l'issue. ### Validation Schema check passé. Le peering border leaf7/8 → AS 64999 dans VRF gold est maintenant modélisable.

Damien referenced this issue

2026-02-13 19:25:36 +00:00

[Phase 2] Define Infrahub Schema for EVPN-VXLAN Fabric #51

Damien closed this issue

2026-02-13 19:36:45 +00:00

Damien moved this to Done in Fabric Orchestrator on 2026-02-25 13:59:11 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Damien/fabric-orchestrator#50

Support BGP sessions in VRF context (BGP VRF peering) #50