Re: [PATCH pve-network] sdn: zones: vxlan: restore the flood entries after an FRR reload

[Gabriel Goller <g.goller@proxmox.com>]

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]