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

[Wolfgang Bumiller <w.bumiller@proxmox.com>]

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).