all lists on 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal