Re: [PATCH network v4 1/6] sdn: evpn: enable force_forwarding for ipv6 forwarding to subnets

["Lukas Sichert" <l.sichert@proxmox.com>]

Thanks for the response, comments inline:

On 2026-08-24 09:23, Hannes Laimer <h.laimer@proxmox.com> wrote:

> On 2026-07-27 15:55, Lukas Sichert wrote:
>> +        if ($is_evpn_gateway) {
>> +            #find outgoing ipv6 interface
>> +            my ($outip, $outiface);
>> +            eval {
>> +                ($outip, $outiface) =
>> +                    PVE::Network::SDN::Zones::Plugin::get_local_route_ip('2001:4860:4860::8888');
>> +            };
>> +            if ($@) {
>> +                my $msg = "interface for IPv6 forwarding could not be resolved: $@";
>> +                log_warn($msg);
>> +            } elsif ($outiface) {
>> +                push @iface_config,
>> +                    "post-up echo 1 > /proc/sys/net/ipv6/conf/$outiface/force_forwarding";
>> +                push @iface_config,
>> +                    "post-down echo 0 > /proc/sys/net/ipv6/conf/$outiface/force_forwarding";
>
> our `ifupdown2` is shippes with `ifreload-down-changed=0`, so
> `post-down`s never run on changes (except for vxlan and vlan), so just
> deleting the subnet, will leave the `force_forwarding=1` on the
> `outiface`
>
> sdn apply does run the `post-down` for removed infterfaces, but it also
> runs all the `post-up`s again, so this works not because the `post-down`
> is not executed on delete, but because the `post-up` re-write the `1`
>
> and with a manual `ifdown`, this can actually break things
>
> we should probably drop the `post-down` here, this is at best a no-op,
> and can potentially break things. so this might generally not be the
> place to manage a shared uplinks sysctl..
>
> something like we do in pve-common with `disable_ipv6` could be an
> alternative, on apply we'd have to check if we still need it on the
> uplink interface, then either `=0` or `=1` it

Agreed, a post-up/post-down pair is not the right place to manage a
shared uplink's sysctl. As discussed off-list, the better approach
is to enable it in ifupdown2, mimicking how IPv4 forwarding is
handled: enable it when a gateway is configured or a flag is set.

>
>> +            }
>> +        }
>> +    }
>> +
>>      push @iface_config, "arp-accept on" if $ipv4 || $ipv6;
>>      push @iface_config, "vrf $vrf_iface" if $vrf_iface;
>>      push(@{ $config->{$vnetid} }, @iface_config) if !$config->{$vnetid};
>> @@ -342,6 +367,13 @@ sub generate_sdn_config {
>>              push @iface_config, "bridge_fd 0";
>>              push @iface_config, "mtu $mtu" if $mtu;
>>              push @iface_config, "vrf $vrf_iface";
>> +
>> +            if ($enable_forward_v6) {
>> +                push @iface_config,
>> +                    "post-up echo 1 > /proc/sys/net/ipv6/conf/$brvrf/force_forwarding";
>> +                push @iface_config,
>> +                    "post-down echo 0 > /proc/sys/net/ipv6/conf/$brvrf/force_forwarding";
>> +            }
>>              push(@{ $config->{$brvrf} }, @iface_config) if !$config->{$brvrf};
>
> emitting `force_forwarding` for the zone `vrfbr_` interfaces is bound to
> the first subnet defined on the vnet, if this first one happens to not be
> IPv6, `force_forwarding` is missing there

Thanks for pointing it out, I overlooked this. The 'vrfbr_' creation
happens outside of the subnet loop, but multiple vnets inside a zone
share one 'vrfbr_'. This means if the first vnet in the loop contains no
ipv6 subnet, the 'vrfbr_' does not recieve the 'force_forwarding' flag.