Re: [pve-devel] applied-series: [PATCH pve-common 0/2] add disable bridge learning feature

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

Hi Thomas,

I'm currently on a proxmox training session this week, so I'll not have
time to work on it until next week.

BTW, I have also an pending bugfix for mtu && ovs here, but I think I
need to rebase it now that others patches are applied, so I'll rework
it for next week.

https://lists.proxmox.com/pipermail/pve-devel/2022-February/051808.html


And, If you have time, I'll like to include this patch before release
of qemu 6.2  (new balloon option free-page-reporting)
https://lists.proxmox.com/pipermail/pve-devel/2022-March/051940.html



Thanks for your time !

Alexandre

Le mercredi 16 mars 2022 à 17:33 +0100, Thomas Lamprecht a écrit :
> On 24.09.21 10:48, Alexandre Derumier wrote:
> > Currently, if bridge receive an unknown dest mac (network
> > bug/attack/..),
> > we are flooding packets to all bridge ports.
> > 
> > This can waste cpu time, even more with firewall enabled.
> > Also, if firewall is used with reject action, the src mac of RST
> > packet is the original unknown dest mac.
> > (This can block the server at Hetzner for example)
> > 
> > So, we can disable learning && unicast_flood on tap|veth|fwln port
> > interface.
> > Then mac address need to be add statically in bridge fdb.
> > 
> > 
> > Alexandre Derumier (2):
> >   network: add support for disabling bridge learning on
> > tap|veth|fwln
> >     ports
> >   Inotify: add bridge-disable-mac-learning option to bridges.
> > 
> >  src/PVE/INotify.pm |  4 +++-
> >  src/PVE/Network.pm | 60 +++++++++++++++++++++++++++++++++++++++++-
> > ----
> >  2 files changed, 57 insertions(+), 7 deletions(-)
> > 
> 
> 
> 
> applied, thanks! But I moved from the single flag to an $opts hash
> for the tap_plug
> option, nicer to use than those overly long parameter flags list,
> that often have
> lots of slightly confusing undef mixed in.
> 
> You need to adapt the calling site of the relevant open patches
> though (sorry for
> the added work).
>