[pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1

[pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1

[Gabriel Goller]

Bump FRR to 10.4.1, we do this for two reasons:
 * we can drop two patches, which have been merged upstream
 * fix the libyang errors in the journal
 * try to update a bit more frequently (maybe always one minor version behind
   upstream would be nice), so that we can avoid the fallout of updating two
   major versions (8->10) again.

Went through the changelog quite thoroughly, didn't find anything that could
cause an issue. Tested it on a few clusters I had lying around (ospf,
fabricd(ip4 and ip6), bgp+evpn) and didn't notice anything off. Stefan said
he'd test on his clusters next week as well. Would be nice if we get it in
early so that we have a nice long testing period.

frr:

Gabriel Goller (2):
  bump frr to 10.4.1, remove obsolete patches
  d/changelog: bump package version

 debian/changelog                              |   6 +
 ...ummy_as_loopback-option-per-default.patch} |   0
 ...A_IF_DUMMY-flag-for-dummy-interfaces.patch | 125 -----------
 ...on-to-treat-dummy-interfaces-as-loop.patch | 206 ------------------
 ...dd-dependancy-to-networking.service.patch} |   0
 ...-starting-order-for-debian-packages.patch} |   0
 debian/patches/series                         |   8 +-
 frr                                           |   2 +-
 8 files changed, 10 insertions(+), 337 deletions(-)
 rename debian/patches/pve/{0006-fabricd-enable-dummy_as_loopback-option-per-default.patch => 0004-fabricd-enable-dummy_as_loopback-option-per-default.patch} (100%)
 delete mode 100644 debian/patches/pve/0004-zebra-add-ZEBRA_IF_DUMMY-flag-for-dummy-interfaces.patch
 delete mode 100644 debian/patches/pve/0005-fabricd-add-option-to-treat-dummy-interfaces-as-loop.patch
 rename debian/patches/pve/{0007-systemd-add-dependancy-to-networking.service.patch => 0005-systemd-add-dependancy-to-networking.service.patch} (100%)
 rename debian/patches/pve/{0007-tools-fix-daemon-starting-order-for-debian-packages.patch => 0006-tools-fix-daemon-starting-order-for-debian-packages.patch} (100%)


Summary over all repositories:
  8 files changed, 10 insertions(+), 337 deletions(-)

-- 
Generated by git-murpp 0.8.0


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH frr 1/2] bump frr to 10.4.1, remove obsolete patches

[Gabriel Goller]

Bump the frr source to 10.4.1 (now that 10.5.0 has been released
upstream). This allows us to drop the fabricd dummy-as-loopback patches
as these have been merged upstream. This bump will also fix the libyang
errors in the journal (https://bugzilla.proxmox.com/show_bug.cgi?id=6968).

Fixes: #6968
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
---
 ...ummy_as_loopback-option-per-default.patch} |   0
 ...A_IF_DUMMY-flag-for-dummy-interfaces.patch | 125 -----------
 ...on-to-treat-dummy-interfaces-as-loop.patch | 206 ------------------
 ...dd-dependancy-to-networking.service.patch} |   0
 ...-starting-order-for-debian-packages.patch} |   0
 debian/patches/series                         |   8 +-
 frr                                           |   2 +-
 7 files changed, 4 insertions(+), 337 deletions(-)
 rename debian/patches/pve/{0006-fabricd-enable-dummy_as_loopback-option-per-default.patch => 0004-fabricd-enable-dummy_as_loopback-option-per-default.patch} (100%)
 delete mode 100644 debian/patches/pve/0004-zebra-add-ZEBRA_IF_DUMMY-flag-for-dummy-interfaces.patch
 delete mode 100644 debian/patches/pve/0005-fabricd-add-option-to-treat-dummy-interfaces-as-loop.patch
 rename debian/patches/pve/{0007-systemd-add-dependancy-to-networking.service.patch => 0005-systemd-add-dependancy-to-networking.service.patch} (100%)
 rename debian/patches/pve/{0007-tools-fix-daemon-starting-order-for-debian-packages.patch => 0006-tools-fix-daemon-starting-order-for-debian-packages.patch} (100%)

