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 D307E1FF165 for ; Thu, 9 Oct 2025 14:18:31 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id F2D221E90A; Thu, 9 Oct 2025 14:18:31 +0200 (CEST) Message-ID: Date: Thu, 9 Oct 2025 14:17:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Julien OHAYON References: <7B6E9EB5-6BFE-43FF-B44E-7CF030A938D0@xoxo.fr> <5E57AFD5-8F5C-44AF-BC8C-6D38563C15C0@xoxo.fr> Content-Language: en-US From: Stefan Hanreich In-Reply-To: <5E57AFD5-8F5C-44AF-BC8C-6D38563C15C0@xoxo.fr> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.714 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-User] OSPF when migrating from v8 to v9 X-BeenThere: pve-user@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE user list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE user list Cc: Proxmox VE user list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-user-bounces@lists.proxmox.com Sender: "pve-user" On 10/8/25 12:47 PM, Julien OHAYON wrote: > My concern is during the migration: if I configure OSPF on a node running v9, will this have an impact on the nodes still running v8? This one is a bit tricky to answer because of a change in the reload endpoint between 8 and 9. The behavior depends on certain factors (which node initiates the reload, how your SDN configuration looks like, ...). This is due to the introduction of an additional API parameter that is incompatible with PVE 8.x instances. For that reason, we recommend only mixing major versions in a cluster while performing an upgrade, not for prolonged periods of time. We do *not* recommend doing any configuration changes while your cluster is on mixed major versions. Problems like this can occur due to changes between major versions and we cannot guarantee correct behavior while your cluster is running on mixed major versions. That being said, upgrading from 8 to 9 alone should not cause your custom /etc/frr/daemons file to get overwritten - since the SDN stack only writes to it when re-generating the configuration (= applying the SDN configuration). If you upgrade from an earlier FRR version (8), then you would get a prompt that the daemons file changed, asking you to review you the changes - like so: Configuration file '/etc/frr/daemons' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** daemons (Y/I/N/O/D/Z) [default=N] ? Upgrading from 10.2 (with ospfd=yes) does not cause a prompt to appear and the daemons file stays untouched. I've also verified this right now by upgrading a PVE 8 instance with ospfd=yes in its daemon file. Upgrading itself did not overwrite the directive in the daemons file - only reapplying the SDN configuration does set it to ospfd=no. So, as long as you do not re-apply the SDN configuration in any way, your OSPF directive in the daemons file stays untouched. On PVE9, when applying a SDN configuration that contains either a fabric or an EVPN controller will overwrite the FRR configuration (including the daemons file). _______________________________________________ pve-user mailing list pve-user@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-user