Re: [pve-devel] [PATCH pve-common] network: disable unicast flooding on tap|veth|fwln ports

[Josef Johansson <josef@oderland.se>]

On 1/14/22 11:51, Wolfgang Bumiller wrote:
> On Thu, Sep 16, 2021 at 11:48:15PM +0200, alexandre derumier wrote:
>> Le mercredi 15 septembre 2021 à 19:09 +0200, Thomas Lamprecht a écrit :
>>> On 15.09.21 17:33, alexandre derumier wrote:
>>>> I have looked at other hypervisors implementations (as it don't see
>>>> to
>>>> have problem with hetzner),
>>>>
>>>>
>>>> https://listman.redhat.com/archives/libvir-list/2014-December/msg00173.html
>>>>
>>>>
>>>> https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-C5752084-A582-4AEA-BD5D-03FE5DBC746E.html
>>>>
>>>>
>>>> Both vmware && libvirt have a mode to manually manage fdb entries
>>>> in
>>>> bridge mac table.
>>>>
>>>> This will work if only 1mac is behind 1 nic, so it should be an
>>>> option
>>>> (nested hypervisor for examples).
>>>>
>>>> but for classic vm , it could allow to disable unicast_flood &&
>>>> learning for the tap interface, but also promisc mode on tap
>>>> interface!
>>>>
>>>> I was think about add an option on vmbrX  or vnetX directly to
>>>> enable/disable.
>>> As this would be on the VM tap devices it would sound somewhat
>>> reasonable to
>>> have it as per vNIC setting, but naturally it would then be a bit
>>> annoying to
>>> change for all; a tradeoff could be to allow setting the default
>>> value per
>>> bridge, node or datacenter (I'd do only one of those).
>>>
>>> What do you think?
>>>
>> I have done test, I think the best way is to enable it on the bridge
>>  or vnet for sdn.
>> because ovs don't support it for example, or its not needed for routed
>> setup or vxlan.
>> I don't known too much where add this option for classic vmbr ? in
>> /etc/network/interfaces ?.
>> I can't reuse bridge-unicast-flood off, bridge-learning off on vmbr
>> with ifupdown, because it's apply on all ports (ethX), and we don't
>> want that.
>> I could add a custom attribute, but I need to parse
>> /etc/network/interfaces in this case  for the tap_plug sub. 
> As far as I can tell, ifupdown2 only applies this to the ports it knows
> about, so in theory we *could* start to honor this for the interfaces we
> crate for VMs as a default, and have an on/off/auto value on VM network
> interfaces (override or use whatever /e/n/interfaces says).
>
> Or do you mean you typically want this to be on for VMs but off
> specifically for the physical port? Then /e/n/interfaces won't fit.
>
> Although it *does* allow listing ports and doesn't seem to mind if a
> port does not exist, so we *may* get away with saying we expect
> something like this:
>
>     bridge-unicast-flood eth0=on _pve=off
>
> Either way, it's a port setting, so I wonder a by-vm-interface optional
> override probably makes sense, not sure (but would be easy enough to
> do).
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>

Maybe something along the lines of

--- Network.pm	2021-05-25 16:35:27.000000000 +0200
+++ Network.pm.new	2022-01-14 12:20:48.181632198 +0100
@@ -309,6 +309,7 @@ sub veth_create {
     disable_ipv6($vethpeer);
     &$activate_interface($veth);
     &$activate_interface($vethpeer);
+    PVE::Tools::run_command(['/sbin/bridge', 'link', 'set', 'dev', $vethpeer, 'flood', 'off']);
 }
 
 sub veth_delete {


This is basically what I do right to solve this problem. I leave everything else with unicast_flood on.
I do not use ovs yet, so basic bridging.

If I enable it on fwln some ARP-functionality stops working.

Regards
Josef