diff --git a/debian/patches/pve/0006-fabricd-enable-dummy_as_loopback-option-per-default.patch b/debian/patches/pve/0004-fabricd-enable-dummy_as_loopback-option-per-default.patch
similarity index 100%
rename from debian/patches/pve/0006-fabricd-enable-dummy_as_loopback-option-per-default.patch
rename to debian/patches/pve/0004-fabricd-enable-dummy_as_loopback-option-per-default.patch
diff --git a/debian/patches/pve/0004-zebra-add-ZEBRA_IF_DUMMY-flag-for-dummy-interfaces.patch b/debian/patches/pve/0004-zebra-add-ZEBRA_IF_DUMMY-flag-for-dummy-interfaces.patch
deleted file mode 100644
index 3c0df893236a..000000000000
--- a/debian/patches/pve/0004-zebra-add-ZEBRA_IF_DUMMY-flag-for-dummy-interfaces.patch
+++ /dev/null
@@ -1,125 +0,0 @@
-From 7cf60fd0bdaa45311eea886cee6d1f290a4ac2d2 Mon Sep 17 00:00:00 2001
-From: Gabriel Goller <g.goller@proxmox.com>
-Date: Tue, 25 Feb 2025 10:13:34 +0100
-Subject: [PATCH] zebra: add ZEBRA_IF_DUMMY flag for dummy interfaces
-
-Introduce ZEBRA_IF_DUMMY interface flag to identify Linux dummy interfaces [0].
-These interfaces behave similarly to loopback interfaces and can be
-specially handled by daemons.
-
-[0]: https://github.com/torvalds/linux/blob/master/drivers/net/dummy.c
-
-Link: https://github.com/FRRouting/frr/pull/18242
-Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
----
- lib/if.h               | 1 +
- zebra/if_netlink.c     | 3 +++
- zebra/interface.c      | 7 +++++++
- zebra/interface.h      | 6 +++++-
- zebra/zebra_nb_state.c | 3 +++
- 5 files changed, 19 insertions(+), 1 deletion(-)
-
-Index: b/lib/if.h
-===================================================================
---- a/lib/if.h	2025-03-07 11:09:47.571424092 +0100
-+++ b/lib/if.h	2025-03-07 11:09:47.568424088 +0100
-@@ -242,6 +242,7 @@
- #define ZEBRA_INTERFACE_SUB        (1 << 1)
- #define ZEBRA_INTERFACE_LINKDETECTION (1 << 2)
- #define ZEBRA_INTERFACE_VRF_LOOPBACK (1 << 3)
-+#define ZEBRA_INTERFACE_DUMMY (1 << 4)
- 
- 	/* Interface flags. */
- 	uint64_t flags;
-Index: b/zebra/if_netlink.c
-===================================================================
---- a/zebra/if_netlink.c	2025-03-07 11:09:47.571424092 +0100
-+++ b/zebra/if_netlink.c	2025-03-07 11:09:47.568424088 +0100
-@@ -221,6 +221,8 @@
- 		*zif_type = ZEBRA_IF_BOND;
- 	else if (strcmp(kind, "gre") == 0)
- 		*zif_type = ZEBRA_IF_GRE;
-+	else if (strcmp(kind, "dummy") == 0)
-+		*zif_type = ZEBRA_IF_DUMMY;
- }
- 
- static void netlink_vrf_change(struct nlmsghdr *h, struct rtattr *tb,
-@@ -576,6 +578,7 @@
- 	case ZEBRA_IF_MACVLAN:
- 	case ZEBRA_IF_VETH:
- 	case ZEBRA_IF_BOND:
-+	case ZEBRA_IF_DUMMY:
- 		break;
- 	}
- }
-Index: b/zebra/interface.c
-===================================================================
---- a/zebra/interface.c	2025-03-07 11:09:47.571424092 +0100
-+++ b/zebra/interface.c	2025-03-07 11:09:47.568424088 +0100
-@@ -584,6 +584,9 @@
- 
- 	zebra_interface_add_update(ifp);
- 
-+	if (IS_ZEBRA_IF_DUMMY(ifp))
-+		SET_FLAG(ifp->status, ZEBRA_INTERFACE_DUMMY);
-+
- 	if (!CHECK_FLAG(ifp->status, ZEBRA_INTERFACE_ACTIVE)) {
- 		SET_FLAG(ifp->status, ZEBRA_INTERFACE_ACTIVE);
- 
-@@ -1646,6 +1649,7 @@
- 	case ZEBRA_IF_MACVLAN:
- 	case ZEBRA_IF_VETH:
- 	case ZEBRA_IF_BOND:
-+	case ZEBRA_IF_DUMMY:
- 		break;
- 	}
- }
-@@ -2398,6 +2402,9 @@
- 	case ZEBRA_IF_GRE:
- 		return "GRE";
- 
-+	case ZEBRA_IF_DUMMY:
-+		return "dummy";
-+
- 	default:
- 		return "Unknown";
- 	}
-Index: b/zebra/interface.h
-===================================================================
---- a/zebra/interface.h	2025-03-07 11:09:47.571424092 +0100
-+++ b/zebra/interface.h	2025-03-07 11:09:47.569424090 +0100
-@@ -39,7 +39,8 @@
- 	ZEBRA_IF_MACVLAN,   /* MAC VLAN interface*/
- 	ZEBRA_IF_VETH,      /* VETH interface*/
- 	ZEBRA_IF_BOND,	    /* Bond */
--	ZEBRA_IF_GRE,      /* GRE interface */
-+	ZEBRA_IF_GRE,       /* GRE interface */
-+	ZEBRA_IF_DUMMY,     /* Dummy interface */
- };
- 
- /* Zebra "slave" interface type */
-@@ -246,6 +247,9 @@
- #define IS_ZEBRA_IF_GRE(ifp)                                               \
- 	(((struct zebra_if *)(ifp->info))->zif_type == ZEBRA_IF_GRE)
- 
-+#define IS_ZEBRA_IF_DUMMY(ifp)                                               \
-+	(((struct zebra_if *)(ifp->info))->zif_type == ZEBRA_IF_DUMMY)
-+
- #define IS_ZEBRA_IF_BRIDGE_SLAVE(ifp)					\
- 	(((struct zebra_if *)(ifp->info))->zif_slave_type                      \
- 	 == ZEBRA_IF_SLAVE_BRIDGE)
-Index: b/zebra/zebra_nb_state.c
-===================================================================
---- a/zebra/zebra_nb_state.c	2025-03-07 11:09:47.571424092 +0100
-+++ b/zebra/zebra_nb_state.c	2025-03-07 11:09:47.569424090 +0100
-@@ -87,6 +87,9 @@
- 	case ZEBRA_IF_GRE:
- 		type = "frr-zebra:zif-gre";
- 		break;
-+	case ZEBRA_IF_DUMMY:
-+		type = "frr-zebra:zif-dummy";
-+		break;
- 	}
- 
- 	if (!type)
-
diff --git a/debian/patches/pve/0005-fabricd-add-option-to-treat-dummy-interfaces-as-loop.patch b/debian/patches/pve/0005-fabricd-add-option-to-treat-dummy-interfaces-as-loop.patch
deleted file mode 100644
index eb7e4a03dd81..000000000000
--- a/debian/patches/pve/0005-fabricd-add-option-to-treat-dummy-interfaces-as-loop.patch
+++ /dev/null
@@ -1,206 +0,0 @@
-From 99aab947f7b89b31f08ba9ccf755ff60af9005a8 Mon Sep 17 00:00:00 2001
-From: Gabriel Goller <g.goller@proxmox.com>
-Date: Tue, 25 Feb 2025 10:24:58 +0100
-Subject: [PATCH] fabricd: add option to treat dummy interfaces as loopback
- interfaces
-
-Enable dummy-interfaces to be used as router-id interfaces in openfabric
-networks. This allows multiple openfabric routers with different
-router-ids on a single node when using IP unnumbered setup (interfaces
-without IPs configured). Previously we were limited by having a single
-loopback interface, allowing only one openfabric router per node.
-
-Link: https://github.com/FRRouting/frr/pull/18242
-Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
----
- doc/manpages/frr-fabricd.rst |  4 ++++
- doc/user/fabricd.rst         | 17 ++++++++++++-----
- isisd/isis_circuit.c         |  9 +++++----
- isisd/isis_main.c            | 16 +++++++++++++---
- isisd/isisd.c                | 19 +++++++++++++++++++
- isisd/isisd.h                |  6 +++++-
- 6 files changed, 58 insertions(+), 13 deletions(-)
-
-Index: b/doc/manpages/frr-fabricd.rst
-===================================================================
---- a/doc/manpages/frr-fabricd.rst	2025-03-07 11:09:47.700424235 +0100
-+++ b/doc/manpages/frr-fabricd.rst	2025-03-07 11:09:47.698424233 +0100
-@@ -21,6 +21,10 @@
- 
- .. include:: common-options.rst
- 
-+.. option:: --dummy_as_loopback
-+
-+   Treat dummy interfaces as loopback interfaces.
-+
- FILES
- =====
- 
-Index: b/doc/user/fabricd.rst
-===================================================================
---- a/doc/user/fabricd.rst	2025-03-07 11:09:47.700424235 +0100
-+++ b/doc/user/fabricd.rst	2025-03-07 11:09:47.698424233 +0100
-@@ -15,11 +15,18 @@
- Configuring fabricd
- ===================
- 
--There are no *fabricd* specific options. Common options can be specified
--(:ref:`common-invocation-options`) to *fabricd*. *fabricd* needs to acquire
--interface information from *zebra* in order to function. Therefore *zebra* must
--be running before invoking *fabricd*. Also, if *zebra* is restarted then *fabricd*
--must be too.
-+*fabricd* accepts all common invocations (:ref:`common-invocation-options`) and
-+the following specific options.
-+
-+.. program:: fabricd
-+
-+.. option:: --dummy_as_loopback
-+
-+   Treat dummy interfaces as loopback interfaces.
-+
-+*fabricd* needs to acquire interface information from *zebra* in order to
-+function. Therefore *zebra* must be running before invoking *fabricd*. Also, if
-+*zebra* is restarted then *fabricd* must be too.
- 
- Like other daemons, *fabricd* configuration is done in an OpenFabric specific
- configuration file :file:`fabricd.conf`.
-Index: b/isisd/isis_circuit.c
-===================================================================
---- a/isisd/isis_circuit.c	2025-03-07 11:09:47.700424235 +0100
-+++ b/isisd/isis_circuit.c	2025-03-07 11:09:47.698424233 +0100
-@@ -491,16 +491,17 @@
- {
- 	struct connected *conn;
- 
--	if (if_is_broadcast(ifp)) {
-+	if (if_is_loopback(ifp) || (isis_option_check(ISIS_OPT_DUMMY_AS_LOOPBACK) &&
-+				    CHECK_FLAG(ifp->status, ZEBRA_INTERFACE_DUMMY))) {
-+		circuit->circ_type = CIRCUIT_T_LOOPBACK;
-+		circuit->is_passive = 1;
-+	} else if (if_is_broadcast(ifp)) {
- 		if (fabricd || circuit->circ_type_config == CIRCUIT_T_P2P)
- 			circuit->circ_type = CIRCUIT_T_P2P;
- 		else
- 			circuit->circ_type = CIRCUIT_T_BROADCAST;
- 	} else if (if_is_pointopoint(ifp)) {
- 		circuit->circ_type = CIRCUIT_T_P2P;
--	} else if (if_is_loopback(ifp)) {
--		circuit->circ_type = CIRCUIT_T_LOOPBACK;
--		circuit->is_passive = 1;
- 	} else {
- 		/* It's normal in case of loopback etc. */
- 		if (IS_DEBUG_EVENTS)
-Index: b/isisd/isis_main.c
-===================================================================
---- a/isisd/isis_main.c	2025-03-07 11:09:47.700424235 +0100
-+++ b/isisd/isis_main.c	2025-03-07 11:09:47.698424233 +0100
-@@ -80,9 +80,12 @@
- 	.cap_num_p = array_size(_caps_p),
- 	.cap_num_i = 0};
- 
-+#define OPTION_DUMMY_AS_LOOPBACK 2000
-+
- /* isisd options */
- static const struct option longopts[] = {
- 	{"int_num", required_argument, NULL, 'I'},
-+	{"dummy_as_loopback", no_argument, NULL, OPTION_DUMMY_AS_LOOPBACK},
- 	{0}};
- 
- /* Master of threads. */
-@@ -269,15 +272,16 @@
- {
- 	int opt;
- 	int instance = 1;
-+	bool dummy_as_loopback = false;
- 
- #ifdef FABRICD
- 	frr_preinit(&fabricd_di, argc, argv);
- #else
- 	frr_preinit(&isisd_di, argc, argv);
- #endif
--	frr_opt_add(
--		"I:", longopts,
--		"  -I, --int_num      Set instance number (label-manager)\n");
-+	frr_opt_add("I:", longopts,
-+		"  -I, --int_num		Set instance number (label-manager).\n"
-+		"      --dummy_as_loopback      Treat dummy interfaces like loopback interfaces.\n");
- 
- 	/* Command line argument treatment. */
- 	while (1) {
-@@ -295,6 +299,9 @@
- 				zlog_err("Instance %i out of range (1..%u)",
- 					 instance, (unsigned short)-1);
- 			break;
-+		case OPTION_DUMMY_AS_LOOPBACK:
-+			dummy_as_loopback = true;
-+			break;
- 		default:
- 			frr_help_exit(1);
- 		}
-@@ -311,6 +318,9 @@
- 	/* thread master */
- 	isis_master_init(frr_init());
- 	master = im->master;
-+	if (dummy_as_loopback)
-+		isis_option_set(ISIS_OPT_DUMMY_AS_LOOPBACK);
-+
- 	/*
- 	 *  initializations
- 	 */
-Index: b/isisd/isisd.c
-===================================================================
---- a/isisd/isisd.c	2025-03-07 11:09:47.700424235 +0100
-+++ b/isisd/isisd.c	2025-03-07 11:09:47.698424233 +0100
-@@ -116,6 +116,25 @@
- int clear_isis_neighbor_common(struct vty *, const char *id,
- 			       const char *vrf_name, bool all_vrf);
- 
-+
-+/* ISIS global flag manipulation.  */
-+int isis_option_set(int flag)
-+{
-+	switch (flag) {
-+	case ISIS_OPT_DUMMY_AS_LOOPBACK:
-+		SET_FLAG(im->options, flag);
-+		break;
-+	default:
-+		return -1;
-+	}
-+	return 0;
-+}
-+
-+int isis_option_check(int flag)
-+{
-+	return CHECK_FLAG(im->options, flag);
-+}
-+
- /* Link ISIS instance to VRF. */
- void isis_vrf_link(struct isis *isis, struct vrf *vrf)
- {
-Index: b/isisd/isisd.h
-===================================================================
---- a/isisd/isisd.h	2025-03-07 11:09:47.700424235 +0100
-+++ b/isisd/isisd.h	2025-03-07 11:09:47.698424233 +0100
-@@ -74,9 +74,11 @@
- 	struct list *isis;
- 	/* ISIS thread master. */
- 	struct event_loop *master;
-+	/* Various global options */
- 	uint8_t options;
-+#define F_ISIS_UNIT_TEST	    (1 << 0)
-+#define ISIS_OPT_DUMMY_AS_LOOPBACK (1 << 1)
- };
--#define F_ISIS_UNIT_TEST 0x01
- 
- #define ISIS_DEFAULT_MAX_AREA_ADDRESSES 3
- 
-@@ -269,6 +271,8 @@
- void isis_terminate(void);
- void isis_master_init(struct event_loop *master);
- void isis_master_terminate(void);
-+int isis_option_set(int flag);
-+int isis_option_check(int flag);
- void isis_vrf_link(struct isis *isis, struct vrf *vrf);
- void isis_vrf_unlink(struct isis *isis, struct vrf *vrf);
- struct isis *isis_lookup_by_vrfid(vrf_id_t vrf_id);
-
diff --git a/debian/patches/pve/0007-systemd-add-dependancy-to-networking.service.patch b/debian/patches/pve/0005-systemd-add-dependancy-to-networking.service.patch
similarity index 100%
rename from debian/patches/pve/0007-systemd-add-dependancy-to-networking.service.patch
rename to debian/patches/pve/0005-systemd-add-dependancy-to-networking.service.patch
diff --git a/debian/patches/pve/0007-tools-fix-daemon-starting-order-for-debian-packages.patch b/debian/patches/pve/0006-tools-fix-daemon-starting-order-for-debian-packages.patch
similarity index 100%
rename from debian/patches/pve/0007-tools-fix-daemon-starting-order-for-debian-packages.patch
rename to debian/patches/pve/0006-tools-fix-daemon-starting-order-for-debian-packages.patch
diff --git a/debian/patches/series b/debian/patches/series
index f72dce4b7ae6..985909c64c45 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,8 +1,6 @@
 pve/0001-enable-bgp-bfd-daemons.patch
 pve/0002-bgpd-add-an-option-for-RT-auto-derivation-to-force-A.patch
 pve/0003-tests-add-bgp-evpn-autort-test.patch
-pve/0004-zebra-add-ZEBRA_IF_DUMMY-flag-for-dummy-interfaces.patch
-pve/0005-fabricd-add-option-to-treat-dummy-interfaces-as-loop.patch
-pve/0006-fabricd-enable-dummy_as_loopback-option-per-default.patch
-pve/0007-tools-fix-daemon-starting-order-for-debian-packages.patch
-pve/0007-systemd-add-dependancy-to-networking.service.patch
+pve/0004-fabricd-enable-dummy_as_loopback-option-per-default.patch
+pve/0005-systemd-add-dependancy-to-networking.service.patch
+pve/0006-tools-fix-daemon-starting-order-for-debian-packages.patch
diff --git a/frr b/frr
index 35e662efa7cc..88f5c06cbc1c 160000
--- a/frr
+++ b/frr
@@ -1 +1 @@
-Subproject commit 35e662efa7cc9ef3e97a253368950cc1a58f3bc1
+Subproject commit 88f5c06cbc1cc4d62e1cba3e7791f5cea4179ba5
-- 
2.47.3



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH frr 2/2] d/changelog: bump package version

[Gabriel Goller]

Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
---
 debian/changelog | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 40637c4e839b..197043f2eed6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+frr (10.4.1-1+pve1) UNRELEASED; urgency=medium
+
+  * update upstream source to 10.4.1
+
+ -- Proxmox Support Team <support@proxmox.com>  Fri, 21 Nov 2025 11:52:56 +0100
+
 frr (10.3.1-1+pve4) trixie; urgency=medium
 
   * do not enable/start frr systemd service on initial installation or update,
-- 
2.47.3



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1

[DERUMIER, Alexandre via pve-devel]

[-- Attachment #1: Type: message/rfc822, Size: 15823 bytes --]

From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1
Date: Tue, 25 Nov 2025 16:53:06 +0000
Message-ID: <303fec039b8faa7ae3b78e3872e142e4ff304dcb.camel@groupe-cyllene.com>

Hi, 

10.4.2 has been released last week.


be carefull with frr updates, from my experience they are always to a
lot of bugs && regression when new major version is release,
and sometime it take weeks to triggers specific bugs in production.
(and even more to debug)

and frr still maintain 10.2 branch for example (10.2.5).


Personnaly, for my pve9 production, I'll pin my frr version to 10.2,
because I don't have time to retest new version each 6 months.



-------- Message initial --------
De: Gabriel Goller <g.goller@proxmox.com>
Répondre à: Proxmox VE development discussion <pve-
devel@lists.proxmox.com>
À: pve-devel@lists.proxmox.com
Objet: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1
Date: 21/11/2025 15:13:21

Bump FRR to 10.4.1, we do this for two reasons:
 * we can drop two patches, which have been merged upstream
 * fix the libyang errors in the journal
 * try to update a bit more frequently (maybe always one minor version
behind
   upstream would be nice), so that we can avoid the fallout of
updating two
   major versions (8->10) again.

Went through the changelog quite thoroughly, didn't find anything that
could
cause an issue. Tested it on a few clusters I had lying around (ospf,
fabricd(ip4 and ip6), bgp+evpn) and didn't notice anything off. Stefan
said
he'd test on his clusters next week as well. Would be nice if we get it
in
early so that we have a nice long testing period.

frr:

Gabriel Goller (2):
  bump frr to 10.4.1, remove obsolete patches
  d/changelog: bump package version

 debian/changelog                              |   6 +
 ...ummy_as_loopback-option-per-default.patch} |   0
 ...A_IF_DUMMY-flag-for-dummy-interfaces.patch | 125 -----------
 ...on-to-treat-dummy-interfaces-as-loop.patch | 206 ------------------
 ...dd-dependancy-to-networking.service.patch} |   0
 ...-starting-order-for-debian-packages.patch} |   0
 debian/patches/series                         |   8 +-
 frr                                           |   2 +-
 8 files changed, 10 insertions(+), 337 deletions(-)
 rename debian/patches/pve/{0006-fabricd-enable-dummy_as_loopback-
option-per-default.patch => 0004-fabricd-enable-dummy_as_loopback-
option-per-default.patch} (100%)
 delete mode 100644 debian/patches/pve/0004-zebra-add-ZEBRA_IF_DUMMY-
flag-for-dummy-interfaces.patch
 delete mode 100644 debian/patches/pve/0005-fabricd-add-option-to-
treat-dummy-interfaces-as-loop.patch
 rename debian/patches/pve/{0007-systemd-add-dependancy-to-
networking.service.patch => 0005-systemd-add-dependancy-to-
networking.service.patch} (100%)
 rename debian/patches/pve/{0007-tools-fix-daemon-starting-order-for-
debian-packages.patch => 0006-tools-fix-daemon-starting-order-for-
debian-packages.patch} (100%)


Summary over all repositories:
  8 files changed, 10 insertions(+), 337 deletions(-)


[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1

[Gabriel Goller]

On 25.11.2025 16:53, DERUMIER, Alexandre via pve-devel wrote:
> Hi, 
> 
> 10.4.2 has been released last week.

I don't think so? At least I can't see the tag on github...

> be carefull with frr updates, from my experience they are always to a
> lot of bugs && regression when new major version is release,
> and sometime it take weeks to triggers specific bugs in production.
> (and even more to debug)

Yeah, that's exactly why I want to release every minor FRR version
(while staying one release behind). This approach should minimize
the impact when a major version is released. The big issue with PVE
8.5 was jumping from FRR 8 to 10 -- that's two major versions at
once, which caused many problems. I believe it's better to do
frequent small updates where issues are discovered quickly, rather
than large yearly updates where many problems surface at once.

What do you think about this?

That said, I understand your concerns. We've also seen FRR being
quite unstable lately with many regressions in recent releases. The
maintainers have told me this should improve going forward.

> and frr still maintain 10.2 branch for example (10.2.5).
> 
> 
> Personnaly, for my pve9 production, I'll pin my frr version to 10.2,
> because I don't have time to retest new version each 6 months.

Pinning is always possible and something the user can do. Maybe we
should create a official "guide" or article on how pin in case of
critical network bugs.
Obviously the newer features (e.g. fabrics) won't work.

I don't know how we handle other upstream dependencies that are critical
yet optional? @Thomas?

Gabriel


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1

[Thomas Lamprecht]

Am 26.11.25 um 13:58 schrieb Gabriel Goller:
> On 25.11.2025 16:53, DERUMIER, Alexandre via pve-devel wrote:
>> Hi, 
>>
>> 10.4.2 has been released last week.
> 
> I don't think so? At least I can't see the tag on github...
> 
>> be carefull with frr updates, from my experience they are always to a
>> lot of bugs && regression when new major version is release,
>> and sometime it take weeks to triggers specific bugs in production.
>> (and even more to debug)
> 
> Yeah, that's exactly why I want to release every minor FRR version
> (while staying one release behind). This approach should minimize
> the impact when a major version is released. The big issue with PVE
> 8.5 was jumping from FRR 8 to 10 -- that's two major versions at
> once, which caused many problems. I believe it's better to do
> frequent small updates where issues are discovered quickly, rather
> than large yearly updates where many problems surface at once.
> 
> What do you think about this?
> 
> That said, I understand your concerns. We've also seen FRR being
> quite unstable lately with many regressions in recent releases. The
> maintainers have told me this should improve going forward.
> 
>> and frr still maintain 10.2 branch for example (10.2.5).
>>
>>
>> Personnaly, for my pve9 production, I'll pin my frr version to 10.2,
>> because I don't have time to retest new version each 6 months.
> 
> Pinning is always possible and something the user can do. Maybe we
> should create a official "guide" or article on how pin in case of
> critical network bugs.
> Obviously the newer features (e.g. fabrics) won't work.
> 
> I don't know how we handle other upstream dependencies that are critical
> yet optional? @Thomas?

We do not have many of those. But in general I agree with releasing
more often and in smaller increments being the better way almost all
of the time.

Version pinning is not something I'd heavily promote, but having an
article/how-to that describes how it could be done and what one needs
to watch out for makes definitively sense, as sometimes it's just the
fastest and simplest stop-gap.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] applied: [PATCH frr 0/2] Bump FRR to 10.4.1

