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 8E0CF1FF09C for ; Mon, 05 Oct 2026 15:32:33 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id B51B9215AE; Mon, 05 Oct 2026 15:32:30 +0200 (CEST) Message-ID: Date: Mon, 5 Oct 2026 15:32:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH pve-network] sdn: zones: vxlan: restore the flood entries after an FRR reload To: Gabriel Goller References: <20260929092845.189004-1-h.laimer@proxmox.com> From: Hannes Laimer Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791207146091 X-SPAM-LEVEL: Spam detection results: 0 AWL -3.162 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: PINPD6BBRSGPNQIZNFBJYI5RP43V4QQ5 X-Message-ID-Hash: PINPD6BBRSGPNQIZNFBJYI5RP43V4QQ5 X-MailFrom: h.laimer@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 2026-10-05 15:13, Gabriel Goller wrote: > 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? > actually not sure, we did write the frr config already at that point, but without the controller.. no, i guess, as you say it shouldn't >>> 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. yes, but as you said, a (or no) sleep is probably better here > >>> 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. that would actually work i think.. could be seen as an unnecessary one though, depending how easily the "remove after our add" would actually be hit.. > >>>> } >>>> >>>> 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]