From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 1ADE01FF178 for ; Mon, 15 Dec 2025 10:31:37 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 543025153; Mon, 15 Dec 2025 10:32:21 +0100 (CET) Date: Mon, 15 Dec 2025 10:32:17 +0100 From: Gabriel Goller To: Thomas Lamprecht Message-ID: Mail-Followup-To: Thomas Lamprecht , "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" References: <20251121141446.349501-1-g.goller@proxmox.com> <9fcb92c222a931110010ae0be8d102cb4194ec99.camel@groupe-cyllene.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20241002-35-39f9a6 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1765791130145 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.003 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 Subject: Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1 X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Cc: "pve-devel@lists.proxmox.com" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 15.12.2025 08:57, Thomas Lamprecht wrote: [snip] > > FRR updates always had regression, when I had implement evpn I had > > regression with 7.5,7.6,7.8,8.0,8.1 as far I remember. > > > > so, you really don't need to big gap to have problem, it's occur all > > time (I don't known, they don't seem to have automatic test on readl > > infra) > > Maybe something Gabriel could look into, as I'd prefer upstream testing > more over us testing more, while both are required, the former helps every > FRR user and should avoid some redundant effort. Testing frr is inherently difficult. Upstream has extensive topotests (integration tests with containerized network infrastructures) that are mandatory for all new features and bugfixes. However, routing protocols are (at least in frr) unfortunately non-deterministic -- even bgp route selection can vary between runs. For example, these are the recent frr regressions we've encountered (since 8.5) (that I know about -- could be that I forgot some): - BGP BFD peers failing to establish sessions (bfd bug, backported by Stefan) - EVPN type-5 routes not being installed (bgpd race condition, backported by me) Both have not been catched by the upstream integration tests and both where not easily reproducable (flaky). They don't even have a topotest right now, because we weren't able to write one that makes sense (without inserting random sleeps or lua scripts that sleep inside of frr). Nevertheless we're trying to write some integration tests using full PVE clusters with specific SDN topologies. While these probably won't catch frr bugs directly, they provide us a reference to test against. > > here we go again.... :/ > > > > https://forum.proxmox.com/threads/frr-update-to-10-4-1-1-broke-external-routing.177736/ > > This specific issue seems to have been our fault though :/ Looks like it was the users fault :) > >>> The maintainers have told me this should improve going forward. > > > > don't trust them ;) > > Hmm, I really get that you have been burned a bit too often by them, > but IMO the only good possibility to improve on their releases for our > users in the mid/longterm is to more frequently update in smaller steps, > and then give feedback or (cherry-pick) fixes back. And with Gabriel we > now have a depth that is a bit more involved with upstream, so I have more > confidence in that working out, albeit I certainly do not expect wonders > (quickly). > > In any case, we'll certainly move FRR updates, especially those for new > releases along more slowly. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel