From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 6FB651FF09C for ; Mon, 05 Oct 2026 15:13:08 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 6E99A215A9; Mon, 05 Oct 2026 15:13:06 +0200 (CEST) Date: Mon, 5 Oct 2026 15:13:00 +0200 From: Gabriel Goller To: Hannes Laimer Subject: Re: [PATCH pve-network] sdn: zones: vxlan: restore the flood entries after an FRR reload Message-ID: References: <20260929092845.189004-1-h.laimer@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20260504 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791205981582 X-SPAM-LEVEL: Spam detection results: 0 AWL -2.207 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_DBL_SPAM 5 Contains a spam URL listed in the Spamhaus DBL blocklist [sdn.pm] Message-ID-Hash: MHIMTBX2LO7QTJ7U7HYYT2YQT5HDLB5V X-Message-ID-Hash: MHIMTBX2LO7QTJ7U7HYYT2YQT5HDLB5V 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 05.10.2026 15:01, Hannes Laimer wrote: > On 2026-10-05 14:31, Gabriel Goller wrote: > > On 29.09.2026 11:28, Hannes Laimer wrote: > >> [snip] > >> diff --git a/src/PVE/Network/SDN.pm b/src/PVE/Network/SDN.pm > >> index 33a3cf3..42af00d 100644 > >> --- a/src/PVE/Network/SDN.pm > >> +++ b/src/PVE/Network/SDN.pm > >> @@ -492,7 +492,12 @@ sub generate_frr_config { > >> my $raw_config = PVE::Network::SDN::generate_frr_raw_config($running_config, $fabric_config); > >> PVE::Network::SDN::Frr::write_raw_config($raw_config); > >> > >> - PVE::Network::SDN::Frr::apply($needs_restart) if $apply; > >> + return if !$apply; > >> + > >> + PVE::Network::SDN::Frr::apply($needs_restart); > >> + > >> + # zebra removes a VXLAN zone's static flood entries with the VTEPs it withdraws > >> + PVE::Network::SDN::Zones::restore_vxlan_flood_entries(); > > > > Hmm so this is tricky, on reload bgpd tells zebra to remove these changes > > and zebra enqueues this to the dplane, so this is asynchronous in many > > ways. So we can't guarantee that the entries have been removed when running > > restore_vxlan_flood_entries(). > > > > yes, this is unfortunately not something we can guarantee. restart > happens already at the end of FRR::apply, we could force a `reload` of > there is a removed evpn controller and an existing vxlan zone. I'm not > sure there is a difference for this here tough.. Hmm the problem is with the reload though isn't it? A restart would simply kill all the daemons and zebra on startup doesn't nuke the fdb entries right? > > Not sure what we could do here. > > > > Three options that came to my mind where: > > 1) sleep(5) > > not sure what kind of timeframes are realistic here, since we can't > guarantee anything anyway, something like 1s is probably enough. but in > my (limited) testing i also couldn't hit this without any sleep > > > 2) `bridge monitor fdb` before running the frr reload/restart and then check if the entries have been removed (kind of overkill) > > we still wouldn't know how long to wait.. True. At least we could shortcut it when they are gone. > > 3) force a frr restart (not 100% sure if this works) > > ideally we could just tell frr 'hands off these VNIs..', but we can't, > and given `advertise-all-vni` that might also be weird/wrong to begin > with Yeah, don't think thats possible. But IMO forcing a restart when advertise-all-vni is removed wouldn't even be so bad. Of course that would break other connections the user has open. > >> } > >> > >> sub generate_dhcp_config { > >> diff --git a/src/PVE/Network/SDN/Zones.pm b/src/PVE/Network/SDN/Zones.pm > >> index f668303..2c3c69c 100644 > >> --- a/src/PVE/Network/SDN/Zones.pm > >> +++ b/src/PVE/Network/SDN/Zones.pm > >> @@ -178,6 +178,24 @@ sub generate_etc_network_config { > >> return $raw_network_config; > >> } > >> > >> +sub restore_vxlan_flood_entries { > >> + my $raw_config = eval { PVE::Tools::file_get_contents($local_network_sdn_file) }; > >> + return if !defined($raw_config); > > > > Maybe an error here would be nice instead of a silent return. Although this > > probably can't happen anyway... > > > > yeah, not really an error imho.. but a warning should be fine, > because the caller assumed there is a config file > > > thanks for taking a look! :) > > >> + > >> [snip]