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

["DERUMIER, Alexandre" <Alexandre.DERUMIER@groupe-cyllene.com>]

Hi Wolfgang,
Thanks for reviewing this.

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

bridge_learning && unicast_flood should be keep "on" on physical
interfaces. (bridge need to forward unknown dest mac to the outside
world and register macs when they coming from outside).

bridge_learning && unicast_flood can be set "off" on the vms.
(and we need to register manually mac address in bridge fdb)
https://lists.proxmox.com/pipermail/pve-devel/2021-September/050089.html
This avoid to flood unknown mac traffic from vmbr0 to vm tap or fwbr
bridge. 



if bridge_learning && unicast_flood is disabled on all vms ports,
and that we only have 1 interface (the physical etX) with
bridge_learning on, prosmic mode is disabled on the bridge.
That mean than traffic with wrong mac, will not enter to the server.


So, this is more secure, but in this case it make more sense to have a
global option instead vm by vm option.

That's why I have added a custom  "bridge-disable-mac-learning" global
bridge option in this patch:
https://lists.proxmox.com/pipermail/pve-devel/2021-September/050088.html



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

AFAIK, the only problem is if user have multiple mac addresses inside
the vms that we don't known (mainly nested virtualisation).


Vmware have a simple option "promisc" on/off on the vswitch (and I
think it's off by default, they register manually mac). And it need to
be disable when they need to do nested virtu.