public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: alexandre derumier <aderumier@odiso.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH pve-common] network: disable unicast flooding on tap|veth|fwln ports
Date: Wed, 15 Sep 2021 17:33:35 +0200	[thread overview]
Message-ID: <790dd453ab8b0fab53942c7dd4b536d5285a3c00.camel@odiso.com> (raw)
In-Reply-To: <4a34d44143f1c32f38988c478698c094badbc740.camel@odiso.com>

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@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
> 





  reply	other threads:[~2021-09-15 15:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14  0:26 Alexandre Derumier
2021-09-14  6:32 ` alexandre derumier
2021-09-15 15:33   ` alexandre derumier [this message]
2021-09-15 17:09     ` Thomas Lamprecht
2021-09-16 21:48       ` alexandre derumier
2022-01-14 10:51         ` Wolfgang Bumiller
2022-01-14 11:23           ` Josef Johansson
2022-01-28  3:39             ` Josef Johansson
2022-01-14 16:50           ` DERUMIER, Alexandre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=790dd453ab8b0fab53942c7dd4b536d5285a3c00.camel@odiso.com \
    --to=aderumier@odiso.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal