From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 726941FF13E for ; Fri, 17 Apr 2026 13:22:19 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7012C1EC4E; Fri, 17 Apr 2026 13:22:18 +0200 (CEST) Date: Fri, 17 Apr 2026 13:22:13 +0200 From: Gabriel Goller To: Hannes Laimer Subject: Re: [PATCH proxmox-ve-rs v2 1/7] sdn: fabric: add BGP protocol support Message-ID: Mail-Followup-To: Hannes Laimer , pve-devel@lists.proxmox.com References: <20260415111134.124720-1-h.laimer@proxmox.com> <20260415111134.124720-2-h.laimer@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20241002-35-39f9a6 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1776424853227 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.027 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 6PX2NLQHIKMPC2RBVHIOL3W4QBXCFAGH X-Message-ID-Hash: 6PX2NLQHIKMPC2RBVHIOL3W4QBXCFAGH X-MailFrom: g.goller@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 > >> > >> 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 > >> Signed-off-by: Stefan Hanreich > >> Signed-off-by: Hannes Laimer > > > > 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.