[Thomas Lamprecht]

On Fri, 21 Nov 2025 15:13:21 +0100, Gabriel Goller wrote:
> Bump FRR to 10.4.1, we do this for two reasons:
>  * we can drop two patches, which have been merged upstream
>  * fix the libyang errors in the journal
>  * try to update a bit more frequently (maybe always one minor version behind
>    upstream would be nice), so that we can avoid the fallout of updating two
>    major versions (8->10) again.
> 
> [...]

Applied, thanks!

[1/2] bump frr to 10.4.1, remove obsolete patches
      commit: 03a2853fde15a4858916f56b61f070a0ac1410e0
[2/2] d/changelog: bump package version
      commit: 309200ce8202e9f9da46055594ee41b9ce840fa7


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1

[DERUMIER, Alexandre via pve-devel]

[-- Attachment #1: Type: message/rfc822, Size: 16816 bytes --]

From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "t.lamprecht@proxmox.com" <t.lamprecht@proxmox.com>
Subject: Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1
Date: Thu, 11 Dec 2025 06:05:19 +0000
Message-ID: <9fcb92c222a931110010ae0be8d102cb4194ec99.camel@groupe-cyllene.com>

Hi, 
sorry I didn't see your message and was super busy

>>Yeah, that's exactly why I want to release every minor FRR version
>>(while staying one release behind). This approach should minimize
>>the impact when a major version is released. The big issue with PVE
>>8.5 was jumping from FRR 8 to 10 -- that's two major versions at
>>once, which caused many problems. I believe it's better to do
>>frequent small updates where issues are discovered quickly, rather
>>than large yearly updates where many problems surface at once.
>>
>>What do you think about this?

Well, It's like ceph, you don't want uncontrolled major upgrade. (Minor
are ok, because they are only backporting small patches).

so , doing it during major PVE upgrade is ok. or adding a version
handling like ceph.

The only problem is that they don't have an LTS for security upgrade


This is a criticial part of infrastructure, even more criticial than
ceph


>>That said, I understand your concerns. We've also seen FRR being
>>quite unstable lately with many regressions in recent releases. 
>>
>>>>

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)


