Re: [PATCH proxmox-ve-rs v2 1/7] sdn: fabric: add BGP protocol support

[Gabriel Goller <g.goller@proxmox.com>]

On 16.04.2026 14:46, Hannes Laimer wrote:
> On 2026-04-16 11:16, Gabriel Goller wrote:
> > On 15.04.2026 13:11, Hannes Laimer wrote:
> >> From: Stefan Hanreich <s.hanreich@proxmox.com>
> >>
> >> Add BGP as a fabric protocol for eBGP unnumbered underlays. Each node
> >> has a mandatory, globally unique ASN for interface-based eBGP peering.
> >>
> >> Unlike OSPF and OpenFabric, BGP does not have its own FRR daemon -
> > 
> > This is a bit wrong, BGP has its own frr daemon, maybe rewrite this as "the bgp
> > router is not exclusive to the bgp fabric"?
> 
> yeah, will improve in v3, thanks!
> 
> > 
> >> the fabric config needs to coexist with EVPN in a single 'router bgp'
> >> block. To handle this, the fabric merges into an existing router
> >> rather than replacing it, using local-as to present the per-node ASN
> >> to underlay peers when the router already runs under the EVPN ASN.
> >>
> >> For IPv6-only nodes, the BGP router-id is derived from the IPv6
> >> address using FNV-1a, since router-id must be a 32-bit value.
> > 
> > Hmm this is a bit weird since the generated address is not really reachable
> > right?
> 
> I mean, the route-id shares a format with ipv4 addresses, but it's not
> supposed to be ip reachable. In perl we use part of the mac, for the
> router-id if we don't have an ipv4 address. We can't really in rust, and
> this seemed like a good(maybe better? cause macs may change) approach.
> 
> > 
> > How do we handle this (frr bgp docs)?:
> > 
> >  To derive system-IP and anycast-IP, the default BGP instance’s router-id is
> >  used as system-IP and the VxLAN interface’s local tunnel IP as the anycast-IP.
> > 
> > 
> > Would it be stupid to select a ipv4 address, set it on the lo interface and then
> > just use update-source and set the ipv6 address?
> > 
> 
> hmm, good point actually, we need v4 reachability(at least for now),
> just putting the derived router-id as an ipv4 address on the lo should
> work. just not super sure if this is more on the actually common or
> actually weird side of things... but I like the idea
> But I don't think we should do this generally when creating a bgp
> fabric, needing the router-id to be reachable is more of an EVPN
> specific requirement I think
> 
> the alternative would be to require a configured v4 prefix on fabrics if
> used for EVPN
> 
> either way it's more of an EVPN, than fabric, concern I think

Had a look at this again and spoke with Stefan:
We always set the anycast ip and anycast mac address explicitly on the bridge,
so we don't rely on this behavior. So the ip doesn't need to be reachable.

Note that it's used in the bgp route-selection process though, so e.g. when
having two exit-nodes peering with some other bgp nodes, the other nodes
will select the nexthop based on the lowest router-id (because all the other
properties are the same.)

But if the router-id is generated from the ipv6 address it should be stable and
this shouldn't be an issue.

We could fix this with some route-maps and loc-pref stuff but that's not so
important right now.

> >> Co-authored-by: Hannes Laimer <h.laimer@proxmox.com>
> >> Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
> >> Signed-off-by: Hannes Laimer <h.laimer@proxmox.com>
> > 
> > Maybe a few more tests with other existing fabrics, e.g. ospf and openfabric?
> > These are quite easy to add, so adding a few more won't hurt.