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

alexandre derumier aderumier at odiso.com
Wed Sep 15 17:33:35 CEST 2021


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.

I'm going to do tests, testing vlan aware && live migration too.




Le mardi 14 septembre 2021 à 08:32 +0200, alexandre derumier a écrit :
> Thinking a little bit more about this,
> I think we should add an option in vm/ct nic options, to enable it.
> 
> It could break some network where arp timeout is bigger than default
> brige ageing-time (5min by default), or with special asymetric
> networks.
> 
> 
> Le mardi 14 septembre 2021 à 02:26 +0200, Alexandre Derumier a écrit :
> > 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 unicast_flood on tap|veth|fwln port interface.
> > bridge will learn mac address of the vm|ct, when it send traffic
> > or when It'll reply to arp requests coming from outside.
> > 
> > Signed-off-by: Alexandre Derumier <aderumier at odiso.com>
> > ---
> >  src/PVE/Network.pm | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/src/PVE/Network.pm b/src/PVE/Network.pm
> > index 15838a0..119340f 100644
> > --- a/src/PVE/Network.pm
> > +++ b/src/PVE/Network.pm
> > @@ -207,6 +207,12 @@ sub disable_ipv6 {
> >      close($fh);
> >  }
> >  
> > +my $bridge_disable_interface_flooding = sub {
> > +    my ($iface) = @_;
> > +
> > +   
> > PVE::ProcFSTools::write_proc_entry("/sys/class/net/$iface/brport/unic
> > ast_flood", "0");
> > +};
> > +
> >  my $bridge_add_interface = sub {
> >      my ($bridge, $iface, $tag, $trunks) = @_;
> >  
> > @@ -334,6 +340,7 @@ my $create_firewall_bridge_linux = sub {
> >      veth_create($vethfw, $vethfwpeer, $bridge);
> >  
> >      &$bridge_add_interface($fwbr, $vethfw);
> > +    &$bridge_disable_interface_flooding($vethfw);
> >      &$bridge_add_interface($bridge, $vethfwpeer, $tag, $trunks);
> >  
> >      &$bridge_add_interface($fwbr, $iface);
> > @@ -359,6 +366,7 @@ my $create_firewall_bridge_ovs = sub {
> >      PVE::Tools::run_command(['/sbin/ip', 'link', 'set', $ovsintport,
> > 'mtu', $bridgemtu]);
> >  
> >      &$bridge_add_interface($fwbr, $ovsintport);
> > +    &$bridge_disable_interface_flooding($ovsintport);
> >  };
> >  
> >  my $cleanup_firewall_bridge = sub {
> > @@ -406,6 +414,7 @@ sub tap_plug {
> >         } else {
> >             &$bridge_add_interface($bridge, $iface, $tag, $trunks);
> >         }
> > +       &$bridge_disable_interface_flooding($iface);
> >  
> >      } else {
> >         &$cleanup_firewall_bridge($iface); # remove stale devices
> 






More information about the pve-devel mailing list