here we go again....  :/

https://forum.proxmox.com/threads/frr-update-to-10-4-1-1-broke-external-routing.177736/


>>The maintainers have told me this should improve going forward.

don't trust them ;)





-------- Message initial --------
De: Gabriel Goller <g.goller@proxmox.com>
À: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>,
Thomas Lamprecht <t.lamprecht@proxmox.com>
Objet: Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1
Date: 26/11/2025 13:59:00

On 25.11.2025 16:53, DERUMIER, Alexandre via pve-devel wrote:
> Hi, 
> 
> 10.4.2 has been released last week.

I don't think so? At least I can't see the tag on github...

> be carefull with frr updates, from my experience they are always to a
> lot of bugs && regression when new major version is release,
> and sometime it take weeks to triggers specific bugs in production.
> (and even more to debug)

Yeah, that's exactly why I want to release every minor FRR version
(while staying one release behind). This approach should minimize
the impact when a major version is released. The big issue with PVE
8.5 was jumping from FRR 8 to 10 -- that's two major versions at
once, which caused many problems. I believe it's better to do
frequent small updates where issues are discovered quickly, rather
than large yearly updates where many problems surface at once.

What do you think about this?

That said, I understand your concerns. We've also seen FRR being
quite unstable lately with many regressions in recent releases. The
maintainers have told me this should improve going forward.

> and frr still maintain 10.2 branch for example (10.2.5).
> 
> 
> Personnaly, for my pve9 production, I'll pin my frr version to 10.2,
> because I don't have time to retest new version each 6 months.

Pinning is always possible and something the user can do. Maybe we
should create a official "guide" or article on how pin in case of
critical network bugs.
Obviously the newer features (e.g. fabrics) won't work.

I don't know how we handle other upstream dependencies that are
critical
yet optional? @Thomas?

Gabriel


[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1

[Thomas Lamprecht]

Hi,

Am 11.12.25 um 07:05 schrieb DERUMIER, Alexandre:
>>> Yeah, that's exactly why I want to release every minor FRR version
>>> (while staying one release behind). This approach should minimize
>>> the impact when a major version is released. The big issue with PVE
>>> 8.5 was jumping from FRR 8 to 10 -- that's two major versions at
>>> once, which caused many problems. I believe it's better to do
>>> frequent small updates where issues are discovered quickly, rather
>>> than large yearly updates where many problems surface at once.
>>>
>>> What do you think about this?
> 
> Well, It's like ceph, you don't want uncontrolled major upgrade. (Minor
> are ok, because they are only backporting small patches).
> 
> so , doing it during major PVE upgrade is ok. or adding a version
> handling like ceph.

If we would add versioned FRR, I'd rather use the approach from the
kernel over the one from ceph. I.e., add the version to the frr package
names and provide a meta package that depends on the default one over
having a dedicated repo like we do for ceph.

That said, I'd be prefer if we could avoid doing this, as it's not a
panacea on it's own. It adds confusion and complexity for not only us
(that can be managed) but also our users (like having more easily
multiple different FRR versions in a cluster). It can be an option
to re-evaluate though.

> The only problem is that they don't have an LTS for security upgrade
> 
> This is a criticial part of infrastructure, even more criticial than
> ceph

Definitively, but that with the potential complexity is also a reason
of seldom big updates not being ideal either.

>>> That said, I understand your concerns. We've also seen FRR being
>>> quite unstable lately with many regressions in recent releases. 
>>>
> 
> 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.

> 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 :/

>>> 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

Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1

[Gabriel Goller]

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